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.

                          

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.

                          

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.

                          

Groundswell shows a way to tool up your Product Owner?

One of the most important scrum principles is to assign a Product Owner.

Tool me up, Temple, Ho Chi Minh City, Vietnam: Martin Harris

This person should have a very good understanding of the business.  At first glance is seems like a good idea for that person to be an active part of the business.  For a single dealer platform it looks like a good idea to recruit someone who actively deals or for a legal application a senior member of the law staff.  The problem with this is a dealer is likely to be too busy looking after money, and the Lawyer is in and out of court.  Active members of the business have better things to do, so we have to look elsewhere for our product owners.

Some links if your interested in the problems a product owner deals with and how to find a suitable candidate:

Being an effective product owner

Product owner – Choosing the right person for the job

So instead another option is to appoint a business proxi.  Perhaps a Business Analyst or a traditional Project Manager.  There is nothing fundamentally wrong with this and I have seen it work well but at the end of the day this person needs to tune into their sponsors and customers.  This is where the book Groundswell comes in.  Groundswell has several documented cases where Social Technologies have been used to garner information from communities, check out this blog post for some idea of the mechanics.  Some such cases have been in areas where it would normally be very difficult to get any feedback from the community i.e. a pharmaceutical company setting up support communities for cancer patients.

There is one great example of Credit Mutuel a French retail bank who asked of their customers “If I were a banker” and collected responses on what the customers thought the bank should be doing.  A huge wave of Groundswell resulted in the bank making changes and in Credit Mutuel benefiting from increased competitive advantage.  They were able to respond to customers quickly and make the changes they deemed sensible.  The customers loved it.  There is a caveat to this though.  You have to be able to turn around changes quickly, and now we are back to scrum.  A development system that done well can implement software changes quickly in reaction to a clients demands.  What I am suggesting is that correct use of Groundswell could make the product owners job easier.

In particular within organisations who have trouble getting the right kind of requirements from the users of the applications we write.  I have worked in several industries where getting access to your users is a real problem.  Lawyers and Traders who are just phenomenally busy and expensive, highly dispersed users of global applications where the logistics of visiting them all is impossible.

In the book there are several documented cases where companies like Communispace or Passenger setup and manage systems to recruit and manage a comunity focused around a product or idea.  I think it would be great to try out ideas like this to gather information about an important software product from its internal and external users.  The end game, is to gather the best ideas, then put them back to the community for voting and prioritisation.  Yes, you get a ready made backlog off the back of this.  How incredibly handy is that!  Take a look at this, its pretty much a community fed backlog used by Salesforce.com: http://sites.force.com/ideaexchange/. Here is another that Dell use based on the same Crispy News system: http://www.ideastorm.com/

I think that doing something like this has these benefits possibly more:

• It helps the product owner get a more representative view of what the customers think is important.  What requirements they put at the top.
• The customers feel more involved in the evolution of the product.
• Your scrum team is likely to find out some things that all the experts and analysis have missed.

Its powerful, but as with any power tool be careful!

• You will have to show both the good and bad feedback.  Are you ready for the honesty required?  Make sure all your sponsors are prepared.
• The scrum team should be ready and established, if you can’t turn around the best ideas quickly the mood will quickly turn sour.
• It takes a great deal of skill and a degree of humility to make this work, but the closer alignment with your customer will soon show results.

So why not give it a try?

                          

Pushing the cart, Matheran, India: Martin Harris

I went along to the London Scrum User Group yesterday evening.  For a change it was a quiet night.  Christmas is around the corner so we had less attendees.  Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum.  After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack.  So we stopped there and got on with eating the snacks and drinking the beer.  The night was sponsored by Rally Software, cheers for the food guys.  So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment?

The London Scrum Groups 6 Good Scrum Tips

• Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
• Run Retrospectives. Its very important to take actions away from a retrospective.  Be realistic though, your never going to solve them all, so ask the team to priorities them.  If your doing the retrospective right your product owner will be there to help with prioritisation.  If you find something very big lands at the top, split it down into stories.  Otherwise pick one or two that the team feel strongly about and turn them into stories.  Make sure these stories are included in the next game planning sessions and make it into the iterations.  If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time.  Commit to doing them and then deliver.
• Ask your team to Pair Code. The XP technique of two programmers working on the same task.  It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput.  Don’t be dogmatic, let the team decide how much work should be pair coded.
• Setup Self Directed teams. Self directed teams have been proven to be more efficient.  We discussed the role of a scrum master in a self directed team.  Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks.  The scrum master does not plan or allocate tasks.  The empowered team needs to work out what the tasks are and find out how to finish the stories.  The scrum master should spend his efforts removing blocks for the team, checking quality.  Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed.  We also decided that to be empowered you need to make the team multi discipline.  Include testers, user interface designers etc to remove hand off waste and increase team knowledge.  With role diversity comes better decision making.
• Deliver what you commit to. Another gem, it sounds obvious but is so often ignored.  Delivering builds trust in the team and the process.  Classic ways to miss delivery include: Failing to produce a strong definition of done.  The definition should include the programming, integration, testing and setup tasks.  In fact everything required to get that task ready for delivery.  Another way to miss delivers is to fail to demonstrate at the end of the iteration.  You may think your done, but when the product owner sees the work for the first time they may request refinement.  If you have kept your product owner close then the demo is likely to be painless.  No power-point slides please, only real working software in the demo!  So commit and then deliver what you commit to.
• Co-locate your team. The group defined co-location quite tightly.  Co-location is not putting everyone in the same office.  Its putting the team members next to each other in the same space.  Intra team communication does not happen with the team scattered around an office.  You should be able to turn around and join the stand up meeting.  This closeness, speeds up the myriad of tiny important messages that pass around the team.  Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea.  If your doing these, then your doing very well indeed, and are likely to get better over time.

So another excellent meeting, a few more beers and I headed home enlightenend, well fed and slighlty merry.  Why not come along to the next one, we could use your input.