Beach Hut - By Martin Harris

More and more I have been thinking about the effect of culture on Agile adoption. Then a friend tweeted this article on Agile Culture by Michael Sahota. Its a real eye opener and one key message is that it might be quicker to fit your process to the culture rather than the other way around.

There is some evidence to suggest that trying to introduce and Agile Development system into a culture that won’t naturally accept it is a recipe for failure.

For me its more complex that this. I am not 100% sure I am anywhere near a solution but these thoughts arise.

Evolution v Revolution and mandate
Without going into the detail which can be found on other posts the cultural fit is probably more important if you can’t change the culture. Most of the time we are somewhat restricted by our mandate. Its rare that someone senior wants this bad enough that they are prepared for the risk of revolutionary change.

If you were about to move in that direction, perhaps you can change the culture to fit. This path is also easier if your scope is small. i.e. if your dealing with a small group of people and not a multinational.

Otherwise perhaps initially selection of technique and Agile process should be culture driven.

The Kanban / Control argument
Its interesting to see Michael point out that Kanban is not Agile. At least by cultural definition. It occurred to me also that successful open source cultures might not be Agile either, they seem to fall into the “Craftsmanship” section.

Yet, were you to take a controlling culture and conduct Kanban with XP practices might it not over a long period of time begin to change. Perhaps towards craftsmanship as an appreciation of quality evolves?

So what now then Agile Coaches and CTO’s?
Well I for one have found the diagrams very useful. Just an awareness of this idea helps bring people to a higher view of what might be going on in their Agile Adoption process and that is no bad thing. Its too easy to get wrapped up in the daily Punch and Judy show forgetting about the bigger picture.

                          

InfoQ: Chet Hendrickson on the Need for Good Technical Practices.

                          

4 hour time box in 20 minutes!

Once again I decided to time box the work to 4 hours.  This time though the whole process only took about 20 minutes.  The product owner and testers produce a story file.  The Tumbler format allows for multiple stories each containing scenarios, so its possible to cover a complex set of requirements in one file.  This allows for flexibility when breaking down the work into tasks.  As per the usual behavior driven approach, a scenario contains the Given, When and Then sections which describe the behavior.

A simple tumbler behavior file

Story: Building a simple page

Scenario: should create a page 4 lines long with 5 data items in each line
Given a data fixture capable of complex page checking
When a page is created with 'twenty' items on a page
Then there should be 'four' lines on a page with 'five' data items on each line

Generating the Java files

The next step is to generate java from the scenario files I used an eclipse run configuration but the command line is:

java -classpath Tumbler.jar tumbler.ScenarioToJavaConverter YOUR_STORY.scenario

For the above scenario this was the result.  Note the generation of given, when and then methods and @story, @Scenario annotations that match up with the original file.

import org.junit.*;
import static org.junit.Assert.*;
import static tumbler.Tumbler.*;

@RunWith(TumblerRunner.class)
@Story("Building a simple page")
public class BuildingASimplePageScenarios {

        @Scenario(pending = true)
        public void shouldCreateAPage4LinesLongWith5DataItemsInEachLine() {
                given("a data fixture capable of complex page checking");

                when("a page is created with 'twenty' items on a page");

                then("there should be 'four' lines on a page with 'five' data items on each line");
        }
}

Which just leaves filling in the behavior and the actual test

@RunWith(TumblerRunner.class)
@Story("Building a simple page")
public class BuildingASimplePageScenarios {
	private SimplePage page;

	@Scenario(pending = false)
	public void shouldCreateAPage4LinesLongWith5DataItemsInEachLine() {
		given("a data fixture capable of complex page checking");
		final PageDataFixture dataFixture = new PageDataFixture();

		when("a page is created with 'twenty' items on a page");
		page = SimplePage.newInstance(dataFixture.getDataItem(), 20);

		then("there should be 'four' lines on a page with 'five' data items on each line");
		Map expectedLines = dataFixture.createPageExpectation(4, 5);

		Map actualMap = page.getMap();

		assertThat(actualMap, is(expectedLines));
       }
}

Finally there are two flags that can be applied to the test runner which turn on the production of a report. (-DgenerateReport=html -DoutputFolder=target)  It would be easy to configure a maven profile that picked up all your scenario files, and passed in these two flags.  The standard report uses Freemarker so it would be easy to produce your own.  Its a simple list of scenarios and their detail.

This is what my report looked like

