In business environments, professionals are still questioning if agile scales at the portfolio level, when in fact the answer is quite clear - yes it does. However, I am still seeing immature practices and behaviours at this level of the organisation.
The other day, a quote jumped into my eyes while scanning the Twitter feed. I wish that the following situation was an exception, but unfortunately too often it is the norm:
“Worst Management: Poor productivity compensated by starting more projects. Result: 150 people working simultaneously on 400 projects.”
In my view this is not a team problem, it is something much more systemic within the organisation.
The Scaled Agile Framework (SAFe) (Leffingwell, 2011–14) is a scaled approach to Agile adoption. Officially launched in 2012, it draws on the experiences of its creator, Dean Leffingwell, and his collaborators as to ‘effective practices that worked for us’ when they found Scrum and eXtreme Programming insufficient in addressing the problems faced by large software organisations.
SAFe is a mix of original work and a container for several existing Agile approaches. SAFe is organised around three layers:
- Teams, who adopt Scrum (or Scrumban) and eXtreme Programming.
- Programs, each of which contains 5–12 teams working towards a common goal.
- Portfolio for funding and coordinating programs.
The Scaled Agile Framework (SAFe) provides a good starting point for thinking about how you might organise work at the Portfolio level in an agile way with a prototypical Kanban Board. (See Below)
In summary, it consists of the following steps/stages:
- Funnel - this is the capture state, where all new “big” business ideas are welcome
- Review - where preliminary estimates of opportunity, effort and cost of delay are established
- Analysis - where the more thorough work is done to establish viability, measurable benefit, development and deployment impact, and potential availability of resources. A lightweight business case is developed to gain approval of the Epic
- Portfolio Backlog – these epics have made it through the Portfolio Kanban with “go” approval.
But we can’t just blindly adopt, we still need to implement with our brain ‘switched on’.
In my day-to-day experience with clients and organisations, there are a number of anti-patterns that I see. These present a risk of doing agile at scale rather than being agile at scale. It’s the same as Golf; first you learn how to hit the ball then you learn how to play!
The most common anti-patterns I see are listed below.
Ideas not aligned to strategy
Senior Executives spend a serious amount of time and money on defining their strategy. Then, they will proudly present their Strategic Themes for the next year or longer.
This is great - it makes sure that the organisation has a vision for the future. But then it gets ignored. Harsh? Maybe. However, have a look at all the ‘big’ business ideas and see if (a) they map to the strategic themes, and (b) if they do, are they a balanced representation of the strategic themes?
Let’s apply this to our personal life. Most of us will have a Pension Plan. Within that Pension Plan we probably have a number of ‘funds’ that we have decided to invest in. For example I have decided to invest in 4 funds to balance my investment risk:
- European Equity
- International Equity
- North American Equity
- Global Equity
I have decided to invest my monthly contribution equally across the 4 funds.
Having decided on a pension strategy, it would be nonsensical to then completely ignore this and start investing in Asian equity, or alternatively deciding to invest everything into the European Equity. And this is exactly what I see time after time at the organisation’s portfolio level when it comes to either the ideas or the approved projects.
Too much Desktop analysis
I guess we are all familiar with hefty business cases based for the most part of SWAG numbers – some wild arsed guess! Too much theoretical analysis not based on any real world testing.
Hence I really like the concept of Gemba.
Gemba is a Japanese term meaning "the real place." Japanese detectives call the crime scene gemba, and Japanese TV reporters may refer to themselves as reporting from gemba.
In business, gemba refers to the place where value is created; in manufacturing the gemba is the factory floor. It can be any "site" such as a construction site, sales floor or where the service provider interacts directly with the customer.
The gemba walk, much like Management By Walking Around (MBWA), is an activity that takes management to the front lines.
So yes, by all means, go ahead and create your ideas and a value creation hypothesis. But then get out into ‘ the real place’ and test that hypothesis with the front line, your customers – would you use this, would you buy this, how much would you pay for this?
This is the real acid test of value delivery - and not some desk-based analysis.
Too much Team WIP
If I put more paper into the printer it will print faster. – Er… no! So why do we think the same about projects? The quote mentioned at the beginning of the blog applies to this situation too, and can be accompanied by the following worrying quote:
“I can beat yours. I met a client that had 18 people and 95 projects when I arrived.”
Quite frankly, it is ridiculous. We need to not only limit the amount of Work in Progress (WIP) for the teams, but we also need to stem the tide upstream.
There is absolutely no point having an army of analysts creating more and more approved projects that will never get delivered. Hence, we also need to constrain the Portfolio Backlog, otherwise we are undertaking ‘wasteful’ analysis.
Projects which are too big
We really must stop funding 3, 4 or 5-year projects / programmes. If you have children, would you give them their entire pocket money for the year at the beginning of the year? Of course you wouldn’t - unless you want to wake up buried in candy and chocolate. You would probably give it to them in tranches, probably weekly or monthly.
To be honest, I wouldn’t want my salary paid in one lump at the beginning of the year either. And yet we do that with project funding, when in fact it’s the same principle: you don’t want all your long-term project money to be poured in at the beginning, because the risk of not managing it well is much higher.
Considering this, why don’t we only approve project funding for a maximum of 3 months? At the end of the 3 months demonstrate what you have achieved and more importantly what value have you created. That value creation can then help fund the next tranche.
You might want to shout: ‘We can’t create value in 3 months!’ If this is the case, let me provoke you. The Chinese can now build a 57 story building in 19 days. Now, let’s give this a second thought. Are we sure we can’t do something in 3 months?
PMOs don’t close out on Benefits Realisation
This practise really frustrates me the most. We spend so much time pouring over theoretical business cases, analysing every facet, and questioning this, questioning that. And yet when it comes to realising benefits, organisations seem ambivalent. Why?
‘We have invested all this money in delivering this project... Surely we should track whether the anticipated value has been created.’ You would be surprised how often this is not the case.
Back to my pension portfolio. I get an annual statement of how my pension funds have performed. Based on their performance I might review my pension strategy. It’s as simple as that - thus it is not much to ask organisations to do the same at the end of every project, and say, quarterly across the portfolio. Are we achieving what we said we would achieve? Are we focusing on the right things?
It’s your turn now. Do you find the same things in your organisation? If so, how do you stop these anti-patterns? Share your thoughts with us using the comments box below.
Did you miss the Agile Evening Briefing hosted by Darren on 7th July 2015 - Does Agile Scale to the Portfolio? View the slides here and a selction of photo's from the evening below.