Tumble dried BDD from Studio Pragmatists

On the 18th of May, 2010, the very new tumbler-glass project by Studio Pragmatists uploaded Tumbler 0.2.1 to Maven.  Having recently written about JBehave I found myself really liking the concept of behavior driven development.  So I decided to write a similar article about Tumbler. If you want the project code its available in my example project.

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. Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Bad or Good? Behavior Driven Development within Scrum.

I wanted to explore the possibility of using JBehave to formalise scrums definition of done. The idea being to encapsulate a definition of done as a JBehave scenario. So in true scrum style I decided to timebox 4 hours of work dedicated to JBehave.

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. Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Scrum, where exactly do the managers go?

Two friends helping with a load of dried fish.

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.

Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Dancing to the tune of the Scrum Demo

As you achieve more experience with the scrum process, you come to realise that there is very little if anything you can afford to leave out. If your conducting scrum and considering leaving out a practice, its worth considering what is to be gained and lost.  So continuing with the scrum and agile theme this year I plan review some of the scrum practices highlighting the benefits and some of the errors that are made.  The first of these focuses on the Sprint Review and within that in particular the Software Demo.

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.

Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)