Every profession has their myths and things that are accepted as true, and the Agile and project management world is pervasive with all sorts of them. Here we will look at a few things in Agile that may be accepted by some to be an established fact within Agile, but in reality they may be myths and certainly debatable.
1. You must live in an Agile world in order to practice Agile
Pedro: We are both fans of Agile, but to say that one must live in an agile world and practice Agile are two different things and the first seems to be associated to the changes and peoples interpretation. It may seem like Agile takes over everything. Practicing Agile can be very complex, but it is not always applicable to all of your work.
In my case specifically, there is an issue of the enterprise culture and education that mislead you in certain cases with the fact that they have too much pressure placed on daily work. Decisions pressed on quick judgement lead one to ignore several different methods because they are considered time wasted. In this way, sometimes an Agile approach is chosen hastily and without thought.
Joshua: Saying that one must live in an Agile world in order to practice Agile may not always make the most sense. While it is true that you should adopt this mindset of change, collaboration, and continuous improvement to be effective at Agile, you have to also recognize when to apply the tools you have. Going all in on a process because “that’s what the rules of Scrum are” (using Scrum as an example), immediately makes you less Agile.
From my own experience working in Robotic Processing Automation (RPA), the vast majority of my projects would not fit into what one would normally label Agile. There is good reason for that, RPA tends to be several smaller and low complexity projects. It’s more of a whole program with people working in various stages of different bots as they go through the bot development lifecycle. Agile is made to reduce complexity of a project, but going full Agile in my experience actually increases the complexity when it comes to many RPA projects.
We can still bring in things from Agile that may not normally be utilized within the traditional waterfall approach. This idea of putting in feedback loops to ensure our project is on the right track, for example. We make attempts as we move through the bot development lifecycle to collaborate with the business units by showing them what we have accomplished and making it a point to ask them if things are going as they expected. This can, and has, saved me lots of time wasted through misinterpretation of their goals with automating a process.
The point is, failing to look outside of the Agile box can make you less Agile. Every practice within an Agile approach is not always the best approach for every given situation that you may encounter. There can be a benefit to adhering to a framework in some situations, in others you may find things work better outside of what is traditionally thought of as Agile.
2. Agile is not a project management method
Pedro: It is not uncommon to hear companies say that they don’t need project management because they work on Agile. Then we just ask… “So what would you classify Agile as? What is the purpose of applying Agile?”
And again frequently the answer we get is “It’s make it simpler”, “it’s applicable to make companies running faster instead of going deep on bureaucracy” or “it’s adequate for developers to organize in to teams, and we don’t need any management to work on projects except for some services and results”.
The truth is that Agile is an incremental iterative development life cycle of project management! Believe it or not, it’s a branch, not an alternative. It means that when deciding through a project which kind of development method should the team use, Agile is an option which is commonly used when the team doesn’t have much information on what their project can become.
Joshua: Many people in Agile don’t like the term “management.” I can’t claim to know their full rationale behind the dislike of the word, but it seems to be related to this idea that we have a boss dictating to us what we need to do and how we must do it. That style of management doesn’t have to exist, even in a traditional waterfall approach. That would fall in line with a more authoritarian type of leadership style.
The fact is, someone, somewhere, needs to manage the project and Agile is certainly one method that can be used to manage a project. There are duties that must occur for a project to move forward, and these duties fall under the management umbrella. You may only have a vague sense of what you want to accomplish and how you want to get there, but you still need to guide the team to get there. That may not necessarily be a function of just one person, but those “management” functions still need to occur.
I explored this idea a while ago with Scrum (Who is the Project Manager in Scrum? ). My conclusion is that everyone on a Scrum team is performing some duty that leads to the project being managed. You very much need project management with Agile, you just don’t need that authoritarian style of leadership. You don’t really need that style of leadership anywhere.
3. Agile can’t work together with other project management tools
Pedro: Agile works with almost all project management methods and tools I can think of. We could say, maybe, that some tools can be more used then others but even so, not any specifically.
Let’s make a specific example. Agile or any other development cycle, more predictive or more adaptive, need to monitor progress. Therefore time management, schedule management, and/or cost management are as important as any other.
Joshua: Yes. No. Maybe. It depends on the tool and the current situation.
I would say that many commonly used Agile tools borrow heavily from traditional project approaches. Some tools work better than others within Agile, and many need modified. As Pedro mentions, we can bring over time management tools, schedule management, and cost management – but I think most end up modified when used within Agile.
As an example, time is often managed differently in Agile, but it isn’t so different that we can’t borrow ideas that worked in a traditional approach. We may just modify it some. We usually aren’t planning out every step for a full year, and as such a traditional Gantt chart may not work (not to say I haven’t seen people get frustrated trying to use one). What we can do is bring in other tools to help us handle this, or we can modify how the Gantt chart works. In the end we may end up borrowing things from traditional project management, it just may not always be able function the exact same.
4. Agile is simpler and faster than traditional project management
Pedro: This one is quite fun because, as metaphor, we would think that Agile is like a Ferrari and project management is the old traditional Cadillac. When we think like that, it sounds kind of hilarious and this is in fact the feeling when we hear comments like this.
Agile can become complex as “hell.” Additionally, what some people call as traditional, they mean predictive, and everything that it is predictive is for sure more perceptible, therefore simpler. The simplicity that we can understand in Agile comes sometimes from some frameworks that reduce some of the tools, but that happens with or without any framework by the hand of the project manager. Any project manager has to choose the strategy according to the company culture or the project dimension and always independently of which development method we are using
Joshua: Simpler? No. It’s goal is to reduce complexity of the work you need to perform, but doing that isn’t a simple “one and done” type of process. This may make the complexity of the work simpler, but the methods to do so more complex. The complexity that it reduces is in our understanding of the work, not in our approach to the work. Calling Agile “Simpler” I just don’t believe is an accurate description of Agile.
Faster? That isn’t its intent and it very well may not be – and that’s not a bad thing. Although, in highly complex projects it could reduce the need for rework, thus making it faster in the long run. But I wouldn’t adopt Agile if your goal is speed. I would adopt it if your goal is accuracy of your output during uncertainty and complexity. The end result COULD be faster, but not necessarily.
5. Project management tools are dead, long live agile
Pedro: A few years ago I heard about a company promoting a project management software by saying “project management tools are dead.” This is kind of contradictory, and that might be the reason they even changed the brand name later. After all they provided a wonderful interface but it was not something to replace project management tools. The interesting thing though, they kept a lot of wonderful traction for that idea of project management tools being dead. About that time, I received some criticism saying that I should think about new tools like them. However, the solution is not about having new tools, it is about creating new ways that are easier to understand and simpler to follow. These tools existed before, they exist now, and they will exist in the future.
Agile requires basically the same tools as any other project management development process, they will never die and certainly not because of the growth of Agile community.
Joshua: Whether you are a co-located team using sticky notes on a white board with a camera to preserve the status, or you are using a piece software in a distributed team – Project Management tools will always have a place in Agile. The goal should be to reduce the learning curve on those tools and not have them take over the project.
*Personally, I think taking a picture of the Scrum board everyday and storing those photos leads to that tool taking over the project (I have seen this done). I find it Ironic that Agile adherents often seek automated ways to deploy to production or test the complex software they are building to help streamline their process – but tout this Scrum board method as the best method. I have always disliked this approach as it is far more involved than a nicely designed piece of software that can do a better job. I can just search for the information I want, you can sort through your photos for hours trying to find what you want.
6. Agile reduces the need for methods and tools
Pedro: If Agile reduced methods and tools, it wouldn’t be called “agile” but more like irresponsible. The only way the methods and tools are reduced will depend on project dimension and company culture. Agile can be extremely complex when we go to several other frameworks, making this super hybrid methods full of quality procedures for planning, testing or validation like typical DevOps systems.
Joshua: As I stated in #5, the tools will always be there. Agile won’t magically get rid of them, or magically reduce their need. You have to actively try to reduce that need, and that may even be outside of your power. Sometimes, the tools you use are more dictated by the company you are working for. Sometimes those tools have gaps, and you have to cobble an Excel file together to fill those gaps. You can complain about it or deal with it – in the end you are going to have to do it either way unless you can convince someone to take pity on your needs.
Summary
So, maybe at the end, most of the readers would simply ask “In what ways is Agile different and why is everybody a fan of it?”
We definitely can’t speak for everybody, but Agile is in fact an approach that can be used for projects which intends to reduce failure when the project is full of unknowns. Therefore, as a simple example, we can just begin first with a small prototype, we tested and validated, then we move to another version more complete. It may still be a prototype, but we would test it again. Since there is in some projects a lot of unknowns, Agile might be the best method to take care of these unknowns.
Agile isn’t a magic wand that will get rid of tools or the need to manage your company’s projects. If those are your goals, then by all means make them your goals – but don’t expect strict adherence to an Agile framework to automatically achieve that. You have to actively work towards your goals.
Be “project” oriented, be well, and under scope
Sources:
Header Image from Pexels.com Yan Krukov:
Umbrella icons from Pixabay.com (modified by me): and
Tools image from Pexels.com:
Source link