The Change to Agile Development – Make it Visible
A common occurrence when driving the change to agile development is that once you start to try to increase the circle of influence of the initiative, you will undoubtedly run the risk of encountering cultural, personal and political resistance to the change. There are certainly a number of team-level and top-down stakeholder-level approaches which agile coaches and agile champions can pull from their tool belts; they select the appropriate ones based on the context and their circle of influence/control. The one universal tool for agilists and Lean folks that is often not leveraged adequately, and the one I want to talk about in this post, is the fundamental concept of ‘make agile visible.’
For example, let’s say we have a scenario where teams in one group are working in an agile development fashion and producing deliverables that then need to be assembled and deployed as a release by a second group working in a more sequential manner. This second group delays the release of value and causes significant work inventories to stack up in the overall value flow. A third factor is that this group is also testing the release package(s) for deployment (late-stage integration) and sending defects back to the teams who originally created the features of the release long after they were considered done. This adds risk to quality, and more variability to the agile development team’s work queue.
One of the fundamental ways to shine a light on this issue objectively is to measure and make visible the metrics to show the cost of delay by such a release scenario.
With these metrics you are much better equipped to have conversations with stakeholders. Having a value flow that shows where the bottlenecks are is one way. A team with whom I have worked has two tiers of Kanban boards, which serve as an excellent means for identifying the unnecessary cost and risk being added to the system. The top tier is for the
release-level picture and the second level(s) are for the teams involved in building, testing and releasing the product.
In the scenario I described, you would see a significant inventory of demand for service stacking up in front of the release operation group. This adds inherent risk to throughput, quality and business agility. Depending on the product/service domain, some teams will decouple the cadence of building the product from releasing the product. This tactic would clearly shine the light on the bottleneck of a more waterfall process-oriented release group and how they are preventing the accelerated delivery of value to customers and users while impeding agility.
Lastly, ensure you truly understand the perception of the ops folks if you find yourself experiencing a similar scenario. Most resistance to change is driven by fear, which is usually rooted in not knowing the benefits to the individual (not just the benefits to the company). This can be remedied by education and possibly a pilot. Second, the management over the ops group may have a reward system that motivates behaviors and work patterns more consistent with serial execution. Find out what metrics they are using to drive the reward system, and whether they’re counter to a team-based, outcome oriented reward system. If the reward system is contrary to agile team execution, this may be another front upon which you might need to influence change by making the dysfunctional reward model visible.