Thursday, 17 December 2015

Good PI Planning is the Enemy of Great PI Planning

When I first met +Dean Leffingwell, I had already launched the EDW Release Train - without doing PI Planning. I was attending one of the early SPC classes in Boulder, CO. It was day 3 before I built up the courage to ask Dean the question that had been on my mind since I decided to attend the class: What should I do about the fact we weren’t doing PI Planning?

Tuesday, 15 December 2015

There is no such thing a Feature Owner... Or is there?

When an organisation introduces agile, it is not uncommon for there to be a mass rollout of Agile Fundamentals training, where the role of the Product Owner is positioned as being an empowered business person who is colocated with and 100% dedicated to work with the agile team. This sounds wonderful in theory, but when we start to scale this begins to get tricky.

I once worked for an organisation that had a policy whereby you were only allowed to run your project agile if the business made a product owner 80% available to the project. Of course, the business wasn’t silly, they knew how to get around this constraint - either find someone in their department who isn’t adding a whole lot of value and allocate them to support the agile team or hire a contractor off the street and have them fill the role of Agile Product Owner. Problem solved!

Tuesday, 1 December 2015

Scaling Agile - Cucumber Podcast

As part of my participation in CukeUp Australia last month, the team at Cucumber invited me to join them in recording a podcast about Scaling Agile and how large organisations can make it work.

You can tune to the discussion with +Terry Yin+Matt Wynne+Hamish Tedeschi,  +Steve Tooke and of course me, using the +SoundCloud player below.

Monday, 23 November 2015

The Journey of SAFe and Thawing Middle Management

While I was at Agile 2015, I had the opportunity to catch up with fellow Aussie +Craig Smith from +InfoQ. We talk about how I came to lead Australia's first Scaled Agile Framework (SAFe) implementation and both my Agile 2015 sessions - The Magic Carpet Ride: A Business Perspective on DevOps and Thawing the Frozen Middle.

You can watch, listen to or read the entire conversation at:

Tuesday, 10 November 2015

From teams to tribes: Creating a one-team culture in DevOps

One of the topics I have been talking about at various conferences over the last 18 months, is scaling culture with agile tribes. This is a topic that resonates with people in both the Agile and DevOps communities. As part of my participation in the DevOps Enterprise Summit last month I was invited to share my thoughts on this topic on the TechBeacon blog:
From teams to tribes: Creating a one-team culture in DevOps

Wednesday, 26 August 2015

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:

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 sessions. 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…

Tuesday, 28 July 2015

Educating DevOps: A Business Perspective

Back in March I was approached to contribute to DevOps Perspectives, a quarterly eBook sponsored by +CA Technologies. The resulting article, "Educating DevOps", starts on page 26 of "DevOps Perspectives 3: Straight talking and the latest thinking from the DevOps frontline".

Use this link to download a copy of the eBook, which also includes contributions from +Dan North+nicole forsgren and +Matthew Skelton.

DevOps Perspectives 3

Tuesday, 14 July 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”.

Wednesday, 27 May 2015

How to be Agile With a Fixed Scope Business Case? Part2 - Business Benefits over Business Requirements

In my previous blog post, I explored how “small batch funds release” can be an enabler for organisations starting their agile journey constrained by a traditional fixed scope, time and cost business case. With this more flexible but also more tightly controlled funding process in place, it is time to turn our attention to navigating the “signed off”, “locked down”, “fixed scope” requirements contained in the Business Requirements Document (BRD) that underpins the business case.

Software developers working in traditional software development shops have been conditioned to expect their work to arrive in the form of requirements documents. Many organisations new to agile have fallen into the trap of transposing hundreds of pages of requirements documentation into thousands of “user stories”  in a misguided attempt to provide “agile requirements” to the dev teams.  As logical as this may seem to some this is not the answer.  I could write write a whole blog series on the flaws in this approach, but some words from +Mary & Tom Poppendieck's latest book The Lean Mindset summarise it well: “A detailed list of requirements is not the starting point for good engineering. The Wright brothers did not start with requirements; they started out with an idea: build a glider and learn to fly it and then add power (and don’t get killed in the process).” So our challenge is clear, we need to make a shift from requirements to ideas.

Monday, 4 May 2015

How to be Agile With a Fixed Scope Business Case? Part1 - Small Batch Funds Release

How do you embrace change when your hands are tied by corporate red tape?

Many organisations I work with have existing business cases with fixed scope, time and cost expectations when they first decide to "go agile". The early conversations about "going agile" are generally prompted by either some misstep with a previous project or delivery issues with an inflight project. Agile is the magic answer that is going to radically improve the way Information Technology deliver projects. As the technology teams begin to "embrace change" and deliver "clean code", pressure begins to mount on the business processes that govern the project. Cries of "that's not very agile" are heard at every turn and the tension between the business and technology that had started to relax begins to increase again.

If you’re in middle management, you begin to feel trapped. You don't make the rules. Changing the corporate business case process is beyond your scope of influence. The project's governance board is holding you accountable for delivery of the project exactly as it is laid out in the business case and supporting business requirements document. So how do you escape the locked box and enable true business agility?

Wednesday, 11 March 2015

Scrum of Scrums 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.

Wednesday, 11 February 2015

Bridging the Great Divide Between the Business and IT: A Business Perspective

A while back a friend of mine suggested I take the time to write the story of how a business general manager found agile i.e. my story. While bits and pieces of the story appear in this blog, this is the first time I have put pen to paper and written about my journey in detail. This forms the basis of my latest article in the Cutter IT Journal. In this article I explore how agile helps change the dynamic between the business and IT, as I experienced it.