Tumbler Report - Scenario Detail Page

Good Points

• As per JBehave I like the attempt to draw the product owner closer to the testing and development team members.
• Its a very simple system with very small learning curve
• Generating the Java improves productivity and allows the product owner to work on separate artifacts

Bad Points

• Currently its a very early beta release.  Not so much a criticism as a reminder that things might evolve in a breaking fashion at this stage.
• I would like to see the ability to generate parameters out of the scenario files.  If not, then a way to edit the tests to introduce parameter driven testing.
• Scrum and agile are iterative.  Adding to the original scenario files would mean generating the classes again.  This leaves the developer with the unpleasant task of transferring over changes. This might be solved if the inputs were the scenario file, and the finished test Java, with output that modifies and adds.  Running them would show the breaks if the parameters were also part of the generation.

Conclusion

I can’t wait to see a full version, or at least a release candidate version because I can see a future for this project.

                          

From a scrum point of view BDD can be used to turn the definition of done into a test artifact. The team produces scenarios for each task. With JBehave a scenario file describes the required behavior and test steps it will need to pass to be considered done. I.e Given some prerequisites, perform some action and expect some results. See the JBehave project for more detail as this is only a simple example.

BDD in 4 hours?

So scenarios are just text files describing the required functionality in terms of expected behavior. Even before development though, its possible to run them and see the pending expectations. Lets wizz though a simple example showing who in a scrum team is responsible for what. I already have a project that I use to explore test patterns so I thought I would just introduce it to that.  If you want the working version just take a fork from github.

Nb. I have a data fixture used in testing a complex page component. So whilst not a pure scenario I can make its existence part of the Givens. In this project, its likely that no real given is required, but a developer would add it during the build.

First the product owner and tester produce a simple scenario file describing behavior and expectations.

Given a data fixture
When a page is created with 20 items on a page
Then expected lines on a page is 4 with data items in a line 5

Next developers write a harness and flesh out the steps required to meet the behaviour.

We need to bootstrap the scenario and add steps to it. The general idea is to have a scenario test, that then includes the steps. This is one way of bootstrapping in the steps, other ways are available including a spring system that uses SpringStepsFactory. I ran into problems with the spring system as my project uses spring 3 and JBehave is still locked into spring 2.5.6. In addition I am using junit 4.8 and spring 2.5.6 requires 4.4. This is ultimately an issue as on many projects. I would not want to tie in those older versions. In fact other ideas in my project prevent me from doing this too. So in my timebox I avoid the issue and bootstrap manually.

The Bootstrap test class

public class SimplePageScenario extends JUnitScenario {
	public SimplePageScenario() {
		super(new MostUsefulConfiguration() {
			@Override
			public ScenarioDefiner forDefiningScenarios() {
				return new ClasspathScenarioDefiner(
						new UnderscoredCamelCaseResolver(".scn"),
						new PatternScenarioParser());
                        }
                });

		addSteps(new SimplePageSteps());
        }
}

Before adding the call to addSteps()) running the scenario shows the steps that are pending.

(org/testpatterns/scenarios/example_scenario.scn)
Scenario:
Given a spring data fixture (PENDING)
When a page is created with 20 items on a page (PENDING)
Then expected lines on a page is 4 with data items in a line 5 (PENDING)

Finally the developers fill in the Steps class adding sections that match against the scenario keywords, Given, When and Then. Development is done until the behavior passes the test.

public class SimplePageSteps extends Steps {

	private SimplePage page;

	private final PageDataFixture dataFixture = new PageDataFixture();

	@Given("a data fixture")
	public void givenASpringDataFixture() {
		notNull(dataFixture);
	}

	@When("a page is created with $itemsOnAPage items on a page")
	public void createPage(int itemsOnAPage) {
		page = SimplePage.newInstance(dataFixture.getDataItem(), itemsOnAPage);
	}

	@Then("expected lines on a page is $linesOnAPage with data items in a line $itemsInALine")
	public void validatePage(int linesOnAPage, int itemsInALine) {
		Map expectedLines = dataFixture.createPageExpectation(linesOnAPage, itemsInALine);

		Map actualMap = page.getMap();

		ensureThat(actualMap, is(expectedLines));
	}

}

Good Points

• I like the potential to get key scrum members interacting. The collaboration between the testers and product owner is an important one as it should flesh out questions about behaviour at an early stage. Similar benefits occur when the development team starts to get to grip with the behavior.
• Having a simple scenario artifact means the product owner can get involved with something that actually becomes part of the continuous integration.

