“Why do we use Agile?”
“What is the purpose behind it?”
You must have asked yourself these questions at least once.
Perhaps you’re among the people who think the answer is obvious — “To deliver more and quicker!”
If you are, I suggest you reconsider as this is the most common misconception about the purpose of Agile. In fact, if your answer is the above, you most likely don’t use the Agile approach at all.
It happens that software developers focus too much on completing tasks and watching them move across Scrum boards instead of thinking what good their code might bring.
If you understand the needs driving the requirements, you will write better code. All the change requests coming your way will make more sense. When things make sense to you, it is less frustrating to change the same code again and again. But most of all, you give yourself a chance for a little oxytocin. Your body releases it as a reaction to positive social interactions. It is the feeling you get when you are glad that you were able to help someone.
Knowing these dependencies, it’s only natural to try to develop empathy before you develop software. It’s a win-win situation!
Let’s put on the Scrum Master’s spy-glasses and investigate the 7 critical points for a project’s success or failure. Which one will be a sin and which one a win when it comes to the Product Owner?
Imagine your team has done everything that was required. They’re happy. At the same time the client is angry because the work is incomplete. Say “hi” to poor, assumed or undefined definition of done - source of many miserable failures.
Client demo is so damn important that it’s hard to overstate it! Not presenting working software is a brilliant way to pile up problems in the project. Yet plenty of its benefits are subtle and easy to overlook. Do your project a favor and know what’s to gain or loose here.
Sprint scope changes are one of the most common ways Scrum goes sideways. “We have sprints, but… we change their scope.” The paradox of keeping a sprint scope fixed is to welcome change!
Project estimates are extremely difficult and important. Clients need ones they can rely on. They put them on their roadmaps. They make promises to their stakeholders based on the estimates. They budget according to them. There's always a pressure for the estimates to be low (cheap), yet accurate. At the same time we never have enough information about the project. This is the crux of every project. That's the intersection of plans, expectations, priorities, assumptions and uncertainties. How do you handle all that?
Have you heard about Scrum, but…? This means “we do scrum, but…” we don’t do retrospectives, don’t do daily standups, etc. Well, there’s a deep wisdom behind all the Scrum practices we give up. Be aware of the risks you create and know how to counteract them. This is a first post in a series that aims to show how you can keep the benefits of Scrum in real life.