In this blog we hope to give you some useful tips on how to fix or improve your Agile Software development process, and more importantly, give you some insight on why you do not see the results you expected.
The popularity of Agile Software development caused many companies to jump in without fully realizing how radically different Agile is compared to a traditional method like Waterfall. They quickly conclude that Agile is not suited for their organization and go back to their trusted Waterfall. From our experience at Evolving Digital, we find that it’s not because the Agile process didn’t work, but because they created a hybrid model – in essence, they were adding some Agile elements to a Waterfall process, creating a hybrid closer to Waterfall than Agile.
Hybrid model (Agile/Waterfall) does not work
If you take one thing away from this post, it should be this: Do not try to make your own hybrid model because it doesn’t work. If you go down this road you will not see the benefits of Agile. At Evolving Digital we have seen this too many times, organizations butcher the Agile process to the extent that only a daily stand-up/scum remains Agile and everything else is the same old Waterfall.
Educate your management/sponsor
If you decided to transition from Waterfall to Agile you’ve committed your team, your department, and management to a very different process. Agile will change your budget conversations, and your scheduling process, so don’t assume that applying Agile to a small team doesn’t require stakeholder education. If you skip this vital step, your sponsor will correctly believe that it’s business as usual and ask for Waterfall style project commitments.
Educate your team
Every Agile team member should understand their role and how they fit within a team. Asking your ScrumMaster and Product Owner to attend training is not enough. Everyone on the team must understand the process. How will the Agile process impact testing? How will it impact requirements gathering? When does Design come into play? When everyone on the team understands the process and their role, only then will you have a high performing cross-functional team.
Don’t apply typical Waterfall contracts to Agile teams
If you force or sweet-talk your Agile team into committing to a project with a fixed scope, fixed price, and fixed timeline you’re setting them up for failure. This comes back to the previous point of trying to create a hybrid model (Agile/Waterfall); it just doesn’t work. You can achieve the same end goal with a well written Agile contract.
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.
Avoid analysis paralysis
Over-analyzing and trying to define every Story in great detail is not productive and should be avoided. Only Analyze and document what you need to start moving forward. You don’t need to analyze, estimate, and resolve every concern at the beginning (Sprints 1 and 2).
Avoid early overoptimism
Taking on too many Stories at the beginning (Sprints 1 and 2) typically results in Sprints that are not shippable – with too many incomplete Stories and features. So basically you didn’t complete what you committed to (Sprint backlog), so you’re starting with a failed Sprint. This will demoralize your team, and also your Sponsor who put trust in you and this new process. This is especially true for new teams with little experience planning and executing Sprints. Give your team at least two Sprints to adjust and become productive.
Allow time for refactoring
While most project plans allow time for defect resolution (bug fixing), they often fail to do so for refactoring. For example, you may plan a Sprint with assumptions such as – our typical project has 150 bugs, and we usually fix 4 bugs per person per day and considering our development team size we should be able to fix them all in a single Sprint. However, refactoring is very different to bug fixing. We have seen refactoring take 20 days on a project which only had 15 days for Quality Assurance. The nature of Agile software development is to move quickly, so refactoring is inevitable, and you need to plan for it.
Empower your team and avoid micromanagement
Asking your Project Manager or another senior manager on the team to assign tasks is not empowering. Every member of the team needs to take ownership of their tasks; they have to believe and commit to delivering their work. This is crucial, and the only way to accomplish this effectively is to involve them in all aspects of task planning – analysis, estimating, prototyping, etc. Everyone on the team needs to have the freedom to make decisions about their tasks, and also be allowed to make mistakes. Resist your urge to take back control every time your team makes a mistake; you can’t learn and improve without making mistakes.
summary
For most software development teams, following Agile development principles will improve productivity and morale. However, as highlighted in this three-part series, if the process is implemented incorrectly or core principles are ignored it can have the opposite effect.
