Scrum Fundamentals – Iteration, Sprints, and Feedback

I said in the previous post that one of the biggest problems brought about by a waterfall approach is the lack of feedback.  The future users of the software get to see the software only when it is finished, when the opportunity to provide valuable corrections and suggestions are practically over.

Not only is it too  late (or too expensive) to modify the program, the software is often actually unusable.  Scrum directly addresses these problems by mandating that software must be developed iteratively, in iterations, and the at the end of each iteration, the software must be demonstrated to the stakeholders to get their feedback. 

Scrum calls its iterations Sprints.  Scrum recommends that Sprints be between 2 to 4 weeks.  Whatever duration you choose, all the Sprint must be always the same duration.  If you go for 2 weeks, then all the Sprints must each be 2 weeks. 

This is in the ideal case of course, in practice a Scrum team that is just beginning to learn the ropes can choose a tentative duration to try out (say 2 weeks).  If the team finds that 2 weeks is too short, they are free to adjust it (and all future Sprints).  If they find that it suits them, they stick to it.

The key thing is to establish Sprints as a regular occurrence, like a heartbeat.  Sprints of different lengths are like arrhythmia, with all the unpleasantness it brings.

The completion of each Sprint produces a finished subset of the product.  The ideal is to deliver a working subset, preferably something that can be shipped.  In practice this is not so easy to achieve, for some functions rely on other functions which may not fit in the current Sprint. 

For example, an online store may include such functions as allowing the customer to search for products, order products, apply discounts, and have them shipped to an address of their choosing.   Very often all of these functions cannot be built within a single Sprint. So which ones to build in order to product a shippable subset?

The Scrum team (together with the Product Owner) decides which functions to build in order to deliver working software.  One such option could be to simply include only the search for products function.  So at the end of the Sprint you end up with software that searches for products, and does nothing else.  That is an acceptable choice.

It is far better than deciding to build all the user interfaces for all the above functions, but not have them work.  If you do this, what you get at the end of the Sprint is not working software, rather, you end up with a glorified series of screenshots.

Back to feedback.  At the end of each Sprint is a Demo of what was built.  The Scrum teams demonstrates the current product so that the Product Owner (and other stakeholders) can review it and give their feedback.   Is this what was envisioned?   If it was, was it what you wanted?  Very often, once we see the the incarnation of what we said we wanted, we come to the realisation that that is not really what we wanted.

The purpose of the Demo is NOT to show the Product Owner that the Scrum Team is working hard.  No.  The purpose is only feedback regarding the product.  (There is a time when evaluation of the Scrum Team occurs, but this is not that time, and I will talk about it later).

If there is one thing that feedback causes, it is change.  You can be sure that the feedback will result in changes, changes to what the software will do, and changes to what it is currently doing.

So what do we do with the changes?  I’ll talk about that in the next post.

Scrum Fundamentals – Iterations, Sprints, and Feedback

I said in the previous post that one of the biggest problems brought about by a waterfall approach is the lack of feedback.  The future users of the software get to see the software only when it is finished, when the opportunity to provide valuable corrections and suggestions are practically over.

Not only is it too  late (or too expensive) to modify the program by then, the resulting software is sometimes not only bad, but even unusable. 

Scrum directly addresses these problems by mandating that software must be developed iteratively, in iterations, and the at the end of each iteration, the software must be demonstrated to the stakeholders to get their feedback. 

Scrum calls its iterations Sprints.  Scrum recommends that Sprints be between 2 to 4 weeks.  Whatever duration you choose, all the Sprint must be always the same duration.  If you go for 2 weeks, then all the Sprints must each be 2 weeks. 

This is in the ideal case of course. In practice a Scrum team that is just beginning to learn the ropes can choose a tentative duration to try out (say 2 weeks).  If the team finds that 2 weeks is too short, they are free to adjust it (and all future Sprints).  If they find that it suits them, they stick to it.

The key thing is to establish Sprints as a regular occurrence, like a heartbeat.  Sprints of different lengths are like arrhythmia, with all the unpleasantness it brings.

The completion of each Sprint produces a finished subset of the product.  The ideal is to deliver a working subset, preferably something that can be shipped.  In practice this is not so easy to achieve, for some functions rely on other functions which may not fit in the current Sprint. 

For example, an online store may include such functions as allowing the customer to search for products, order products, apply discounts, and have them shipped to an address of their choosing.   Very often all of these functions cannot be built within a single Sprint. So which ones to build in order to product a shippable subset?

The Scrum team (together with the Product Owner) decides which functions to build in order to deliver working software.  One such option could be to simply include only the search for products function.  So at the end of the Sprint you end up with software that searches for products, and does nothing else.  That is an acceptable choice.

It is far better than deciding to build all the user interfaces for all the above functions, but not have them work.  If you do this, what you get at the end of the Sprint is not working software, rather, you end up with a glorified series of screenshots.

Back to feedback.  At the end of each Sprint is a Demo of what was built.  The Scrum teams demonstrates the current product so that the Product Owner (and other stakeholders) can review it and give their feedback.   Is this what was envisioned?   If it was, was it what you wanted?  Very often, once we see the the incarnation of what we said we wanted, we come to the realisation that that is not really what we wanted.

The purpose of the Demo is absolutely NOT to show the Product Owner that the Scrum Team is working hard.  No.  The purpose is only feedback regarding the product.  (There is a time when evaluation of the Scrum Team occurs, but this is not that time, and I will talk about it later).

If there is one thing that feedback causes, it is change.  You can be sure that the feedback will result in changes, changes to what the software will do, and changes to what it is currently doing.

So what do we do with the changes?  I’ll talk about that in the next post.

Scrum Fundamentals

Stripped to its essence, Scrum is an approach to delivering software.  Nothing more, nothing less.

There are many approaches to developing software.   At one end, you can have a very formal ‘waterfall’ style approach where the development lifecycle consists of major phases that follow one another.  These phases include the Requirements Phase, where the project analyses and documents what the stakeholders need.  The next phase would be the design phase, where designers design the system to be built, which once built will deliver the requirements identified in the Requirements Phase.

After the Design Phase comes the Build Phase.  This is where the actual product get built, based on the specifications produced from the Design Phase.  Once built, the product gets tested in the Test Phase, in order to ensure the quality of the built product.

The phases in the waterfall approach are very logically  structured.  Each phase produces exactly what the next phase requires.  From arguments based on reason alone, it seems to be the perfect approach. 

In reality, however, the above approach is riddled with inefficiencies and problems, not due to the phases themselves, but because they are performed by fallible human beings, using fallible communication methods.  

Perhaps the most commonly cited problem is that very often, the product that comes out at the end meets the specifications, which in turn meets the requirements, but somehow ends up not being what the end users wanted or expected.

The lack of feedback between the stakeholders and the product being built – as it’s being built – contributes in no small part, to the problem.

Agile, and in particular, Scrum, proposes to fix the above problem by increasing the visibility of the product being built, while it’s being built.

We can illustrate Scrum at a very high level in the IDEF0 format as shown.

The output of a Scrum process is working software.  The inputs are a vision of the product, and of course time and money.

The process is executed by the Scrum Team, who relies heavily on the Product Owner, who represents the business stakeholders and from whom comes the Vision of the product.

Scrum comes with a set of techniques and procedures, and guided by the principles espoused in the Agile Manifesto.  You execute Scrum using these techniques.  In theory, you get working software, and the software that is guaranteed to be what the customer wants.

How does Scrum do that?  We’ll start exploring beginning with the next post on this topic.