Aug 2015

Screen Shot 2015-08-23 at 11_Fotor_Collage

Facilitating SAFe Team Self-Assessments

As part of an Agile Release Train’s commitment to relentless improvement it is necessary for all the teams on the train to reflect and assess the effectiveness of their Scrum and XP practices on a regular cadence. For most once a PI seems to be a logical frequency. The Scaled Agile Framework provides a self-assessment tool to support this process and makes it freely available for download at: http://scaledagileframework.com/art-metrics/

I have found clients often want to do self-assessments by sending them out as an online survey for team members to complete individually.  Personally I am not keen on this approach for a number of reasons. Firstly, most new agile teams don’t have a clear and consistent understanding of what good looks like, therefore, they tend to overstate their level of maturity. (The first time we conducted a self-assessment with the EDW Release Train, the most mature team gave themselves the lowest score and the least mature teams gave themselves the highest score!)

Secondly, by completing online surveys the team doesn’t have an opportunity to discuss their different perspectives and reach a shared understanding.  In my experience self-assessments provide an excellent coaching opportunity, especially if you are the only coach supporting an ART and doing so part time. Often this can be a simple as reminding them of what a 5 looks like and resetting their anchors. Even though an RTE can take a DIY approach to this, an external facilitator can be very valuable and as a coach this is your opportunity to ensure the assessment is only used for good and not evil.

Last year I was getting ready to facilitate the first round of self assessments for a new train and I got thinking about my approach to facilitating these session. My priority was to ensure that every team member got an opportunity to express their individual point of view. Which led to me contemplating how Planning Poker uses the simultaneous reveal to prevent anchoring. One idea I had was to create cards numbered with the 0 to 5 rating scale, but that felt a little boring. Then it came to me - the perfect combination of silent writing on post-it notes and a big visible information radiator…

Continue reading...


Jul 2015


Spotifying SAFe with Guilds, Chapters and Squads

Last month’s Agile Australia conference played host to both +Dean Leffingwell, the creator of the Scaled Agile Framework and +Anders Ivarsson, Spotify Agile Coach and co-author of the Scaling Agile @ Spotify paper. Those who were able to drag themselves (and their hangovers) out of bed early enough on day 2 of the conference were treated to an “Ask the experts” panel featuring both +Dean and +Anders, along with +Linda Rising and +James Shore.  I’m sure you won't be surprised to learn that it was not long before an audience member asked what might seem like the obvious question - SAFe vs. “the Spotify model”.

