Skip to main content

Improve your Agile Software development process (Part 2)

For Part 2 we continue with tips on how to fix your Agile Software development process. Here is the link to Part 1 if you missed it (Improve you Agile Process - Part 1).

Cross-functional means cross-functional (always, not sometimes)

When you have a team with all the necessary skills, then you can quickly make decisions and corrections, one of the key reasons why Agile teams tend to be more productive. However, if you occasionally have to introduce an outside resource, then you immediately slow down your team and create confusion. Now you have to get this new person “up to speed” which is taking away from your team’s productivity. Even worse, if you are continually pulling resources from the team.

Stop adding scope to a running Sprint 

This should only be allowed if you are new to Agile and you are still getting your team adjusted to working with Sprints. However, this sets a dangerous precedence. You may be tempted to add small things your manager or client asked for, but it’s a short-term fix with long-term consequences. If you did it once you will do it again, so it’s better to have difficult conversations early on.

Your Agile team should be able to deal with new information, even if this new information results in more work. However, if significant work/hours are required, then you need to move this expended story to a subsequent Iteration/Sprint.

Also, if your industry or work environment demands quick action, then shorter Sprints (e.g. 1-week Sprint) is your solution.

Less documentation doesn't mean NO documentation

Yes, your team should focus more on producing working software, but some design documentation is required - a well-architected solution is one of the best insurance policies against significant rework. That being said, keep in mind that your documentation objective is to provide guidance and not to cover every possible scenario and feature. 

Understand the Product Owner role

A Project Manager is not a Product Owner, and your Senior Developer is not a Product Owner. The Product Owner is there to represent the business, not the project, and not the development team, therefore, it is a role which cannot be filled by a Project Manager or a Developer. In the ideal world, a Product Owner should be the person that sponsors the project. However, if that is not possible then whoever is closest to them should take on the role. Prioritizing features with a Product Owner that doesn’t have control over scope and budget is almost pointless.

Understand the Scrum Master role

Scrum Master is a facilitator; therefore, they should not be assigned development tasks, management responsibilities, or any other tasks that will take away from their ability to facilitate the process. Scrum Master has many responsibilities, but two responsibilities are essential. 1) Help the team remove roadblocks, and 2) Keep moving the team forward. If done well, these two responsibilities will consume most of their time, so your Scrum Master should be very busy, assuming they are performing their role correctly.

In Part 3 we continue with tips on how to fix your Agile Software development process. Improve you Agile Process - Part 3.

Join and receive one email per month on how to grow your business. 

Improve your Agile Software Development Process
Related Content

Aleksandar (Sasha) Radonjic Evolving Digital Profile Picture About Evolving Digital
Hello, I am the Founder & Chief Growth Strategist at Evolving Digital, a digital marketing agency specializing in Growth Strategy, Digital Marketing, and more.