Scrumban

On Thurs 11th March I went to a Skillsmatter talk by Chris Pitts called 'Scrum to Scrumban'. The presentation was based around his experience in moving a dev team away from Scrum and towards a more Kanban style approach. It's actually an evolution I'd been involved with before but it was really interesting to see his take on the process.

(Skillsmatter are excellent at uploading videos you can find Scrum to Scrumban here.)

There were a few points that really jumped out at me especially as I'm part of a new team that are keen to try more of a lean approach. We've rejigged our wall board which helped make each story go through a pull system but there are still some things that need to be straightened out. Chris suggested a few good ideas and I'm keen to try some to see if it helps our new team settle into 'Scrumban':

1. Pomodoro planning - Once your work is coming through as part of a pull system there is no need to hold huge planning meetings for upcoming work. When you feel the team needs more stories for the 'Backlog' or 'To do' column hold a 25min planning session with the business to get the next stories onto the board.
   
   
2. What about future Epics? A question I asked! By giving them an initial t-shirt size the business will know if they should be broken down. Any large epics need be broken down but everything else can then be brought up in the Pomodoro planning sessions when the team have run out of stories.
   
   
3. Dealing with too much WIP - Some teams use post-its to stick stories on their wall board but if you're finding too much WIP is going on try switching to cards which can be added to the board with magnets. Want to limit the WIP to say... 5 stories. Make sure you only have 5 magnets! A story can't make it to WIP if there isn't a free magnet. Brilliant.
   
   
4. Dealing with stories blocked by a third party - This is something that seems to happen a lot and it's always difficult to deal with. In such cases Chris suggested that it helps to introduce a new section on the board called a 'Sin bin'. The concept being the issues remain visible to the team and the devs constantly review the stories in the 'Sin bin' to make sure they haven't been unblocked by the third party. This is strictly for stories that are blocked by third parties though, other blocks should remain on the board until the team have resolved them.
   
   
5. Using date stamping (effectively) - My previous attempts at date stamping proved unsuccessful. As a team we tried to stamp each story as soon as it made it to a new column on the board. Unfortunately this wasn't a great approach as devs would often forget and stories would get through unstamped. On the other side of that we had loads of stamped stories and no idea how to use the information it gave us.
   
   Chris had a fresh take on this concept - ask your product owner to date stamp a story when it's first picked up by a dev and then once again when the story is has been demoed and verified by the product owner. In effect you only have 2 dates, one for the time the story was started and one for the date it was business verified. So what does this give you? Well first of all you can start to work out approximate cycle times for similar sized stories. Perhaps medium stories are going through at a maximum of 3 days. Now the product owner knows that any medium stories can be expected to arrive back at his desk in approx 3 days. Ok not bad but there is also an added benefit here. It pushes the devs to communicate early with the product owner and also forces them to demo the story at the earliest opportunity. All in all everyone wins!
   
   
6. Weekly retrospectives - The process to move towards a more lean approach can be very intense. Even small changes in the wall board or planning sessions can introduce concerns within the team. To assist the evolution towards lean it's a good idea to hold weekly retrospectives. Chris suggests that he found them very helpful as concerns or problems were caught early and resolved without spiralling out of control. Even months into the new process Chris made sure the team held weekly retrospectives just to make sure the team was happy.
   
   
7. Next evolution? Try Kaizen - Although I've got a long way to go before I can call myself a true Kanban disciple I've often wondered what the step after Kanban will look like. This is the first time I've heard of the word Kaizen and the concept appears to be - continuous incremental improvement. From what I can gather it introduces the ability for teams to retrospect and fix on demand without the need to sit down and plan at all. It sounds interesting although one guy at the talk suggested he is using Kaizen and implied that he has added several new columns to the board. Hmmm unconvinced, part of my liking for Kanban is the way it simplifies the wall board and increases clarity of throughput. Then again maybe this guy found this was the best way to implement Kaizen and my experience (once I get there) may be different. Anyway something to think about I'm definitely not writing it off yet!
   

One final point - towards the end of the talk Chris bought up the subject of headphones. He indicated that developers on the team he helped were asked not to use them and the team found it improved communication dramatically. One pair might be talking about something and then another dev might overhear and say 'Oh you're doing that, I'm glad I heard you mention it, etc'.

At first I wasn't convinced but our team has paired up a lot more recently which kind of forces you to abandon your headphones. I have to agree things are a lot more enjoyable and the team has gelled really well. Although I don't think you can enforce a headphone ban I'd hate to go back to those bad old days when each of us stuck on our headphones and banged out stories with our heads down.

Setting up Cucumber to use the Watir test runner

Recently I was asked to demo Cucumber and how our developers could use it to automate acceptance criteria. I've worked a lot with Cucumber as a way of running Watir commands but I couldn't remember the initial steps you go through to get it installed. After googling a few things I found a couple of links that were really useful - the Cucumber website is good and also a blog post by my friend Mike Wagg helps map out the Watir aspect.

So let's fast forward a bit, I had installed Ruby, Cucumber, Watir and everything was fine no errors at all. I even wrote a quick Cuke test to search Google for the phrase "Cucumber". Yep all worked well so everything looked good for me to start coding the demo.

Now this is where I lost about 2 days OF MY LIFE!!! (Ok maybe not that much but more time than I would've liked). I created a nice new Visual Studio solution with a bare bones HTML form and a couple of textboxes. I typed out a rough scenario with some acceptance criteria and filled out the step definitions. It was going to be around cars (very manly) so my first couple of step definitions looked like this:

Given /^I am on the Cucumber brown bag page$/ do
@browser.goto 'http://localhost/cucumberbrownbag/'
end

And /^I have entered my car details correctly$/ do
@browser.text_field(:name, 'makeTextBox').set("Fiesta")
@browser.text_field(:name, 'modelTextBox').set("1.6 Ghia")
end

Ok looks good so let's run the Cuke test... FAIL! I got this:

Unable to locate element, using :name, "makeTextBox"

Hmmm that's not good so I double checked my naming and step syntax, they all looked correct. Then I tried to rejig the steps, same error. Then I tried to see if Watir knew the textbox existed on that page:

Given /^I am on the Cucumber brown bag page$/ do
@browser.goto 'http://localhost/cucumberbrownbag/'
@browser.text_field(:name, 'makeTextBox').exists?
end

Which gave me this error:

unknown property or method `document'
HRESULT error code:0x800706b5
The interface is unknown. (WIN32OLERuntimeError)

Hmmm now this is strange! I stepped back for a moment to try to work this out. It felt like it was something to do with the browser not being found or Watir being unable to attach to it. What happens if I change the step definition from my localhost domain to my IP address?

Given /^I am on the Cucumber brown bag page$/ do
@browser.goto 'http://10.1.0.185/cucumberbrownbag/'
@browser.text_field(:name, 'makeTextBox').exists?
end

Bingo it worked... so it's permissions! Don't ask me why but I can only use localhost in my Cucumber scripts if I'm running the command line as administrator OR if I use my domain or IP address instead.

On a separate note, I found a link to Scott Hanselman's blog on interactive Watir which allowed me to bring up the Interactive Ruby tool - IRB (get it from the command line by typing "irb"). It's VERY useful as a way of stepping through the Watir process and seeing why things aren't working.