The glass ceiling: Water-Scrum-Fall
I've talked before about breaking the glass ceiling in my last entry, and I would like to extend a bit, and talk a bit about the things that are happening around the teams "working in Agile".
Many organizations going through the agile transformation have a Water-scrum-fall framework, (coined term by Dave West placed in Forrester). Let me do a quick overview of this perspective:
How do we get a project to start in an organization under this framework?
Usually you got in an organization just a few budgets approved for massive projects, of yearly or wider perspectives, for which they had some kind of previous analysis. Through some kind of large study you get to an approval, which leads to a design proposal.
Only a few big projects get funded. And sometimes the decision of which projects are funded are based on ROI or some other finantial modeling (yay, economics!). As if the market trends will help you see what will be useful or even used in the future, or the HiPPO (See image).
So there's the "Water"
Once that lengthy design proposal gets a pass, is when the development teams start being involved, on an overview of the architecture design at sprint 0, and iterative agile, beautiful, with all the neat things we've learned that needs to happen within a team.
Here's the "Scrum"
Until we get to a unified QA process generating a new bottleneck, since that is whole other set of people, and after that's done, they send that to another team responsible to make that deploy, and handle the operations.
And here's "Fall"
By your process decisions combined, you get water-scrum-fall.
Now you might find that with this process you do not get, but a small percentage improvement in comparison to pure waterfall, but that's just because you are not grasping the full value of doing agile, the time from the moment you get a long delay from the moment the project is conceived to the point you get the feedback on the product you are trying to put in the market. Due to this we have also big risks of not getting what we want.
Then we enter in the agile process masked by "Water" and "Fall". What is the main thing that we are asked to do to define if something is feasible or not right when we enter in the agile process?
Estimating!
We spend a considerable amount of time estimating cost and continuously adjusting it, when we should spend a lot more time instead trying to understand the potential business value.
The things that have more value in being measured on a project, according to a study are: if it will be canceled, how quickly can be rolled out, and whether people will use it at all. Cost, as in "what we are trying to get predictable at", has currently a higher importance than it should, in comparison to these other three. Don't misunderstand me, it is important, but should not be the main guide of your product.
We've seen that in most cases, with the interest of keep a strong delivery pace and grasp the advantage of having people working towards a product, we try to release more features, as if more features will get a more valuable product. Often then small value stuff goes together with high value stuff, just for the sake of doing. It really shouldn't be like that. If we do something is because is the most valuable thing we can do. Teams often get lost on the value prioritization of the small list we have with the next one or two sprints. And there's where the PO should step up and offer a vision perspective so that everyone is on the same page. As a user, you don't go to ebay or amazon to see what's the recent new feature that will blow your mind, you go there to buy stuff, aim to fulfill the simple premise and with a good quality first.
RUN EXPERIMENTS. As you step out of formal learning and into your working life, you will no longer learn by having you being told what to study or how to proceed to be most efficient, you'll have to learn that through experimentation. The scientific method is a process anyone could easily apply.
Define with your customers and team what is the action you are going to experiment on.
Choose the right outcomes by measuring the severity of the problem/size of the opportunity.
Set target outcomes, It should be your poka yoke. (Keep yourself on target, avoid mistakes by making it hard to do the wrong thing)
Define Target clear and measurable.
You start with a desired outcome and begin to explore it separating this outcome in what are the areas that can impact it in a way we can achieve that. Get goals for each, and slice those down in the actual stories.
Place achievable, measurable objectives and start working to get them. This goes beyond "just developing" this is a framework that product representatives and customers could embrace just as well, and maybe even with greater benefits.
Get those feedback loops on the move! With this you are accepting you don't have the absolute truth on what's needed but you'll start moving forward iteratively.
Executives change their minds usually due to a disaster, from my experience. Not that you need those to happen, (let's hope not).
In any case, to get organizational change to be successful, what you need is a "sense of urgency". Find people at leadership levels feeling this urgency, since that is people willing to try new things. People at high level with urgency for a change, will cascade down in people at mid level with same urgency to make that change.
Many organizations going through the agile transformation have a Water-scrum-fall framework, (coined term by Dave West placed in Forrester). Let me do a quick overview of this perspective:
How do we get a project to start in an organization under this framework?
Usually you got in an organization just a few budgets approved for massive projects, of yearly or wider perspectives, for which they had some kind of previous analysis. Through some kind of large study you get to an approval, which leads to a design proposal.
Only a few big projects get funded. And sometimes the decision of which projects are funded are based on ROI or some other finantial modeling (yay, economics!). As if the market trends will help you see what will be useful or even used in the future, or the HiPPO (See image).
Once that lengthy design proposal gets a pass, is when the development teams start being involved, on an overview of the architecture design at sprint 0, and iterative agile, beautiful, with all the neat things we've learned that needs to happen within a team.
Here's the "Scrum"
Until we get to a unified QA process generating a new bottleneck, since that is whole other set of people, and after that's done, they send that to another team responsible to make that deploy, and handle the operations.
And here's "Fall"
By your process decisions combined, you get water-scrum-fall.
Now you might find that with this process you do not get, but a small percentage improvement in comparison to pure waterfall, but that's just because you are not grasping the full value of doing agile, the time from the moment you get a long delay from the moment the project is conceived to the point you get the feedback on the product you are trying to put in the market. Due to this we have also big risks of not getting what we want.
Then we enter in the agile process masked by "Water" and "Fall". What is the main thing that we are asked to do to define if something is feasible or not right when we enter in the agile process?Estimating!
We spend a considerable amount of time estimating cost and continuously adjusting it, when we should spend a lot more time instead trying to understand the potential business value.
The things that have more value in being measured on a project, according to a study are: if it will be canceled, how quickly can be rolled out, and whether people will use it at all. Cost, as in "what we are trying to get predictable at", has currently a higher importance than it should, in comparison to these other three. Don't misunderstand me, it is important, but should not be the main guide of your product.
We've seen that in most cases, with the interest of keep a strong delivery pace and grasp the advantage of having people working towards a product, we try to release more features, as if more features will get a more valuable product. Often then small value stuff goes together with high value stuff, just for the sake of doing. It really shouldn't be like that. If we do something is because is the most valuable thing we can do. Teams often get lost on the value prioritization of the small list we have with the next one or two sprints. And there's where the PO should step up and offer a vision perspective so that everyone is on the same page. As a user, you don't go to ebay or amazon to see what's the recent new feature that will blow your mind, you go there to buy stuff, aim to fulfill the simple premise and with a good quality first.
Prioritize value first
A good way to easily realize what are the things that you should be doing, is to organize it by the cost of delay. The cost of delay would be how much money is the organization losing in opportunity cost, each week it passes that this feature is not done. Get the costliest things first! You might see that the opportunity cost of just a few of them will separate themselves widely from the whole lot of features you had sighted. Your teams should stop right then and there whatever they are doing that does not relate directly to those, and work right away in getting those out as fast as you can.Deliver value faster
The value of slicing stuff down is that you will have faster deliverables with smaller increments to receive feedback from. And by doing what you do, won't get you widely faster than waterfall unless you do this at those levels too.Feedback loops! That's why you do agile in a first place.The faster the feedback loop the faster you can correct your path and smaller the risk in case of failure.
RUN EXPERIMENTS. As you step out of formal learning and into your working life, you will no longer learn by having you being told what to study or how to proceed to be most efficient, you'll have to learn that through experimentation. The scientific method is a process anyone could easily apply.
What to do:
- Don't optimize the process in a way that assumes you are right. Most likely you are not, optimize it to realize how to adjust and rearrange quick.
- Focus on value, not cost. Value is the one that will give you a greater ROI than reducing costs.
- Create feedback loops to validate if you are right.
- Make it economic to work in small batches, the value-cost relation of doing stuff in small batches resides in your ability to iterate on that fast. Remove the waste you have at the beginning and end of your delivery process, enable an experimental way to Prod development.
How: some tools to get there
1.- Impact mapping.
Impact mapping will get you to a shared understanding of the teams. Communicating this to all the chain of people working towards a goal, will help everyone understand better where are we going and how are they being part of a more complete solution.Define with your customers and team what is the action you are going to experiment on.
Choose the right outcomes by measuring the severity of the problem/size of the opportunity.
Set target outcomes, It should be your poka yoke. (Keep yourself on target, avoid mistakes by making it hard to do the wrong thing)
Define Target clear and measurable.
 |
| (Source) |
2.- HDD Hypothesis driven delivery
We believe
[building this]
[for these people]
will achieve [this outcome]
We will know we are successful when we see [this signal from the market]
Place achievable, measurable objectives and start working to get them. This goes beyond "just developing" this is a framework that product representatives and customers could embrace just as well, and maybe even with greater benefits.
Get those feedback loops on the move! With this you are accepting you don't have the absolute truth on what's needed but you'll start moving forward iteratively.
3.- Get support from leadership
To start from the bottom up of your organization won't get you far, and no change lasts long without leadership support.Executives change their minds usually due to a disaster, from my experience. Not that you need those to happen, (let's hope not).
In any case, to get organizational change to be successful, what you need is a "sense of urgency". Find people at leadership levels feeling this urgency, since that is people willing to try new things. People at high level with urgency for a change, will cascade down in people at mid level with same urgency to make that change.
Comments
Post a Comment