Bad Points

• The bootstrap is clumsy. Having to add steps means that after producing the new scenarios development have to get involved before the pending steps appear. There are other ways to bootstrap. The spring system is a step in the right direction, in fact I would like to use injection throughout the application. This still does not solve the problem of having to edit something before the steps appear. I would prefer that once the scenario is in place, steps are automatically found as they are written, and appear as not started until they are cut.
• Extending Junit Testcase is also a problem. Its highly likely that in more complex projects we would need mocking techniques or spring based tests. These have their own runners brought in with the @RunWith annotation. It would be better if there were some way to bootstrap the behaviour into any other test framework.
• In my 4 hour timebox I did not get the reporting working. Unfortunately the reporting requires more coding, and setup and is far from being just a bit of maven configuration.
• When running from maven things did not work until I configured the maven-resource-plugin to copy over the scenario files. This should have just worked out of the box.
• Most of my 4 hours was taken up with configuration which was compounded by the slim documentation.

Conclusion

Attempting a behavior driven approach using scenarios is worth doing. I could see the benefits. Not sure if JBehave is the solution for me though. Difficult to configure, and incompatibilities with other frameworks would put me off at the moment. I will find some time to have a look at easyb another java BDD system next.

                          

Cuban Car: Martin Harris

Well perhaps not Nirvana then, but at least having a suitable level of test coverage. 

I wanted to write an article around the uptake of test driven development. Scrum and agile are hard to do well. If you break these down, you often find that the components are pretty challenging too. TDD is difficult but it has gained widespread recognition at the intellectual level.  On the ground though the practice can be patchy. Why?

Before writing this article I had a look around to see what else had been written.  This article on Geiger’s Counterpoint sums up my thoughts exactly.  Its such a good article that I hardly have anything left to say.  In fact neatly I can just provide some bullet points!

Improving the uptake of Test Driven Development

Programmers need help to adopt test driven practice.  So how can you go about that?

• Lead from the front: If your senior developers are not checking in fully tested code it will destroy the practice.  Its highly demoralising to be producing well tested code only to have a senior ruin it by checking in code with partial coverage.  I can not stress hard enough that the practice must come from the top.
• Pair code and mentor the practice: I have yet to meet a developer that took to TDD right from the off.  Most people struggle to produce good code, and TDD is far from intuitive.  The best way to improve is to see good code and work with people that write good code.  So mentor and pair code to disseminate the practice.
• Use coverage reporting: Use tools like clover, cobertura and emma to provide reports so that you can see what lines of code are covered by tests.  Make this reporting part of your build.  Encourage developers to use coverage reports to check the quality of their testing practice.  Understand though that coverage is not everything you need to concern yourself with, sensible assertions are important too.
• Encourage discussion: Next time you find something un-tested in your codebase, create a discussion about it.  Sometimes there are reasons, its badly written making it difficult to test.  Perhaps its an  integration point.  Through discussion you will encourage the team to find a solution and write some tests.
• Set a bar: Find a way to set a bar.  i.e find the current coverage levels and don’t allow the numbers to fall.  I worked on a project where a custom build component was added.  It parsed the clover reports, found the current coverage level and broke the build if it fell after checkin.

Summary

Most project suffer lower levels of test coverage than ideal.  Encourage test driven development and find ways to teach how it can be done.  Create dialog and get the teams to self organise around the goal of improving test quality and coverage.  Use tools and processes to support the team.

                          

Pink Rose, Beijing: Martin Harris.

I have been reading chapter 12 of Succeeding with agile by Mike Cohn.  The chapter title is Leading a Self-Organising Team. I have been reading it in the following context:

Strive for technical excellence and Improving technical practices is not optional.

Why is it that improving technical excellence is sometimes neglected on a project?  Why do developers think its ok to check in classes with warnings, leave essential and easily written tests out or add to messy code.  You must of heard the phrase “nobody cares about a building with broken windows.”  One more broken window will not matter. The same applies to software. Often you will find developers harboring some kind of guilt for not fixing things.

Once possible reason for this that I offer, is these teams although self directed are not being managed correctly. Draw a cause and effect diagram for your team, and include pressure or influence from management. Is there pressure to deliver at the expense of quality improvements?  Have you got managers using downward pressure to influence teams? There are other reasons but it seems to me that its more than just the scrum and agile practices, the team needs to engender a culture of self improvement and continuous change.  Conceivably a non scrum team with the right culture would work out its own scrum and agile systems if they had the right mindset.

