How to: Introduce Agile with an adaptive framework
Try not to make a BDUF waterfall plan for introducing Agile
There is a temptation to make a great plan for an “Agile transition” involving finding best practices and leading all teams in the same direction. There are many reasons not to do this, one in particular stands out: if you believe in an adaptive framework for development, using the agile mindset, associated values and principles, what harm is there introducing Agility with the same adaptive framework, values and mindset.
Instead of the big up-front plan, just start. Get a couple of teams going with Scrum/Kanban/XP/Crystal/... etc., and let’s make an assumption that they will struggle with organizational issues that they cannot fix within the team. It isn’t a bad idea to have a Community of Practice in place to help them eradicate their issues, clear the path of their obstacles, as they arise. This CoP, call it whatever you want to call it, we’ll call it the “Agile Helpdesk CoP”, for lack of better name, works on a backlog just like any other team. Their backlog items will be solely consisting of items that are impediments to organizational agility - organizational items that are outside of the teams’ sphere of influence to fix directly.
Backlog items they will see will be items ranging in subject from culture, training, tools, business process, work policies, ethics, and so on. Basically anything that slows us down, impedes our agility that cannot be solved within the team will appear in the Agile Helpdesk CoP’s backlog. And this backlog is prioritized by what slows the teams down the most. In this way we can plan for the best, and assuming there will be failures, and prepare for the worst.
An example of a backlog item from one of our clients: “As a Product Owner I want an iterative finance process so that I do not have to guess a budget for a year of development that has not yet been fully planned.” The result in this case was the creation of a rolling, look-ahead finance process matching the rolling, look-ahead release planning needed for adaptive, iterative development. If feedback during Sprint Reviews is unfavorable, we can test and retest plans with the evidence of progress based on pillars of transparency, inspection, and adapting to any change needed.
The idea is that the backlog is managed with Pareto in mind, with the most urgent items bubbling to the top. We can then focus on the 20% of the activities netting 80% of organizational agility improvements creating “just in time” agility using an empirical process vs a big plan up front. Photo by ruhender Pol 78 via Flickr, CC Licence Info
