For the past six months, I have been consulting an internal team that has embarked on an Agile transformation journey. Though the trigger for change was a top-down transformation drive at the organizational level, as this team understood and internalized the Agile concepts, it became more of a bottom-up approach, with the team having committed to adopting the Agile way of working.
In this article, I intend to share our experience in this transition journey, leveraging the single-piece flow
concept, as practiced in Lean manufacturing, using Scrum and Kanban.
Leg 1 of journey
Earlier the team had followed the traditional Waterfall approach. Around six months back, they started their Agile journey by first conducting a value stream mapping (VSM) for the portfolio, which was completed jointly by the business partners and IT team. The exercise provided great insights into the current state and surfaced the pain areas clearly.
The top pain areas that were uncovered:
- High lead times (even for small changes)
- Schedule slippage (as a result of rework)
- Higher cost (as a result of rework)
- Low customer satisfaction
Based on the insights extracted from the results of the VSM exercise, the team decided to adopt Scrum as the primary method. This would take some time, since it needed to be done for the entire portfolio and not just for this one team.
We decided to work on a solution that would be developed around people and process:
- Scrum practices, such as sprint planning, Daily Scrum, sprint review, and sprint retrospective, were selected as the way to work.
- Additional practices, such as story grooming, were also picked up to support their way of working.
- The team agreed to have two-week sprints.
- The team was trained through workshops and self-learning on Agile and Scrum before starting its first sprint.
- With the roles defined, team structure in place, and agreement on the way to work, the team embarked on the Agile journey.
Leg 2 of journey
Four months in, the team and the business decided to review their progress. Below are a few of the key findings from the retrospective:
- The business partners were happy with the high degree of collaboration that Scrum promotes.
- Dramatic improvement was seen in lead time for small changes.
- Significant reduction in the risk factor was seen, because of the level of collaboration with business.
- There was reduction in rework.
- There was increased engagement between the team and business, and both parties developed more empathy toward each other.
But we still had the problem of a high lead time for delivering large changes or projects. Further brainstorming with the team revealed the following:
- The team was unable to contain the various development activities within the sprint.
- System testing, user acceptance testing, security testing, performance testing, and final quality inspection were being done outside of the sprint.
- Much of the work in progress (WIP) was being collected and passed among developers, testers, business, and other actors.
- The entire portfolio was not structured into Agile teams. Only one Agile team existed, while others continued to work in the Waterfall environment.
- Multitasking on different projects was ongoing.
- The same team members were pulled into application-support activities whenever there was an incident. This was causing severe distractions and pulling the focus away from development work.
This is when I decided to bring the team closer to the single-piece flow model. Now that the team already had its first experience with Agile, it was time to raise the bar. The team brainstormed and agreed on the following changes:
- No more Waterfall work; group all team members (dev, test, and product owners) within the portfolio as Scrum Teams.
- Maintain a separate small team for production/application support and ad hoc work so that the development team can remain highly focused on the sprint goals, delivering value to business while application support continues to maintain availability of the system.
- Have application support join key Scrum ceremonies hosted by the development team. This helps the support team understand the bigger picture and changes that will be deployed in production in the near future.
- The team and the business updated the Definition of Done and Definition of Ready and agreed to meticulously follow the guidelines.
- Write features and then break each feature into stories. The traceability between features and stories is maintained through implementation.
- The stories are to be of INVEST (independent, negotiable, valuable, estimatable, small, testable) quality. Each story will be so granular that it could be implemented within one to three days. The product owner and team must learn the skills for story writing. Team members were advised to read Mike Cohn's book User Stories Applied.
- Formalize story grooming sessions every week to create INVEST-quality stories.
- Adopt release planning practices from XP. This will help the teams understand the potential big picture for the next two months.
- Continue Scrum practices, such as sprint planning, Daily Scrum, sprint retrospective, and sprint review, but with more rigor.
- Ensure that the team's capacity use remains well below 80%.
- Pass each story from one actor to the other when he or she completes the activity for that particular story. The story is passed in this order: From developer (story coded), tester (functionality tested), and team (quick demo to PO) to PO (story user testing), who finally hands it over to security and performance. This will help avoid work piling up in each bucket.
- There are fewer testers than developers. So if the developers' WIP reaches an unacceptable limit, development helps testers bring down the WIP before deciding to pick up new work. This way smooth flow continues.
- Align with security and performance teams for assigning dedicated resources to the portfolio who will work closely with the team as shared resources.
- Implement a physical Kanban board and conduct the Daily Scrum standing in front of it. The portfolio has members in two locations, so the physical board will be replicated across locations.
Change is not easy. The Agile way of working brings transparency to the end-to-end process, from idea to product. People may not be comfortable continuously working in the limelight. Self-organization in teams may cause functional managers to feel insecure and uncomfortable with the resultant diminished influence. We anticipated this reaction, but this is where coaching came in handy. Continuously coaching the team to make them comfortable by resolving their queries and resolving their currently held notions helped in driving the point that the Agile way of working will make all their lives better.
Though the journey was not hurdle free, constructive debates and discussions, stakeholder buy-in, and a highly motivated team helped Lean out the process and move the team closer to the single-piece flow model. The teams are continuing into the new year with the new process.