Scrum

2010-04-22 19:48

Specification by example – the missing link?

I’ve been thinking. That statement alone will be sure to put fear in the heart of a lot of you… But if you have continued on this far, here we go.

Learning programming stuff

During the last year or so I have been reading a lot. I have read stuff on XP, on good design DDD and TDD. This reading has affected me and my coding style way much more than I first thought. I simply cannot write code anymore without the test first, interface first, thinking of SOLID etc..

Learning lean stuff

At the same time I have change role at Avega. I am now an AvegaCoach. This means that my time is divided between my regular (often coaching) assignments with customers and Avega and Elevate. Since my fellow AvegaCoaches (Joakim and Christophe) and me are interested in agile and lean stuff we have focused our joint efforts on that.

This has led that I have learned a lot from them about lean and Kanban. And this has expanded my understanding of Scrum and how to work agile.

Frustrations

But around here the frustration started to kick in. I felt that these two areas; technology and process stuff could marry in a great way. But how? And how much does the it affect each other?

Also, a specific thing that I have been really frustrated in is how to include test in an agile world. Testing are left out in planning, are left to try to keep up with development and the regression stuff will eventually kill them. So “testing sprints” are introduced, “we’re running a sprint behind the rest of the team” and other solutions like that is used to try to get around it.

Surely – this cannot be the best case? So I started read about agile testing. I loved the book by Gjoko Adzic. This book introduced me to the term agile acceptance testing and specification by example.

The solution?

I have heard and learned quite a lot about BDD. I knew that BDD and “outside-in” thinking can help me design my application in a maintainable way. But BDD can be applied at any level. It could be used to spec out your unit test. Another way to do TDD (AAA becomes GWT)

But I had missed the fact that the specifications and features should could be written in collaboration with customer or business analysists. This will turn the specs into executable specifications. (Those words still gives me the shivers. It’s so cool!)

That’s the thing! With executable specifications you have a living specification to code against, and the moment you’re done (as in done done) with the story the specification is “magically” turned into an acceptance test.

And the specifications finally reflects what the code is doing. I can never forget a quote by a customer how very proudly showed me the folder with all the specifications (use cases in this case) and then told me:

“And the best thing… they are almost up to date with what the system does”.

The really scary part about that is that it was actually the best I ever seen. Most documentation and specifications are a violation to the DRY principle. But with executable specifications you’re as close as it gets.

But it doesn’t stop there: since the specification with any current tool is written in plain English you can workshop around it to get everybody's (business analysis, testing, coding, deploy etc) views on the matter. And you minimize the misconceptions by using real world examples.

And that in turn closes the gap for me; agile testing is hard since I am still viewing testing as something separate from coding. And the same goes for specifying… But it’s not! You can do this in agile way, a little slice of functionality at the time. A way to do that is specification by example.

Recommended watching and reading

Read Gojkos book – Bridging the communication gap. Stop reading whatever you reading now and start reading this. It was a eye-opener for me.

Watch (anything you can get your hands on) this webcast by Dan North. There are lots of great stuff in here on BDD and design.

I’m reading Agile Testing right now. That has really showed me that testing is something that any agile person (developer, tester, business analysist etc.) should care about. Or as Deming put it:

“Quality is everyone's responsibility.”

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Scrum    Agile    Life of a consultant    DDD

2010-03-30 08:57

Status of work items – where to keep it

This is a question that arises very soon or sometime even before you start doing work with a board; Scrum, Kanban or Scrumbut.

Where should the status be? Or more often – “let’s use TFS” (and keep the work items in TFS/SharePoint/Excel and then make copies of them to use on the wall).

A variant of the question is; “we are a distributed team – can we still use the same board?”

Well of course there is not a yes or no answer to that but here is my take on it:

Low tech rules!

First I think that no electronic system will ever beat the flexibility, simplicity and agileness of a board. See this for some examples. There are some that have come close but a low tech board communicates so much information with the added flexibility to move things around very easy.