I am of the view that building a team with a positive drive to deliver quality and meet deadlines is extremely difficult. Its hard to build up the right attitude and one short word, or foolish reaction from someone with influence can destroy that process.

So what is the alternative?  Unfortunately the alternative requires a great degree of skill and thought to pull off.  Its much harder than dragging a team into a room and attempting to bully them into submission.

Just to recap to improve technical excellence you need a team that actively engages in engineering practices.  Its easy to list them off: TDD, Refactoring, Collective Ownership, Continuous integration, Pair Programming.   Its quite another thing for a team to actively pursue the improvement of these processes and have the collective view that “Improving Technical Practices is not optional“.

Chapter 12 has the best write-up I have seen so far on how this might be done.  It suggests more subtle ways to influence your team to enable them to do this.   If anyone knows of similar works let me know as I want to build on this.

The following is just a list, read around and practice them to fully understand the processes.  Never be tempted to take the pressure your under and just apply it raw to the team.  This will have the opposite effect to the one you require often causing morale problems and damaging the team interactions.   This ultimately leads to reduced quality, higher defect rates and slower delivery and change.   All of these techniques require a deep understanding of how the team works.  Spend time working with your team to understand how its working or not as the case may be.

Once you have a handle on what is working and what is missing there are a series of alterations that can be made to change the balance.  The team will react to this and if you get it right adapt and improve from inside.

So these are the high level things I am looking at currently.  Check out the book for more detail.

Adjusting containers: Teams have boundaries and members.   This effects the way the team self organises.  Adjusting these changes the personality dynamics and can alter the skills balance in the team.
Example: Perhaps one member is too strong reducing discussion.  Another counter strong member might stimulate dialog and stand up to them.

Amplifying or Dampening Differences: The idea is to draw out those differences.
Example: Stimulate dialog by asking the team some hard questions about architecture or process that is not currently working.

Altering exchanges: Changing the way the team communicates with itself or other entities within the organisation.
Example: One team keeps impacting and rubbing up against another. Introduce a practice where individuals attend each others scrums. Mix it up, make it different individuals each day and get them to report back.

Apologies for the shallow list each of the above can be achieved in many ways, and a certain amount of creativity is required to make it work.  There will be failures but its important to keep experimenting and changing the equilibrium.  In summary its techniques like this that address the fundamental issue for me, how to get teams to fully take collective ownership and evolve towards continuous improvement.

                          

Goa State, India, Lifting the load: Martin Harris

Project Management Offices really serve no purpose in scrum. You are either a product owner, (not a manager), scrum master (not a manager either) or your in the team, (no technical leaders here either). So what about all that useful controlling and reporting stuff they used to do?

• Program management functions should be moved into the team.
• Team support comes from Agile coaches, or scrum masters.  They are not managers, they guide and do not tell the team what to do.
• Responsibilities of release, budget, tracking reporting etc, are the Product Owners domain, once again the Product Owner is not a manager.

Its a bad idea to keep the PMO and attempt to re-brand it under Scrum.  Keeping the unit and asking people to be scrum masters is a recipe for disaster.  Its hard to change team culture over to scrum.  Teams find it a big challenge to throw off the old and become self directed.  If you have your old manager coming to your team the roles stay right where they were.  So if you want to keep members of the PMO and they are technical, make them part of the team or remove them from the process.

Educate the Fake Scrum Master

Along similar lines, have you met a Fake Scrum Master? Its common for an organisation to take existing managers and ask them to be scrum masters.  Often with little or no training, rarely assigning mentors.  Its a very difficult thing to do, to change within your own organisation.  Michael Watkins exposes this as a potential area of failure for new leaders in his book the first 90 days.  A manager is typecast by his existing interactions within an organisation, so being promoted within his existing unit to a more strategic role is possibly one of the hardest things for a manager to do.  So moving from the role of manager to one of coach, mentor and guide with the same people is nigh on impossible.  People just put you back where you were despite your best efforts.  Its a big ask turning a team self directed, its tempting as a manager to tell the team how to do it.  So you see the paradox.

To help you spot a Fake Scrum Master, think Cargo Cult Programming but with a process slant.  These are typical behavior characteristics.

