So you’ve heard from your boss that your company is finally adopting an agile approach in managing software projects. As a manager of a software team, a team lead, or even as a developer, you are undeniably excited. You have your eyes on agile project management for quite some time and even took a refresher to prepare for the transition. You are now in the planning process and you’re thinking of the challenges you might face. Of course, there are always challenges when introducing process changes in an organisation. Adopting the agile approach is no exception. Every agile project management literature will walk you through these challenges.
I have worked with organisations of various sizes and project management approaches from waterfall to waterfall-agile hybrid to fully agile. Here are the common challenges that teams encounter in adopting the agile approach.
A development team can have developers, a business analyst, a UX designer, and testers, but for simplicity let’s refer to them as developers.
1. Building a truly cross-functional development team
There are a couple of factors that often make it difficult to build a truly cross-functional team.
In organisations following a matrix structure, it is not uncommon for one employee to have at least 2 direct managers at a given time: a functional manager and a project manager. It is also not uncommon to find an employee confused about which manager really has authority to decide on his allocation to projects. For an agile project to succeed, developers should be fully dedicated to the project–the realm of the project manager. Having too many tasks from other managers makes the team lose focus and less cross-functional. Members cannot provide whatever expertise they have to the project because they simply do not have time. It’s like they are not there.
In this case the project manager who is likely to assume the scrum master role should make sure that developers are fully allocated to the project and far from distraction. Developers must also learn to assess, even question the value of each task they are being assigned to, to the project they are in. Other managers should respect and follow the new process.
Another typical challenge are developers’ unwillingness to go beyond their usual scope. A frontend developer won’t touch or even look at backend codes and backend developers will do the same to frontend codes. While developers are not asked to change their career paths, it is best to eliminate single points of failure by ensuring that multiple people can take on a task or understand a certain aspect of the product.
For this, developers should be open to challenging themselves and extending whatever they can to deliver the agreed features. After all, they all succeed and fail as a team. Scrum masters should enforce pair programming and peer review. This also helps build rapport among the developers.
2. Swarming
It often starts with an honest mistake. Developer A thinks that developer B can handle the user story by himself and so he starts on another user story. Developer C does the same with developer D. On the 3rd day of the sprint, you notice that there are way too many user stories that are in progress than expected, and nobody can explain why stories that should have taken just a day are still not up for review.
This happens because of lack of communication and engagement among developers, and because of developers focusing into getting as many things moving as possible, as opposed to getting features done one small step at a time. The team should swarm over a feature until it’s good for review before moving on to the next. After all, 8 fully functional features at the end of the sprint is way better than 16 ones not ready for any release. Big teams may have many user stories in progress. The key is making sure that each story has adequate attention.
3. Organisational clout
A scrum master especially for an organisation transitioning to agile project management has a critical role. Since he is primarily in charge of removing blockers and often become the default champion of the agile approach, he needs a certain level of influence that will allow him to effectively implement it. His knowledge of how things should be is not enough. He should know how to communicate to leaders and even call them out if they are acting against the process.
Soft skills, personality, and even the organisation’s culture can either make the scrum master’s role easy or difficult. The latter, sad to say, is often the case based on my experience. What could help is getting an authoritative third party to speak about and enforce agile approach. An agile coach is often employed in these transitions to ensure that there is support from all levels and units of the organisation.
4. Sponsor/stakeholder expectation
If you belong to a product development company, there’s a good chance that your stakeholders are people from the company as well. In this case, they should be on board the transition and should have attended all the necessary sessions. Their expectations are easier to reset if they haven’t done so yet on their own.
On the other hand, managing external stakeholders used to waterfall approach is often harder. Typical of waterfall projects, they would hold on to whatever timeline or cost you have mentioned at the beginning of the project. Yes, even if they request a few more features along the way; that’s a familiar story. In an agile project, while we build the roadmap and provide estimates at the beginning of the project, we are conscious of the fact that we don’t know a lot about the product at that point and we are open to changes at any point in the project. That simply means that whatever timeline or cost we provided, although we’ll do what we can to meet them, should not be treated as final. If we happen to be so good at estimates and have provided very accurate figures then we’ll be fine. But what if we’re not?
Without proper expectation setting, you will likely find yourself explaining multiple times in the project why a release should be moved or even why the cost will be adjusted. To avoid this, it is important to take some time at the beginning of the project to discuss the approach and how it will impact stakeholders. A material for a crash course on the agile framework to be used would come handy.
5. Old habits die hard
This doesn’t need a lengthy explanation. We are humans. We have lapses. We have a tendency to revert to our old ways when nothing reinforces the new ones. You can’t have an external agile coach around forever to function like a cop to everyone. The following can be done to address this.
Review existing organisation policies, take out ones that go against agile approach, and more importantly, create ones that can support it. Surely you can think of some. Start with the types and duration of meetings that people can entertain or the communication plan for projects.
While everyone is fresh from training, create an environment where people can call out one another if they are falling back to old ways. A person may not recall everything discussed in an agile project management training but he would remember what he was called out for and these are often the things they need to stop doing. They are probably doing fine with the rest of the requirements for the transition.
As said, these are just the common challenges. You might encounter other things in your organisation or professional life. It will be good to take note of them and write about how you solved them. – mB
Photo by You X Ventures on Unsplash
i. am. mark. 