Agile Myth: Agile Development = Requirements Change at Any Time 24×7
There is a myth out there, that if we are Agile we can “Change” what is being done at any time, 24×7. People say we are “Agile”, so we can change at any time, Right? I personally would love to roll my eyes when I hear that said. Many business people actually truly believe it. Well that is a Myth! Agile Development does NOT allow for “Change” to the work effort 24 x 7. In Agile, no one is supposed to change the Agile Team’s plans, while they are Sprinting. My question to those who want to is, why bother “Changing” in the middle of a Sprint, useless something blew up? The Sprints or Iterations only last 2 weeks or less and in the old Waterfall process the time would be months. Change can come soon enough in the Agile sequence.
Agile Development allows for change to be inserted at regular intervals. Those intervals (Sprints or Iterations) are typically very short (2 weeks to 4 weeks or even less). So in my mind, if a “change” can’t wait until the next interval which is only a couple of days away, then that organization has even bigger issues to tackle. Seriously!!!!
Could one image a Waterfall development approach that allowed for change anytime? Hmm? Maybe that is one of the main reasons why waterfall projects tend to be late. They never get out the design phase because of the constant change. I guess one could constantly change out (modify the Sprint Backlog) the User Stories or Requirements in the middle of a Sprint. However, this would cause the time already invested in User Story task planning to be wasted and this planning process would have to be repeated again for the new User Story “Change”. This introduction and removal of User Stories would a less than optimal use of the team’s time and for what just to move ahead a couple of days early?
One of the Great Things about Agile Development is that the “Change” window intervals are set at a regular pace, therefore, the Product Owner (PO) or Customer knows exactly the opportunity or window to introduce a change. There is no guess as to when, because everyone knows. It is pretty simple and made visible to all. There are no “Secret” meetings.
So if this is a Myth, that Agile Development = Requirements Change at Any Time 24×7, then when does change occur in Agile Development? Typically, it happens at the Sprint Planning meetings occurring at the very beginning of each Sprint. The change requested is also verified and groomed by the team and PO / customer prior to the Sprint Planning Session. So these changes are typically well thought out if ones Agile organization is a top performer.
Here is a simplified scenario (see the graphic to follow), for a new Fixed Price Development proposal. At the bidding and proposal phase, the PO and Systems Architects (and even the Dev Teams) came up with the following Feature and User Story Development plan. They broke the proposal into four Features and created rough User Stories as part of their proposal and estimation process. The PO and Systems Architects figured it would take 5 Iterations or Sprints to complete, The Team even threw in a couple of Spikes to reduce the Risks to the on-time delivery of the Fixed Price contract.
As shown in the first graphic earlier in this article (shown again below), there are opportunities to change the Sprint Plans at the Sprint Planning meetings (shown as Delta triangles). But once in a Sprint, “Change” from outside forces are not supposed to happen. In the Scrum world, the Scrum Master is supposed to protect the team from such changes in scope in the middle of the Sprint.
However, a Scrum Master should not limit his or her actions to just blocking. The Scrum Master should also be helping the PO or customer mature (groom) the new requirements. This way the development work can be performed ASAP in the next Sprint by the Agile Development Team and feedback can be gained by and from the customer.
So what might “change” look like in an Agile Development process? The next graphic below shows a scenario. Here while the Team was in the middle of their 2nd Sprint, the PO decided that Feature 3 was more important (or has more valuable) than Feature 2. Upon the completion of the 2nd Sprint they all, the PO and Dev Team, agreed to shift the User Stories around, so Feature 3 could be fully “Done” at the end of Sprint 3. Feature 2 was now planned to be “Done” at the end of the 4th Sprint.
Also shown in the scenario graphic above, is a “Change” that resulted from a Feature 2 Spike finding that was performed in the first Sprint. Maybe is was determined that more work was needed than planned or there was an additional requirement piece that was forgotten (like that never happens in a Waterfall or Agile Dev projectJ). So the PO and Dev Team decided to add another User Story to fully complete (“Done”) Feature 2 in the 4th Sprint. The team had planned for a Spike in the 4th Sprint to help with task planning for the final Feature, however, that Spike now becomes a nice to have and is moved to the bottom of the priority for the 4th Sprint. This would also be a “Change.”
This ability to change requirements every two weeks might have contributed to the Myth of the ever changing Requirements in Agile Development. Because before in their Waterfall Development experience, it was 3 to 6 months before they (PO/Customer) saw any useable product they could comment on or request changes to. Customers typically don’t like to read pages of specs or development code. They only can comment on finished product. People in the Agile World now could say they make changes at any time because “2 weeks” is so much shorter in comparison to 3 to 6 months previously need to make a change and see the output.
One last “Change” scenario discussed here is the Intra-Sprint change. This is not be some sort of change control board (CCB) activity that allows outside forces to add user stories while the team is Sprinting. During a Sprint Planning meeting the Agile Dev Team plans out all the User Stories and Tasks desired to be “Done” in a Sprint interval. The Team can always change the priority order of the items already planned to be done within a Sprint.
Here in this scenario, while within Sprint 1 the Team thought it made more sense to work a User Story for Feature 2 prior to running a Spike for the Feature 2.
Or maybe the PO was going to be unavailable for a Demo at the end of the Sprint, because of some urgent travel. So to get the valuable feedback from the PO, the Team decided to move a User Story to be completed ahead of the Spike.
These are examples of Intra-Sprint “Changes” which might have also contributed to the “Change 24×7 Myth.”
So in summary, it is a “Myth” that Agile Development allows for change at any time or anywhere.
The Truth is that in Agile Development it is assumed that Change Will Happen, therefore, the planners have created specific ceremonies and intervals for the “Change” to be cut in.
One of the disadvantages of the Waterfall estimation process is that once the design process is complete, it is grossly over assumed by some that there are no more changes. But we, as experienced Project Managers (PM), all knew that as soon as the customer saw the work product, they the customer or even the Team themselves would want changes. Even at the various Systems Engineering reviews there would be new changes to the requirements as a result of development, test or customer demos. I always laughed, on the inside, when people would say to me, “what do you mean a change to the requirement? post design review” As a PM, I always knew it was coming. I always put in budget for my systems engineers to change the specifications after each and every design review or gating activity. Those who didn’t were always over budget.
The Beauty of Agile Development is that the “Change” is accepted and is made visible for all to see. So some people, as a result, think that this “acceptance” means “a free for all” to make changes. For most people, from their typical experience in the Waterfall development process, the “Inevitable Change” was never brought out into the open and totally transparent for everyone to see. It was always a dirty little secret or the Project Manager was clueless to reality and bound to be over budget or late to deliver. This is also why a change process and change budgeting is always a good thing in Waterfall planning.
I hope this article helps to minimize the Agile 24×7 “Change” myth just a bit.
3/15/2015