• Produces the Sprint Backlog on their own.
• Decides how long the tasks will take.
• Assigns tasks to people.
• Chases around the team (outside the scrum) requesting status updates.
• Takes on the role of co-ordination with other teams where dependencies lie.
• Takes the heat when the pressure is on.  What a hero!

All these things the team should do.  Those tasks teach, pressure and form the team into an efficient unit.

Things you can do with project managers to help them transition

Get external help.  Find good, skilled facilitators who can come in and pair with the new scrum master.  They should help with the new meeting formats, show how to guide instead of manage, and jump on any of the fake symptoms.  Its not always the scrum masters fault but a facilitator will be able to spot when the relationship is reverting to type and break it up.  If you recruit facilitators to the organisation you can often share them amongst projects.  Let them move around the teams from week to week and be on hand if anyone wants “emergency support”.  Sometimes its important to get something resolved before it develops into a habit.  Remember, support not control.

Other signs that your project managing

• Sprint lengths are project lengths.
• Teams are broken up people moved around frequently.  Teams need to change but give them time to settle and grow.  Only change individuals infrequently, keep the team.
• You have a matrix structure in software development.  It was an idea to reduce load on managers, no longer needed if the team shares the work.
• Scrum managers are shared.  How could a genuine scrum manager have the time.

So save some cash and spend it on facilitation and budget for development.  Disband the PMO, give people support and new scrum roles.

                          

Beware all yea who let the stand-up slip into longer formats, your wasting company money and time.  Possibly you could end up on this new social site Meet or Die!

I have been in scrums with established teams, where extraneous dialog started to creep in.  My scrum master introduced a speaking ball.  The ball is passed around.  You can only speak if you have the ball.  Anyone speaking out of turn is marked on a board.  When you gather enough marks you have to buy food for the team.

Sounds silly, but it did make the meeting fun…chucking the ball around, and kept it short.

                          

Cambodia, Phnom Penn, the water festival: Martin Harris

Probably one of the most common mistakes in Software Development is to allow Estimates to become Commitments.  I am sure you know the following scenario all too well.  The development team is called into a meeting room and asked the following question.  We (the management team) have had a look at the estimates, and your tasks on average are taking longer. The insinuation is that the development team is, stupid or perhaps lazy.  Worse still, an individual is called in because the stats show their work is “Behind Schedule” as judged by the estimates.  The problem is none of this though, the problem is believing that estimates are anything other than an educated guess.

The most likely outcome of this is a dissatisfied manager requesting for more hours to be worked.  This pressure normally results in dissatisfied team members and a drop in morale.  Its likely outcome a drop in productivity.  Extreme cases result in high turnover of staff as they leave in search of more enlightened projects.  In addition developers drop quality to meet the deadline.  This code is unmaintainable in the future as corners have been cut just to get it working.  So the initial surge in productivity results in slower progress ongoing.  Watch the defect rates, your teams will spend more time fixing than producing new work.

In actual fact what does the business require of our Software Development services that has lead to the belief in estimates?  We need to know when something will be delivered.  In some cases we demand that at all cost something will be delivered.  The book Peopleware by DeMarco and Lister describes this as The Phony Deadline.  Poor delivery is the result of picking a phony deadline.  Yes you got something, but it might not work quite as expected.

I still want that delivery date, what can be done?

Have it you shall, but not straight away.  Now I have spent the last few paragraphs showing how estimates poison the team and reduce product quality.  In the next section lets look at the relationship between our team and the sponsors.

A collection of estimates can be used to provide the paying customer with an inaccurate delivery date.  So given that the average customer has problems with the definition lets re-brand estimates as guesses, educated or otherwise.  There are two important things that a software development team needs to provide the business.

1. The contents of a delivery.
2. A delivery date.

There are only three variables in delivery, time, cost and scope.  Cost is most often set in stone at this stage, scope can be negotiated and time has an awful habit of not sticking to the rules.  The trick is to use our guesses to address the content of the delivery instead of the go live date.  For delivery date we will record story velocity over the first few tasks and use that to extrapolate the delivery date.  We will carry on tracking velocity and the cone of uncertanty will get tighter, leading in turn to a more accurate date.  Commitments can be made on that date once you move into the cone and the variance diminishes.  This can be problematic to the business at first because the date is non existent at the start, and as you begin to track reports will vary.  This will settle down, especially if you try to keep other variables consistent.  So stop mucking about with the team makeup and the iteration size, concentrate on tracking the work accurately.  Once you have a few releases over, you will find that velocity is a much better way to work out delivery dates.

