I come from the days when Waterfall way of delivering projects was the de-facto standard. And it was successful, let me tell you.
Then the competition started and new variations started coming up until we reached where we are today i.e. extreme Agile and ScrumOps.
We have come a long way from the times where product release once a year was fine with everyone to the daily releases or incremental deployment was the expected quality of service standard.
Coming to the crux of the matter:
- Have you ever faced a dilemma or moral questioning or a practical scenario where you asked yourself why are we pushing so hard to ship daily?
- Or your team asked you to schedule some items sequentially whereas the pressure on you from the top was to make them agile [read “parallel”]?
- Have you ever come across situations where your team members were executing project internally in a waterfall manner because it was simpler to do it that way?
If yes, then please raise your hand and continue reading.
If you have never encountered such situations then trust me you are blessed my friend! Please pass on the blessings to us by leaving a comment below with your experiences.
The eternal fight between Agile Vs. Waterfall
Ever since Agile concepts came into being and helped us show a better way of executing projects, a battle ensued in the project management rooms.
While some of the managers and companies were able to use Agile to the best possible results leading to a faster delivery, efficient services and others could not make much use of it. This is a well-known fact.
Sooner, the discussions started getting centered around the points that Waterfall used to allow enough time to test before shipping, it helped ensure better quality for the consumers whereas the issues being reported by customers from field started to pile up for the Agile-run projects.
I have been lucky enough to witness this transition from pure waterfall to pure Agile to a much more balanced Agile during my stint with world-renowned companies such as Microsoft et al.
My own scales used to tip in favor of one concept only to tip towards another as I ran into issues!
This frequent oscillation of my feelings, affinity, and common sense helped me understand a few things very clear and these were that:
- Agile was being blatantly misused in the name of faster development. And this was leading to a poor quality software being shipped to earn revenue fast and quick.
- Waterfall was being looked down in an unfair manner. It actually had a very mature way of delivering projects that was being run down by popular opinion.
- Quality was suffering and team morale was going down due to continuous pressure on them.
My multiple conversations with my peers and experts in the industry revealed that they were experiencing similar pains. One of the research revealed that projects revenue had shot by a whopping 230% by switching to Agile mode, but the employee satisfaction dropped by 53% and the number of issues from the field jumped by 80%.
Obviously, Agile is not going away, neither we are going to slow down to yearly shipping once again. So what do we do then?
Juggling Agile with Waterfall
I like to call it “Balanced Agile” [Trademark; Copyrighted by Abhinav Gupta, 2018].
Balanced Agile is a concept that aims to help projects get back to health. Too much of everything is bad; isn’t it?
Before I delve deeper into what “balanced Agile” entails, I would like you to know what benefits you will derive from juggling Agile with Waterfall efficiently:
- Your work life balance will improve. Chances of you working over the weekend or late nights will go down considerably.
- Your team will start respecting you once again and their motivation levels will go up certainly.
- The quality delivered will be a slight notch higher and your customers will feel better with lesser number of issues on ground.
And trust me, it will not hamper your project margins. Agree there will be a slight slowdown on topline but those effects will be nullified with reduced cost for low productivity, better quality, and lesser live field issues. Don’t be surprised if you actually are able to increase your margins if done properly.
How to strike the perfect balance?
There are many ways with which you can implement Balanced Agile in your projects irrespective of domain. Whether you are handling a software project, hardware project, manufacturing project, anything can take benefit of this approach.I am assuming you would like to make this switch in your ongoing projects, so start with calling a series of post-mortem meetings that discuss the following items:
- Issues reported from field
Issues reported in last 3 months
Minimum 3 sittings
Make sure you actually know 5-Whys of the problem being reported.
- Review the redundant work items being done by the team in last 6 months.
6 months duration helps make reasonable trends
This feedback of redundancy should be taken from stakeholders
Make a list of top 50 items that are being used repeatedly but don’t have automation
Make a list of top 25 items that are not adding any real value and can be merged with other activity
- Review team’s pulse
Ask your team about their feedback on the overall project, product, management
Explain to them the intention of this exercise
If they feel more comfortable in giving anonymous feedback then let them give
Finally, come up with a list of items that reduce project complexity if they are done sequentially instead with Agility. Because the trade-off you will do in this area will help you buy some extra quality and better customer reaction by letting go off some speed in project execution.
Once you are done with these reviews you should come up with a plan on how you want to incorporate those change in your existing project wheel.
But not before considering the impact on:
You need to have your stakeholders on boarded with these changes but above all, it is you THE PROJECT MANAGER who should be convinced with this plan. Only then you will be able to drive it to success else it will end up being just another initiative that bit the dust.
I will list out some of the common examples of items that are causing the pain to you, your customers and team. These are collated based on my experience from my projects.
Items that commonly are redundant or lead to time wastage:
- Daily status meetings
- Separate sync up calls with entire team to discuss issues being faced by only a couple of members
- Too many approvals or organizational hierarchy in your team or company
- Team deadlock where one team member is dependent on another but that person is unavailable
Items that can improve team efficiency without creating extra burden:
- Cross training. Helps the team members reduce the dependency on each other. It comes in handy in unexpected situations.
- It helps the team members improve their skill repository leading to a better resume. That way you get support from the team as well.
- 25-Minute sprint review meeting. Focus only on the good things for the first 10 minutes then delve into things that could be improved for the next 10 minutes followed by last 5 minutes to summarize.
1) Remember this meeting is not to discuss people but to focus on highlights and low lights.
2) I have intentionally kept it for 25 minutes. So because it creates a psychological goal for us to be efficient.
Items that are most commonly reported from field:
A feature that used to work earlier is not working anymore or in other words, a new way of doing things is not easy to use. This comes under scenario engineering.
Good amount of field issues are also due to lack of proper customer training. So you should focus on that as well.
Guided tours help in such situations.
I hope my post on how you can juggle Agile with Waterfall in a seamless manner for better results. I will certainly look forward to hearing your experiences through the comments section or you can write to me on email@example.com
All the best!