Using Agile to Transform: Lessons Learned (so far…) Nine things we have learned about using agile for our program

Agile transformation is not easy; it is even harder in large corporations with years of waterfall experience. We believe it is useful to share on the ground experience of success, and failure, so that others can benefit and we can calibrate our experience against others’. 

This case study/ experience report lays out a recipe based on nine key takeaways from our positive experience on a large project. The presentation will show how the Agile Manifesto, Agile Principles, and Scrum Values, which were largely words on a piece of paper at the beginning of the journey, slowly came to life as the transformation progressed. We know we have many lessons to still come, but  after about 12 sprints, the executives are actively engaged, the product owner sees the value, and Scrum team members enjoy their work, and we all continue to have ‘aha’ moments of learning!


Outline/Structure of the Experience Report

A. Background: Explain the nature of the effort, team size, environment, goals etc., so that the audience understand the context of the project and the associate experience.

B. Agile Manifesto and Scrum Values: Flash them to highlight that these were just words on paper at the beginning of the journey:

C. Nine key takeaways: One slide for each of the nine takeaways with some pictures. What is presented below are some key points that will be covered in the talk against each slide. Goal is to get feedback from the audience if this resonates with them, if they have similar experience or contrary feedback.

1. Prepare: Agile does not mean jump in blindly! Preparation is critical at the beginning of the project and also at the beginning of each sprint or major release. Several weeks of architectural work and business analysis, followed by an eight-week “Sprint Zero” period positioned the team well at the beginning of the project.

Since then, an Advance Team comprised of business analysts, systems analysts, designers, testers, and assorted subject matter experts has been prioritizing and writing user stories in preparation for each sprint.

2. Commit: The Scrum teams are 100% dedicated to the project and abide by the Scrum values of commitment, focus, openness, respect, and courage.

During sprint planning, each Scrum team member has the opportunity to seek clarification from the Advance team as the user stories are presented. With the help of senior technical staff members who are embedded to assist and guide the teams, Scrum team members assign story points until maximum velocity is reached.

The Scrum teams then commit to completing their stories by the end of the sprint, and work with the Product Owner to complete the stories. At the Sprint Reviews, the Scrum teams demonstrate their software and get additional feedback from stakeholders.

3. Empower your Scrum Master: The Scrum Master enforces the rules of Scrum, protects the team, and removes impediments; Scrum Masters often ruffle feathers when they make unpopular decisions for the good of the team. As the leading change agents, Scrum Masters coach people at all levels on Agile principles and Scrum values. The Scrum Master cannot back down when someone says, “…but that’s how we’ve always done things.” To achieve the benefits of Agile, the Scrum Master must guard against running the project as a series of iterative, mini-waterfalls with Agile titles. To accomplish this, the Scrum Master must be experienced and have the support of executive sponsors.

4. Automate testing: Test automation is pivotal. Agile development without test automation could be worse than waterfall! New user stories must not break existing code. The testers develop Gherkin scenarios for new development while maintaining the regression suite to ensure no previously accepted code is broken. Using Continuous Integration for rapid feedback and validation, the team has automated 80% of the functional test scenarios, enabling rapid regression testing. This has led to decreased defects and better quality output.

5. Educate your executives: Without proactive involvement and training it will be very difficult for executives to transition from waterfall oriented governance to governing in the Agile world. Effective engagement requires the executives to be fully knowledgeable of the process, culture, behaviors and ceremonies of the Agile teams. Agile transformation requires executive training and involvement. The management team completed training on Agile processes, where they were introduced to Scrum artifacts and metrics. They spent time with the team going through ‘A Day in the life of a User Story.’ This has helped the executives ask the right questions and makes it relatively easy for the project team to effectively explain project status, risks, and issues. Ultimately, without the understanding and support of the executive team members, the Agile vision for the project could not succeed.

6. Make your PM Agile: Making Agile successful in a large organization requires a mature project management (PM) team that can effectively bridge the Agile cadence from the project room to meet various governance requirements. While we use metrics to monitor if we are on course, working software is the primary measure of success. The PM team also collaborates with the Architecture Review Board and other governance teams, making sure that Agile artifacts and governance expectations are in sync.

7. Develop self-governing teams: Adopting Agile is not easy; it requires a transformation in the way people think, act, and communicate. About 40% of the team had no prior Agile or Scrum experience. As the sprints progressed, the teams became more comfortable with tasking, time-boxing, and story pointing and swarming. The teams have bonded, adopting names and mascots. They work hard and have fun together, meeting often for team lunches and coffee breaks. Team building is not a one-time exercise, but something that continues throughout the sprints.

Co-location of the team is also essential; we have a team room with no cubes, but plenty of wall space for project artifacts and whiteboards.

8. Prepare early for production: Flawless production operations and customer praise are the ultimate proof of the quality of the product. Consistent with Agile’s emphasis on ‘potentially shippable’ product at the end of each sprint, early focus on non-functional requirements (NFRs) is imperative. Examples from our project include performance tests at the end of each sprint and implementation of monitoring tools early in the project. Early performance tests might not meet the ultimate NFRs, but will significantly enhance the chances of meeting NFRs without last-minute drama!

9. Manage the matrix: Our Strategic Initiative teams are highly matrixed organizations, requiring close management of interpersonal and inter-team relationships. Given that ultimate production support will come from a variety of teams, extensive engagement and collaboration across the organization is required early and often.

D. Work in Progress: Acknowledge that we are nowhere close to done with our journey. Identify a few areas of improvement that is on our radar.

Learning Outcome

You will be able to validate / fine tune your Agile implementation based on the nine key takeaways from a team that is finding success in moving to Agile and Scrum methodologies in a relatively large organization.

Target Audience

Anyone who is about launch or has just launched Agile efforts / who has gone through a transformation from waterfall to Agile in the recent past

schedule Submitted 7 years ago

  • John Hughes

    John Hughes - Waterfall comfort in an agile world: How to give Execs the answers they "used to get" now that you are agile

    60 Mins

    Your progressive and efficient agile program can go downhill fast, and agile can get a bad rap, if upper management begins to think that the answers they used to get in the "Waterfall world" are no longer available to them in an agile world. Executives assume the team is managed poorly if they can’t produce artifacts they are used to seeing like fully resourced project schedules. They get frustrated when they can’t get a “straight answer” to questions they are used to having answered like “what is the project schedule’s critical path showing,” or “are we staffed properly to complete all the remaining requirements by the end of the contract.” They become unhappy with the team and possibly even start to see that “agile doesn’t work for our program” if they are told that they can’t get that information anymore in agile, or it isn’t clearly explained to them how to ask for the information they are really trying to understand.

    The answers are still there though the tools and methods are likely different. We need to be able to translate the questions being asked and help upper management understand how to better ask the questions to get what they are really looking for. Executives are responsible for ensuring the health of the program, that sufficient progress is being made, the program is within budget, the contractual requirements are being met, etc. Agile methods can leave executives uneasy because answers to questions regarding these can be “squishy” since user stories can be added and removed, they can use relative sizing techniques for estimation instead of specific hours, priorities can shift, and the customer’s needs drive much of the process decisions. By understanding what upper management really needs in order to be successful themselves, and how to extract that information using our agile toolset, we will be able to give them the data they need to continue managing the program and communicating its health to their leadership and customer counterparts. The goal for this session is to provide you insight into what is really being asked, to help your leadership better ask the questions “in an agile way,” and to deliver impactful answers derived from our agile toolset that allows for strong communication of the health of your program.