Lots of organisations struggle with an explosion of divergent information related to the work in progress and to be done. They try to get a hand on things using one or multiple project management techniques and Agfa’s Enterprise Healthcare BU was not different in that sense! Many projects ongoing, many requirements documents flying around, many sources of work for “resources” in the organisation ending up with a very unbalanced ratio of people “doing” (development) the work versus people “managing” the work (incl. analysis).
In order to change this we went from a multitude of projects to managing a product as described in “Scaling Lean and Agile Development” by Bas Vodde and Craig Larman, basis of currently known as LeSS (Large-Scale Scrum). This meant consolidating all ongoing work as well as the soon to be done work in a single Product Backlog for a 400+ R&D organisation that was spread in 5 locations over 4 European countries. A challenge that we want to share.
Enterprise Backlog, Product Backlogs, Areas, and Teams
Together with people from the business, P.O.’s, P.M.’s, PjM’s, … a true Product Backlog for the overall Enterprise Healthcare solution was created with over 800 items.
Of course this is not done overnight and it took us many Product Backlog Refinement workshops with many people from the organisation, even customer organisations, involved. As information was spread over so many silos and so many documents it is false thinking we would be able to do this in yet another silo. The only solution we saw and found useful was setting up a series of Vision generating workshops, Product Backlog Refinement workshops and Agile modelling workshops that brought the hugely dispersed knowledge together. At the same time, and for the first time ever, the organisation started to benefit from collective wisdom versus handoffs between silos.
For the practicalities of these workshops and other ways to get this sorted out the Agile way, we refer to “Practices for Scaling Lean and Agile Development” by Bas Vodde and Craig Larman or related LeSS website.
All items got prioritized with the Agfa Enterprise Healthcare BU management team. No batch prioritisation on project or any cluster, but an absolute prioritisation per item that supported the vision of the product and the lots of customer projects in many countries. Even tough the single Product Backlog is not a portfolio - even better … because of this restructuring portfolio management was not needed anymore – we would still recommend prioritisation techniques from “How to prioritize your project portfolio” by Luke Hohmann.
Great, but what is missing? Indeed, you guessed it: “estimates”. How will we get estimates from the entire organisation? Some teams were already doing Scrum, others were doing Kanban and some were still strong believers of a more waterfall approach. All this is inherent to a large incremental transition without a big-bang approach.
Hiccup one: what kind of unit could we use for estimates? Not story points, as close to half of the organisation did not understand story points at all and we did not see how to get decent estimates from others in a timely manner. So we decided to go with person days of effort. This would allow Scrum teams to recalculate their story point estimates back to person days and allow other teams to use their metrics to come with “good enough” estimates. This way the entire organisation was able to provide rough estimates on all items in the Enterprise Backlog.
Hiccup two: how do we get people to be courageous enough to provide a useful effort estimate? Useful in the sense of helping to re-prioritize the backlog items taking into account a sense of cost (based on the estimate) versus value. Some teams were not used to giving estimates, some teams were used to get punished for providing the “wrong estimate” The culture was not open everywhere to take such a huge leap forward. That’s where we got inspiration from “The Cone of Uncertainty” by Boehm, which shows us variation in estimation over time. Next to having a person day estimate we added a notice of confidence in the estimate: “S”mall when you are sure about the estimate given, “M”edium when you are ok about it, “L”arge when you are not sure about it, “XL” when you were blindfolded and threw a dart backwards to get to your estimate. With the confidence added we projected 2 different futures towards management and our internal customers. The first one is based on the estimates given, called the “optimistic” future or the “high risk” commitments as Boehm taught us that these were most probably not going to be met.
The second one was based on the estimates multiplied with a weight coming from the confidence level, based on the cone of uncertainty (XL = 4x; L = 2x; M = 1,5x; S = 1,25x). This is the future that we called the “realistic” future or the “low risk” commitments.
We speculated that the truth would be somewhere in between those two projections. How much risk to take when communicating to end customers and shareholders was not one to decide on by the teams. Teams provide a range, account managers (outside the R&D organisation) would then translate that range to something useful for their customers. This allowed the R&D to take a huge step forward in the mindset of inspect and adapt, away from committed contracts and as such live in a world of reality instead of living the illusion of control.
The entire Backlog with 800+ items got estimated by all teams involved. They were grouped in 21 product areas, spread over 5 sites. The estimates were done in about 3 weeks. The coaches and team representatives spend hours in video sessions with over 100 people attending. Discussions were timeboxed and people were asked to be courageous and provide honest input. Everybody involved knew that the results of this huge effort were taken seriously and became the new truth to communicate roadmaps and other Feature/Date combinations.
Note: Working with the results we discovered that most groups provided honest estimates. One group initially doubled their estimates at first and came back with a confession about it after discovering the real use of them and adjust the estimates accordingly.
Once this was done teams started working on this single Backlog of items that allowed the product to grow. We learned along the way that the decision to have Solution Managers taking over the Backlog prioritisation from the BU Management Team wasn’t really effective. Why is that? Next to prioritisation they also initiated workshops with customers to get a decent understanding of the needs to fulfil. In fact, they started acting as Product Managers for the entire solution and went beyond helping the teams to focus on the right things. We should have left the responsibility of requirements clarification to the teams themselves as this ended up in a silo that, in good intent, was doing up-front requirements analysis for the teams and as such introduce a hand-off layer where it was not needed. From a Lean perspective: adding waste where it didn’t belong. Then again, knowing from where we came, this was still a big step forward for the organisation, you win some – you loose some.
With the Enterprise Backlog set up, the Product Owners (in LeSS terms, the Area Product Owners) pulled in items to their Product Backlog (in LeSS terms, a variant of an Area Backlog) to feed their teams.
On a two-weekly cycle (Area) Product Backlog items were considered for refinement and execution based on the teams capacity. Up to five Scrum teams consumed a single Product Backlog. In total 21 Product Owners were pulling items from the Enterprise Backlog into 21 Product Backlogs that were consumed by in total 400+ makers (hands-on team members).
And yes… There were still project managers. Why? They were needed as the translators of the internal workings to the outside world (being 900+ hospitals spread out over the world) and helped in generating documents to comply to ISO/FDA regulations. In theory, the Product Owners could have done this work, but it was too much work and too “secondary” to consume the time of the Product Owners. Project managers in the organisation would use the enterprise backlog and add a filter on their requirements for specific customer projects. This way they get an overview of where things were (WIP) and when things might be delivered in order to keep existing communication as it was before the transition to Agile. When disagreeing with projected dates (based on team estimates and capacities) they could play with a snapshot of the backlog and its priorities. Immediately discovering what kind of impact this might have on requirements expected by their fellow project managers. Which in its turn leads to more of a customer project management team instead of individuals with each their own priority demanding items to be delivered. As such the PO’s job on facilitating outside communication towards 900+ customers and several C.A.B.’s (Customer Advisory Boards) became easier.
An extra benefit we got from our Enterprise Backlog was that it proved to be an easy way to identify which items were causing the most disturbance and then we could decide to get those handled at the start of a new release or push them out of a certain release. In the graphs shown before, these high-risk items are items that make the lines “jump” up in the chart. When this “jump” is close to a release date one could decide to move the item causing the jump to move up in priority and thus be handled sooner or lower in priority and as such out of the release. Keeping a high-risk item at the end of a release would be self-destructive.
Aside from managing risk, management got a good overview which product areas were out of balance, having some areas being able to finish all they have to do within the upcoming year and others needing 5 years (see graphs above). This way management could take action upon this months before it would become an issue, either by hiring extra mind power or by moving mind power from one area or team to another, or by merging 2 areas together, or look for other ways to solve issues. Again, looking at above graphs you could see that one line is ending up very high while others stay very low, by moving teams from a low-line-area to a high-line-area we could balance out the organisation according to the prioritized items in the backlog. This way the organisation of R&D teams was aligned with business priorities in the backlog and not the other way around where you keep teams busy just because they exist.
Having a couple of months in advance to decide on actions to balance the organisation, generated a multitude of options. This was in contradiction to the surprises we often see in organisations which leaves the management with no other option than quick fixes such as postponing things and/or hiring extra people, which in its turn takes the balance out of an organisation, complicates the situation and most probably increases the cost of delivery while not having an increased revenue.
Conclusion
By changing the inner workings from a project perspective to a product perspective we established a less complicated process using a single backlog for the entire organisation of 400+ people. Doing so we have less problems keeping our organisation in balance, we have less roles involved in getting things done, we have less problems identifying and handling risks, we have less documents produced and yet… we had better understanding of the product and its future throughout the organisation.
This shift from projects based development to product based development with a single product backlog might seem scary and undoable within your organisation but have courage! First of all make sure you are getting familiar what it means to have a single product backlog in place. Once you are familiar with the concept at hand start using the people and teams in your organisation to get there, don’t try this on your own. It is all about collaboration. Keeping the teams away from this change too long will have a negative effect and cause a lot of rework to happen.
Having less is better and… better will at the end be more... more satisfaction, more value, more innovation, more interaction…
As such also try to avoid setting up silos where they do not belong, even with good intent there are non-linear effects hampering progress. When applying LeSS it is important to stick to its basic rules even though they are, in most organisations, very disruptive.
You can read more here: Case Study of the First Steps LeSS Adoption at Agfa HealthCare
About the Author
Jurgen De Smet was a guiding hand in one of the largest Agile transitions in EU Healthcare. A master of game techniques for serious enterprise, he has taken companies in some of the most risk-averse, regulated industries and made them rock star achievers of sustainable innovation. His Belgium-based company Co-Learning supports senior and middle management in building and sustaining learning organizations. Jurgen is a Certified LeSS Trainer, Licensed Management 3.0 trainer, Qualified Innovation Games® Instructor, the author of Budgetspelen: Inwoners bepalen het beleid!, co-author of Personal Kanban in a nutshell: The practical guide to personal happiness and a leader in regional and global communities of practice that keep him freestyling with the best. Twitter: @JurgenLACoach, LinkedIn, Mail: jurgen@co-learning.be
