Real agile requires failure

There is so much written about the various flavours of Agile. For those of you new to Agile you’ll find yourself reaching for the books, the blogs and the training courses. In some quarters Agile gets a bad press. Projects fail and those responsible, point the finger of blame at Agile. “This would never have happened if we’d done things the proper way”.

Agile, when implemented and used properly is a fantastic framework. While it’s easy to understand Agile, it’s not so easy to implement. Unlike a strict methodology, Agile simply provides us with some principles and some tools to use, and it’s up to us to make it work.

Experience counts for everything with Agile. In the same way that Agile provides us with the means to iterate over the products that we create, your Agile experience is something to iterate on too.

Don’t fear Agile and don’t give up if it doesn’t work for your first project. As you’ll do during your projects, review your implementation of Agile, understand what worked, what didn’t work. Look at how your team used Agile, review the tools you use and identify what can be improved.
​
Your products will not be perfect at the end of the first iteration and neither will your understanding and implementation of Agile. If Agile didn’t work for you then understand why. As you reach the end of each sprint, factor questions about Agile into your retrospective. After all, retrospectives are about learning and improving.

Here are some tips to consider in improving your implementation of Agile…

Manage stories and report on progress

So, from the start. Are you set up correctly? Do you have tools in place to help you manage and report on your project? You can keep things simple and manage your backlog in a spreadsheet or you can choose from the many online tools available. Whatever you choose, make sure you can share the backlog, that you can record the information you need. Keeping a close eye on the progress of a sprint and the overall project relies on the information you capture and make available.

Stories should be written properly so anyone looking at the board could understand them — many teams lapse into a shorthand that is more like writing a task than a story. Is there a clear ‘Why’ in each story?

Strict standups

Are your daily standups effective? Are they keeping the whole team informed of progress?  Are they being used to identify blockers? Or, are there people outside of the core team hijacking the meetings? Be sure to take control of the daily standups, keep the momentum, ask the right questions, take non-related discussions outside of the meeting and keep to the 15 minute timebox. The timebox is short even for small teams, make it count, make it work.

Communicate, be honest, even when it’s difficult

Keep an open dialogue with the team and the customer. Daily standups are one thing but keep channels of communication open with your team so they can highlight blockers and risks as early as possible. The sooner you know about them, the more time you have to deal with them.

Don’t avoid risks, embrace them. Identify the risks at the outset of the project and make your team and the customer aware of them. If there is a risk, discuss it with the client, understand the value of the thing at risk and agree whether it’s worth mitigating the risk or avoiding it altogether. Being upfront about risks and discussing them openly opens you up to the skills and experience of the customer. Combining their experience with the experience of your team sets you up to manage the risk effectively. If the worst should happen then it’s less likely to come as a surprise and you’ll all be ready to deal with it.

Realistic estimation and trends

Estimating is always difficult. What you commit to during sprint planning will not necessarily be delivered. Estimation is not an exact science, it’s based upon the knowledge that you have at the time. As a sprint progresses, as the team delve into the finer details, unknown details and situations often occur that impact the ability to deliver on time. Communicate these impacts early and avoid surprises.

When estimating, record those estimates and compare them against what you actually deliver at the end of the sprint. Discussing and understanding why an estimate was not accurate helps the team understand how they can be more accurate in future. Use the data to provide trends and base your sprint velocity based on those trends. They’ll provide you with a more realistic picture of what’s possible. When a team is feeling extra confident, remind them of reality. The estimations set the level of client expectation so be as accurate as possible and be prepared to explain any shortcomings.

The customer is not always right

If you want to add real value to your project then have the confidence to challenge your customer (This doesn’t just mean the client of an agency, it also means stakeholders etc). Requirements are often described by the customer based on what they think needs to be delivered based on their knowledge, not in terms of what they want to achieve. Question why they want something, and ask why again. Ask them what value that requirement will deliver. If they’re not clear about the value that’s delivered then why deliver it at all? “I want a carousel on my site.” Why? Because loads of sites have them? Take control, provide your own value, explain what the analytics say about the site, show the results of reports that talk about carousels not providing the value that people think they do. Facts are difficult to argue with and they help us provide answers and better solutions.

Remember, if your customer is trying to spend time and effort on something that doesn’t deliver value then they’re wasting money and effectively devaluing their product.

Take a break

While Agile can deliver great results, it can also be relentless, and fatigue can set into a project working at the kind of velocity that is achievable under this way of working. Agile delivery needs the team to be on their toes constantly and battle-weary developers are not efficient. Try to implement occasional breaks into a project. Let your team focus on other projects, personal development or holidays and give them the mental space to recharge before kicking the project off again. Use the downtime to review the project, make sure it’s on track, make sure you’ve not let your eye off the ball. If you have, refocus the project and bring it back on track.

Although project downtime is not billable, don’t look at it as money lost. It’s not. It’s so important to look after your team, to keep them at optimal performance. They need occasional oil and filter change. Don’t work them into the ground. The team will suffer, no matter how positive they might seem, and the project will not benefit either.

Iterate, review, improve, repeat

Nobody knows everything, particularly at the outset of a project, a new venture or a new way of delivering projects. Agile works best when implemented properly (not half-arsed), with a consistent team, with regular reviews and regular improvements.

When making changes to how you deliver, regardless of how big or small, make a note of the change and review the impact of that change later. Some changes will work, others won’t. Failure is an option, but try to fail fast and fail cheaply. Sometimes it’ll feel uncomfortable but use that to make things right. If you’re working within a larger organisation then feel confident about sharing your failures, describing why it went wrong and how you’re going to fix it. Encourage others to share their experiences too and learn from each other.

There is no one way of doing everything. What’s important is to develop your Agile toolkit, learning different ways of achieving results and selecting the right tool for the job. We can plan the same way hundreds of times but without trying different approaches you’ll never know if the approach you use is the best, most efficient. If nothing else, use different and approaches and tools to shake things up, to help break the monotony and keep things fresh.

“If you’re going through Hell, keep going” – Winston Churchill

Okay, it might not be quite that bad but people often give up quite easily on new ventures. If you’re struggling to get to grips with Agile, the chances are that Agile is not the cause. Implementation and external factors need to be considered. Look at how you’re delivering.

Look at what’s blocking you, taking the project off-track. Keep reviewing, even when things are going well. It’s important to understand what works as well as understanding what doesn’t work.

Persevere. Agile isn’t going away. It’s popularity is rising for a reason. Don’t let your hard work go to waste. Keep focused on what’s important, keep challenging, keep improving, maintain your authority, focus on your objectives and focus on value. You, your team, and your customer will appreciate it in the end.