Friday 6 February 2015

Who Am I?

I am Waterfall. You must have read a lot about me and have probably used or may still be using my method in your projects. I have lived a very fascinating life. I and my followers have tasted success in most projects with my well-defined processes. Sometimes there have been failures and slippages during deliveries. . . . OK, OK, I admit that many times there were slippages. But it was neither my fault nor that of my processes. Even the people involved were following the processes well. Everything was in place. The whole blame goes to the clients, as they never stuck to the initially defined requirements and kept on asking for changes, even in the advanced stages when such changes were too expensive. And the most daunting thing was that the demand for these changes was always urgent.

I sometimes see that teams are in the process of making plans for the requested changes and are near to finishing detailed documents, and suddenly clients change their minds and come up with new changes/functionalities. Even worse situations happen when products go for user acceptance and they find that the functionalities incorporated are not as intended.

Furthermore, the complexity of projects is at a peak these days. There was a time when clients were patient enough to wait for products. They used to provide each and every small detail, and based on that we prepared precise documents and contracts. But now every client wants early ROI (return on investment) and every requirement is urgent, due to competitiveness in the market.

Nonetheless, things were working by and large -- until I met my cousin, Agile.

She is younger than I and seems very dynamic. I came to know that she also has a few frameworks/methods -- Scrum, XP, BDD, TDD. She advocates iterative deliveries with the collaboration of customers/clients. I thought I should analyze those Agile methods to find out why they were going viral.

Very soon I encountered Scrum. He has some weird activities, such as the Daily Scrum, sprints, review and retro, backlogs, etc. I started comparing these ceremonies with my practices, and I found that most of my followers were doing such activities as and when required. However, the significant difference was the timeboxing.

Then I remembered the "Cone of Uncertainty" in software development.



The "Cone of Uncertainty" graph was initially discussed by Barry Boehm (Boehm, 1981) and later called the Cone of Uncertainty by Steve McConnell (Mc Connell, 1997).
And to my surprise, the uncertainty is being handled very well in Agile/Scrum. The reason is those small sprints and fail-fast strategies. The fail-fast strategy means trying some task, getting quick feedback, and then inspecting and adapting as per the feedback received.

I started liking these small yet effective measures. But I still had one more thing to consider. The Iron Triangle. . . .



I always give the example of the Iron Triangle. And this is the fact, that one has to keep a balance among scope, schedule, and resources while maintaining quality. How was Scrum was handling that? What I found was that Scrum also maintains the triangle but has some flexibility. If clients choose the fix date, Scrum accommodates only those features that are feasible to deliver by that date, keeping a focus on prioritized features. And if scope is fixed, then the schedule is planned accordingly. The most striking part is the involvement of the client/product owner from start to finish during product delivery.

Scrum also has a 
Manifesto for Agile Software Development:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

There were a lot of other such practices in Scrum that amazed me. I felt transformed by this upstart project development practice. I felt energized. And why not? I and my cousin were both from the same family -- Project Management -- and the sole purpose of my existence was to help the people managing projects.

I advised my followers to learn to apply Agile practices, to embrace agility for organizational change. There were a few questions from a few managers about their existence. They feared losing control of team management. They were concerned about their role in self-organized teams. And certainly their questions needed to be answered to mitigate their anxieties.

This was quite challenging to me, guiding them toward agility. But I was determined, so I explained them the following:

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is. -- Philip Anderson, The Biology of Business
Although project teams are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. At the same time, management avoids the kind of rigid control that impairs creativity and spontaneity. -- Takeuchi and Nonaka, "The New New Product Development Game"
So do you think that I got defeated by my cousin Agile? No, I have not been defeated. I have given way to Agile for advancement of project management as per the current fluctuating and complex projects. I will still exist by transforming myself according to the specific needs of organizations. Many of my good practices can be blended with Agile/Lean/other practices.

The word water in my name reveals that I can change my shape per the needed vessel. If you are using my method, you still can tailor me by blending agility as per your specific needs and moving further toward agility.

Who am I? I am Waterfall. . . .

 Originally appeared at: https://www.scrumalliance.org/community/articles/2015/january/who-am-i-a-biography