Pilot an Agile Project in Your Organization
As Agile is more suitable for software development, but not all companies are ready to move from Waterfall to Agile.
Waterfall has served many projects well and is still considered as a good methodology. It is used by many companies in their day to day work. Agile is a relatively new methodology in development with many advantages, but it is not always suitable for all project types.
Let’s elaborate an approach to starting an Agile Pilot project in your organization.
Select a Project
There are several important factors to consider when selecting a project:
- Project size must be at least 4 weeks. This time is optimal to form a full feedback and understanding of the methodology itself. The optimal maximum size of the project is 12 weeks.
- The project should be important, but not critical. Since this is a pilot project, it is very important to consider a project without mission-critical deliverables or outcomes with a clear and specific expectation of project success.
- Stakeholder involvement is important to involve in the project the Project Manager, designers, developers, testers, and Business Analysts. Ensure feedback from all participants is elicited and documented.
- The project selected should go through all stages of development such as initiation, discovery, concept, design, analysis, development, testing and implementation. This gives participants a broader perspective of how Agile works from the beginning of the project to the end of a project.
Chose a Team
Perhaps this is the 2nd most important element in the first project experience is team member selection. Team members should have the skill sets and experience to be able to deliver the project outcomes and deliverables. Beginner or novice team members will have little knowledge of the potential solution will be a detriment to completing the project successfully for the first time in an Agile environment.
The team should want and be willing to implement a project using the Agile framework. Enthusiastic teams are more likely to be successful in implementing an Agile project for the first time.
Team members should also have a basic understanding of the Agile and Scrum methodologies or have used Agile and Scrum methodologies in a previous organization or role. Be careful to have a majority of team members with real experience with Agile on the pilot project. They will be able to help less experienced team members on how Agile and Scrum operates.
Formation of Roles
The next step will be the formation of the roles in the team. Key roles for an Agile team are:
- Product Owner
- Scrum Master or Agile PM
- Development Team
- Business Analyst or Customer
These roles are divided into 2 groups. Client Side and Technical. The client side, namely the Product Owner and the BA, are responsible for the creation of requirements and form them into user stories. The goal of Product Owner is to provide “Just enough” information to the development team so that they would be able to begin work on the product within the sprint.
User Stories and Acceptance Criteria
An early stage of planning is “Road Map” or sprint planning. It is necessary to plan each sprint based on the estimates provided on what it would take to complete the user stories. Since this is the first Agile project — accuracy is not what you should emphasize. Be mindful that you are still constrained by the length of the sprint. Your first few sprints will most likely have very inaccurate estimates for user stories. This will result in the first few sprints not accomplishing all the user stories expected.
Planning consists of taking the desired functionality and creating user stories to support them. Each of the user stories should have a specific set of acceptance criteria. This ensures the definition of “done” is clear to the team.
A user story is an instrument of functional description which is typically stated in the following fashion:
As a _________ I want to _________ So that_______
Acceptance criteria describes specific functional requirements that will be accepted by the business for the user story. and show specific steps to achieve the result. Acceptance criteria are typically constructed in this manner:
Scenario: Login
Given: I am on the Log in page, and the login ID and password fields are displayed
When: I am able to enter my login id and password
Then: the login button is displayed and available for me to click to start the login process
Prioritization of User Stories
Prioritization of user stories is an important part of any Agile project. As sprints are very time constrained and this is a pilot program expectations need to be set that not all user stories may be able to be delivered within the expected timelines. Prioritization of user stories will allow those user stories with the most business value to be worked upon first. Sprint 0 planning should take the prioritization into consideration when planning which user stories are placed in specific sprints.
Estimating User Stories and Acceptance Criteria
Once the user stories and acceptance criteria are created, then we are ready to estimate. Typically a T-Shirt size system of XS (extra small), S (small), M (medium), L (large), and XL (extra large). Each user story and acceptance criteria are estimated using this approach. As a pilot project, you will encounter estimates that are not very accurate. This will result in the early sprints of an Agile pilot project to not deliver all the expected user stories for a sprint.
Once the user stories and acceptance criteria are sized, they are slotted into sprints. This activity occurs in Sprint 0.
Getting to Zero
Sprint Zero is a very important event. In this sprint several things will be determined:
Sprint size is determined. Sprint size is the duration of all sprints in the pilot Agile project. All sprints should be of equal duration. Be aware that as a pilot Agile project your durations may be a little longer (such as 3 weeks) in order to assist in team members in learning the Agile process more fully). Typically sprint durations can range from 2 weeks to a month. Pick a duration that makes sense for the team and will result in incremental deliverables that will give the team a sense of success.
Plan each sprint by aligning each user story and acceptance criteria into a specific release based on its priority. Be careful not to overfill a sprint. Realistically align user stories with sprints based on their estimates. As always beware your estimates may not be very accurate. Start the first couple of sprints with a smaller amount of user stories to give your team the time to learn the Agile approach to development.
Once user stories are assigned to sprints, review the tasks needed to complete each user story to ensure the tasks can be completed in the sprint. Be aware that some task may require the efforts of resources that are outside of your team. Where ever possible ensure the tasks that are performed outside of the team are completed prior to the sprint starting. An example of this would be a DBA. A database request may take your organization several weeks to complete and implement. Trying to squeeze the database change into the sprint would result in not being able to complete the sprint fully. Instead, have the DBA request completed before the sprint started to developers can focus on the sprint without having to wait for external resources to complete tasks for them.
Starting Up
Schedule the daily stand-ups. Be sure all team members understand the daily standup and the purpose of a stand-up meeting. Put a 15-minute meeting on your team members calendars (hopefully schedule in the same room) every day with each team members covering these topics:
- What I did yesterday
- What I will do today
- Do I have any problems or concerns
The scrum master will lead these meetings. Bring a timer. The is 15 minutes in length and time is of the essence. This is a problem-solving meeting. When problems are identified, immediately ask who needs to be involved in determining a solution for that problem. Then have those individuals tackle finding a solution OUTSIDE of the meeting. The amount of time per team member depends on the team size but typically 2-3 minutes is given to each team member.
Interaction with team members is important. Due to time constraints of the daily stand up and sprint a lot of pressure is put on the new Agile team member. Be sure to give them opportunities to discuss their experience and be available to offer solutions to situations that are encountered.
Acceptable Product
Acceptance criteria were established for each user story. As each user story is completed, the acceptance criteria for that user story should be validated. Make sure the team understands that user stories must be validated by the team by executing the acceptance criteria.
End of the Sprint
A sprint review and demo are conducted at the end of the every sprint. This reviews the user stories that were completed ensures acceptance criteria has been met.
At the end of every sprint is a retrospective to reveal lessons learned. This is important as this pilot Agile project will need feedback to improve future efforts and processes to help the pilot Agile project be more successful over time. An hour meeting with all teams should answer the following questions:
- What did not go so well?
- What still puzzles or doesn’t make sense to us?
- What went well? What things should the team keep doing?
A good thing to keep in mind is ending this meeting a positive light. Focus on things that didn’t go well and move into things that went well. This leaves the team members with a positive impression at the end of the meeting.
The leader for the Agile project pilot will need to take steps to improve areas where things didn’t go well or areas that don’t make sense to the team. Always ensure follow-up is performed with the team on items brought forward that need improvement.
Do not try to solve the problems identified in the retrospective meeting. Assign teams members to investigate and get back to the group at a later date.
In a Nutshell
This article elaborates a very high-level set of tasks for piloting an Agile project. The structure and readiness of your organization’s leadership to use the Agile methodology should be explored deeply before starting an Agile pilot project. In setting senior leaders expectations, it is important that senior leaders have a complete understanding of how the Agile Mythology operates. Setting the expectations of senior leaders for the pilot is critical to ensure it has a good chance of success.
Good luck on your Agile pilot project!