Alternative Approaches for Implementing Agile
Top-down implementation of agile is a commonly use approach for agile adoption in organizations. Alternative approaches exist, like implementing agile by stealth, using continuous improvement teams, starting with a quiet phase or taking baby steps by implementing a limited set of agile practices.
In the write-up sneaking up on agile development on FCW, Mark Rockwell reports on the Management of Change 2014 conference. A conclusion from the conference is that implementing agile by stealth might be the most effective way:
"As soon as you say 'agile,' people get nervous," said Shawn Kingsberry, CIO of the Recovery Accountability and Transparency Board. Even though he led his agency's efforts to get Recovery.gov onto the cloud in 22 days using agile development techniques, he advised agencies not to emphasize those techniques but to focus on desired results instead.
Kingsberry agreed that agile development requires commitment but added that sometimes coaxing IT managers into using the techniques can be done stealthily. "You don't have to say, 'This is a cool agile thing,'" he said. Instead, adoption can be done incrementally by introducing some development techniques, such as setting looser goals and focusing less on technology and more on what the agency wants to accomplish.
Tribhuwan Negi wrote the blog post do not get lost in agile ceremonies in which he explores ways to adopt agile with continuous improvement teams and communities. He starts by stating two approaches for agile adoption in organizations:
Agile programs in organization start either in public or stealth mode. They are either, all-teams-together or pilot-team-only agile programs. ‘Public agile initiative’ has team or organization announcing its agile initiative with a big organization wide fanfare. Stealth mode programs are executed with limited or no noise, with one or more specifically identified teams.
According to Tribhuwan focusing too much on the agile ceremonies with incorrect measures to judge the progress of agile initiatives can have negative effects on the agile transition. In stead, agile adoption programs should stimulate agile improvements:
My advice to agile stakeholders is -- ‘ground yourself’. You have just launched an agile rocket in space; you have big tasks ahead to get it into a right orbit, and then drive it into an unknown but continuously improving territory to reap real benefits endlessly. Agile leads need to initiate continuous improvements in practices, technology, tools, values, principles, competencies, collaboration, communication etc. within teams to drive agile efforts to next level.
Tribhuwan suggests to work with an agile transition committee (ATC) that is responsible for identifying, creating, managing and supporting the improvement plan, and continuous improvement task teams (CITT) that work with one improvement at a time and research, observe, model, implement, promote and transfer that across scrum teams:
Continuous improvement is the engine on which the agile initiative survives and grows. It’s the heart of agile. Without continuous improvement, the agile efforts will not succeed. Organization gravity will kill stagnant agile initiatives.
ATC team will work like a scrum team with an agile improvement backlog; delivering improvements every iteration. They will also act as a product owner for ensuring improvement backlog is prioritized, groomed and ready to be consumed by CITT.
In the blog post your agile transformation needs to start with a quiet phase Elena Yatzeck described different approaches for adoption agile, each with their pros and cons:
- Start doing agile practices with one team, and do more practices with that team and with others teams.
- Start with a plan, define KPI’s, do a kick-off telling teams what to do, and measure the results.
- Use a PDCA approach by doing a pilot, verifying results, modify the approach and try out on a larger scale.
Elena provided another approach, based upon a practice from large scale fundraising. She suggests to start with a quiet phase where you first achieve successes with agile before publically announcing an agile transformation:
Fundraisers always start their campaigns with a "quiet phase," in which a small number of "capital gifts" fund-raisers make personal appeals to large scale donors, asking them to help anchor the campaign. Studies have shown that the most successful campaigns actually raise up to 40% of their targeted funds this way before the campaign is even announced. So when the campaign kicks off, it is already successful.
If you need to do a very large transformation, plan to start by spending some time on a series of "Quiet Phase" Plan-Do-Check-Act pilots in a very "Lean Startup" entrepreneurial mode, tracking what works and what doesn't, and racking up success stories. Once you know what important wins you are likely to gain at scale, and, more importantly, once you have actually achieved some important wins at scale, THEN do your kick-off and announce your KPIs.
Jake Gordon wrote the blog post Still not agile? Take baby steps! in which he explores how to start with agile when upper management is not taking the lead:
If you have management support then bringing in an Agile coach is a really great way to kick things off. You’ll have an expert to guide you and answer all of your questions. You’ll also have someone constructively calling you out on your unproductive habits. However, if you don’t have this option then the second best approach is to gradually work it in from the bottom up.
Trying to introduce all of the agile practices can be too overwhelming, said Jake. In stead he suggests to start with three agile practices:
- Document Your Work and Make It Visible
- Daily Stand-up Meetings
- Retrospective Meetings
These practices can give a standalone benefit for organizations as Jake explains:
If you can implement these [practices] then you’ll start prioritizing more effectively, communicating more frequently, and you’ll ensure there is a guaranteed mechanism for improvement.
How are you implementing agile in your organization?
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015