Download
1 / 20
200 likes | 274 Views
Monster-Sized Agile Adoptions. Success and Failure strategies. Amr Elssamadisy
E N D
Monster-Sized Agile Adoptions Success and Failure strategies
Amr Elssamadisy Agile adoption experience with teams and organizations of all sizes for over 13 years. Focus on large, multi-national organizational improvement. Has found that success with larger organizations does not come with larger process, but with a re-focus on individuals and their interactions.
Our Task Today • Learn about agile adoption strategies that work…. And that fail…. (For extremely large agile adoption programs.) • By sharing real stories of success and failure we have a better chance of success today. • Explore an agile adoption strategy that arises from these stories.
A Surprising Result • Large multinational organization. • Grew through acquisition so has significantly different components. • Aging C++ and .NET code base with severe quality problems. • Agile coaching team helped introduce: • Test Driven Development. • Test Driven Requirements. • Human Dynamics . • Changing the environment. • 6 months later, only a fraction of the teams still doing TDD and TDR effectively, however environment and individual human dynamics still present. • What happened?
A Surprising result….. • Previous release was 4 months late. • This release was on-time with high quality. • Individuals, teams, and leaders took ownership for results and used (negative) feedback early reduce scope when necessary and produce a high quality product on time. • The team that was considered in trouble is now the model for success! Lesson: Environment/Culture and individual behaviors much more important than agile practices.
Technical Practices First • Large multi-national organization. • Aging C++ code base. • Successful adoption of Test Driven Development transformed their code base and made it much easier to maintain and add new functionality. • Great success. Right?
Technical Practices First….. • Two years later the code had vastly improved and the team’s success had spread only a little – not through the whole organization. • Unfortunately there was no tie between their success and organizational needs. • The improvements were lost in the vastness of the organization and the reporting levels. Lesson: Technical excellence is not enough. It is not enough to spread or to show improvement at the organizational level.
Scrum without Technical Practices • Medium-sized, multi-site, US-only organization. (Ok, this is not a monster-size ) • Scrum successfully adopted without technical practice (no automatic testing).
Scrum Without Technical Practices… • Resulted in more pain than before. • Code and architecture in worse state. • 50% “hardening cycle” at the end. Lesson: Improvement does not end. Solve one problem, then, as you see new problems solve them. You are never done.
Agile Practices with Top Developers • Small team with top developers and important project. • Using 2-week iterations and performing all the Scrum practices. • QA not involved and quality needed improvement. • Agile coaches worked with this team to integrate QA into the iteration to improve quality. • What happened?
Agile Practices with TopDevelopers… • Discovered the following: • Developers not working on what they agreed to work on at the beginning of the iteration. • Lack of respect between QA, Dev, and Product – developers felt they know best. • Coaching the teams proved to be ineffective • .Individuals were hired because of their individual success with no consideration to teamwork. • Development manager was encouraging this behavior by creating an environment that rewarded individual achievement even with team failure. Lesson: Environment/Culture can make agile adoption ineffective. Management attitude is significant in creating culture and expectations.
Successful Pilot and then…. • Pilot (first test) project run at a medium sized organization of adopting both Scrum and technical practices. • Very successful, showed great results. • Excellent first step for organization wanting to make a change.
Successful Pilot and then.. • Created a “we are better than you” mentality within the organization. • When product was delivered faster than requirements could be built, instead of helping those writing the requirements, the dev team blamed the product management group. • 1 year later that work is canceled and it did not spread within the organization. Lesson: Immediate success is possible at a small scale. Respect of others, succeeding together (and not alone), and many other human dynamics are needed for long term success.
“Magic” Team • Extremely successful results. Rebuilt failing project in 20% of the original investment. • Support from leaders who created an environment that rewarded teamwork, learning from failure, and investment in learning new and better ways to build software. • Team members were excited about the project, helped each other, worked and played together, and took ownership for both success and failure. • I originally thought Agile was the reason for success. However practices alone never replicated these results. Lesson (over many years): Immediate and lasting success requires environment/culture, individual human dynamics, and THEN agile practices.
(as Amr perceives it) The TRUTH! • Agile adoption is difficult and painful. • Reliable and repeatable enterprise agile adoption is an unsolved problem. • When it works, it is magnificent. Frequently delivering 5 and 10 times improvement. • We have been writing great software for years before Agile. • We have written terrible software with Agile.
The TRUTH! (as Amr perceives it) … • Environment and culture is mandatory for success. • Individual human dynamics such as ownership and respect is mandatory for high performance in a distributed team environment. • Agile practices are not necessary but helpful when used in the right context. • I do not know the full answer. • WE can find a better answer by building software and sharing our stories.
Questions • Contact information: amr.e@thoughtworks.com
