Blog

Good & Bad Agile Development Practices - Quick Recap24 May 2016

So, you know what Agile Development is, what rules it follows as a methodology and what results can be anticipated. But, if you've been applying the method for some time and are not quite seeing the benefits, perhaps something is slipping through the cracks?
For a speedy re-evaluation of how well - or not - your team are applying Agile Development practices in their work, take a look at the following:

The essential DO's of Agile Development:

Start with the culture, not tools and details.

Rather than diving all in with a new tool-set, it's worth establishing suitable environment for the team to work in with no distractions - such as calls, meetings and other information noise - which hinders productivity. In other words, remember to start with an Agile mindset.

Planning from the ground up.

Think in terms of large-scale plans, then devise iterations by which these goals can be reached - not the other way round. This way, chances are you will not only realize the major plan, but also keep the team involved in the big picture. All towards better understanding of the process and higher productivity.

While planning, plan actual items, not ideas.

Try to become your customer. There needs to be as few people between the customer and the product development team as possible. This way the product that gets built is closest to the one that was desired. Keep in mind, that each person that an idea goes through adds their own spin on it, whether they want to or not. People simply never see things in quite the same way, so instead of adding 20 000 more words to the product description, concentrate on building it the way it needs to be.

Team Communication.

Many would argue, this is the key element to making Agile work. If the aim is to respond quickly and to swiftly adjust to changes - developing good ways to communicate the needs and impediments effectively is indeed essential. Try a visualization tool that will make this a piece of cake.

Team orientation and identification.

No matter if your team sit in one room or are spread about a number of cities, states or continents, each of the team members has got to know who to turn to for specific information. In other words, people need to know - not guess - who is doing what part of the project. A lot of time to be saved here.

Iterations.

Split work into workable batches, of preferably fixed, repeatable length and let the team focus on that. So - iterate, assign work, wait for estimates from the people who will do the jobs and expect results. Then repeat.

Priorities!

As easy as it sounds, many teams fall short of being able to prioritise well, meanwhile it is the crucial part of making any process Agile and responsive - is it not?

Responsibility.

Team members need to know which parts of the work are falling under whose accountability. Otherwise, assumed common responsibility for the work items falls on everyone, which in practice means it actually falls on no-one.

The crucial DONT's of Agile Development:

Micro-managing.

Once work is assigned, let it be done, without standing over the team. Micro-managing each stage of the process is no part of Agile development. At the same time, don't assume that teams need no overseeing of any kind. Though general leadership is normally enough, both the leader and stakeholders should have access to updates on process stages and should be able to get involved in case of any issues or hold-ups.

Too frequent team changes.

By adding new team members to the pack with every month, chances of success fall, as the original crew needs to adjust and gauge how the new person will be fitting in. If new people are needed, it might be better to bring them in as a self-contained, new cross-functional team at first. After a while, new and old teams become more familiar and then will be more open to mixing in.

Not sticking to WIP limits.

The aim of the WIP limit is to help you, not work against you. Try to stick to the once set limit and good things will happen. Although it's typical for teams to override or ignore them, it's would be rewarding for all on the team to actually take notice.

Leaving all bugs till debugging.

It's tempting to leave them be, since there is allocated time for getting them fixed before release. This tends to lead to sloppy development practices, and - in the long run - creates procrastination tendencies. Not quite what you need in your Agile environment.

Keeping bad news hidden for too long.

People may think this is a good thing to do, as they're not spreading stressful news round, but in fact, leaving bad news for when it's too late to try and decrease the calamity is only making it worse.

Complying with the same impediments each sprint.

If there are roadblocks in this sprint, teams will work around them. If the same impediment occurs next sprint - this is a signal, that it would actually be worth clearing this impediment out completely, even if by forcing this as a job for the next sprint. It will be worth it in the long run.

Not caring for team happiness.

Individual team members' level of happiness with the workplace or company transfers directly onto the way they do the work. Easy enough to see how. It's dangerous to not think about that at all and leave any initial dissatisfaction to grow and possibly spread team-wide. It is the people who make the company and who make it work - it's vital to pay attention to how they feel in it.

It would make perfect sense to periodically evaluate how your team are working and what can be done to help them get better, more efficient and more satisfied with their jobs. It will most definitely not cause any harm, neither to them nor the business.