Skip to main content

Dinner with Dean at Agile Australia 2015

At the 2015 Agile Australia pre-conference speaker’s dinner I was seated next to invited speaker Dean Leffingwell (pictured here on the left) founder of the Scaled Agile Framework: ‘SAFe', a process framework invented to help organisations scale their Agility beyond a few teams to much larger software delivery teams. Applied to teams and departments numbering in the hundreds, SAFe is now gaining traction at several large Australian organisations, Telstra and Australia Post to name but two notable examples happy to showcase their SAFe successes. 

I shared with Dean one of my frustrations at our implementation of SAFe at Auspost where I was a Head of Digital Engineering. Although I found many good things in the framework, and had blogged previously on the topic myself, I observed that SAFe can lead to software delivery teams becoming bloated with people, and that the ‘Big Picture’ SAFe artifact contributed to the problem. 

This diagrammatic model shows how the three major levels of the framework are represented and supposedly interact, being Portfolio, Program and Team. A quick scan reveals 40 little people represented in different teams and roles that are identified in the framework - and no, I don’t believe the diagram needs to be interpreted that literally. 

However, one of the perennial problems associated with large enterprises is scale; numerous people tend to mass and coalesce around the work, whether they are required or not. A phenomena fuelled by the nature of territory grabs common in an internally competitive enterprise - large teams are advantageous for positional power in an organisation.

In our efforts to apply SAFe to new programs of work, we observed people of many and varied roles, from Project Managers to Architects to Portfolio Managers, pointing to the Big Picture declaring “That’s me, I’m needed in that team” or “We need, a heap of those [teams, roles or programs] in order to deliver product X“ or more darkly “I think I need more budget to hire some of these roles in this here picture”. 

I relayed this observation to Dean, and also my fear that SAFe release trains were trundling along inside other organisations carrying too many passengers - roles that would be considered ‘waste’ in the application of Lean thinking - he replied with an phrase that was both sensible and chilling: “I agree, but you know those people are inside the organisation anyway, would you rather they were involved and supporting you, or not involved and trying to stop you?” 

It’s a likely truth that enterprise organisations waste time and money detracting from each other internally, instead of focussed on the business outcomes. Therefore, is SAFe just a pragmatic compromise that is better than any non-agile approach to delivery? It’s akin to a slogan I keep threatening to print on a t-shirt “It might not be agile, but it’s better than waterfall”. 

The topic of scaling agility is something of increasing interest to the Agile Australia conference audience. As the base of organisations and practitioners applying agility widens, it’s attracting a lot of discussion in the community, as die-hard practitioners debate the merits of scaling frameworks, and consultants sell training and approaches to scaling agile. That’s why my talk at Agile Encore this September is “Scaling agile to the enterprise - frameworks and the debate!” and I hope you’ll be able to join me there. 

(pictured on the right is Cameron Gough GM of Digital at Australia Post and I am in the middle pretending not to have arms) 


Popular posts from this blog

Business Requirement Documents are just no good and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 
If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.
Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to …

Gamify your children

Inspired by James Ross’s LAST conference talk on The Shamification of Lamification and the Reclaimification of Gamification I was motivated to try and “Gamify” the school holidays for my three children, Leo aged 8, Chloe 9 and Max 10.
Buy-in is everything, so the first thing we did was a quick workshop to extract the kids ideas. I asked them to write their ideas for good rewards on sticky notes, with a few examples for context, such as ‘trip to the movies or ‘play date with a friend’ . They had 5 minutes to come up with their ideas – one idea per sticky note (as always).
They then read out their ideas for all of us to hear, there were a few duplicates and also a few comedy suggestions. Even though we had ruled out crazy stuff, such as rewards of a million dollars, Leo had written down ‘A unicorn for the back yard’ reading it out with gleeful giggles.
Then they spent 5 minutes writing down tasks that they could do to earn rewards. By now they had the hang of it and quickly came up with t…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …