Nowadays, the methodologies from this big Agile bucket are the most popular ways of running software development projects. It doesn’t matter if you use Scrum, XP, Kanban, DSDM or some weird hybrid only you know about. What does matter, is if you fully understand how to be Agile and how to deal with it.
In this article, I will talk about the most significant risks you can come across in a Scrum project because this is the methodology we use in our projects on a daily basis.
One goal in a sprint is often a mistake!
Often, while working in Scrum, we don’t bother to “investigate” how long an optimal iteration should be. Following the Scrum Guide, it should be short enough, so the Product Owner can bear the risk and not longer than a month. But there’s no information here about a client! And this matter is often overlooked by organizations and project owners/managers.
The symptoms of this “illness” are not that hard to spot: lots of meetings with the client during the sprint, scope changes in ongoing sprints, not delivering anything functional at the end and a constant feeling of “lack of purpose”. All of this can mean one thing: we have an incredibly changing environment. Is that bad?
Definitely not. But we are agile, we can adapt! The first and easiest remedy is just to shorten iterations, even to as short as one week! This will give us an opportunity to plan only the next four days and also an opportunity to do check-ups with the client more often and in a structured way. Not enough?
Discuss the short and long term goals and try to identify the ones that are the least likely to change. Think of dividing sprints into two categories (or even one sprint into two categories): one dedicated to long term goals, the other to the current business.
Nevertheless, it’s crucial to put it into some structure, get a hold of the chaos and help the team focus on what’s important.
Can I be Agile without Demo and Retro in a project? YES!
This one is tricky!. In Scrum and other Agile methodologies, we have procedures describing how and when we should communicate on the client - project manager - team line. But what if we don’t stick to these guidelines? What if we over or, even worse, under-communicate? What if the client doesn’t attend Scrum Reviews, demos, and it’s tough to get decisions from them or feedback about the last increment? Or what if the client contacts the PM and the team with every little thing, each of them being more important, “more ASAP” and more critical than the previous one?
Even for the most experienced project managers, it’s still challenging to deal with these situations. In both cases, we have the same result — the team is less focused on the job that needs to be done. In one case — we don’t know if we follow the right path, in the other, we have so many paths we don’t know which one we should take first!
The best solution here is to start the project from determining the strict rules of communication, and stick to them! If the client is really anxious about the project, it’s worth having a quick meeting twice or thrice a week apart from the typical Sprint Reviews or Demos, where they can discuss with the project manager (not the whole team!) every little detail they need. It’s a bit more work for a project manager, but in the end, it’s definitely worth it. The team can focus on the development and the client is better informed.
In the case of under-communication, the remedy is similar — regular communication — it doesn’t have to be meetings, sometimes asynchronous communication can get us there! But remember, according to Scott W. Ambler (link) nothing can fully replace a good old face-to-face talk!
And that’s why at Software Brothers we always insist on having product workshops with clients in our office, so we can best understand their needs!
Business values connected with technical decisions - it saves money!
One of the worst risks - at least in my opinion - is the risk of losing the target. What should drive us the most in the Agile/Scrum project should be the business value and the road to deliver it. We often forget that it should occupy the first place in the majority of the decisions we make.
For both teams and managers, it’s crucial to know the final value we need to deliver, often it’s the only way to make a good decision. For example, when designing a way of signing up, we should carefully determine what is the final target here. If the client wants to integrate a sign-up with Google, Facebook, LinkedIn and other options in the future, we should consider using dedicated solutions (i.e. Firebase Authentication), instead of developing each sign-up method independently. It will not only make integrations faster in the future but also way easier! And that’s definitely something that we can prepare for when designing the sign-up structure.
The best remedy for that risk is taking care of the business value almost daily and from the very beginning just by discussing this with a client, the team and including it in the user stories. Often, just by noting down the business value that the product feature is expected to bring, might make us wonder whether the technology we are about to use is suitable for what we want to achieve or even if the feature is necessary.