Blueprint For An Agile Guild in a large Corporate Environment

Vision Statement

As an Agile Guild, we want to engage, excite and educate Agile Coaches, so that Agile flourishes in [corporation X].

Implementation

Iterating down from the Vision to a proposed implementation plan in support of the vision, there are three parts (engage, excite, educate):-



1. Engage. Create a sub group within the Guild who will undertake to:
• Identify Agile Coaches and stakeholders, within [corporation X] and within vendors and suppliers, onshore and (if required) offshore.
• Connect with them. Construct an informal hierarchy or pathway that allows vision and strategy to flow from the Agile Guild to vendor coaches and and (if required) offshore coaches and development teams. This structure should allow goals to flow out and team-proposed implementation details/impediments to flow back. Follow the basic Agile principle - goals from the business, implementation details from the team.
• Identify potential Agile projects at [corporation X] and ensure that [corporation X] stakeholders, vendor and (if required) offshore coaches (identified above) are engaged and connected.
• Ensure that vendor coaches are involved in planning, retrospectives, education sessions etc. Ideally, the vendor coaches need to be so engaged that they identify themselves primarily as part of the [corporation X] Agile Team, not as part of the vendor team.


2. Excite. Create a sub group within the Guild who will undertake to improve engagement…. by exciting our stakeholders.
In order for people to buy in, we need to “sell” Agile. This means we need to answer the “What’s in it for me?” question for a variety of audiences/stakeholders. I’m not a sales person, but here are some answers I use for a few different types of audience:
• What is in it for developers – A level of self-determination, control and success. You get to decide your own actions and estimates, while ensuring that your customer is happy with the decisions.
• What is in it for upper management – This one is a no-brainer. Numerous studies from Gartner, Forrester, IBM, etc have shown that Agile gives them a Competitive Advantage. If they do not go down this path they give the competitive advantage to their competitors. Most of them would rather disembowel themselves with a spoon than give an advantage to the competition.
• What is in it for Vendors. This is a tougher sell, as you are outside of your organisation. The contractual model really needs to support your story. Split Contracts (a fixed price “Discover” phase followed by a Capped T&M “Evolve” Phase) or a “Pipeline” style contract, combined with the knowledge that other vendors are going down the same path, will strongly encourage the right behaviours. Within your vendors, make sure you form very close ties with your vendor coaches, and encourage them to do a lot of the “Selling” at the various levels.
• What is in it for Middle Management… Demonstrating self-interest for the “Frozen Middle” is difficult.  I try to hit two points. Firstly, they get to do something new and exciting. Secondly, Agile is currently hot in the market. So the skills they develop are very “marketable” either within [corporation X], or outside. Make sure you form very close ties with your vendor coaches, and encourage them to do a lot of the “Selling” at the vendor middle manager level.


3 Educate. Create a sub group within the Guild who will undertake to:
• Find out what our coaches are good at. We need experts in the nitty-gritty of Agile - Kanban/Scrumban, Lean, XP Technical practices (CI Automated Regression Testing, TDD, etc) and supporting tools, BDD, Backlog generation, etc, etc. And we need experts in the more esoteric or theoretical side of Agile – Queuing theory, the Theory of Constraints, Systems Thinking, Scaling Agile, Complexity Theory, Vanguard, etc.
• Schedule Cross-Training based on the list developed above. Everybody has something to give and everybody has something to learn.
• Find out who is coming out for Agile Coferences and find Corporate Sponsors who will get them to come into [corporation X] and speak.
• Make sure Vendor coaches are invited and/or recordings of the sessions are shared with them – your Vendor Coaches need to feel like involved equal partners.
• Connect people up with Special Interest Groups, Meet Up groups, Conferences, etc. Get our people recognised as experts, so that we can attract the best.
• Develop standard packages for running repeating task and ceremonies (such as Discover Workshops and even Retrospectives). This is intended for inexperienced practitioners - encourage experienced practitioners to improvise and adapt, as Retrospectives and similar ceremonies get boring and unproductive if you always follow the same pattern. The standard packages should include instructions and a physical package of things they will need (sharpies, paper, etc).
• Develop minimum standards for developers involved in Agile Projects – run courses. These standards apply to Vendor developers too!!!! Get your vendor coaches to develop courses, or do a “Train the Trainer” course for them, and let them use your course. The course needs to be run just before the project starts. Earlier than that, and the developers forget.

