Agile Transformation - Coaching needs and requirements

Having been involved in Agile for over 10 years, and for most of these years I have  helped organizations switch to Agile, I have (I believe) a great grasp of what needs to happen when your organization decides to 'Go Agile'. Yes the larger the organization the more that the organizational change element is brought in to the mix, and for this post I want to focus on the elements of Agile coaching as it relates to these larger transformation efforts, which with SAFe is a hot area of growth for Agile consulting.

With the large Agile transformations I've been involved with I have identified what I believe are the three main types of coaches you are likely to come across in an Agile transformation:

1. Those that have had experience in the trenches, who have led Scrum teams, built the products that are delivered to the business.
2. Those that have primarily been involved with Agile 'transformations' at the management level.
3. Those that have taken the necessary courses to 'become' Agile and may have been  a Project Manager in another life. (I'm not denigrating PM's as I was a PM who first experienced Agile from this perspective, I'm rather saying that there are coaches who haven't actually been involved with Agile, but have gone out and obtained Agile certifications, making them 'look' like people who have the right 'credentials' when people who don't know Agile are looking to hire coaches)

Let's talk about what each one brings to the table and what you need to look for when bringing on a coach to support your specific Agile transformation.

1. Coaches from the Trenches
   1. Key Benefits- These individuals bring a wealth of experience with how to operationalize Agile. They get it, they believe in it and they now what works, how to make course corrections when something isn't working AND they have huge levels of creditability with technical teams.  They talk the talk and can walk the walk.
   2. Key Weaknesses - If there is one the weakness with this type of coach is that in larger scaled Agile transformations, there are very specific processes and formats that get rolled out to the entire organization so that everyone is doing the same thing.  Sounds right doesn't it?  This individual will want to work out what works for their team and not always align to the Transformation processes, causing frustration between the coach and the group leading the transformation.
   3. Things to think about - Agile is not like making cars where every production line making car X has to be doing the same thing so that you maximize the speed of the process and build in your quality and productivity INTO the process.  Agile isn't like that, rather Agile is a framework that should allow for each Scrum team the flexibility to determine WHAT works for them without being prescriptive.
      1. My Input When I am helping an organization move to Agile I like 'sprinkle' the framework and tenants of Agile to the teams and then let the teams iterate on the process that works for them.  I give them the things I look for to determine how they are doing, such as stable velocity, good backlog and effective and accurate estimation (which of course feeds the stable velocity).  The 'from the Trenches' individual is one who will succeed very will in this type of environment and not very well in an extremely structured Agile process.
2. Coaches who were Managers - These individuals have typically seen their organization have success with Agile and have made the decision to move into an Agile career.
   1. Key Benefits - As with the from the Trenches coach, this individual does 'get it' and has an ability to gain creditability with upper management and can convey the higher level benefits to them.  This individual talks the talk of management and understands how to get in the head of management to help them understand their responsibilities in helping a transformation succeed.
   2. Key Weaknesses - So far I see way more of these individuals as coaches than I do the in the trenches coaches.  This can cause issues because they can sometimes tend to take a more hands off approach in working with their teams and don't have the experience nor creditability to work with the technical teams in a direct manner.  They simply don't have the technical and Agile chops to help the team grow and aren't as adept and making course corrections to the process.  Here you are seeing the effects of Top down driven Agile over bottom up (which I'm more a proponent of).
   3. Things to Think about - Consider having these types of coaches run more of the program level coaching, working more closely with upper management to help them mature in their thinking and protect the teams as they figure out how to be successful in their Agile processes.
3. Certification Coaches - As I indicated these are the people who have been involved with software development for many years, perhaps in the project management career path and have taken Certified Scrum Master classes and maybe Certified Product Owner.  Though they understand 'software development' they don't, IMHO, understand Product Development and all that this implies in an Agile world.
   1. Key Benefits - Of the three types of coaches, these individuals probably offer the least from a benefits perspective if expected to lead an Agile transformation effort.  These types of individuals understand the basics of Agile and run teams from that perspective.  Not having worked in the trenches they haven't yet had the opportunity to deal with real world Agile and the challenges it presents.  This is not to say that these individuals don't have the skills, knowledge or capabilities to be great coaches but what I am saying is that if you have a large number of coaches fall into this group then your PD teams will be at a disadvantage and this individual will struggle to gain creditability with their Scrum teams and your Agile adoption will fail.
   2. Key Weaknessess - As stated above, these coaches tend to not yet have the creditability or depth of knowledge to be as effective as coaching types 1 and 2, they will need to be partnered with more experienced coaches to enable them to be successful and grown their Agile skills.
   3. Things to Think about - Look for people who can demonstrate servant leadership in their past experience, this is a key behavior of successful PM's, Tech Leads and Managers.  I believe my success in Agile is primarily due to the fact that I am a servant leader by nature.

