- How long does it take to replace an antiquated system that has been around for decades? 3 Years
- How long does it take to build a strategic system that could leap frog the competition? 3 Years
- How long does it to take to transform your organization to Agile? 3 years
- How long does it take to do anything that requires large strategic investment? You guessed it, 3 years.
What gets presented is a Gantt chart that looks something like this:
Phase 1: Will be delivered 9 months after the money is secured and will deliver something called the "framework"
Phase 2: Will be delivered 6 months after Phase and will delivery the first valuable delivery
Phase 3 (where the magic happens): Will get delivered at the end of the three years and will deliver all the value
What actually happens:
Phase 1 gets continuously delayed until a senior manager threatens that heads will roll. In order to meet said manager’s expectations, Phase 1 gets rebranded to Phase 1a and the scope is cut by 30 percent.
After 2 years, Phase 1a eventually gets delivered and drinks are had.
Discussions about how this is not working and about how to wrap it up nicely begin to replace other discussions.
One or two PM casualties later the project is shelved and another system remains to be decommissioned by another 3 year strategy.
I understand now why the answer is always three years. It looks great on a deck, and is neat and tidy. That's not what interests me. What I find fascinating is how intelligent, well-paid managers can sign-on to something they know is not possible over and over again.
Do people really believe it? Does it take three years to forget? I know the people presenting the three year strategy don't really believe it. So what is their motivation? Simple: They want the money. They are not going to get millions in investment if they tell the simple truth: it will probably take about a decade to do what we promise on page one of the deck. So they promise the impossible.
My assertion is that major banks are part of a system that is beholden to share price and providing shareholder value. CxO’s don’t have a long shelf life, 3-5 years. Their attention span is, understandably, 3 years. They are not going to sign-off on a very expensive program that will last longer than their perceived tenure.
Don't get me wrong, you can build lots of stuff in three years. It just takes far longer to realize the benefit, which is often the reason you start the project to begin with.
If your plan is to replace many systems with one system, or build a platform that will leap frog your competitors, chances are it will take at least twice as long as you have quoted on paper.
If any of the above rings true to you, your project is doomed to fail before you begin, and your time is better spent tidying up your existing infrastructure.
Make it last...Toilet paper financing
Money is like toilet paper, if you have too much you will waste your resources and run out very quickly. Give a person an allowance of one roll of toilet paper and they will make sure they use their limited resources appropriately. Give them too much (e.g. 30 million in the first year) and they will waste it on cleaning up spills in the kitchen.
Give the team as much toilet paper as they need and no more. Down the line, they may have Mexican and need twice as much toilet paper. That’s fine. But the key is to make it last the 5-10 years that will be required to actually execute on the strategy.
You can also avoid the above by going "tactical"...
During a retrospective with a client, we did an exercise called 5-whys to try and uncover the underlying reason behind the lack of focus on production. One enlightened developer provided a valuable piece of insight when he noted that we *may* still be in a “waterfall mind-set,” hence the lack of urgency.
This is natural after living under the tyranny of the waterfall deliveries for many decades.
Why does getting to production every sprint matter so much? Why won’t I just shut up about it?
In my experience, the greatest two barriers to a meaningful agile adoption are the waterfall mind-set and the belief that everything will magically come together at some point in the future.
Nothing has a more profound impact on changing the waterfall mind-set than actually getting to production at the end of every sprint. It will change the way you think and operate.
If the teams and the product owner do not insist on getting to PSPI (potentially shippable product increments) every sprint here is broadly what will happen. You basically end up with scrum-fall (scrum+waterfall) (devolopment sprints->line up environments-> integration test -> uat-> production). Estimates start to become meaningless as you will need an equally long time for the “release sprints”.
The net result will be a failure to deliver and ultimately blaming agile: e.g. “Agile does not work.” “We need to go back.” “If we stayed doing things the way were doing things, we would be live by now”.
As if to say that we delivered so wonderfully in the waterfall model.
But the product owner is not pushing for production
It is the job of everyone (feature team, scrum master, product owner). To date, the push to production has been coming from people outside these three groups. This should be discussed in PBR (product backlog refinement). The scrum master should keep the production tension alive.
But there is no business value going to production every sprint
That is probably true during the first couple of sprints, but going to production every sprint will change the nature of PBR. The team/PO will start thinking about what useful things can be built to drive revenue. (e.g. if we do X can we start generating a subset of the revenue).
When agile/scrum is introduced into an organization one of the side effects is a perceived or real lack of urgency. I have seen this on a number of occasions, where teams seem to be losing the sense of urgency. Estimates feel too high, not enough "stuff" is getting built.
"enough of this hippy B.S., we need to crack the whip"
I want to share some of my observations regarding why this happens and some suggestions.
The traditional model of getting things done is referred to as the authoritarian model by Peter Senge (the 5th discipline). In this model, one person understands the problem and shoulders the sense of urgency and tells his “team” what to do. That person is the information bottleneck. He/she cracks the whip when he needs to be but many also reward a person for a job well done. The sense of urgency comes from the fear of this person and not from the “real problem. Let’s call this model, the Lewis model.
To a certain extent the Lewis model actually works and “stuff” will get delivered. Lewis will get rewarded. He works hard and shoulders most of the stress. As a side effect of the stress and the whip cracking, few people want to work for Lewis.
Another model is one where the team feels and understands the problem. Rather than the sense of urgency stemming from the fear of a “person” it stems from understanding the real underlying problem or business opportunity. This will result far more creative solutions to the problem. Teams working under this model will usually work harder/smarter than under the Lewis model. Let’s call this model the Harvey model. Everyone wants to work in this model.
A big part of the product team’s role is to translate the opportunity/problem to the team and protect the team from Lewis. The team in turn must seek to understand the problem/opportunity and deliver results.