Monster-Sized Agile Adoptions SUCCESS AND FAILURE STRATEGIES.

Slides:



Advertisements
Similar presentations
Program Management School Agile & ADDIE Add-Up (AAAU) Elliott Masies Learning 2012 October 21-24, 2012.
Advertisements

Chapter: 3 Agile Development
An Agile Retrospective Clinton Keith Overview Retrospective format What works (clear wins)? What doesn’t work so well? What do we need to start doing?
Steve Collins Richland County IT Manager Agile.  Have Fun  Learn About Agile  Tell Some Stories.
AgileMan Consulting So what the heck is Agile? It came about as a response to the high failure rate of software projects (> 60%), where failure means late,
8 lessons learned from becoming agile ESTONIA Marko Taipale.
Extreme Programming Team Members Gowri Devi Yalamanchi Sandhya Ravi.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
Introduction to Agile.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Gaining Support for a Sustainable Agile Transformation Dennis Stevens, VP Enterprise Engagements LeadingAgile November 12, 2013.
Chapter 3 – Agile Software Development Lecture 2 1Chapter 3 Agile software development.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Software Development Landscape
Technical Documentation in Agile Colin Greenberg.
Larry Apke Agile Expert
Dr. Tom WayCSC Software Processes CSC 4700 Software Engineering.
Chapter 3 Agile Software Development (2/2) Yonsei University 2 nd Semester, 2013 Sanghyun Park.
Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming.
Agile Software Development Chapter 3 – Lecture 1 Adrián Susinos.
Agile and XP Development Dan Fleck 2008 Dan Fleck 2008.
One XP Experience: Introducing Agile (XP) Software Development into a Culture that is Willing but not Ready Joe Bergin * Fred Grossman * David Leip **
Extreme Programming Daniel Baranowski 3/29/06. What is Extreme Programming? An agile development methodology Created by Kent Beck in the mid 1990’s A.
Teaching material for a course in Software Project Management & Software Engineering – part II.
+ Personal Agility The human dynamics of high performance teams SDC 2013 March 2013.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Chapter 3 – Agile Software Development Lecture 2 1Chapter 3 Agile software development.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Extreme Programming (XP). Agile Software Development Paradigm Values individuals and interactions over processes and tools. Values working software over.
Introduction to Systems Analysis and Design
1 김 수 동 Dept. of Computer Science Soongsil University Tel Fax
Chapter 2 Software processes. Topics covered Software process models Process activities Coping with change.
Copyright © 2015 Curt Hill Software Development Paradigms What do you need to know?
Het einde van het beroep van tester - Wat Agile, DevOps en Scrum betekenen voor het testvak -
AP-1 4. Agile Processes. AP-2 Agile Processes Focus on creating a working system Different attitude on measuring progress XP Scrum.
© 2007 BigVisible Solutions, Inc. All Rights Reserved Training Solutions Agile Training Game v
2  Examine effects of using agile methods for creating Internet products on customer satisfaction and firm performance  Agile methods are informal,
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
Jeff Briggs Senior Consultant Capstone Consulting.
Agile Software Development Jeff Sutherland, one of the developers started it In February 2001, 17 Tools: continuous integration, automated or xUnit test,
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Agenda: Overview of Agile testing Difference between Agile and traditional Methodology Agile Development Methodologies Extreme Programming Test Driven.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
By Manish Shrotriya CSE MS 4 Point Agile Manifesto 1.Individuals and interactions over processes and tools 2.Working software over comprehensive.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
AGILE METHODS Curtis Cook CS 569 Spring 2003.
Embedded Systems Software Engineering
CS223: Software Engineering
Software Development.
Introduction to Agile Software Development
From manual test shop to fully automated test coverage: A How-To session to speed up your journey Jayshree Bhakta ITHAKA/JSTOR.
Extreme Programming.
Chapter 3 – Agile Software Development
Extreme Programming.
Obstacles to Agility 1. What does agile mean?
Script-less Automation: An Approach to Shift-Left.
Johanna Rothman Create Technical Excellence Chapter 9
Johanna Rothman Start Somewhere Chapter 17
TDD adoption plan 11/20/2018.
From a controlled chaos to well oiled machine
Chapter 3 – Agile Software Development
Introduction If you have got a call for an Agile testing interview, then congratulations are in order. You may be feeling nervous, but it sure to be felt.
Coming up: What is Agile?
Projects, Assignments, and other Assessments
Extreme Programming.
Obstacles to Agility 1. What does agile mean?
Agile, Scrum and CMMI Methodologies
Presentation transcript:

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 Top Developers… 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.

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. (as Amr perceives it)

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.

Ingredients for Success

Amr’s Model for Success

Questions Contact information:

Further Reading Several articles in this shared directory. shared directory Agile Adoption Patterns  Elssamadisy. Teamwork is an Individual Skill  Avery Anatomy of Peace  Arbinger Institute Crucial Conversations  Patterson. Five Dysfunctions of a Team  Lencioni