>Arlo Belshee – notes/further reading

>At my current client, we were fortunate enough to have Kevin Rutherford as an Agile Coach.

In talking to him about Agile, he suggested I have a look at thoughts & musings of Arlo Belshee as anything he talks about is largely adopted by the Agile community.

This post is for a dumping any interesting links I find whilst researching Arlo Belshee.

Interesting conversation on the Agile Toolkit podcast re pair programming :

And the associated paper he wrote on the pair programming :

The Progammers practice pair programming here, but the Test team were seen as a separate entity. Although we were called in for huddles as the story progressed, we still felt a bit like outsiders.
This has now changed and we pair/triple with the Programmers a lot more & have more input into planning the the test suite throughout the whole web stack, not just at the Twist/User Journey level.

The team is comparatively large for an Agile team – 16 Programmers to 6 Testers. Arlo talks about an optimum pair swap time for a team of 6 to be around 90mins, with the first Programmer to roll on to the story being the first Programmer to roll off. This way, as the Programmers roll on to a story, they’re fresh (beginners mind) & then they get to move onto another story after 180mins.

Programmers here work slightly differently – (probably due to the size?) Programmers don’t tend to swap as often as 90mins. Also, A Programmer will tend to own a story through to completion, as opposed to rolling off after 180mins. This allows to be an ‘expert’ in this story.

I’m not sure which is better. I can see the benefits of both, but I can also see the downsides. 
We’ve had some stories which have caused the Programmers a lot of grief, and the original estimate of complexity has gone out of the window. Would this situation benefit from have a fresh programmer every 90 mins, and for the pair to be completely changed every 180mins? Or does it require 1 Programmer to remain on the story to steer it through?

The Naked Planning idea is interesting. We have implemented a similar solution here, and it first mentioned by Kevin (practising what he preaches!). 
We have the priority column on the left, which has the metaphor of the dinner plate stacker found on ferries & the like – You take a card from the top & all the other cards move up the priority pile. New stories can be added underneath.
We slightly differ form Arlos idea of naked planning, in that most of the prioritising has already been carried out on the epic wall – Stories are promoted from there, and although the Product Owners can change the priority once the story is on the wall, We generally work through the stories in the priority pile.
Also we don’t have an expedited section – high priority stories / defects move directly to the top of the priority pile.