The most common question I get when transitioning project teams from Waterfall to Agile is — “Where do we start?”
Transition from Waterfall to Agile requires a change in paradigm, a shift in priority. The Agile Values declared in Agile Manifesto are:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The two methodologies are conflicting. It seems impossible to shift to the other without sacrificing the current and ongoing project commitments.
Don’t fret. I recommend the following 8 Steps to Agility to gradually yet effectively transform your project team from Waterfall to Agile.
1. Discover your Agile Champion within the team
To initiate the change, find a person in your team who is passionate about the need for change towards Agility. This person should exhibit servant-leadership philosophy. Servant leaders put priority on people’s needs. Agile Values put emphasis on people over processes and tools.
The Agile champion should have a lead role in the project and may use his/her role to influence others. If you can’t find an Agile Champion, nominate yourself!
2. Empower the team
Agile teams are cross-functional and self-organizing.
A cross-functional team has all the necessary skills needed to complete the required functionalities. Individual members may have specialized skills and area of focus but the accountability belongs to the team.
A self-organizing team is empowered to organize and manage their own work. The team shall decide the strategy and action plans on how to turn requirements into potentially releasable functionality.
A team is the basic unit in Agile. The ideal team size is from 3-9 members (does not include Project leadership roles). This is to reduce communication overhead due to exponential increase in communication lines.
3. Familiarize the team on Agile
In order to transition to from Waterfall to Agile, the team members should be know Agile methodologies and have common a language and understanding of Agile.
The team should be familiar with the Agile Manifesto. The Agile Manifesto has 4 values and 12 principles. A one-hour session within the team to walkthrough and reflect on these simple truths should emphasize the importance of delivering value to the customer at the earliest possible time. Common awareness on which areas to work on can be identified in this joint study.
A widely used framework for Agile Development is SCRUM. SCRUM is lightweight and easy to understand. The ScrumGuide, available from scrum.org, is a short document translated in over 30 languages, sorry no Filipino translation. Each team member can read this in two hours.
For a detailed process adaptation of SCRUM, ScrumStudy.com released a SCRUM Body of Knowledge (SBOK). It is a process framework that aims to apply SCRUM on any industry (not only Software or IT). This is a 400-page book. This can be used as base model in documenting Agile Processes if the need arises.
There are some minor inconsistencies with the original ScrumGuide, such as the maximum length of sprint and definition of SCRUM Team. Make sure to follow the ScrumGuide when there are inconsistencies.
When your organization can afford it, have at least the Agile Champion take an external training on SCRUM. Check scrum.org or scrumalliance.org for SCRUM training availability in the country. The training include recognized certifications on SCRUM.
4. Increase communication and collaboration within the team
Agile values regular face-to-face communication and daily collaboration between developers and business people. To increase interaction among the members, conduct daily stand-up (Daily SCRUM) meetings that are typically held in the same location and at the same time each day. Each member shall report 1) what the member did the previous day, 2) what the member plans to do on the current day, and 3) are there impediments on the members tasks.
Establishing team house rules to improve team collaboration. The team can set penalties showing up late during Daily SCRUM or breaking the daily build test.
Employ consensus-building techniques in decision-making and discussions to resolve conflicts within the team. Some of these techniques include The Fist of Five, The Planning Poker, or the usual Filipino favorite of discussing matters over food. The team can use funds from the penalties collected in breaking the house rules.
5. Identify and rank each requirement based on priority
Projects have requirements list, each requirement is usually prioritized based on scale ranking (Very LOW-HIGH or from 1 to 5). For Agile, the whole requirements list should be ordered from 1 to N, where N is the total of all requirements in the list.
The Agile Team should be working on highest priority items first. Priority is set based on the combination of the following attributes: Value, Risk and Dependency.
Value is how much business value the requirement can deliver. Early delivery of high value features can immediately realize ROI. Risk is how much risk is associated in the requirement. The sooner the team removes unknowns, the more confidence and control can be expected. Dependency is sequencing of requirements based on order of implementation dependency. As an example, in a banking application, View Bank Account feature will not be possible without the Create Bank account feature.
Prioritizing the requirements list (Product Backlog) is an ongoing and regular activity as new items may be inserted or existing items may be removed or modified.
6. Set Time-Boxes to activities and stick to it
In case you started transitioning to Agile in the middle of the project, divide the remaining time into equivalent time intervals called Sprints or Iterations. Sprints are consistent duration with a maximum of 1 month. The team should decide on the Length of Sprint. Sprint Length will depend on the following factors: Change frequency, Uncertainty, and Project Risk. The higher the Change/Uncertainty/Risk factors are, the shorter the Sprint Length should be. Once the Sprint Length is decided, it should not change throughout the project duration.
Meetings usually take a lot of time from the participants. Some people arrive late. Some participants talk about unrelated topics, like the traffic! Setting time limits to meetings promotes prioritization and the discipline to be clear, direct, and purposeful.
SCRUM events have the following time limits: Sprint: 1 Month, Daily SCRUM: 15 minutes, Sprint Planning: 8 hours, Sprint Review: 4 hours, Sprint Retrospect: 3 hours.
7. Increase transparency through visibility boards and ticketing systems
One of the pillars of SCRUM is transparency. There should be common definition of progress (such as Definition of Ready, Definition of Done). Each team may define different stages of progress where each requirement has to go through before considered DONE. The stages can from Analyzed, to Designed, to Implemented, to Tested, to Installed, etc. This can be best illustrated using a Kanban Board and overall progress can be shown using Burndown Charts.
To automate task management the team may setup Project Management infrastructure. Since pinoys would rather spend money on coffee than on efficiency tools, I recommend the use of Redmine with Backlogs Plugin installed, the software is totally free.
8. Conduct regular retrospect
Last step but the most important to agility transition is Retrospective. At regular intervals, preferably at the end of each Sprint, the team should reflect on past performance, identify actionable items to improve its performance, and apply it on the next sprint.
You cannot expect the team to be fully Agile and productive after one sprint. Allocate time for the team to conduct retrospective meetings to reflect on the current sprint and implement changes. Using the Agile Manifesto, ScrumGuide, and other techniques available in the Internet as your source of information try to adapt at least new practice per sprint!
Good luck on your Journey to Agility. Please do share your Waterfall to Agile Transition stories.
– Agile Pinoy