The inscription on the cake says “Teamwork Makes the Dream work”.
After nearly two years of hovering between 60% and 75% delivery for every PI, we were chomping at the bit to celebrate when we reached a delivery of 85% for our previous PI. But circumstances held us back and the moment passed. I was just a little sad.
And when we planned PI-7, the thought uppermost in many of our minds was whether we could repeat the 85% delivery? The jump from 75% to 85% was considered a huge leap and I was really nervous about whether we could do it again.
Metrics in an Agile shop can be a contentious topic. And I have steered clear from posting anything about metrics until now. We have tried all kinds of metrics. We have measured business value, story points, stories, features and we have produced some rather elaborate metrics packs with colorful graphics that few understood and many more did not believe.
We stuck to the same pack for a few PIs while trying to work out what unit of measure made the most sense. Then just before PI-6, our new COO stated that it didn’t matter how big or how small our features were, or how many story points we were delivering in an increment, or how big or small our teams were, what did matter was whether we delivered to our commitment or not. And he implemented one simple rule – deliver 100% of your commitment.
The rumble of discontent could be heard in the silence that followed. Impossible! We have too many third party dependencies. We have too many complexities. Our vendors don’t work the agile way. Why doesn’t management understand? Why doesn’t management support us?
The hypothetical question put to the teams was – if we were only paid for what we delivered, would we be happy? Tough question that got tongues wagging and minds thinking for a long time.
So what could be done to improve? How do we help teams to deliver 100%?
At this point I should tell you a little about our demand management model. We had co-created a demand management process with business at the start of our journey. Demand could only come through mandated people; demand had to be sized; demand required a business case, demand had to be pre-approved. Few bought into the process and work was still being done for whomever shouted the loudest rather than what carried the highest business value. Prioritization was not done correctly; epics were prioritized and we had 20 or more priority one epics for PI-1. Work on prioritized initiatives began too late for the PI, so the Program backlog was made up of a mixture of epics, capabilities and features that mostly did not meet the definition of ready. Teams complained that we were setting them up for failure.
Our ART is huge and although we follow the SAFe framework, we have not conformed to the guidelines for size of the ART nor for the size of teams. Our ART at the last count has nearly 400 people on the train. We also have 32 teams on the train. Our first PI planning session was held on the floor because the cost to take everyone away was too high. Alignment across so many teams is an enormous task and we don’t always get it right. This leads to a large number of impediments that arise during execution that we are not always able to resolve within the increment. We seemed to have a lot of excuses for non delivery. And the business was not happy with the uncertainty or the level of delivery.
We battled with this process for a number of increments; we did our best to make it work. The main problem was that demand wasn’t fully business driven, so how could we expect business to support it. The new COO brought in a new demand management model. Accountability for prioritization was placed firmly in Product Management’s court. Program backlog prioritization became centre stage. Product Management and Product Owners started to fulfill their responsibilities with more enthusiasm and made sure that teams were taking the right features into PI planning. Teams began to enjoy the support of their business which fostered closer collaboration. Although the metrics seemed simpler, teams were still sizing stories using story points and teams were still planning according to their velocity. For me, this was the turning point in our journey. This was PI-6. And this was when we hit 85%.
And so onto PI-7. What did we do differently for PI-7? We pre-planned earlier. We took the time to understand dependencies better. We didn’t commit to features if we didn’t get the commitment from dependent third parties. We didn’t accept iteration overload. We learnt to say no or maybe if there was any doubt. Teams were asked to identify mitigation plans should they experience delays. PI execution was tense; we scrutinized every iteration. Our CIO often walks the floor at the end of day to chat to whomever is still around. He remarked one day that he could see more people on the floor than usual. We took this as a sign of commitment to the 100%.
And then we hit 95%. I asked for the numbers to be triple checked.
How could we NOT celebrate this time round? This achievement is unheard of in the rest of the organization*. The effort to reach this remarkable milestone needed to be acknowledged and celebrated. Teams needed to be thanked. So we ordered a special cake and after the final plan presentation for PI-8, our CIO thanked the team, our RTEs cut the cake and we all had something sweet to remember this by.
We could not have done this without the unstinting support of our CIO, COO and other senior management. They left us to work this out for ourselves but were there to guide and support. Of course, we need to sustain this and become predictable with our delivery. I suspect that we will still experience a number of ups and downs. We can never rest on our laurels, our work is not done.
#Teamwork #SAFe #Agile
Until next time ☕️
*Metrics and units of measure are not standardized across the organization.