Agile in waterfall or waterfall in agile?
Agile Antipatterns
Many teams claim they adopted agile over a waterfall model for software development. Surprisingly there are instances that teams claim they do ‘Agile’ just by introducing a sprint/iteration cycle and a tool (JIRA, Rally, TFS etc) with lots of misinterpretations. What teams fail to understand is agile development is a specific approach in software development or project management that waterfall cannot achieve.
Waterfall Development
The waterfall approach is a sequential project management process with various stages of activities such as requirements gathering, high-level design, low-level design, code development, unit testing, integration, then system testing, alpha & beta testing and rolls out. Waterfall model is highly structured and it works well for specific types of projects where requirements are unlikely to change and with a fixed end goal for product delivery.
Agile with mini-waterfall
There are instances where we see teams often switch back to the waterfall way of working while using the agile delivery model. There are concerns that team members are spending more time in attending multiple meetings and overwhelmed with the number of calls during the day. Teams do participate in standard scrum ceremonies such as Sprint/Iteration Planning, Daily Stand-Up calls (Scrum Call), Sprint Review and Retrospective. In scaling environment; additional ceremonies include PI Planning, ART Sync, System Demo and I/P Event.
However, there is also another set of activities which happens in the parallel world of agile is team members involved in other events/meetings which are not facilitated by the scrum masters like
Daily Development Updates
Daily Testing Updates
Daily Status Email
Weekly Status Email
Reports (Including utilization in hrs)
Though team boards give visual information on the progress of work items which was committed, above events often continues to be practised.
Agile is often misunderstood and below two anti-patterns are seen where teams using scrum model making it a mini-waterfall.
Code development in the first week and testing in the second week of the sprint.
Development in sprint N and testing in N+1
These lead to confusion whether teams are doing agile or waterfall. Transforming teams from the waterfall model to agile in the right way is critical to avoid the discussed items. Let the cue and reward remain the same, i.e. Product Development and Customer Satisfaction. Replacing the routine which makes the difference in successful transformations. Teams should understand the benefits of the agile development process by practising agile ceremonies. Having said that, it is also important to move away from the old way of working (learnt from the waterfall model). Otherwise, there will always be confusing whether the team is doing agile in waterfall or waterfall in agile projects instead of focusing on working product.
True. As it is said, Agile is the mindset transformation rather than just following the ceremonies without appreciating the underlining principles. As you rightly brought out, once we understand and appreciate the values that we intend to create to our customers, aligning to agility becomes possible.