10 Things that Make Your Agile Project Go Wrong
Today Agile is a buzz-word, and almost every organisation aspires to adopt its ‘best practices’. Startups and mature companies go for Agile in pursuit of its advantages – decreased cycle times, improved customer collaboration, timely response to change, and so on. But the problem with Agile implementation is that too many practitioners treat it as a methodology, losing its real meaning.
Agile is Not a Process or Methodology – it is a Frame of Mind
What many organisations fail to understand is that Agile is not a set of practices; this is a frame of mind. Michael Sahota, the author of An Agile Adoption And Transformation Survival Guide, says:
Well, what is Agile? The consensus definition is provided by the decade old Agile Manifesto. Agile is an idea supported by a set of values and beliefs. <…> Agile is about a fundamental shift in thinking.
Are You Doing it Wrong?
Unfortunately, Agile is so overused nowadays that it has lost the original meaning. To achieve agility, many companies introduce more processes and more tools that in fact contradict the Agile values and principles. Here we describe 10 signs you’re doing Agile wrong.
1. Be Agile instead of just doing Agile
As we said before, Agile is not a set practices, it’s a philosophy, a frame of mind, a mental shift in how you approach software development. There are specific techniques but they are of secondary importance. First, you should be agile. You should embrace the Agile Manifesto and live by its values: avoid useless paperwork and ceremonies, focus on working code, fast feedback, self-organization and self-optimization. And then you will do agile automatically.
2. Don’t treat story points as goals
User stories that capture a software feature description from the end-user perspective, are the backbone of Agile. Each story is given points to estimate the overall effort required to implement a product backlog item.
But many teams treat these story points as goals. The problem is that one team’s two-point story can be a five-point story for another team. And when you use story points as a measure of success, you destroy its usefulness as a means of estimation.
Remember, success is not about points, it’s about the value you delivered.
3. Stay delivery-focused
Surprising as it may sound, way too many agile teams forget that their goal is to deliver working software to the end-user who expects certain benefits from it. That’s why it’s crucial to stay connected to users (otherwise, your software becomes useless). But when you unintentionally replace user stories with tasks, your development process becomes task-focused instead of delivery-focused. In other words, you’re simply doing things instead of creating value.
4. Agile ≠ Scrum
Many people believe that Scrum equals Agile. But Scrum is a framework for managing a project, while Agile is a philosophy based on certain principles. And Scrum is only one of many methodologies built on agile principles.
Agile is much broader that Scrum. Simply “doing Scrum” doesn’t mean that you’re practising Agile.
5. Avoid huge backlogs
The easiest way to kill your production is to have large queues. Unfortunately, many companies still continue to plan and execute software development projects in a large chunk. This leads to huge backlogs and means that valuable features at the end of the queue will wait too long to be put to work.
The key is to organise your project around the essential set of features that deliver real value to the end-user.
6. Don’t ignore pair programming
Pair programming (two programmers work together – one writes code while the other reviews each line of code as it is typed in) promotes a closer collaboration and knowledge sharing between developers. It helps understand the requirements correctly, ask questions and resolve misunderstandings on the spot, which allows to build the right product faster.
7. Say no to never-ending standups
Always keep in mind that standups should be brief team-sharing ceremonies. Discuss what you did yesterday, what you’re doing today, and whether there are any blockers or anyone needs help. Team members can also share what helpful they’ve learned. But make sure standups take no more than 15 minutes, otherwise, you’re doing them wrong.
8. Don’t skip retrospectives
Even though Agile teams are self-organised, their behaviour should be periodically examined and analysed to identify how the processes can be improved. This is what retrospectives are for. They are a neutral approach to fixing processes without wasting time blaming people.
9. Don’t forget about modelling and design
One of the Agile principle says “favouring working software over documentation”, so it might be tempting to skip all modelling and design activities and only write code. But because you’re doing agile, it doesn’t mean you “can’t” model or design. Just the other way round – when you’re trying to solve a really hard problem, all means are important to figure out the right solution.
10. Be careful when adopting “best practices”
There are no universal best practices. Every team is a unique combo of people, personalities and skills. And what works for one team may be a total disaster for another. So instead of mindlessly following another Agile “best practice”, experiment, try new things, review and make changes that will let you deliver better products.
