Agile this, agile that... Everything is turning agile. Everyone is talking about it, but many people don’t really know what it means. Recently, I have come across the term agilitis. I think it pretty accurately describes how agility is perceived. But will everything be better if we use the agile method? Does every business need to be agile in order to even function properly? And what on Earth does it even mean to take an agile approach? It’s time to clear up a few misconceptions!
The endurance runner. In a nutshell... there’s no such thing. The opposite is true – agile methods have no project management. This role doesn’t exist. There’s also no waterfall project management. Waterfall methods and agile methods are (as the names suggest) methods for handling projects. Of course, it’s possible to deploy tools from conventional project management in agile methods, but that doesn’t make your project management agile.
The academic response: “it depends...” For various reasons, agile methods are generally better for software development than something like the waterfall approach. But that doesn’t mean that the projects are better, too. A company needs to have a certain degree of maturity in order to work effectively and efficiently with agile methods. This maturity might have already been achieved before agile methods are implemented, or it might be reached in the course of the implementation. One thing is for sure, though. After the start of implementation of agile methods, the projects will run somewhat worse, and the teams will need to put in more effort than before. When you’re learning something new, you won’t be a wiz at it from the get-go. Pretty soon, though, you’ll see improvement.
No. If you’re using SCRUM, you probably are agile, but there are other agile methods, for instance, XP & Kanban. Working agile means taking the agile manifesto seriously, following the values and principles and continually improving yourself. The methods aren’t that important. It’s the mindset that counts.
And yes, that's the right website, and yes, that’s all there is. The agile manifesto is intentionally kept very compact.
This is an almost religious outlook. And (as the case in many religions) it’s simply incorrect. The agile method might be much better than other methods for certain projects and products. But not every business can use the agile method. Sometimes the organizational structures or the customer requirements are not suited to agile thinking. In such cases, it’s better to stick with conventional methods. Otherwise, if you’re just dead set on implementing agile methods anyway, you’re bound to fail. That’s when people get frustrated and blame the methods.
This is one of my favorite myths. Unfortunately, for a long time, people have tried to run agile projects using conventional project management. This is unnecessary. Even if agile methods don’t involve the project management role, that still doesn’t mean that these tasks aren’t realized by other roles. Apart from that, the tools simply look different than they do in conventional project management.
Let’s be serious for a moment. Either your method is agile, or it’s not. There’s simply no in-between. What you can do, however, especially if agile methods are not an option, is to borrow tools from the agile sphere. For example, the daily standup from SCRUM can help with the daily coordination of your team. Or try the Retrospectives as regular lessons learned. But this alone doesn’t make a method agile. A more accurate term would be hybrid method. A waterfall model is still a waterfall model, however. On the flip side, there are only very limited possibilities for carrying conventional tools over to the agile sphere.
One of my favorite phrases that likely lead to the term agilitis. If you're going to implement agile methods like SCRUM, it is important – essential even – that Management is behind it and wants it. But you won’t experience agility if Management simply demands that you use agile methods without understanding what that means or giving you the necessary freedom to do it. In order to be agile, a company has to change the way they think and not be afraid to make mistakes. Otherwise, the implementation will fail. It doesn’t matter what consulting firm is involved, how many consultants you hire or how many training and certification courses you complete.
Agile methods give off a vibe of unpredictability that is actually deceptive. Waterfall methods give off a vibe of security that is actually deceptive. No conventionally managed project ends up being delivered exactly as initially planned. This goes back to the definition of projects. Projects are innovative, high-risk, dynamic and complex. Agile methods address these characteristics directly and say that if the path to your goal is uncertain, then let’s probe ahead and continually check to see if we’re on the right path. At the end of the day, it’s no harder or easier to plan either method.
Just between us, the same goes for conventional methods. The magic triangle that connects cost, content and time applies to both agile and conventional methods. The assumption that cost, content and time are fixed is incorrect. There are a few tools that you can use with agile methods to plan out fairly well what you’ll get by when.
Big projects can be agile, too. The hard part, though, is in the method. If the organization is too large, SCRUM can end up slowing you down, whether it’s a project or a line. That’s why it’s important to understand that agility doesn’t depend on the method. If SCRUM is no longer appropriate, you simply adjust the method. To do otherwise would go against the agile approach.
Agility is more than just a buzzword, and it’s about more than just implementing a new process. If you’re going to implement agility, prepare to be confronted by a change in mindset, organization and daily work. This change is going to hurt; it’s going to bring up conflicts. But when the change process is complete, it will be better than before. You will see higher motivation and better delivery quality. The key is just to take it seriously and give up on the idea that you can switch to an agile approach overnight. Otherwise, you’re bound to fail.