Lean Agile adoption can only be successful when the people themselves create the necessary changes and therefore are really committed and feel accountable for it. The path to Lean Agile adoption can therefore not be planned in full detail upfront. But the path towards adoption can only emerge, the path can only emerge by walking it!
In my little booklet I am writing called Emergent Transformation I discuss how you can go on your agile transformation journey. One of the things I use to make an initial adoption plan is a set of questions and possible answers that I call the Emergent Transformation canvas. The canvas is your guide to create your adoption plan by going through all the building blocks and answering the questions. By filling the canvas you create your transition backlog. After that you can order it by business objective and there you go; your first adoption sprint plan is ready! You can now use Scrum in your adoption journey.
In this blog I will only discuss the set of questions you can use to make up your plan. See below an explanation of the canvas.
Emergent Transformation Canvas
What are our business objectives? Why are we doing this?
The Business Objectives building block defines the objectives the organization aims to achieve. The business objectives are the reason why an organizations is going on the lean agile transformation journey. As the transformation leader you have to ensure the business objectives are crisp and clear so people can identify with and work towards them. Missing or vague business objectives gives poor sense of purpose and direction to those involved.
In the context of lean agile adoption the business objectives are formulated as a vision story including goals and forecasts.
How do we measure progress towards our objective? Are we moving in the right direction?
The Measures building block defines how the organization is going to determine if the transformation is on the right path. The measures identify how you are going to assess success, measure progress towards the business objectives and learn. In addition the measures are used to discuss whether the transformation process should stop, continue or change direction. Thinking about good measures and quantifying them is very powerful because it forces you to discuss exactly and precisely what you mean with success. This discussion increases understanding among all involved about what you are striving for.
Measures are defined on outputs and on outcomes. For example your transformation could produce shorter release cycles which is an output. The outcome could be that the business can successfully react to opportunities.
How does management support the transformation?
The Lean Management building block describes what management needs to do in order to support the transformation so you can achieve your business objectives?. What is it about our working agreements, policies and organizational structure that has to change? What is it that management needs to do to become a coaching manager and to manage knowledge. What are the changes that need to occur to focus on creating customer value and see high performing teams as a key asset?. You need to assess your current way of managing, decide what changes you are going to make and create your transformation backlog.
From the a lean agile perspective the way to go is to start learning as quickly as possible and use that learning to increase results.
Which practices align with our objectives? How do we build the thing right?
The Agile Development building block describes your plan to be able to build the thing right. It is about the practices you need in order to shorten the feedback cycle and support the business objectives.
Below some example practices for software development
- Test Driven Design
- Emergent Architecture
- Pair programming
- Exploratory testing
- Inspection charts
- Collective ownership
How do we co-create our innovative solutions?, are we building the right thing?
The emergent innovation building block describes how you are going to engage with your employees and your customers to really understand their needs. What do you need to do so the people feel comfortable to innovate their ways of working and the company can learn how to do agile?
The teams and organizations have to learn how to apply the practices in their specific context. How are you going to support them to learn and share their capacity to act.
On april 22-23 I will give the certified Innovation Games® training for Customer Understanding in Utrecht.
You can register here.
The last decade we have had quite some success with agile development. The agile community moved from a 14% project success rate in 2002 to a success rate of 45% in 2012. And Scrum emerged as the most popular agile framework being used 82% of the time in 2011. But there are still some problems to say the least. It is estimated the USA spends 150 billion a year on failed IT projects, the european union around 140 billion and The Netherlands around 5 billion a year on failed governance IT projects. That is serious money. Out of a large number of potential causes I think that the failure to validate early and often is one of the main reasons for failure.
The agile community now knows how to build the product right, but we are still a long way from building the right product. Agile teams are used to deliver working product for validation at the end of each iteration. Frequent delivery of working product motivates people as they experience real progress, provides transparency to all stakeholders so they understand exactly how the project is progressing and short deadlines actually increase productivity too. Frequent delivery also creates the possibility for customer validation keeping you from going of track too far. But all this is not enough to build the right product!
After each iteration agile teams ask themselves the following questions
- What is preventing us from shipping today?
- What is our minimal viable product?
- Which features are innovative and make a difference to our customers
- What are the real drivers and challenges of our customers
- Which improvement will have the biggest impact
Validation is not going to provide the right answers to these questions! Not if you are looking for innovative results. For validation to work you first need a correct vision. For validation to work for innovation you have to discover what really drives people, understand their problems and create high customer empathy.
Most methods for understanding customers like focus groups, questionnaires and also validation do not give good innovative results. That is because these methods mostly activate the rational part of the brain. The problem is that the rational part of the brain tries to produce rational answers and those answers are often not the real thing. The real drivers, thoughts and motivations of people that provide you with innovative insights, are formed in the unconscious part of the brain. So in order to really understand our customers and be able to come up with innovative ideas we need to connect with their unconscious brain.
A good method for getting innovative insights is through serious games. A subset of serious games are the Innovation Games®, these are serious games specialized in getting innovative insights from your customers. For example a game like Buy a Feature helps you answer what the most valuable features to be worked on are. Another game like Product Box helps you understand your minimal viable product. The fascinating thing about Innovation Games® is that they actually produce innovative insights. The outcome of the game is very valuable but lots of insights also come from the conversations and discussion that arise among the people during the games. It is in the game environment when people are really engaged in collaboration with others, moving things around and discussing points of view that their real drivers, reasons and motivations emerge.
The days that innovators could sit in a team disconnected from development, had enough time to analyze, think and propose grand innovation plans are over. The assumptions that you can predict customer interest, reduce risk by extensive marketing analysis and have the wisdom to know what customers really want are fundamentally flawed but are still common practice!
Working from these assumptions brings us long lasting, high risk, high costs innovation projects.
According to Jeffrey H. Dyer in his paper The Innovators DNA there are 5 essential innovation skills.
Five “discovery skills” separate true innovators from the rest of us.
According the Jeffrey H. Dyer the innovation skills are
Discovery Skill 1: Associating
Associating, or the ability to successfully connect seemingly unrelated questions, problems, or ideas from different fields…
Discovery Skill 2: Questioning
…Innovators constantly ask questions that challenge common wisdom ….
Discovery Skill 3: Observing
Innovators carefully, intentionally, and consistently look out for small behavioral details—in the activities of customers, suppliers, and other companies—in order to gain insights about new ways of doing things…
Discovery Skill 4: Experimenting
Like scientists, innovative entrepreneurs actively try out new ideas by creating prototypes and launching pilots…
Discovery Skill 5: Networking
Devoting time and energy to finding and testing ideas through a network of diverse individuals gives innovators a radically different perspective.
Innovation Scrum Team
True innovation progress starts once real customers experience your ideas and provide feedback to validate your experiment. Innovation should therefore be done by teams that cover the whole stream from customer engagement to delivering customer value. Teams that understand the customer needs, experience how their lives are affected and are able to create the solutions.
We therefore need to shorten the innovation cycle of
2. Developing and
Co-creation can be done in numerous ways. A fun and agile way for beginning with Co-ceation are Innovation Games®. By playing Innovation Games® you can practice all of the innovation skills mentioned above. The Scrum team itself can do the observations and process the results of the games. This will increase customer empathy and customer understanding among the people developing the solution.
Scrum gives you a framework you can use for developing and validating your experiments at low risk to get high value. The Product Owner can be the driver of low risk high value innovation.
The other day I was in the expert panel at the Scrum Day Europe.
One of the questions from the audience was
If you could only choose one Scrum event, what would you consider the most important event?
People in the expert panel ofcourse disagreed to have a interesting discussion. Ken Schwaber said the Retrospective is probably the most important event because improvement is key in Scrum, others said the Sprint Review is the most important one and so on. I was left with the Daily Scrum and argued that the Daily Scrum is probably the most important event in Scrum. Let me tell you why I think so.
The Daily Scrum is used by the team to determine the plan for the day. If there is a problem or impediment reported during the Daily Scrum all the problem related data is right there, it is at most half a day old! The understanding of the data is still easy, the problem is still small and can therefore be handled easier and there is still a chance that a counter measure helps you in the current sprint.
The Retrospective gives the team time to reflect on the past sprint(s), work on team building and improve what and how it develops. The team comes up with better ways of doing things, defines experiments to try out the next sprint and utilizes it collective problem solving intellect. A disadvantage of the Retrospective in comparison with the Daily Scrum is that it takes place at the end of the Sprint. And that could be too late! The longer you wait to handle a problem the harder it is to come up with good solutions. You loose context while time goes by.
You can better deal with a problem while the problem trail is still hot! The longer you wait the more time you spend in the retrospective establishing a common understanding of what happened or ‘Gathering Data’ as it is called in the retrospective circles. Most teams don’t even gather any data as they start their retrospectives right away with “what went wrong and what went right” questions… and that is a serious problem!
So next to having a big PDCA cycle every sprint, I like to also have multiple smaller PDCA cycles during a sprint which gives a better continuous improvement. The Daily Scrum makes having the small PDCA cycles possible. And that’s why I think the Daily Scrum is the most important event.
I would have chosen another if I had first pick in the panel discussion 🙂
In agile we say that we do value driven development. We try to work on the most valuable items first so that when the time comes when there is either no more money to spend or no more time left we have the most valuable stuff done and deployed to production.
From all the projects and product development teams I worked with over the years I have seen only a few that measure and track value across time.
The challenges with measuring value are that value is defined different depending on your perspective and that there are numerous possibilities to measure it.
There is value in doing the right thing, that is value measured on outcomes. And there is value in doing things right, that is values measured as output. There is a big and important difference. Output is the stuff you produce like e.g. stories. How much stuff are you making, how fast and at what costs.
Outcomes is the difference it makes. Why are we making this stuff? and why should anyone care? You could measure things like economic value, product quality, strategic alignment and innovation rate just to name a few.
In this post a simple example of how you could work with economic value.
Lets say you are a project team and are delivering your project in 3 month release cycles. The objective of the project is to be able to increase online sales by 10% from 10M to 11M. Great, how do you measure that while you are developing? you can’t as you will only get feedback after shipping the functionality!
What you can do is to let the product/sales/marketing people make an impact estimate on how much sales increase they can achieve with the proposed epics of functionality.
Lets say they estimate that the new functionality impacts sales increase as follows
|Epic 1||Epic 2||Epic 3||Epic 4|
|Increase from 10M -> 11M||30%||10%||10%||50%|
Don’t worry, product managers, sales and marketing actually studied for making these estimates. It was when a VP once told me
…getting value estimates is easy, that is what our product managers and our sales people have been doing long before you came in…
that I started to realise that it is nothing special at all.
Once you have these impact estimates you can use them to assign economic value points to your stories. The impact estimates limit the amount of value the epic and its stories can create. Without such a limit the value points would be meaningless because you would not able to see progress towards the objective. One way to assign economic value points is to first do a relative value point estimation on your stories. Once that is done you can just distribute the estimated impact.
Lets say Epic 1 consists of 8 stories.
|Epic 1||Story 1||Story 2||Story 3||Story 4||Story 5||Story 6||Story 7||Story 8|
With this data you can easily measure value delivered each sprint. You can use this data as one out of many of the attributes for ordering your backlog. Another benefit is that you can take action when the rate of added value starts decreasing. It will as value added most of the times follow an s-curve.
After your first release you can start measuring real progress towards your objective of 10% online sales increase.
You can easily extend the impact table with other objectives and estimate impact for those. You could add for example strategic alignment, innovation rate, costs and so on.
Oh yes, of course you have no time to spend on estimating and planning as there is never enough time to do it right, but always enough time to do it over?
I’ll be giving the Scrum.org Professional Scrum Master training in Utrecht on September 17 and 18. The training will be in Dutch.
You can register at here at Scrum.org
Check AgiliX for more information.