I often think Agile is over-hyped while Waterfall is over-criticised.
Isn't it good practice to think before you act, look before you leap, read a map (or these days check your Sat Nav) before you start out on the journey? Procrastination, excessive risk aversion, uninformed design and too much planning are bad - but Waterfall does not promote any of these. Waterfall implemented well can be much better than poorly executed Agile.
It is definitely good to break up a project into manageable chunks and to start working on these, test them early and find real results and customer responses early. But you still need to plan, and think, and evaluate risk and size the task. Agile is not about jumping straight in.
I think Agile is "Crawl before you walk" - you are moving, not just waiting until your legs can bear your full weight; you are testing the resources and capabilities you have by starting to use them; and you are getting real-world feedback immediately.
If the Product Owner is doing his/her job, Agile (speaking in the abstract) can be look before you leap. It also depends on the type of project. If it's more about exploration than delivering a specific product, there will be some crawling involved, but if you have an experienced Agile team, you're not testing your resources and capabilities.
There are definitely people that over-hype Agile. It has been getting better, but there are also companies whose existence is based on Agile and individuals whose livelihood is agile consulting and books, so there is going to be some hype.
Interesting thoughts, and I agree that Agile seems a bit over-hyped and Waterfall is over-criticized at present. I think both methodologies are sound and the application is dependent on the project/product situation. Following your post to see what others are thinking as well, thank you!
I've done several projects where we "waterscrummed"; defined monthly release sprints but within the sprint used development/integration testing/user acceptance testing within the sprint. We staggered the sprints where dev was sprint+1 while integration/user testing was working on sprint+0, so when dev was complete testing could occur then dev went on to the next sprint. While not purist agile or waterfall, it worked because it gave us monthly capability releases. At the end of the day, we're measured by what we delivered to the business and how fast; not how much we adhered to a methodology. Happy to talk about this more if helpful.
Building on Denise's definition, I'd say Agile is looking while leaping a short, achievable distance - like leaping from stone to stone across a creek when we were kids. We'd hop to one stone, then calculate how we'd leap to the next stone. We'd did this because each stone differed in size, shape and slipperiness, and we'd apply the lessons learned from our previous jumps to our upcoming jumps.
Agile is about creating a working product .
I definitely see it's value in software development.
You save time by not gathering all the requirements upfront and only plan what you need . The keyword here is "Plan" .
If Agile is run properly , The product will still undertake good development practices, including pair programming and testing before being released. You still need to implement quality and customer satisfaction and stick to the scope of the sprint.
The need to do agile , springs from requiring a quicker time to market, and/or a Minimum Viable Product.
It gives opportunity to the customer to try out the product to see what it can do for them and then based on the usage, suggest improvements which then may form part of the next Sprint.
Agile is also useful where the Business is a startup and would like to develop it's business process around the Product.
Waterfall can absolutely be implemented in iterations as well . You can use the 5 PMBOK process groups in a Feasibility study or a Pilot before choosing to do a big bang implementation.
Agile is definitely not intended to be the absence of documentation or approvals. The scope needs to be verified by the customer at the end of each sprint and the acceptance of the product has to be formally recorded.
There absolutely have to be PMP, scope , cost and schedule plans , base lined during sprint planning and approved by the customer before execution. It doesnt matter if these are one page documents. They have to exist !
I have the opportunity to work in Agile definition and practice from the very beginning when I was part of the place where Agile and Agility was formally defined: the USA DoD NSF/Agility Forum in 1990. After that I was part of the group of authors that apply Agile to software when I worked creating the DSDM method version 1 and 2. The problem is that Agile is missundertood. Agile is not a method, is not software or IT related, is not a process. Agile and Waterfall are not matter of comparision because are not the same. Agile is a practice. Waterfall is a life cycle process based on a life cycle model: predictive. So, you can implemente Agile using waterfall life cycle. There are a lot of examples outside there including non-software products. Saving Changes...
Fantastic Sergio very well said. I've read somewhere recently that you don't "do" Agile - you "are" Agile. Thank you for reminding me of that.
1 reply by Sergio Luis Conte
May 26, 2017 10:47 AM
Sergio Luis Conte
You are welcome. When more and more people understand what Agile really is and take into account to use it in their next initiative if fits for that then it will be good for others. With your post you have contributed to that so thank you very much. Right now I am leading my seventh initiative to implement Agile at the level where it was born: enterprise level. And when you search about some practices that today becomes "buzzwords" you will find that there is nothing new below the sun.