How to Begin Your First Agile Project (with Examples)

573

Is this your first agile project and looking for guidance on – How to Begin Your First Agile Project. Interested in implementing Agile Scrum methodology but unsure of where to begin? Read on for some guidance. As you begin to transition your team, the following is a high-level guidance with some definitions to help you along the way.

Beginning

Let’s start with the Agile Manifesto which emphasizes:

• Individuals and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiation
• Responding to Change over Following a Plan

While the items on the right are important, the items on the left are more important.

Now, Identify the Team:

• Stakeholders: These are the people who have the wants and needs and are the reason the team forms to develop the product. Stakeholders collaborate with the Product Owner to generate the narrative. 
• Product Owner: Represents the stakeholders’ interests, and has a thorough understanding of users, the marketplace, competitors, and type of system being developed. 
• Scrum Master: The servant leader that does everything necessary to help the team succeed at their maximum level. 
• Development Team: A self-organizing group focused to providing a potentially releasable piece of product at the end of each sprint. 

Identifying those involved is the first step, so let’s get going!

Start of the Project (Sprint 0) 

Sprint 0 is not a Scrum principle. As a result, it has generated some debate and can create divisions among those who identify as Agile. DO NOT utilise Sprint 0 to fall back into waterfall approaches by utilising it to design the application and gather all requirements. That stated, it has been used successfully to: 

Whether you perform these things in a Sprint 0 or merely prior to getting started, here are some recommendations to set yourself up for success:

Make a Selection of Your Tools 

Select collaboration tools to be utilised by and for the team. Pick tools that match your process and not the other way around. I’ve had success with Scrum boards, Jira & confluence 

Facilitate an Initiation Phase Meeting 

Develop a Project Charter with the team’s engagement, including: 

• Define definition of done: What will the team need to have accomplished for the narrative to exit the sprint? This guarantees when each person says they are ‘done’ it means the same thing. 

• Define Team Agreement: In order to hold each other accountable, the team should establish ground rules. It’s all a part of the team realising what it needs to succeed and self-organizing around that.

Plan Sprint Ceremonies

• Story mapping: This is done only once at the start of a project or a sprint. 
• Sprint planning: On the first day of each sprint, we set a time box for one hour per week of the sprint. This is the same for each sprint (2 hours for typical 2-week sprint) 
• Daily Scrum/Standup: This happens every day during the sprint. It lasts for 15 minutes, and it happens every day during the sprint. Add a 16th minute for more collaboration, set a timer for 15 more minutes, and get rid of any team members who aren’t needed for the meeting. 
• Backlog Prioritization: It happens three days before the last day of each sprint. It can last from one to six hours, depending on the needs and complexity of the stories. 
• Sprint review: This happens on the last day of each sprint, and it lasts for about an hour or two. It happens every time. 
• Sprint Retrospection: Reoccurring on the last day of each sprint, this is a time boxed meeting that lasts about an hour.

Conduct initial backlog prioritization sessions

• Create a healthy backlog with enough stories for at least 2 sprints if possible 
• Prioritize stories 
• Development team estimates stories

Sprint Start

Day 1: Sprint Planning

• Developers agree to stories until you have enough to meet the needs of your team and the priorities of the people who own the project. After the first sprint, the team will use the average velocity to help them decide how much work to do in a given sprint. 
• Over the course of the sprint, figure out how much time each team member has available and subtract how much time each person needs for the ceremonies. For example, if four developers each work 40 hours a week, that works out to 80 hours each for the two-week sprint. Then subtract the daily standups, sprint planning, backlog grooming, sprint review, and sprint retrospective time to figure out how long it will take to finish stories. Each developer will now be available for 68 hours. Multiply 68 by 4, and you get 272.
• Create your Definition of Done

Daily Scrum/Standup

1. The team meets and talks about what they did the day before and what they plan to do next. This is a meeting that is less about how things are going and more about how to work together when there are dependencies and coordination issues when people self-assign stories. People on your team are not telling you what to do. They are organising so that all stories are done by the end of a sprint. 
2. If a team member needs to talk about a problem or work together without the whole group, they can use the 16th minute after the standup meeting. Only the people on the team who are important will be there for this part. A lot of people use this principle even though it’s not a strict Scrum principle. Because people have this time on their calendars, it works very well. In the most important trick, you have to let people out of the meeting when it is not necessary. 
3. Backlog grooming: 3 days before the end of the sprint. 
4. Keeping track of stories that the Product Owner comes up with. 
5. Prioritizing stories
6. Asking questions/clarifying requirements: Developers should ask as many questions as they need to figure out how much it will cost and finish the storey for the Product Owner. 
7. Estimating stories: Identifying test case scenarios can help the team better understand what they need to do. 
8. It gives the product owner time to get any open questions answered before planning a new sprint, which helps them get ready.

Finally, the last day of the Sprint: Review & Retrospection

• Demonstration: The team will show the product owner stories so that they can get immediate feedback and figure out how they might affect future development. They should have dummy data and examples set up to show how the new feature will work so that they can be ready.
• Retrospection: The team will look back at the sprint and figure out what they want to stop, start, and keep doing. After each sprint, they have a lot of chances to make things better. There could be a big change in quality, administration, and practise in just 2-3 sprints. This could happen quickly (as short as 4-6 weeks).

As much feedback as possible is very important to the success of the team!

Observe and adapt 

Sprint until all of the things in the backlog are done. Sprinting is fun!

---

A few key things to say before you take the plunge.. 

1. Companies have tried to implement scrum and other agile practices to become more agile but it didn’t work in some cases because it didn’t think about business. 

2. There is still no answer to the question “why really change.” Scrum and agile methods don’t actually solve problems in the same way. They make them more clear so that hopefully the organisation can do something about it. Bottlenecks and incompetence are getting a lot of attention. Sometimes, they don’t get better even if you change the organisation, move the office, or fire someone. 

3. In order to get customers to care about this, put the message in business value terms rather than in terms of process and developer value. Business… you want to get what you want quickly. In order to make an investment and hire the right people, you need to support an experiment for three to six months of forming, storming, norming, and performing. In that time, you may not get any direct value. Most businesses don’t want to deal with a long, bumpy road. At the end, the value is high. 

4. The team and organisation must be able to accept change, failure, and learning in order for any agile method to work. 

5. Scrum is not a set of rules for how engineers should work. Instead, it is a simple framework for managing projects that is based on a few common sense rules. Scrum uses a process called “empirical process control,” which means that the team doesn’t follow a strict set of steps or a very detailed plan. Instead, the team adapts based on what they’ve learned. There are still some people who think Scrum isn’t very strict because engineers want rules. It’s kind of funny how often they get changed or rethought or turned into some hybrid crap that doesn’t need to be changed at all. Agile project managers are a great example of this. 

6. The backlog should never be done. There should always be a few PBIs that aren’t done. It is possible to add software to meet a DoD, but when the business value justifies it, it should be changed.

Recommended Reading: 8 Agile Estimating Methods