When you go looking for coaches consider your organizations size, current development maturity and honest assessment of the problems you face with your current Product Delivery processes.  And I do mean HONEST, if you can't take honesty then Agile is not for you.  The Continuous Improvement element of Agile demands honesty and if you are an organization that doesn't want to hear that you PD teams have issues then you will continue to have a less efficient model of delivering value to your customers (and isn't that what ALL of this is really about?)

These will provide you insight into what you will need to move towards Agile.

Also try to avoid labeling your coaches when they come in such as that one is our BDD expert, that one is our blah blah expert. This will tend to keep other coaches from participating and sharing their skills for a specific area and ensure that you processes for that specific area of expertise will suffer ( I speak from experience on this one ).

Agile Discovery - Addressing fixed date/scope projects through upfront planning

Most of the Agile projects (perhaps all) that I have worked on over the years have started with an express understanding of scope AND a fixed date for the delivery.  One of the common myths I think people have about Agile is that when you 'go' Agile this issue goes away, it doesn't. By ignoring the need for some level of planning prior to taking on an Agile project, teams start with a deficit of knowledge (ie well groomed story backlog).

I'm a huge proponent of having teams take on their project backlog with an initial Discovery workshop that includes the entire team and can take anywhere from 1-5 days depending upon the size and scope of the project being considered.

I've used this approach to plan out a 6 month release with tremendous success, typically delivering more value than the stakeholder asked for and with virtually no defects.

I think this planning effort is key for teams to realize high levels of iteration productivity.  The time to build context in your stories and features is not after the iteration (or train) has left the station.

Many of you, especially Product Owners, will make the assumption that it's a waste of time for the team to perform a Discovery session that builds out stories and acceptance criteria at a lower level for more than an iteration out.  The concern that everyone has is that if we don't start coding immediately we'll be behind and won't make our commitment.  The truth?  Having a user story backlog that is well formed and understood by the team allows the team to stay focused and productive over trying to design and address context while trying to actually code the feature.

What do I mean by Discovery?

Once a team receives a project from their stakeholders with a set date for delivery, the 'scope' of the project then becomes the key to meeting the delivery expectations.

If the team just starts coding with the first few stories that are available they are already in story deficit, they don't have enough work to keep the iteration engine going, meaning Backlog Grooming, Pre-Iteration Planning and Current Iteration planning.  High functioning Agile teams understand that the iteration engine only works when you have a product backlog that is clearly prioritized, has sufficient context and can be worked on with no real impediments.

For example if a team has a six month project which consists of 12 two week iterations the team needs to identify the following:

• Story Themes - What are the functional slices of the features/product you are delivering.  Themes form the basis for building your release plan.  Themes will hold the high level user stories that are identified in Discovery, typically greater than 40 points.
• Epics - These are the larger User Stories that are identified during discovery as they relate to the Story Themes.  These will typically be larger than 40 points.
• Features - As Epics are decomposed they are further brought into focus as distinct features that can be worked on a independent units of work.  Features will typically be sized between 21-40 points and have a much greater shared understanding by the team of what it will take to deliver this.
• User Stories - As teams continue to decompose Features that are able to get to the granular set of work, complete with Acceptance Criteria (such as BDD).  These are the items that are addressed in iteration planning.

My experience over the years has seen teams be able to spend anywhere from 2-5 days working through the Themes, Epics and Features such that we have a strong understanding of how the project will unfold from a release standpoint and a lower level set of Features and User Stories that help UX work ahead of the Delivery team.  This process has proven successful for the teams I've worked with who have tried it.

I'm not suggesting that an entire 12 iteration project needs to be flushed out to the user story task level, however getting further than the Epic level with a few features and a few stories will allow teams to be very focused on iteration level delivery on a consistent basis.

This effort can provide a higher level confidence level for the team with a small spike of investment in upfront planning.

Planning is an important element of successful Agile teams, don't short change it when working through new features/functionality.