Difficulties of Being Agile
Common mistakes of transition to the Agile workflow and why should you care about them.
As a reputed coach and consultant James Schiel said, a lot of agile organizations instead of being truely agile just using right words. The cause of that is general misunderstanding of the idea of what the Agile method actually is. This leads to a set of mistakes in organizing software development process. In this post I tell about six ones I’ve been coming across most often and of which I think as of the most common and yet crucial.
People who got used to work with exhaustive requirements often interpret the word Agile wrongly. Programmers think that they are allowed to do anything. Testers are sure that they will need to re-write test cases every day because requirements will also change every day. But in fact, the Agile methodologies teach us how to get by under volatility: to respond to changes and to re-arrange plans, to meet user’s needs and to deliver product by small chunks. In other words, it teaches us to exist in the real world.
The Agile methodologies teach us to exist in the real world.
2. Mini Waterfall
A lot of teams adopt Scrum or Kanban, start dividing their work on iterations and don’t change their attitudes to the working process. They tend to prepare exhaustive requirements for each task before a sprint. They don’t let any changes during the sprint. They still think of the development as of a set of phases — analysis, development, testing… And in the end of the sprint they expect to get exactly what they planned despite all problems and changes that emerged during the sprint. This phenomenon is called Mini Waterfall. Instead of solving problems it masks them.
It’s true that iterations help navigating release cycles. But what really matters is organizing your workflow so that all team members do their job simultaneously. The main point is to highlight the priority and work together on getting it delivered to market.
The main point is to highlight the priority and work together on getting it delivered to market.
3. Far-Reaching Release Plans
Anything that can possibly go wrong, does. And it always takes longer than you expect, even when you take that into account. These truths are always valid.
You’re not going to implement the long list of new features by the scheduled date. If you commit to completing all tasks, you’re going to move deadlines constantly. Commit to fixed deadlines instead and focus on finishing as much valuable work as possible before the next release date.
Commit to fixed deadlines and focus on finishing as much valuable work as possible before the next release date.
4. Early Test Cases
Testers who take the transition to Agile hard are followed by their old habits. They tend to fully cover requirements with test cases and don’t realize that the final result may vary. The Agile approach encourages you communicating with team, figuring out what the result is going to look like and keeping your expectations updated.
Static test cases are good for your regression suite. A better way to check acceptability of a feature is exploratory testing. Imagine you’re a user and think about whether the result solves the problem described in requirements. If you’re afraid of forgetting something, mind maps are here to the rescue.
The Agile approach encourages you communicating with team, figuring out what the result is going to look like and keeping your expectations updated.
5. Meaningless Metrics
Managers like using any opportunity to measure the results of work. Sometimes it leads to a meaningless or even harmful conclusion. Are many lines of code good or bad? — Is it a lot of work done, or a poor, spaghetti, code? Are a lot of defects found good or bad? — Is it a low product quality, or testers who have their job properly done? Just stop wasting your time counting everything countable.
Stop wasting your time counting everything countable.
6. Old Habits
Old habits die hard, but that’s the price. You need to break your mind-set and build the new one from scratch. Stop waiting for everything to be documented beforehand. Stop expecting a feature to be completely implemented before testing it. Stop drawing a new set of features to the shine before releasing them. The only thing you’ll achieve by this is that your product will become obsolete before your customers saw it. If you’re not embarrassed by the first version of your product, you’ve launched too late, after all.
Old habits die hard, but that’s the price.
Why Should You Care?
Sometimes it’s easier to say than to do. Why whould you break your current workflow that has been serving you faithfully for ages? Here I collected the most important, in my opinion, benefits of transitioning to Agile.
Delivering the product early keeps it updated and therefore, your customers are happy with you. You’re constantly improving your software while other companies are struggling to catch up their plans.
Working in short iterations and delivering big features in small (yet valuable) chunks makes development simpler and less error-prone.
The sooner you realize the need to change direction of development, the cheaper that change is. If you spend a two weeks sprint implementing a wrong feature it’s not as catastrophic as half a year of planned work lost. Agile approach makes the price of mistake affordable.
Clients will force you to change plans very often and you will be prepared to that.
Agile encourages paying attention to learning and creates environment to experiment. You will always be in the forefront of the latest instruments and technologies.
I’m aware that Agile approach is not a novice. But at the same time I’ve met a lot of people who just don’t understand how it works. Although they all are professionals, good programmers, talented testers and experienced managers, they still miss opportunities. That’s why I think such posts are still relevant. And I hope this one will do some good, too.
My other posts about Agile method: