Agile frameworks, which are ubiquitous in today’s software development environment, sometimes run into issues that can affect its effectiveness. In this article, we explore what factors could have an impact on agile methods and four workarounds to help resolve them.
Agile frameworks are the norm
Software development management is generally split between Scrum (or variations of Scrum) and Kanban. There are, of course, other implementations of agile – such as lean development and extreme programming – but, as they have a small market share, we won’t cover them here.
Agile became popular as the de facto framework for running software development projects, primarily because it promises to deliver value in a consistent and predictable manner. In addition, it puts emphasis on continuous communication with stakeholders, and aims to concentrate efforts on the high value parts of the final project.
Here at Softwire, we believe in using the right tool for the job – be that, the tech stack we choose for a project, or the management framework we use. I’ve found that some projects are easier to match to agile principles than others. But, there are also times when this framework struggles.
What factors could impact the agile framework?
Here’s a list of the factors that need to be considered when choosing your framework:
Small budgets
Small budgets is a factor that could impact the success of using an agile framework. This issue tends to come up support engagements, especially for projects that are in their ‘maintenance’ phase of life.
Having a small budget to balance makes it harder to justify the overheads associated with agile ceremonies. For example, why would you spend two hours doing a retro, when you only had a budget of five days for this sprint?
Sharing projects
Another factor to consider is, as perhaps a consequence of small budgets, is when teams share projects.
If a project does not have enough budget for the full team’s work, project leaders may want delivery teams to handle multiple projects at the same time. This approach leads to a major challenge for a developer: balancing out the priorities from multiple product owners.
Team volatility
There are some projects that have less-than-predictable work volume patterns, meaning there may be times where an influx of developers are needed to work on tasks. This often happens when budgets get signed-off close to the delivery date of a feature.
In my experience, agile is not particularly detailed on how to onboard team members quickly.
Four workarounds that can help you resolve these problems
1. Ruthlessly prioritize
With small budgets, the only option you’ll have is to be super strict when signing off work. This task is made easier by cultivating a good relationship with the product owner.
I find that on larger projects, the product owner is naturally more involved in the project, so building a relationship comes easier. For small projects, you need to make a conscious effort to maintain open communication lines and keep the relationship warm.
2. Have someone responsible for balancing priorities
At Softwire, we introduced a role called Team Lead. The role of the Team Lead in this context is to balance priorities between projects, especially when there are multiple projects being actioned at the same time.
The Team Lead also acts as a bridge between the various product owners and the team, and supports the developers while they focus on their tasks.
3. Share the overheads
Switching from a project-focused agile approach to a team-focused agile approach can have positive benefits for more than one project at a time.
At Softwire, if we have a consistent team working on several projects, they’ll hold all agile rituals at a team level, which will also cover all the projects that the team are looking after. This way, overheads are shared fairly across projects and the incremental improvements that follow from running an agile project also affect all projects.
4. Document, document, document
Having a volatile team means that a lot of time is going to be spend running through the project setup. It makes sense to invest time into quality documentation and processes.
Pay attention to how a new team member finds setting up the project, and support them with a ‘safe space’ to share their challenges. I find that team members with less experience can provide a lot of information on how the setup process can be improved, if they feel free to challenge the status quo and share their problems without limitation.
Developer and team support
As we know, a lot of things can go wrong in a project, and running the project in an agile manner does not mean you are free from trouble. From my experience, situations where there are lots of small projects shared across the same team (where there is a lot of churn) tend to have the most problems.
It’s important to recognise that you are not going to solve all the problems in one go or at one time for your project, but if you keep a close eye on the priorities, share the overheads between projects and keep up-to-date documentation, it should make your job a lot easier.
Additionally, if you think a team can benefit from some additional DevOps support, check out our made-to-measure DevOps services, or speak to one of our consultants today.
