Challenges with scaling agile? Discover 8 best practices for successfully scaling agile development in large organizations.
Subscribe to our blog
Quite a few companies have already switched to agile methodologies like Scrum or Kanban for the development of their digital applications. However, due to the growing popularity of these applications and the increasing expectations of the users, the development teams are growing quickly and the need to apply the agile methodologies on a larger scale is getting bigger.
This causes many challenges: how do you stay flexible and efficient? How do you maintain high quality but still get predictable output? How can you increase the velocity? Below I explain the answers to these questions with 8 best practices for scaling agile development successfully.
Servant leadership actually means ‘serve your team’. Make sure your team is kept away as much as possible from management decisions/influences. Put your time in helping other team members in communicating, coordinating and collaborating. In general, make sure your team can reach its goal. It also means you need to trust your team. Let the team organize and manage itself. Also give them the possibility to try out initiatives. Support them in this by defending these initiatives higher up.
Grow in phases
When the demand is huge and the pressure on the team to scale fast is becoming bigger, try to preserve enough oxygen during the growth. Oxygen to get up to speed again every time a change in the team has been implemented but also time to reflect and to continue growing the right way. Take a buffer in order to take the next step every time. Don’t burn your people. Lower the output by incorporating spare time. This time can be used to work on initiatives that can facilitate the growth. Try to find the right ratio between output (delivery) and team growth.
Mixing the teams is allowed and is even recommended. That way you make sure developers get in touch with everything and learn to collaborate with everyone. It makes them multidisciplinary team members. It will also allow teams to collaborate more with each other and you don’t create isolated cells. But don’t exaggerate with the mixing. The moment you start to mix too often, it can start to work counterproductive. Don’t mix the teams every sprint. Do it for example for every release, keeping the team stable for a longer period.
Pull dedicated testers in the team
There cannot be a gap between the developers and the testers. A separate test team is obviously not a good idea. Involve your testers in the sprints so they know what is built and what will need to be tested. A tester does more than just testing and logging bugs. He is a part of the development team and is closely collaborating with the product owner. He collaborates with everyone in the team with the aim to improve and bring quality into the product as early as possible. Collaborating with the product owner helps the tester to get more details out of the stories and thus makes it easier for the team to meet the acceptance criteria.
To keep the quality high and deliver as little bugs as possible, make the number of bugs per team visible. You can do this by showing the number of critical bugs per team on a big screen. That way you’re making the teams competitive and they’ll be more inclined to solve the bugs first before they continue developing new functionality. Allow a maximum of three bugs to be open before development can continue.
Eliminate the noise
Don’t let the support issues or incidents be picked up by the development teams. They will lose their focus and their planned developments in the sprints won’t get ready. Seniors are heavily consulted, you end up with unplanned priority switches and unpredictable lead times. Eliminate the noise. Create a separate team that is only working on this kind of issues. Within this team, post release activities can be handled, the team can serve as a first line for external parties, they can categorize issues into hotfixes or external release fixes, they can clearly communicate about the status of a defect etc. Besides, this team can work on structural refactorings (required for growth) which are all collected on a technical backlog. This way you can keep this team constantly busy, also during times when fewer issues are logged.
Estimate in story points
The problem with estimations in man-days, is that people are inclined to overestimate themselves (certainly juniors). This often results in budget overruns. By estimating in story points, you enforce people to estimate with relative values, based on the overall effort required to implement the backlog item. As the team velocity will get more stable after a few sprints, you’ll be able to estimate how many man-days your team needs per story point. In next estimations, you can easily recalculate the estimated story points to the number of days and get your estimations as realistic as possible.
Seen your application usage is enormously growing, chances are that your code base and application architecture are not prepared for this growth. You’re quickly carrying away years of legacy. But you can’t scale crappy code. Take the time to work on structural refactoring to facilitate the growth. Put these refactoring activities on the Kanban board and let the support team work on them or use the time that is put aside when incorporating a buffer. It will ensure every increment reflects quality standards and it will enable high velocity and a sustainable development pace.
About the author
Dimitri Honlet is Project Manager at AMPLEXOR Belgium. For the past 6 years, he’s been delivering successful projects for customers from A to Z, managing teams of skilled consultants and developers, controlling planning, scope, quality and budget. He has gained experience working on numerous projects in different technologies (SDL, AEM, Drupal, SharePoint) for customers active in the banking, manufacturing, retail or public sector. He’s passionate about exploring all new trends and methodologies in Project Management in order to continually improve delivering web development projects according to plan.