Strategic Kanban in Practice - Rolling Wave Planning Guided By Hypothesis Driven Development

Here is an approach to Strategic Portfolio Kanban that I have used with some success.

1.   Rolling Wave Planning Allows Planning in Increments.

I have suggested in the past that SAFe’s Portfolio Kanban methodology is applicable in almost any Enterprise that needs to manage multiple teams, but that SAFe’s  Agile Release Train (ART) planning methodology may be too heavy-weight for many situations.

However this raises a question – if you have no ART (Agile Release Train) planning process, what feedback mechanism is used to keep your Portfolio Kanban realistic?

And here is my answer, based on experience in recent engagements: Your Strategic or Portfolio-level plans should be incrementally reviewed and updated based on real-world feedback around team capacity and team progress - so use Rolling Wave Planning regularly updated from your Iteration or Sprint planning process.

In using Rolling Wave Planning remember the basic Agile Tenet that Estimates come from the team – so the planning process needs to feed a prioritised Backlog to your teams, and get a realistic work commitment based on capacity back from your teams. In this respect, it is similar to the ART planning process.

A rolling wave planning approach differs from an ART planning approach in that Rolling Wave Planning does not require all teams to run simultaneous, synchronised planning sessions. Rolling Wave Planning allows you to update your plan incrementally, rather than commit to the longer-term Release Plan cycles that an Agile Release Train plan tends to require.

 

2.   Hypothesis Guided Product Vision.

However Rolling Wave Planning is only one part of the Portfolio Kanban puzzle. Your planning comes from the Rolling Wave…. But where does your strategic direction come from? What guides the goals that shape the plan? SAFe suggests that you need a Vision Statement – but this just begs the question: What guides your vision?

And here is my answer: The Lean Start-Up approach provides Hypothesis-driven development (or Experiment Driven Development) as an aid to guiding your strategic vision.

But the Enterprises we work in are not Start-Ups. How, in an Enterprise environment, do you generate testable Hypotheses? (Yes, I had to look up the plural of hypothesis before I wrote that.)

The answer is easier than you might think. In an Enterprise environment you have two big advantages:

- First you probably have access to numerous sites from which to choose a few Pilot Sites.

- And second, you probably have a good user base, from which you can select representative users.

In my current engagement we have a user integrated into the team (echoes of my old XP days).  This product user is NOT the Product Owner. The product user has been brought in from the field, and is proving to be invaluable in two ways:

i.    The user can describe the reality of how the product is used (this has proved to be an education for the Product Owner – who is too high level to have a grasp of the fine-grained details).

ii.  The user can talk to other users to develop hypotheses about where the product might go.

The value of that last point cannot be overstated. If you want to develop a good hypothesis, don’t just bring users into a product review and ask them what they think. Instead, ship your product to the first pilot sites and let it settle in for a while. Then send your user out to talk to the people using the product. Don’t send a BA or a manager – your user has to be a peer. The pilot-site users will be much more likely to give extended, honest and thoughtful responses to a peer – because they know that the peer will soon be using the product.

You can equip your user with questions, but it has to be a user that asks them.

When your user comes back into the office, you can start generating hypotheses. At this time, compare the user findings and hypotheses to your Product Vision. Adjust Vision as required.

After reviewing your Product Vision, you may need to send the user back out to the pilot site to validate or further refine the hypotheses list (keep your list short). Once you have your list of hypotheses developed and finalised, you are ready to test.

You may not need to write code for your tests – consider using physical mock-ups, wireframes, or simple what-if scenarios. Remember the Agile dictum – the simplest thing that works.

Once you have tested your various hypotheses, you can enter the highest-value ideas into your Portfolio Kanban, where they can be analysed, assigned a business case, and then prioritised against other ideas to form a portfolio backlog.

Streaming to the Pipeline

Now stream your Portfolio Backlog into Pipelines of work and send the Pipeline Backlogs out to your Pipeline Teams to get their estimates and a commitment to the work. The teams can update estimates, progress and work commitment  using the usual Agile Iteration or Sprint mechanisms.

This allows you to constantly update the plan and look forward using your Rolling Wave approach.

And there you have it – your Hypothesis-driven Product Vision drives your Portfolio Kanban, which generates your prioritised backlog, which is incrementally updated in a Rolling Wave Planning process..... A practical approach to Strategic Kanban using Lean Start-Up ideas in an Enterprise environment.