Common Mistakes in Agile Development

You'll hear a lot of project managers nowadays swearing they are applying an agile methodology. But are they really?

I came across a number of mistakes people commonly make when applying agile, or when they think they're applying agile.

One of the most common ones is that people think of agile as iterative development. It is not! While some agile variants do consist of iterations, it is not iterative in a classical sense. Iterative development is about continuous refinement towards the end goal. On the other hand, agile si about achieving short feature-complete and scope-limited milestones in the project. There's a big difference.

So what's the most common consequence of this mistake? People will, under the excuse of being agile, simply adopt an ad-hoc approach in the early stages of the SDLC, expecting that things will change frequently and not bother to spend enough time on architecture and design. What they should be doing is setting up milestones based on the customer value (a concept from the agile project management triangle, I'll touch on later). And then working towards those milestones, following the usual SDLC processes.

Another very frequent mistake is that some people tend to stick to a known agile process to the letter, not even bothering to validate that it works well in their organization. Agile methodologies were meant to be tailored. What you typically want do is tailor it to the organizational policies, competencies and communication style in your organization. Being too rigid about applying a known agile process can lead to people rejecting it. Being flexible allows you to appeal to the needs and constraints of your organization, making the adoption effort more likely to work.

Developers as well as other participants in software development projects, like most people, resist change unless they have a clear incentive. Adopting agile often doesn't present that clear incentive, especially if the management doesn't really believe in it. And how could they when they're not the subject matter experts. Instead of forcing change on their team members, project managers are far more likely to succeed by bringing in external agile SMEs to facilitate the process.

I mentioned the agile triangle previously. Some people think of it as a new wholy grail of agile project management. The classical project managent triangle scope-time-cost with quality in the center is in agile replaced by different facets: customer value, quality and the third one is the classical triangle as a single facet.
What that means is that in agile you need to continuously deliver new value to the customer, while maintaining high quality and staying within the constraints of the classical project management approach.

Not thinking of this new metric is another common mistake people trying to adopt agile make. Naturally, not keeping it in mind can lead to either poor quality or producing a piece of software that noone is going to use.

Some agile SMEs think that one of the ways to improve an agile development process is to keep learning the right lessons. I definitely agree here. Some organizations will even go as far as making the learning aspect a core part of their culture, which results in a complete change in the mind-set of the employees, making them more oriented towards improving their competencies rather than succeeding on projects. Both are equally important in my view, but finding a way to balance the two is key.

Last but not least, an agile process is not a purpose in itself but rather a delivery method that ensures the organization can quickly adapt to change. It's important not to become too attached too any particular process, especially agile. There are downsides to having such a flexible development process. If your organization rutinely deals with change, change will become expected, eventualy even desired. The more your organization becomes able to rapidy respond to change, the more it will feel relaxed about accepting it and the better the chance of a high-risk change having a negative impact. This is to say, don't ever get too comfortable with change.

SCRUM: What Works and What Doesn't

Let's try to illustrate this on one of the most commonly used agile development processes, SCRUM.

The roles in the SCRUM process include: the product owner, the team, the SCRUM master (who often is a member of the team). Some of the key features in the SCRUM process (and this is an over-simplification) are short sprints (usually couple of weeks in duration), daily 15 minute stand-up meetings to briefly check-in with the team, sprint planning and sprint review meetings at the beginning/end of each sprint, product owner assigns the tasks in order of priority to the product backlog, team does the pick'n'choose in each sprint, SCRUM master reports the daily burndown chart.

Now, one of the things you may want to tailor in your organization are the actors in this process. I've seen SCRUM with a team member being the product owner and SCRUM master work, I've seen SCRUM with no SCRUM master work, too.

The key to having a successful SCRUM process is a well balanced team. You don't want team members who can't take on a task from the backlog, or who will fight over taking a task. Good communication is key to ensuring all risks are caught early and mitigated accordingly.

Sprints may or may not be fixed in duration. If you see you can't achieve significant enough value in a sprint, extend it. Don't artificially create more sprints to make up the time. Don't leave features unfinished or partially done. It's not iterative, it's agile.

Don't make architecture decisions likely, expecting they will change. They don't have to change, unless they're wrong. Agile architecture development is tricky since it's hard to figure out the value that it provides. One way to go about it is to vertically partition the solution and split architecture development into phases.

Again, learning is an integral part of SCRUM. Common mistake organizations make is to not spend enough time in sprint review meetings and concentrate mostly on sprint planning. Sprint review is as important and should not be neglected. Successful techniques for sprint review that people use include things like success and failure stories, communication matrices, various types of root-cause analysis etc.

I'm going to leave you with an analogy to a car accident: they say that when in a car accident you're far better off keeping your eyes on where you want to go instead of on what you might run into.