Also using a board promotes face-to-face communication which is always good. I have been in teams where the status of the electronic system should be updated before the daily standup – what use is the meeting then?

Master data problem

Secondly this problem is a master-data problem; who is the master of the status?

There are places, big companies, distributed team etc. where electronic systems are the only way (or so they say ;)). Then you’ll have to use them. But be sure to know where your master status is – on the board or in the system?

When I did my military service I learned: “if the map and reality mismatch then the map is correct” (or master). That shows how master data problems is handled in a bad way, I think. Know where your master status is and treat all other sources as non-masters or copies.

Use the tool not the other way around

Finally – it’s not in the tool. Or put differently these are just tools. Tools are meant to be used by people to get task done easier. Not to add load to the burden.

If you ever find yourself complaining (as I have… a lot…) of having to update TFS with the status of the board – then the tool is using you. Not a very clever way to use your time. Waste – in Lean terms.

How I would do it

If I ever got the chance to decide on stuff like this (Hey, I sometimes do!) I would do it like this:

• Keep your work items and their status on the physical board
• Let the physical board be the master of status for the work items
• Use the electronic system to keep reference data that doesn’t need to be on the physical board.
• Do not keep status of the work item in the electronic system, or rather not all of them. You could keep a simplified status chain (Not started/Started/Done for example)
• Put a reference on the work item on the board to the ID inside the electronic system
• “Stamp” work items with the dates they enter a new stage of your workflow. You can then use these data to find bottlenecks in your workflow, make predictions (search for Disneyland) and get some really nice follow-up-data
• Keep in synch within distributed teams by using any means possible; web cams, digital photos, telephone, IPhone video calls, travel; are some of the ways I have tried to solve this.
• Use the board to get your work to flow smoother – don’t add more work to keep the board and any system up-to-date.

That’s a few thoughts on the subject.

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Scrum    Agile

2009-11-17 21:21

Kanban example by Henrik Kniberg

Finally today I need to store a reference to this Kanban-example that Henrik Kniberg has posted.

He was one of the main reasons I started with Scrum and agile in the first place with his excellent Scrum from the Threnches.

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Scrum    Agile

2009-08-21 09:03

Task Board for Team System – finally!

I have been quite harsh to the Conchango Scrum template for Team Foundation Server, and I actually didn’t like it when I used it last (8 months ago).

That primarily had to do with me being forced to use the standard, heavy-weight forms in Visual Studio to edit Backlog Items and Actions. That did that we couldn’t use it in our daily scrums and hence someone (read: me) had to take notes and then go an update the TFS. In lean terms this was WASTE that was added to our project. I didn’t like that one bit. So we stopped using it. Quickly.

But now Conchango has created the tool that I think was the missing link. A Task Board application that mimics the actual task board that you draw and edit during sprints, planning and daily scrums.

You can read more about it here and learn how it works from these videos. Of course I cannot be sure yet, but it looks very promising, very promising indeed.

All the usual benefits from introducing a IT-support could be found here; automatic generation of burn down (will it work?), the possibility to support distributed teams better, history, support in calculations and reports etc.

Give it a try – I know I will. Way to go Conchango!

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Scrum    Agile    Team Foundation Server

2008-11-14 10:44

Great SCRUM-resources

The Swedish guru of Scrum Henrik Kniberg, has produced some great stuff... yet again. Here you are:

• Video and slides for "10 ways to screw up with Scrum and XP". Got the merge-slide thrown in my face of a co-worker since I have great reluctantancy against branches... But I sure want to be able to manage them in a nice way - haven't seen one yet though...
• Scrum checklist - here is a truly great one page document to get all your stuff in the right shape before starting doing Scrum.
• And of course Scrum from the trenches. Everybody must read this! Even, or maybe especially, if you hate Scrum.

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Scrum    Agile

2008-11-07 08:09

Agile testing - how we get it to work

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Scrum    Agile    Life of a consultant