By Josh Roberts | June 9, 2014 | 0 Comment
Like snowflakes, no two transformations are alike. When leading an Agile/Lean transformation, my past experience, and that of many others, has been to start at the team level. Introduce Scrum, create a grass roots movement that starts with a pilot, generates energy, and eventually drives change into the entire enterprise delivery system. While that is a great approach for some organizations, is it always the best place to start?
If you are currently a Development Manager in the organization, perhaps it makes sense. After all, you probably don’t own the entire delivery pipeline, but you likely do have authority to introduce a new team management framework, like Scrum. You already have a good understanding of your team’s current state. You know what’s working well, not so well, and how work flows into your team. You can have an immediate impact at the team level; be their Agile Coach.
What if you are new to an organization? How best do you develop a “mental model” of the organization’s current delivery state so that you can start to prescribe an approach? And, true to Agile practices, how can you do it without suffering from paralysis by analysis? Sure, you could do an organizational assessment by conducting interviews, surveying, examining process documents, collecting data, etc. You could be one of the The Bob’s from Office Space.
Just a few weeks back I would have said start at the team level. But, as I thought more about it, I decided a Portfolio Kanban offered some advantages. Not only could we visualize how work was flowing through the entire delivery system (better than any assessment), it would be a great learning tool to introduce Lean practices to the organization and engage with the teams. And, as Alan Shalloway points out in “Demystifying Kanban”, Kanban makes a great Transition Management System.
Sometimes it’s the journey that teaches you a lot about your destination – Drake
This week I also decided to start my Transformation Backlog and take an incremental approach to running the transformation initiative. While there are certain Themes (e.g. Teams, Servant Leadership, Agile Requirements, Engineering Practices, etc) that are key to all transformations, the timing and sequencing of activities will vary from organization to organization. And, while laying out a detailed 1 – 3 year Transformation Plan can feel good, we should practice what we preach; identify the high-level Themes and take an empirical approach to the roll-out. For example, starting with a Portfolio Kanban wouldn’t have been the first step in many Transformation Plans, but I do think it’s a good place to start.
I see a lot of benefit from engaging the transition steering committee in a Scrum-like approach. Together, we will groom the backlog, plan our iterations, reflect, and apply our lessons learned. The Transformation Backlog, Sprint Backlog(s) and Sprint Goals will be openly published/visible to the organization. What a great educational tool!
As always, I am interested in hearing from others. Please share your thoughts and experiences!