The business I currently work in uses techniques like this in many financial metrics.  Take a look at how interest rates are set for a year.  Obviously its impossible to know what will happen to interest rates over the course of a year.  We might start at 2% and rise to 2.5% or perhaps not.  News on the economy gives some indication in the short term as to what might happen to the rates.  These news clips cause the market to react and the closer we get to the end of the year, the more likely we are to be able to guess the final rate across the year.

So what is so bad about using story velocity metrics to gain more accurate estimates of how many stories a team can complete in a delivery cycle?  To further improve things we might also consider smaller delivery cycles and standardizing story and task sizes as much as possible.

Estimates guesses still have value don’t they?

So where do the guesses come in?  Lets use a relative estimation system instead of a time based one.  In scrum these are known as story points.  Please do read that link it is probably the best description I have ever come across.  Many thanks to the authors.   The idea behind point-based estimation is to agree that at the beginning we have much uncertainty and ambiguity.  Even if we spent extra time on analysis of the problem, we would still be uncertain and much ambiguity would remain.  Points are relative to each other and are all about size of stories over time.  This is much easier to deal with as a developer.  People are comparators, we do that all the time.  This makes us much better at saying if one task is bigger than another.  Especially if we have done similar stories before.  So points are a weighted system to grade stories into a set of different sises.

Now we need some kind of system to help us standardize the size of the boxes.  In scrum a technique knows as planning poker helps with this.  Planning poker gives us a set of cards representing the relative weight of a story.  Normally 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.  When estimating your thinking goes something like,

Mmm well I have done something a bit like this before, that was a 20 but this is a bit more complex, now is it a 40 well that’s double…and this feels a bit bigger but not double.  So I will plump for a 20.

So as you see the numbers are important as the weighting is designed to help grade the story into standard size boxes.  The other important thing is the whole team takes part in the planning so you get a graded average.  This has a side effect, the team members start to appreciate the effort involved across the full spectrum of work.

So then, that delivery date?

If your able to try and run an iteration or two before giving a delivery date.  Track how many stories you can complete in an iteration and use that to project forward and arrive at a date.  Explain to the business that you will review this date with them on a regular basis and that it will get more accurate as velocity settles down.  A little like the speculation over the next interest rate announcement.  One problem is the initial project stories are often very different from latter ones.  Usually due to building and setting up initial architecture and development environment.

Another idea at the initial stage is to break out a random selection of stories into tasks and estimate / guess those.  Calculate an estimated velocity and explain to the business that you can’t commit to this date and once more accurate statistics come in you will review the new date with them.

So finally your left with no fixed date.  The honest thing to do is to explain how consistent velociy will ultimatly give a better reporting picture This is going to be a sticking point I assure you.  In the past it might have been easy to just give a date to the business.  Chuck in some contingency for good measure.  This is a very bad practice indeed.  If you do miss that deadline you loose the customers confidence.  If you manage the politics better by de-scoping your just going to erode that confidence slower.  At first explaining your system will give them a date that gets more accurate the nearer you get might not go down that well.  I can assure you though that once you get more accurate velocity and that date moves around less the business will gain a profound confidence in the system.  After all soon your dates will be the best ones they have ever had.

                          

Craig Larman in Agile & Iterative Development, A managers guide describes it thus:

Sprint Review: At the end of each iteration, there is a review meeting. (maximum of four hours) hosted by the Scrum Master.  The team, Product Owner, and other stakeholders attend. There is a demo of the product.  Goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots.

Feedback and brainstorming on future directions is encouraged, but no commitments are made during the meeting.  Later at the next Sprint Planning meeting, stakeholders and the team make commitments.

“Power Point” presentations are forbidden.  Preparation emphasis is on showing the product.

What is a Demo anyway?  What should we Demo?

Demo of a Balinese fire dance, Bali, Indonesia: Martin Harris

A demo has to be fully working software.  Although the team considers it ready for production and has fully tested it, its acceptable that the demo environment is scaled down in terms of moving parts and data sets.  Often there are manual test stages that follow user acceptance and such, but during this meeting we expect to get business agreement and sign-off so the environment has to be good enough to inspire confidence in the product.

