Having fun while learning about other teams.
I'm currently trying to bring together three dev teams from within our organisation. All three teams brand themselves as agile and all three produce products around the same domain. It therefore seems like a good idea to get the teams together to share ideas, understand what each team does, how it does it and to look at how our products could work together to improve the lives of our customers.
While this is a good idea, I do sense a real danger of two days packed full of dull, dreary powerpoints. So the challenge is to create an environment for the gathering that is fun, energetic, engaging and creative.
My first thoughts were to have each team present information about themselves and then to follow these presentations with an afternoon of open space which will hopefully follow on from points made in the presentations. The open space should tick the fun, energetic, engaging and creative criteria but I fear the presentations still wouldn't.
I then had the idea that instead of presenting about themselves each team could present about one of the other teams, about who they know very little. In doing this it would take people out of their comfort zones, ensure that each presentation was interactive, unpredictable, collaborative and focussed on extracting the information that the group actually care about.
I'll post a blog in the next few weeks to let you know how the idea develops and how the gathering goes.
The first rule of Agile.
"The first rule of Agile... is don't mention Agile." - John Stevenson
Looking for a Scrum Master? Check the ears!
This is Graham Rowntree or Wig and he is one of the top (rugby) Scrum coaches in the world. As a player he has won just about everything there is to win and is now enjoying life as the England forwards coach. Watching the way England dominated the Ireland scrum on Saturday I would suggest that Wig is pretty good at his job.
The question is why was he given the job in the first place? Was it down to him having a big shiny coaching certificate, was it down to his knowledge of the game gained through years of playing at the highest level(Check out the ears!) or was it down to the way he can develop, motivate and impart his knowledge to the rest of the team? I suspect that the answer is that all three points played a part in him being offered the job but I also suspect that the certificate was probably the least important.
For me a worrying side to the agile community is the ever increasing importance being placed on certification. We see not for profit organisations such as the Scrum alliance churning out trivial certifications that are losing value by the day. We also see the recruitment industry mandating certification as an essential part of being a scrum master, an agile coach or a trainer. With people assuming certification is a sign of quality we are on very dangerous ground and it won't be long before Scrum and Agile are dirty words through failed implementations and a lack of understanding.
I'm not arguing that certification doesn't have a value but I feel that practical skills, knowledge and experience hold more value. Now if only I had some kind of manifesto to pin it on to.
Crewing up – self organising bomber crews.
I recently watched the Ewan McGregor documnetary on the role bomber command played in the second world war. The program was shocking on a number of levels but an unexpected surprise was the revelation on how the crews were formed. I had never given it much thought but just assumed that teams would have been formed by the military hierarchy and team members would have had little to no input into the makeup of their team. It turns out that bomber crews were self organising, air men of different skill sets were put together in a hanger and left to form up into their own air crews. Listening to the veterans being interviewed it was clear that the bonds they formed with their team mates were extremely strong. It is not always natural to pull together in a team when placed in a hostile environment and I am sure that having been empowered to decide on who your teammates were helped the airmen to gel as a team and tackle the appalling situations they encountered during the war.
There is a good clip here from another documentary about "Crewing up".
When does bolognese sauce stop being bolognese sauce and do we care?
I have had a couple of conversations this week with colleagues. Both have been about different things but both have made mention of Scrum being inhibitive because of rules that the process imposes. This got me thinking back to a conversation I had with Rachel Davies a couple of months ago. We were talking about the changes a Scrum team makes to it's process and when that process has changed so much that it ceases to be Scrum. We started comparing Scrum to a recipe for bolognese sauce.
If you and I were to prepare a bolognese sauce you can bet that the ingredients and their preparation would differ wildly between the two dishes yet we would be happy to call them both bolognese sauce. The question is at what point does a change to the recipe stop the dish from being a bolognese sauce? Also if we have refined the recipe each time it is cooked so that it tastes better does it matter that it can no longer be called bolognese sauce? If our aim is to make a delicious dinner then it is surely better to understand why a particular ingredient is present before replacing it or what cooking the sauce for an extra hour will do to the flavour of the dish, than it is to dogmatically stick to a recipe.
Bringing this all back to software our goals should be to produce great software and to delight our users with it. If we can do that by following a process then great and if we can make it better by improving the process then even better. Scrum is a great process with contraints that serve a purpose. You shouldn't shy away from changing a constraint but make sure you first understand it's purpose. If what is left can't really be called Scrum then so what, it all depends whose recipe you follow anyway!
Focusing the Daily Standup
For the last couple of months, I've been growing increasingly dissatisfied with our daily standups.
I have found:
- people talking off topic about work done outside of the sprint.
- people who are working together on a task and both giving the same update or one person differing to the other.
- rambling monologues about intricate problems faced by one person.
- it difficult to disceminate information on where we are with our sprint goals from the background noise mentioned above.
In search of inspiration I found a blog post on Martin Fowler's website which contained several patterns to implement during a standup and one of them struck a chord. Instead of coming to the standup to talk as individuals why not talk as stories.
Talking as Stories
As an Agile team we should be focused on the team's progress rather than an individual's progress. By starting the stand up at the top of your board and working down the stories and discussing what state they are in has the effect of focussing the team on what is important in the sprint. Since changing to this format our standups have become clearer and more informative.
London Scrum Gathering Day One
Well day one of my first Scrum gathering is over and what a great experience on so many levels. The conference opened with a keynote speech from the inspirational Joe Justice talking about his Wikispeed project and "The car that Scrum built". Wikispeed have a brilliant approach to solving society's problems and are also leading the way in applying scrum outside of software.
For me the rest of the day was taken up with a talk on the fundamentals of Scrum with Doug Shimp, Understanding each other with Tom Mellor and finally Scrum master role or job with Paul Goddard. I'll elaborate on the content of these talks when I have more time but I found them all really useful.
Once the sessions had drawn to an end we all migrated to the Thames for a boat cruise which included the stunning spectacle of passing under a raised tower bridge. The evening was filled with lots of enthusiatic between the delegates. My highlight was discussing some of the history of Scrum with Tom Mellor and Harvey Wheaton.
Anyway I'm now off to bed to get rested up for another full day at the Scrum gathering tomorrow.
Scrum an analogy: Don’t fear failure, just fail faster
This post was inspired by a comment a colleague made on the post Fat lads can run too... just a bit slower.
"I think Phil Vickery was also successful because he probably pushed through his fears and tried despite the potential to fail. I like the philosophy in agile that states, essentially, don't fear failure, just fail faster."
I think this is a valid point and one that allows us to extend our Scrum analogy further.
Following the rugby world cup win in 2003 England spent several years producing dire, abject performances that were met with severe criticism from the press and their fans. It was baffling why a team that on paper was so talented were underperforming so consistently. One theory that was put forward was that the players were being restricted by a fear of failure. When faced with a decision they would invariably take the safer option.
There is obviously a balance to be struck when it comes to risk but generally high risk decisions are much safer when taken early. If you throw a speculative pass that gets intercepted in the first few minutes then you have the whole game to recover. If you throw the same pass with the final whistle imminent then recovery is much harder. The same is true in software. We shouldn't be scared to take risky decisions but in doing so we must be willing to accept that the decision could be bad and that we may need to recover. The more time we give ourselves to recover the more likely we are to be successful.
Thankfully this story has a happy ending. In the last year we have seen England lose their fear of failure and instead adopt a pragmatic approach to risk. As a result creativity has returned to their game and they are ultimately more successful as a consequence. This new approach can be summed up by Chris Ashton's try against Australia last year. The try was created by Ben Youngs who chose not to take the safe option of kicking and instead to take a risk and run.
Scrum an analogy: Take small steps to the ultimate goal.
A few years ago Stephen Berkhoff recorded a trailer for Sky Sports' coverage of the Heineken cup. The trailer consisted of Berkhoff giving an adapted version of Al Pacino's half time speech from the film any given Sunday. The jist of the speech is to focus on the inches and to let the yards look after themselves. In other words if you aim to make an inch at a time you are moving in the right direction and more likely to make that inch than you are aiming to make 50 yards. This idea about taking small steps to a greater goal is littered across rugby coaching manuals. If you take the scrumage for instance. The key to a successful scrum is to take small incremental steps rather than giant strides. If you tried to take a big step with 8 guys pushing against you then you will be off balance and unable to exert all your force. Most likely you will end up going backwards.
When learning Scrum we are taught to break work down. Development is done incrementally in small steps. User Stories and tasks that are too big need to be broken down into smaller ones. The reason for doing this is that the bigger something is the more complex it is and the more unknowns exist within it. Trying to tackle a big story in one go is equivalent to taking that big step in the (rugby) scrum. It might work out great but it sure is risky when the same result can be achieved by taking small steps.
Scrum an analogy: Fat lads can run too… just a bit slower.
Scrum an analogy is a series of blog posts about where the name Scrum comes from and why the analogy works so well. In this post I'll look at the makeup of rugby teams, how each position has it's own specialism and how each team member sometimes has to fulfil a role they are not always best suited for.
This is a clip of ex England captain Phil Vickery fulfilling a role he is not best suited for. In the clip we see Vickery who is a burly 20 stone prop receiving the ball where you would expect and want a small agile winger to be. Vickery takes the ball and does his best to cross the try line and score. While he might not be as fast as a winger who would have scored the try with their eyes closed Vickery still manages to take the ball on and score the try. The point is that the end result for the team is the same and it doesn't matter how the team achieved the result.
Placing this in a software context how often do we have the dilemna of a team member complaining of having nothing to do because they are waiting for x to finish what they are doing. In the clip we don't see Vickery stop and wait for the winger and if he had the team most likely wouldn't have scored the try.
There is an obvious to be learnt from rugby. We don't have to be an expert to do a job. Phil Vickery doesn't say I'm a prop, I can't run! Likewise we shouldn't say things like: I'm a developer, I can't design that UI! or I'm a tester, I don't touch code!