Agile Implementation: Get Started With the Agile Development Process

When it comes to software development, there are so many ideas, strategies, and frameworks that selecting the right one for your business can be a major undertaking. That being said, the best approach when it comes to getting started with the Agile development process is to jump right into it and start learning from your mistakes. In this article, I am going to share important tips for the Agile development process, key Agile implementation techniques, and reminders of what not to do in order to achieve Agile success.

This Agile implementation roadmap will help you and your team get started with the Agile development process on the right foot, which will ultimately help your organization in the long run with improved team morale, greater predictability in projects, improved flexibility across the board, and so much more.

Agile Software Development: Where do I start?

Always remember that Agile is a mindset, and it will be deeply integrated into every step of the software development process.

1. Do the research: The best way to learn what successful Agile development practices look like is to look to the people who have already walked the walk. Start by browsing the internet for examples of what success (and failure) looks like for other Agile organizations.

2. Embrace and learn from the chaos: Dip into your Agile toolbox and use activities like retrospectives and demos to learn from your mistakes. Create action items from your retrospectives and make them visible to the team by documenting them in a board, then assign the items to whoever will be responsible during the sprint. 

3. Make sure to have the right lineup: Having the right team is important when getting started with Agile. An ideal Agile team typically consists of a scrum master, a tech lead that will handle the technical conversations, and a few software developers (ideally full-stack). However, be sure you have all the right players in order to answer the questions you might be asking. If you need an answer to “Where is my application going to run?”, you likely need a DevOps engineer. Are you going to need to know if your application is intuitive and has the right look and feel? That’s where UI/UX engineers come in handy. If you need to know if your application is robust and stable, you’ll need Quality Assurance engineers.

4. Product Owners are a MUST: If you went through step three and thought there was a very important player missing from the lineup, you are right. Someone that owns the vision of the product and translates requirements into product backlog items for the development team is essential. The Product Owner will handle all product decisions, be in charge of accepting all user stories, and make sure that stakeholders feel comfortable decentralizing decision-making. The Product Owner is the player on the Agile team that will provide all answers for the development team, making it self-sufficient and self-managed. See four ways an outsourced Agile Product Owner delivers value.

5. Build your backlog: This is typically the Product Owner’s domain, but it requires conversations with key stakeholders, technical leads, and even DevOps engineers to make sure that when the development work starts and the runway for the application has been built with as few blockers and dependencies as possible. 

6. Start practicing Agile software development: With a well-built and educated team, getting started with the Agile development process should be relatively smooth. The Scrum Master will handle the process and coach the team on best practices. Your Product Owner will handle all product decisions and provide the team with the vision. Developers will write code in incremental cycles, providing potentially shippable pieces of code using Behavior Driven Development, and your Quality Assurance engineers will make sure that all code shipped is tested and approved. All that’s left to do is begin your first Agile sprint and start learning and adjusting.

 

Some important techniques that will help you start your Agile implementation on the right foot:

Some of the main questions that emerge when starting with an Agile team are:

• How do I calculate my initial velocity?

• How do I go through my first planning session?

• How much work should the team commit to?

They are all good questions, and, luckily, there is a tool in our toolbox to answer each one of them.

 

Create Historical Data

When working with new scrum teams, people tend to focus on the team’s velocity. My recommendation is not to. Let the teams work and learn from the data collected during each one of the iterations. Let the teams work for two or three sprints and then calculate the average number of story points delivered by the team and use that as your team’s velocity.

Sprint	Velocity
1	20
2	22
3	21

 

In my experience, this approach is more accurate, provides the team the ability to find their rhythm, and removes a lot of stress from the new Agile development team.

 

Capacity Planning

Sometimes stakeholders or high-level managers don’t feel comfortable having a development team work without a commitment from day one, so the approach to creating historical data may not be for everyone. Fortunately, we can use another tool, in this case, called capacity planning. 

While capacity planning can vary from team to team, it generally provides managers with good information and allows the team to commit to work without feeling pressure to meet imposed deadlines.

The main component for capacity planning will be the product backlog. This is where we are able to see the product owner, scrum master, and members of the development team working together to meet a specific goal.

1. Product Backlog: We need a product backlog that has been refined by the development team, and that meets the criteria defined in the definition of ready. We don’t need a huge product backlog, but certainly one that has enough work for a team to fill up one iteration or sprint.

2. Team Capacity: Calculating the team’s capacity is a fairly simple process, but we need to make sure to keep in mind the time the developers spend doing research, going to meetings, socializing with the coworkers, etc. We also need to understand the current status of the team. For a new Agile team, I usually calculate that every team member has four hours of good work that can be accounted for in the team’s capacity. Following this approach, and assuming that the iteration is 10 business days long (two-week iteration), the calculation will be something like:

	Days in the Iteration
Hours/Day	1	2	3	4	5	6	7	8	9	10
Developer 1	4	4	4	4	4	4	4	4	4	4
Developer 2	4	4	4	4	4	4	4	4	4	4
Developer 3	4	4	4	4	4	4	4	4	4	4
Developer 4	4	4	4	4	4	0	0	0	0	0
Total of Hours	16	16	16	16	16	12	12	12	12	12

Note: When calculating the team’s capacity, remember to account for developers’ days off, if necessary (illustrated above in red). 

 

3. Sub Tasking: Sub tasking is the key component for capacity planning. It forces the Agile development team to think more in detail about the work they need to do in order to complete a user story. Tasking is usually done in a separate meeting, and I always suggest it be hosted by a technical lead (if there is one). If not, the scrum master can handle this responsibility.

a. To make the process more efficient, I recommend having a template to create tasks for a user story. Every task will be estimated in the number of hours that it would take the owner of the task to complete it.

i. In the example below, we can see that the User Story US1 will take the Agile development team approximately 14 hours to complete.

 

User Story ID	User Story Name	Estimation in US Points
US 1	User API Update	3
Task ID	Name	Estimate in Hrs.
1	API Change	8
2	Get Peer Review	2
3	Manual Test	4

The team’s remaining capacity is 126 hours. 

 

 4. Identifying the Team’s Initial Velocity: Once the team’s remaining capacity is zero, the sum of the user story points added to the iteration will become the team’s initial velocity.

Note: In order for this approach to work as it should, the product backlog must be prioritized correctly. Now you’ll start to see the importance of a dedicated and present Product Owner. 

 

What not to do when getting started with the Agile development process:  

Starting the Agile development process can be frustrating sometimes, but if you avoid certain behaviors and follow best practices, the results can be very satisfying.

 

1. Don’t focus on metrics: At the beginning of your Agile implementation, don’t pay too much attention to metrics. Invest your time and energy in doing correct planning sessions, have constant retrospective meetings, and work on emerging action items to fix the little problems using fast-learning cycles. If you stick to the plan and invest in the overall wellness of the team, the metrics will fit organically into the process.

2. Don’t play the blame game: In Agile software development, when an individual fails, the team fails. In other words, don’t single out your teammates. Conduct retrospectives with the Start, Stop, Continue technique and come up with ideas on how the team can improve. Don’t forget to celebrate everything that goes well! Create action items, own your mistakes as a team, and improve upon them.

3. Start small: When getting started with the Agile development process, keep it simple. When the time comes, Agile software development allows you to update your process to fit the necessities of your product, your team, and your company. But don’t rush; we have to learn to crawl before we can learn how to run.

4. Trust your team: In Agile, trust is essential, and it takes the collective trust and effort of every person on the Agile team to achieve success.

There are many more techniques and activities you can do as part of your Agile implementation, but always deal with the problem you have in front of you first, then move to the next one. Do it the Agile way.