Get the product owner to drive the software.  No cheating The product owner will get a better feel for it if they drive.  I have seen situations were very good software refuses to behave only when the product owner takes control!  Make sure that your demo room has a spare PC just in cases someone from the team needs to login, check logs, or re-start a service etc.  Its important not to stall on something trivial or unrelated to the demo.

Record any issues or problems.  These have two outcomes.  Either they are bad enough that the product owner will not accept the stories as finished, or if trivial the product owner may sign off a story if they are fixed in the next iteration.  The ideal is obviously to sail into the next iteration with no hangover whatsoever.  Don’t let issues slow the meeting down.  The product owner should make a decision and move on.  The scrum master documents any such issues and the outcome.  Note that the teams testers are incredibly useful in a demo, often providing usability and product usage advice.

If possible everything in an iteration should be included in the software demonstration.  If you get it right it should be possible to demonstrate every story.  If the team is in the habit of producing a definition of done for all tasks and done includes things like, documented, fully tested, deployable then preparation for the demonstration should just be a matter of updating the demonstration environment.

What a demo is not?

A demo is always actual running software, never mocked aside from test or development data.  If you can get production data then all well and good.  The product owner is always present, demonstrating to the development teams has little value.  This is a key opportunity for developers and the business to come together and feel part of the same team.  The product owner is the only person who can sign off a story.  If they are unavailable postpone.

How much does a demo cost?

Very little when measured against the return.  In an ideal project the demo environment is created off the back of a successful build possibly automated.  Its not just used for the demo, but provides a place to test.  In an integration situation its often useful to have somewhere that is guaranteed to be stable.  Its possible to share the environment over several teams as long as its stable during the demo.

What are the Benefits?

The main benefit is the team is able to demonstrate that a set of stories for an iteration is finished.  The burn down is complete.  The product owner is able to report that a key section is complete.  In some projects release to production follows soon after.  You are able to see exactly where you are after updating the backlog.

This process like no other Builds Confidence.  The confidence the team has in itself and the confidence the business has in the team to deliver.  It can not be overstated how important this is.

Sometimes this is the first time that the Team members see the product working end to end, when your working on the small parts is easy to forget where your heading.  The demo brings it all together.

Team becomes more focused on delivery.  I will paint you a picture.  Its Thursday morning, the demo is tomorrow, there is still quite a bit to do before the demo.  Nobody on the team wants to be the one, who’s key piece meant something was not ready for the demo.  By the afternoon you can feel the tension as the team readies the environment and tests everything one last time.  Teams with no demo do not have such focus.  A key part of scrum is something called cadence.  Iterations are always the same length, people get used to that, and they are marked by events.  I would say Sprint Review is the full stop marking the end of a sprint.

Its very addictive to the business.  The product owner will really start to get involved when at the end of each sprint demo after demo builds more working product.  Its a very important part of forging the teams relationship with the business.

Problems you may have with demonstrations.

Problem: We find that at the end of a sprint we have nothing that can be demonstrated!
Experiment with: Longer iterations.  Find ways to make it possible to demonstrate, look for blocks, missing environment and work hard to plug the gaps.  Its vital to demo never de-prioritize this.

Problem: We have difficulty getting the product owner to attend.
Experiment with: Shorter iterations.  Less to demo should mean shorter meetings that are easier to schedule.  Always do the demo at the same time and day.  This is also easier to plan for.

Problem: The team has no time to do demonstrations, they are busy building new functionality.
Experiment with: Plan less and schedule less stories.  Its vital to know you have actually finished an iteration.  A common scenario for teams who do not demo, is one where the project is just collecting more and more partially finished stories because of one block or another.  This can even be hidden as with no demo you have not the assurance that what you build is correct.  So you only think your complete.  There will be a price to pay later in re-work during test or worse after go-live.

Problem: We tried sprint reviews but they broke down after several chaotic attempts.
Experiment with: Create a story for Demo preparation. Have it in mind that your telling a story. Lead the product owner through the stories in a logical order that builds. See links below for more on how a review should be conducted.

Conclusion

Always hold a Sprint review with a demo.  It has hidden benefits and builds confidence in the team.  Don’t underestimate its power to motivate.  Business confidence and reporting accuracy will also improve.  Greater understanding of the product and business are other side effects.  So plan to demo now and enjoy, it can be the best part of the sprint.

Further Reading

Simple Scrum Sprint Review Note the amount of time allocated to demo in this example!

Successful Sprint Reviews Excellent work on how to make them work.