Author: Joseph Sacco
April 23, 2109
I have been in the IT consulting business for the past 5 years or so and more recently working for one of the largest Cloud providers as an Engagement Manager. Prior to that I was involved in managing projects and programs within the corporate environment, where most of my stakeholders were fellow employees. When I started with my current employer two years ago they had a pretty much do whatever you want approach to managing engagements. In the past year the consulting organization has been going through an agile transformation to Scrum with some customization’s that make it unique to our company. Having used Scrum in both a consulting and non consulting capacity I wanted to outline some of the challenges you face using an agile approach to delivery and specifically Scrum when you are a consultant.
Challenge #1 Startup
Those of who have a consulting background can relate to this. The statement of work (SOW) is signed and the customer says can we start next week on Monday? What about agile tools? What about time to on board the team? What about an internal kickoff meeting? Anyways this is typically a pretty chaotic situation. As a consultant you either bring your own agile tools or you use the customer’s, in either case you need to setup Jira, Rally, VSTS, or whatever tool of your choice. If the customer wants you to use their agile tool and you have not used it in the past then you have a learning curve to deal with. In almost all cases there is no backlog so some form of planning meeting needs to occur to define the goals of the engagement and get an initial backlog setup. You will also need to identify your stakeholders and figure out who the core project team members are. The real challenge here is that you will need to do all of this in the first week and then the expectation is that Sprint 1 starts the next week. You are likely to have issues as you on board the team because they need access to email, calendars, wireless network, and various other systems or databases. From an agile perspective the backlog you walk into Sprint 1 with will most likely be lacking in many ways. Your user stories may at best a vague description of what needs to be accomplished without acceptance criteria, estimates, owners, and tasks. So what can you do about this compressed timeline for initiating your engagement:
- Try to buy some time by getting some of the planning done before you go onsite. Start your stakeholder identification and determine who will constitute your core team. Make sure you understand who your Project Sponsor is and figure out who would be the Product Owner.
- If you have done a similar project try to re-use some of that backlog on the new project.
- Find out who is responsible for on boarding your team at the customer site and make those requests.
- Determine ahead of time what agile tools you will be using and determine if you need to bring your own or preferably use what the customer already has.
Challenge #2 Relationships
I’ll use the term stakeholders to mean anyone affected by the project. The funny thing about consulting at least where I work is, you often don’t know your own team members prior to the start of an engagement and most of the time you don’t know any of the customers. So you need to figure out very quickly who will be working on various work streams and start building a relationship with your team members from your company and team members from the customer, not to mention the product owner and project sponsor. I’m not saying this never exists in a non consulting situation where you are an employee and doing the project for your organization, but if you have been there very long you are a bit more likely to know at least some of the project stakeholders. The real challenge here is almost everyone on the engagement is working together for the first time, so you better understand how to quickly move through the stages of forming a team and be pretty good at building trust with your team and the customer.
Challenge #3 Maturity
I’m referring to the customer’s maturity with agile and Scrum. As a consultant you are likely to experience the gambit when it comes to a customer’s experience using frameworks like Scrum. The same lack of experience not only exists with the customer, but also with your own team. This isn’t so much unique to consulting, but you will need to assess the customer’s capability early on in the process, so you can determine how much coaching will need to take place, and to what degree they are capable of fully embracing all of the ceremonies. An example of this might be the retrospective. If they have never conducted retrospectives they may not understand the purpose and approach the meeting with in a guarded fashion versus one of transparency. Another issue I run into all the time are customers who have not performed story point estimating and want to equate these estimates to hours or days. In either case you will need to do a lot of teaching and coaching to get these teams up to speed quickly so you can take advantage of what these ceremonies have to offer. Most of the consulting engagements that I am involved in range anywhere from 3 to 6 months and require you to take your team from forming, storming, norming, and performing very rapidly as customer expectations are that you will be producing at maximum efficiency in a short period of time.
Challenge #4 Level of Engagement
I have encountered this a number of times and it can be difficult to overcome depending on who is your Sponsor or Product Owner in the event you have one. Some organizations think well I’ve hired these consultants so they often don’t understand why they need to be so involved. I mean I’ve outsourced this project haven’t I? They say things like I want you to tell me what to do, be prescriptive, that’s what I’m paying you for. Let’s be real, projects don’t go well without stakeholder involvement and ultimately if the customer shirks this responsibility they will come back to you later on with various complaints about how you missed requirement A or B. You will need to understand how to escalate to the right people or this thing will come off the rails. I’ve worked in organizations where the management team would not come to the Sprint Review and we spent the time doing demos for the core project team. I’m not saying none of this happens with internal projects, but it can often be an issue during a consulting engagement. You will need to identify your stakeholders from the start and set expectations with them, and if you don’t get the level of participation you need then escalate, escalate, and escalate some more!
Challenge #5 Money
One of your good friends in a consulting sales role crafts an SOW with either a lot of vague statements or a list of deliverables a mile long and a budget that supports about 1/2 of what is promised. In most corporate settings you are not held to some ridiculous budget that was negotiated by upper management and procurement. At most you will go through an internal change control process where more internal funds will be allocated, because after all they don’t consider it real money. This is bullshit of course but for some reasons salaries don’t seem to count in most corporations. On the other hand the cost of a consulting engagement will be scrutinized and negotiated by a number of people. Of course consulting companies put language in the contracts that say something like this: “We will assist the customer to deliver X or Y based on the number of hours or days in the SOW”. The problem is that doesn’t change your customers expectations and won’t help you when they call your boss and say you haven’t delivered what they expect. From a budget perspective you will nearly always be having too little budget to accomplish all the scope. Scrum will help you if you have a well estimated and prioritized backlog and begin talking about minimal viable product (MVP) from the beginning of the engagement, but no matter how skilled you are at this you will always be have a supply and demand equation that is not equal. Coaxing another $500,000 out of a customer who only budgeted $400,000 to begin with will be nearly impossible. I’m not talking about some lack of project management budgeting and tracking here. The reality is you will be asked to execute engagements that are flat out underestimated and not adequately funded. Welcome to consulting!
Challenge #6 ScrumMaster vs. Project Manager
In a corporate setting that has adopted Scrum your role as a ScrumMaster can at least lean towards actually being a ScrumMaster, on the other hand when you are a consultant you are often pulled between the ScrumMaster role and that of a Project Manager. Here are a few situations that make you feel the push and pull between the ScrumMaster role and that of a more traditional Project Manager:
- The customer early on in the engagement wants a schedule showing when the deliverables are to be completed and when the project is complete. Without even a decent backlog you are scrambling to come up with some kind of high level timeline and you go from ScrumMaster to Project Manager in a heart beat.
- Instead of relying on the daily scrums, sprint reviews, and retrospectives the customer wants a weekly status report where you have to re-iterate everything that was shown in the sprint review or discussed at the daily scrum. Welcome back to 1990 and you end up spending 3 or 4 hours cranking out another status report week after week.
- As funding is finite on a consulting engagement you will be encouraged to drive your team to achieve the goals of the project with a do whatever it takes type of guidance. Some of the agile values like team autonomy, fostering experimentation, and taking risks can go right out the window under the pressure to just drive the team and get it done. You go from being a team builder and facilitator to a hard ass dictator (Project Manager).
In my experience customers want you to say you are using agile methods and frameworks like Scrum but in reality their actions send a much different message. Face it you will end up playing a hybrid role somewhere between a ScrumMaster and Project Manager. It’s up to you to justify why you need the right people to attend the Sprint Review, having a backlog that drives higher level estimates, and why your team needs to be empowered to make their own decisions. Often only your ability to communicate effectively and establish relationships stand between your engagement being agile or waterfall.
Summary
None of this probably comes to a surprise to any of you who have been consulting for more than a couple of years. Some of these issues can come up with a waterfall project and can have equally devastating results. However with that said using an agile framework like Scrum requires a level of understanding and participation that is unparalleled in many ways. To a large degree your success will be based on your expertise and ability to adapt to one new situation after another.
I would like to know what challenges you have faced using Scrum or another agile framework on a consulting assignment.
AgileMethods.blog 