10 Steps to Enterprise Agile Transformation – Not for the Faint of Heart!

Considering taking on an Agile transformation for your enterprise? Warning – it is not for the faint of heart! There is an easy way – just rename your existing process to “Agile Waterfall”. Then enjoy many subsequent years of … (wait for it) … slow-to-market unimpressive products with poor business results, as your team’s esprit de corps nosedives amidst continuous frustration. Credit: codesqueeze.com “101 Ways to Know Your Software Project is Doomed”. 

Bad news first? An Agile transformation is not easy. The good news: it is not impossible, and has been done successfully by many companies – some out of desperation, some out of a need to remain competitive, and others out of a desire to leave their dastardly competition in the dust.

Let’s talk about what is typically involved in an enterprise Agile transformation. Your experiences may be different. The list below is relevant for any size company, small, medium or large, start-up or existing.

1. Start with an “eyes wide open” introspective. Ask yourself “What problems do we think Agile will solve?” Then challenge yourself and the leadership team by playing Devil’s Advocate – where is the specific fact-based evidence that Agile can solve our problems? If you find it, then proceed ahead… cautiously!
2. Form an Agile Champions team. This team has the responsibility to define the transformation goals, map out a realistic transformation strategy, define the execution steps, formulate measurement collection, and guide the enterprise in its overall transformation to Agile.
3. Take the time to define your Agile transformation goals and gather baseline data. These goals should be specific and measurable. The following table shows a few examples:

This effort is not just writing down words! It involves a lot of soul-searching. Are the attributes truly the ones we should measure? Are the goals actually achievable? It involves collecting data to establish your baseline. For example, you might have to collect data from the business showing that your average time-to-market for any new product is 14 months. You might have to research your product database to determine that over the last 10 years we have launched an average of 1.2 products/year. You may have to run a ginormous Bugzilla report showing that 32 critical field issues are reported every month on average for every product.

You may also find that you just don’t have the data, or it is too effort-intensive to collect. While real data is certainly preferred, you can establish a soft baseline of sorts by forming a consensus opinion around the relevant metrics (described in your Agile transformation goals) describing where the company currently is. Either way, do not skip this all-important step, as otherwise it will be impossible to measure the success of the transformation at a later date.

4. Define the transformation rollout strategy. The strategy will be specific to your specific situation, but in general can follow these types of approaches:

Bottom Up: introduce Agile at the development team level first, targeted for teams working projects with minimal inter-team coordination required. Gain some successes, then over time scale Agile up to the program level for efforts involving multiple teams and strong inter-team dependencies. Eventually scale Agile up to the portfolio level by convincing the business side of the need for business thrust prioritization and value stream analysis.

Top Down: introduce Agile at the business portfolio level first through ruthless prioritization of business thrusts. Decompose these thrusts into features. Prioritize the features within each thrust, while striving for a minimal marketable product. Bleed Agile down to the program level where large efforts involve multiple teams. Have the program-level folks keep a prioritized backlog of features and architectural enablers. Bleed Agile down to the team level by asking the development teams to decompose features into user stories and then tasks. Ask the development teams to create software in support of a small number of highest priority user stories every 2 weeks.

Viral: Agile starts in pockets, sometimes at the development team level, sometimes by a set of forward-thinking program managers, sometimes at the portfolio level for a make-or-break business thrust.

Hybrid: combinations of all of the above.

5. Define the support strategy. For example, what minimal set of guidance, templates, and artifacts are necessary for teams to become effective using Agile? Perform a “gemba walk” and talk to potential users to validate your thinking. Here are some potential examples:

• Agile framework diagram
• Guide describing the Agile ceremonies, who attends, agendas, duration, frequency, etc.
• Templates for vision, roadmap, and release planning
• Visuals depicting scaling Agile from the Team level to the Program level

Form or hire a portion of your PMO team to create these artifacts and provide a one-stop-shop for all Agile questions and requests.

A support strategy will also include an analysis of tools in support of your Agile rollout, decision, and procurement for the enterprise. There are many great options here – Jira, Rally, VersionOne, TFS, etc. Each has its own pros and cons. While I do not have specific recommendation, I would give the following advice – find a tool that manifests the concept of a User Story elegantly and intuitively. User Stories are the seminal work unit for Agile teams, so having a tool that speaks this language is crucial.

6. Identify high-profile project teams deserving of an embedded Agile Coach. Hire (or transfer) employees or consultants experienced in Agile methods with the mandate to achieve the transformation goals within the context of their team’s project.

Don’t make the mistake of starting Agile on small contained low-profile projects in order to “build up some successes”. If you do this and report on your success, the people that need to be convinced will yawn and say it would never work on their large important project. Roll the dice, tee it high, and let it fly.

7. Define your Agile tool belt. Why does Agile work for most every situation? - because Agile is a collection of methods, techniques, approaches, and yes even thinking. It is not a set of rules nor a restricted set of only this and that.

So think of Agile as your “tool belt” and when you need an Allen wrench (Scrum), then pull it out and put it to work. When you need some vice grip pliers (user stories), reach back and grab it and install it. Oh – I really need a Phillips head screwdriver (Kanban) – whip it out and apply it. And don’t forget that the “tool” can be adjusted as needed by the team to fit their unique situation!

8. Determine the Agile training needed. Start small with courses in Scrum, User Stories, and Kanban. Then add in courses in Agile Planning and XP/TDD practices. Hire consultants to develop this new training, or procure it through a 3rd-party agreement with an Agile training vendor. Recruit trainers (internal or external) to deliver the training in a compelling and engaging manner. While Agile certainly sells itself, it never hurts to have excellent delivery of training materials to encourage the positive vibe of the transformation.

Be sure and plan for ongoing learning in the form of lunchtime seminars and emerging Agile topics to be presented by leading Agilistas.

9. Measure your Agile transformation. What challenges in data collection and system support will you face? Create instruments, procedures, and software systems to continuously measure your enterprise transformation progress against the originally stated goals. Report the results honestly and transparently. Even bad news is good news in the sense that you can now take some corrective or more aggressive action.

Some additional performance indicators to consider measuring at the team and enterprise levels:

· How Agile are we really – do we follow (Shu), do we follow and adapt (Ha), or do we transcend (Ri)?

· How many stories do we typically carry over each sprint?

· How happy/fulfilled are we as a team?

· What % of all project teams are using Agile?

· Average wait time for a feature from inception to delivery?

10. Finally, remain positive! Resolve to not get discouraged. Be courageous enough to start small, start somewhere on your Agile journey. There will be some bumps in your road, but don’t get discouraged.

Do not let this article dissuade you from pursuing what you know deep in your heart is the right thing to do. If you will begin your Agile journey, you will experience some near-term benefits such as better prioritization, sharper focus, more predictable workflow, and increased employee satisfaction. Other benefits are longer-term such as culture change, business agility, and reduced cycle times.

Obviously your list may be different than the above as we are all products of our experience. Let me know what your experiences are!

Overall, an enterprise transformation to Agile is well worth the effort! What are you waiting for?