After the mandatory cringe from +Anders (the Spotify folk really wish the rest of us would stop calling what they do the "Spotify Model”), both +Anders and +Dean were quick to agree that it was not an either or question. To quote +Dean Leffingwell, "We had +Henrik Kniberg in class last week and I think it would be fair to say we learned a ton from him and I think they will learn a ton from us." As someone who has been using ideas from +Henrik Kniberg’s books and the Spotify folk since very early in my SAFe journey I must say I agree with the sentiment.

The first time I came across the Scaling Agile @ Spotify paper was when EDW Release Train Engineer +Wayne Palmer decided that the EDW Agile Release Train would benefit from creating a series of “Guilds”. Despite +Wayne's enthusiasm, I don’t think he got past telling us his great idea was “Guilds” before the rest of my leadership team laughed him out of the room, having quickly reached the consensus that “Guilds” sounded like something from Lord of the Rings and had no place on our Release Train! I remember +Wayne invoking the power of wikipedia in his eagerness to help us understand his vision. “According to Wikipedia, a Guild is a collection of artisans who are responsible for the practice of their craft.“, he argued. Resulting in only more laughter from the team. Not one to be easily deterred +Wayne took it on the chin and set about convincing me he was onto something...

Continue reading...

May 2015


How to be Agile With a Fixed Scope Business Case

One of the challenges I find organisations face when starting out with agile is navigating their existing in flight projects and programs with traditional fixed time, cost and scope business cases. In my latest 2-part blog series I explore how the lean principle of small batches and a focus on business value can help find your way through this maze. 

Part 1: Small Batch Funds Release

Part2: Business Benefits over Business Requirements


Apr 2015


Taking the Status out of Standups

Today was a busy coaching day on a large release train with lots of good coaching conversations.  When I got to the "warm and fuzzy moments" part of my coaching journal at the end of the day, memories of the scrum of scrums in the morning put a such a huge smile on my face that I had to come home and blog.

One of the first things I will do walking in the door as a coach is to go and 'chicken' at stand-ups. 99 times out of a hundred, they'll sound like a status report.  How can it be a self-organising team if they have a daily status report?  It's meant to be the timeout where the team gets together for a moment to work out how best to work together that day on moving towards their goal.  Often, I find the real standup happens just after the formal one.  The scrum-master walks off, and all of a sudden the team lights up and has a great conversation.

Fixing a standup is a great place to start as a coach.  Changing that one conversation the team is guaranteed to have every day will lay a strong foundation for much of the deeper work to build on.  And I've built up quite a library of tips and tricks from conferences, blogs, colleagues and blind experiments.  The best ones always vary according to the team - I just offer a smorgasboard and encourage the team to pick one or two and try them out.

Continue reading...



Mar 2015


Leaning into SAFe with Feature Flow

Last year I wrote about the communication cadence and in particular the daily feature wall stand up that was the heartbeat of the EDW Agile Release Train.  Recently I received an email from someone who had read this post and wanted to know more. As he quite rightly pointed out the "post lacked the details to effectively implement a similar event but it sounded really worthwhile."

When I sat down to reply to this e-mail, I found myself thinking about the power of the visualisations more than the event.  The inwards facing Release Train Engineer+Wayne Palmer, had been determined since the birth of the EDW Release Train to create a physical dashboard that represented the performance of the system.

The first incarnation of this was captured in my colleague +Mark Richards's blog back in 2013. This version of the "feature wall" provided a 10 iteration view of what each feature team planned to work on. At first it was +Wayne's hope that the ScrumMasters would self organise a consistent approach to visualising the work, but it was not long before his OCD kicked and he prescribed a legend. Large white cards for features in play, large green cards for features in discovery, small pink cards for defects and small blue cards for innovation work. Teams would visualise their plan for each feature by placing cards and an effort estimate in the relevant iterations. Each team showed the capacity they had available (based on historical velocity and planned leave) and the amount of work they planned to complete each sprint. This 10 iteration view also helped us plan our involvement in the enterprise release integration testing for those occasions when we could not decouple our deployments from an enterprise release.

+Mark always says you can tell a good wall by the conversations that are had at it and there was always plenty of conversation at this wall, mainly about capacity and forward planning.  After a while +Wayne reached the conclusion that while these discussions might be interesting to theProject Management / Pipeline folk, they were not the right conversations. The conversations taking place were predominantly how to get more work onto the train. It was a view of capacity management which didn't truly take into account what people were actually doing and how full the train was.

Continue Reading...


Dec 2014

Screen Shot 2014-12-06 at 2.53.31 pm

Moving from belief to action – implementing WSJF for value based prioritisation in SAFe (Part 2)

In my last post, I described the simulation I use to teach Cost of Delay (CoD) and Weighted Shortest Job First (WSJF).  This often provides the impetus to begin, and one of the beauties of the model is that you can adopt it before you’ve even begun to change delivery method.  Beginning your change with a shared definition of value and a rich supporting discussion is a great launch point!

The first step is to make sure you know your vision and overarching strategy.  This need has usually emerged in the debrief on the simulation.  One group will mention how they paused with 10 minutes to go to say “what kind of city are we really building here?”  Every other group will look around and say “aaah, if only we’d started there!”.   Pulling it back to SAFe terminology, we are looking at the workshop(s) to define the strategic themes and portfolio vision.

With a sound strategic vision in place, we look next at adapting the model to the organisational context.  Three key questions need to be answered:

  • Do we use Dean’s components for CoD?
  • Do we weight the components equally or otherwise?
  • What specific factors contribute to each component?

Continue reading...



Aug 2014

Screen Shot 2014-08-23 at 4.31.59 pm

Getting from theory to practice with Cost of Delay and WSJF in SAFe

Recently, I’ve noticed a number of threads on the SAFe linked-in groups indicating people are struggling to get started with the SAFe “Weighted Shortest Job First” (WSJF) prioritisation model.

When I first heard +Dean Leffingwell teach the model I thought “wow, this fantastic.” His use of a proxy model for Cost of Delay (CoD) seemed inspired. +Don Reinertsen had provided compelling arguments for the power of fully quantified CoD. On the other hand, all too many people abandon all attempts to have a value discussion because it’s “just too hard to quantify”. The 3-part proxy in SAFe seemed simple enough to enable people to begin.

The problem, I learned, was one often encountered in people digesting Don’s principles of product development flow. It sounds like fantastic theory but the complexity makes it challenging to find a starting point. My first breakthrough came in early 2013. I was teaching a public Leading SAFe class, and had 5 people from one company on the same table. While most people tackle the WSJF exercise as individuals, this group had a shared list of features and attacked it as a group exercise. They made up planning poker cards from post-its and started voting. As I listened to the conversation, I got inspired. Not only did I hear a great discussion, but I could hear what they had misunderstood from the theory. Continue reading...