The essence of the Agile philosophy is to enable teams to adapt fast in a world where change is the only constant. When transitioning to a new methodology, making mistakes and learning from them is part of the process, and transitioning to Agile makes no exception.
Here is what we learned along the way and tips on how you can avoid making the same errors.
This article is part of a more comprehensive guide: Demystifying Agile in Software Development. Make sure you get yours! |
A product roadmap is an excellent tool for describing a product's expected future expansion. However, there are frequent blunders that teams make. Some of them include viewing the roadmap as a guarantee, including epics and user stories on the roadmap, and making educated guesses about the product's future development.
|
“Our backlog has improved since having our Product Owner 100% focused on managing the backlog. A documentation tool, such as Confluence, came in handy when we decided to start documenting processes more thoroughly.” Alexandra Filip, Scrum Master, Wirtek |
The product backlog does not evolve well. A stale backlog can greatly impact the team's capacity to deliver value. Priorities change as the project develops and some items may become irrelevant in time.
| “Keeping an eye on the backlog and adjusting it constantly helps you stay away from falling into maintaining a large one which in the end would only work against agility.” Alexandra Filip, Scrum Master, Wirtek |
|
"It’s complicated to prioritize a backlog with 40-50 user stories. So it’s best to keep a minimal backlog with what the team aims to deliver over the next 2-3 sprints. If you put an item in the backlog to develop in the next six months, maybe it’s not that important.” Mircea Alexandru, Software Development Manager, Mark Information |
The journey will never be effortless, but it will always be much easier if you have someone to help you. Industry experts, Product Owners and other teams involved in the project can help the Agile team to have the bigger picture and to better understand the specifics.
|
“To help solve this challenge the Product Owner and the Sales team thought of some study sessions held by industry experts to help us understand the bigger picture and the specifics. This worked very well with the documentation tool. We now have daily open meetings in which developers can address issues or discuss with the Product Owner.” Alexandra Filip, Scrum Master, Wirtek |
|
“Scrum shouldn’t be followed by the book, it should be tailored to the team’s needs.” Alexandra Filip, Scrum Master, Wirtek |
The sprint backlog is supposed to be fixed during the sprint, rather than changed during it. However flexible Agile may be, there is the need for a structure to help things move forward.
|
|
“Stakeholders sometimes tend to change the sprint’s scope right in the middle of it. Setting well-defined intervals for development will help in this sense. Agile is not just about flexibility, it’s a mix of flexibility and structure, and the lack of the latter leads to chaos.” Mircea Alexandru, Software Development Manager, Mark Information |
During the sprint, no changes are allowed; no work can be added or withdrawn. These rules provide the team with the essential focus to meet their goals.
|
“It’s appealing to make a change request during the sprint, but we learned not to affect the sprint scope, except for “A errors” as we call them, critical issues we cannot postpone.” Mircea Alexandru, Software Development Manager, Mark Information |
|
“To combat chaos, you need to have periods of uninterrupted work such as sprints. It’s essential to find your company’s balance between how much adaptability and predictability you need.” Mircea Alexandru, Software Development Manager, Mark Information |
One of the most frequent mistakes in creating Agile teams is to consider how traditional teams are formed. Having a big team that includes many people, each having a small role, does not apply to Agile teams.
|
"At some point, our local team had 15 people. At first, this seemed normal until we realized standups & planning took too long; half of the team was focused on one direction of the product, the other half was going in other directions. We then decided to split the team, and what works best for us now in terms of team size is 6-8 people.” Mircea Alexandru, Software Development Manager, Mark Information |
But size isn’t the only issue. Can a mix of Agile methodologies bring better outcomes?
|
“We then understood that Scrum isn't a one-size-fits-all kind of solution and decided to change the approach: to split into two teams. Team Kanban handles urgent requests, hotfixes and the work dynamic is different, while the Scrum team has planning sessions once every 2-3 weeks, has well-defined tasks, and a short, mid, and long roadmap that keeps us on track. Through trial and error, we managed to come to this solution that works pretty well for us right now.” Alexandra Filip, Scrum Master, Wirtek |
To make sure you come close to the most efficient Agile team in terms of the number of members, ask yourself if you can form a smaller team with the people you have chosen. If the answer is no, then the team has all the skills it needs for end-to-end delivery.
Special thanks to our contributors for sharing their insights and ideas with us:
Mircea Alexandru, Software Development Manager, Mark Information
Alexandra Filip, Scrum Master, Wirtek