Agile Development and Project Management — Part 1
Part of Product Management 101
Agile is not only for the IT industry nor just for developers and project managers. Anyone can apply agile across different industries in almost any project. But just because you can apply Agile to a project doesn’t mean you should. We’ll go over what projects are better suited for Agile later in this series of articles. For now, let’s learn the basics.
What is Traditional Project Management?
Traditional project management is a linear approach, it is often referred to as the “waterfall approach” to project management. This means that all the phases of a project are completed in a sequence, with one phase being totally finished before you can move on to the next.
The phases of a project using this methodology are: Initiation, Planning, Execution, Monitoring, and Closure.
What is Agile Project Management?
Agile project management is a more modern approach to project management and has been gaining popularity among software development teams since early 2000s. Unlike Traditional project management, Agile follows a non-linear process and focuses more on teamwork, collaboration, and flexibility, as opposed to a strict sequence of activities.
Agile Project Management takes an iterative approach to project management, in which projects are time-boxed into short sprints. A sprint typically lasts from 2–4 weeks, and at the end of each sprint a working product is released.
In Agile you wouldn’t spend months building what you consider the final product, instead you would create a basic first iteration maybe just the homepage to get started and to get the concepts out there and then you would enhance it over time. Each iteration would involve adding more features over a period of time, each time prioritizing features that provide maximum value to the end user. In Agile we call that period of time sprints and sprints generally last two weeks.
The analogy above explains a key concept in Agile. In Agile, the minimum you can deliver which satisfies the basic requirement of the customer is known as the Minimum Viable Product or the MVP. The image shown above is an excellent analogy, the wooden seat on the swing serves the same bare minimum requirement of the customer.
We’ll go deeper into Agile concepts in the articles that are coming up but before that let’s recap some important concepts.
Agile is a methodology to deliver incrementally.
It’s iterative and time-boxed.
And that period of time, which is generally two weeks, is what we call sprints. Sprints are sometimes called iterations.
and what you work on during those two weeks are usually called features, these features give value to the customer. These features are what we call user stories.
Now I could’ve waited till forever and kept on improving till releasing this article, but in that case I wouldn’t have been providing any value for a long time. Release and iterate!
How is Agile different?
It’s different in many ways. In a traditional project delivery, you would start off with an analysis phase. This phase would take a couple of weeks to a couple of months, then you would move to a design phase and spend again a couple of weeks or months and THEN you would actually develop or code.
After all of these processes are done, you would then pass it on to the QA team for testing and then once it’s approved by the QA team, testing is done.
So traditionally, one phase has to be finished before the next phase is started. All the milestones and deliverables have to be met and signed off.
You would also ensure that the scope doesn’t change and keep that as constrained as possible since changing the scope would translate to the project taking even longer than originally planned.
And finally in the traditional development, you would work on the final solution from the very beginning, you’d be working on delivering the product with all the bells and whistles, but you wouldn’t do any of these in Agile.
In Agile, you’d plan and analyze every two weeks or however long your sprint is. You would deliver iteratively, often and quickly. You would also embrace reasonable changes in the scope. Since you are working iteratively and building products along the way, you are able to provide more flexibility to your end user and involve them in the development process. This is perhaps THE MOST IMPORTANT advantage of Agile. This is also why so many business owners, stakeholders and customers love it.
Another key difference is that Agile focuses more on the actual work than on documentation. Now don’t go ahead and conclude that Agile doesn’t involve documentation, Agile does, it just isn’t the main focus. The main focus is building the actual product. The documentation is kept short and simple (Always KISS: Keep it short and simple).
Thirdly, roles blur in Agile. Everyone on the team can be involved in testing, not just the people that would normally do it because that’s their official role. Though this doesn’t mean that everyone has to do every else’s work. Your key takeaway from this is that Agile can allow for roles to blur and overlap or complement one another, that’s okay. People embrace this in Agile and support each other to ensure the team’s success.
Lastly, let’s talk about planning. In agile planning is adaptive. Priorities can change for each sprint depending on what the team defines. In Agile, requirements can change and the team is open to those changes, that doesn’t mean that Agile dictates that you should change requirements, it just means that if the team considers something no longer a priority, well feel free to descope it.
In traditional project delivery, if there’s a requirement change from the client, you’d say “well, erm,.. ahem,.. ermm… <profuse sweating> you had signed off on vertical at the beginning. and now it’s ermm… <fighting against crippling anxiety> too late… erm..to make that change. “
But in Agile you’d say “Awesome! I was waiting for someone to give me a reason to change the scope, the developers have been super mean to me lately and this gives me good reason to change EVERYTHING FROM THE START! HELL YEAA”
Also no, that’s not what you’d say.
You’d say “Sure, by the end of the next sprint, we will have another demo with X,Y,Z outta the V-Z changes you want made.”. Given scope is varying, you might negotiate with the product owner about some of the user stories of the next sprint and move them to the next one or maybe remove them so that you can actually deliver and meet their expectations.
See the difference? In Agile, the team is well… Agile. That’ s the point. If this article was a pop up notification, that’s what it would’ve been “Agile project management is Agile”. People love Agile. I know, okay? I was there when people started loving Agile. I saw it with my own two eyes.
