Sunday, 29 September 2013

What Happens to Project Managers When You Implement SAFe?

What happens to Project Managers when you implement SAFe? I see this question come up time and again and while I am sure there is more than one answer, in my experience, the role of the Project Manager changes and there are less of them. In the specific case of the EDW Agile Release Train, pre-SAFe there were 18 Project Managers supporting up to 5 projects each. Today there are 4 Portfolio Managers each overseeing around 20 projects. Portfolio Managers are generally aligned to a specific line of business or program of work. They own the relationship with this stakeholder group on behalf of the Release Train.

Our Portfolio Managers are servants to our development teams, they help protect the teams from bureaucracy and support the teams by removing blockers beyond the teams control. When new projects arrive, they work to smooth the transition of the work into the development teams. They do this by understanding the end to end project and the role EDW needs to play, establishing the priority of the work and securing funding.  They confirm the stakeholders and induct them into our delivery approach, and where possible help break the projects down into pieces more easily consumed by the development teams.

Most of our epics, start with an analysis spike, which we call discovery. This is where our feature teams establish the high level design, estimate the effort involved in delivering the epic and work out an indicative release plan based on their current backlog. The Portfolio Managers support the teams by overlaying the financial profile and packaging up the findings for inclusion in the various enterprise gating processes.



During the delivery of the epic the Portfolio Managers participate in the daily Feature Wall stand up with the development teams, escalate and resolve blockers, manage the project financial and co-ordinate epic showcases with stakeholders. Where necessary, Portfolio Managers, will also negotiate changes in release windows and commercial coverage for additional features. Post deployment, the Portfolio Manager arranges for the formal project closure, facilitates a retrospective on the epic's delivery and obtains a Net Promoter Score from the epic owner.

So what happens to project managers when you implement SAFe? In our case, some grow, taking on the huge responsibility across a portfolio of epics and some move on, to less challenging, more traditional project management roles. I have a huge respect for our Portfolio Managers, its a very challenging role, which requires very advanced juggling skills to keep all the balls in the air.

Sunday, 22 September 2013

How to Grow an Agile Release Train

The EDW Agile Release Train was established as a fixed capacity model consisting of five permanent feature teams. As our ability to deliver has improved over the last year, the demand for our services has increased. This lead to us to contemplating our options - do nothing, add another team. extend the capacity of the existing teams - and deciding to run an experiment.

The train teams were all 8 person feature teams consisting of 1 Scrum Master, 1 Technical Lead, 1 Quality Lead and 5 Developers. Given, the optimal size of an Agile team is considered to be 7 ± 2, in theory we could add another developer to each team and increase throughput. The idea was appealing, it seemed logical. Worst case, should our experiment fail we could always go back to teams of eight by launching a sixth team.

Sunday, 15 September 2013

Switch: How to Change Things When Change Is Hard by Chip & Dan Heath

Having read and really enjoyed Chip & Dan Heath's first book, Made to Stick: Why Some Ideas Survive and Others Die, I bought Switch: How to Change Things When Change Is Hardwhen it was first released, however it sat on my bookshelf gathering dust until I heard +Jean Tabaka talking about it when she visited Telstra in June. In Switch, the Heath Brothers have done a a great job of making the science of change management simple. The book borrows an analogy from +Jonathan Haidt's The Happiness Hypothesis of the Elephant (our emotional side) and the Rider (our rational side). The premise being if the Elephant doesn't want to go in the direction of the Rider, than the Rider is out matched and the Elephant goes the way it wants.

The book is broken into three sections:
  • Direct the Rider - Find the Bright Spots. Script the Critical Moves & Point to the Destination
  • Motivate the Elephant - Find the Feeling, Shrink the Change, Grow Your People
  • Shape the Path - Tweak the Environment, Build the Habits, Rally the Herd

What I particularly like about this book, was the accessibility of the message. As Agilists, it is often our role to change or transform the teams we work with. Switch provides simple techniques that Agilists can immediately apply. I know this, because I have seen it in action. So no matter what your role, if your work involves changing behaviours this book is for you.

Some of my favourite takeaways from Switch:
"What looks like resistance is often a lack of clarity.
"Find the bright spots.. What's working and how can we do more of it?" 
"In almost all successful change efforts, the sequence is ... SEE-FEEL-CHANGE. You're presented with evidence that makes you feel something." 
"Shrink the change." Not only does this help flow, but "When you engineer early success, what you are really doing is engineering hope".
To read about how we applied Switch when introducing changes to the software development teams that formed part of the EDW Release Train check out: Switch in Action: Business Change Management Applied to Software Engineering

For a more extensive list of books that have inspired me and my team check out our bookshelf: http://www.prettyagile.com/p/bookshelf.html

 

Sunday, 1 September 2013

A Perspective on the Scaled Agile Framework

I have watched with interest and disappointment over the past month or so as Agile thought leaders have taken to publicly passing judgement on the new kid on the block, the Scaled Agile Framework aka SAFe. In the interests of full disclosure, I am a certified SAFe Program Consultant, I use SAFe with my team and my teams approach to implementing SAFe is featured in the case studies section on scaledagileframework.com.

Over two and half years ago, I went on two days of Agile Fundamentals training lead by +Mark Richards. Mark's approach to introducing Agile was to provide us with a tool kit we could use to apply Agile in our work place. I remember talking about aspects of Scrum, XP, Kanban and other methodologies. We talked about various agile values, principles and practises, and we participated in a number of learning activities. After the two days in the classroom and a heap of new ideas to think about, the message I walked away with was - "Agile is a term for a range of methodologies that have in common the principles embodied in the Agile Manifesto. We should embrace the full range of tools available to us and chose which to apply in any given context."

Following the training, we commenced our first agile "pilot" project. The transparency introduced by agile, quickly led to all new projects using agile. It was only a number of months before we had 6 agile teams, across 4 projects, working in parallel with a large outsourced offshore team, on a single code base. As if this was not already a recipe for disaster, we also had no clues as to how to effectively co-ordinate the teams and the work. Agile Fundamentals had not prepared us for this at all!