How The Agile Coach Can Learn From The Special One

I am a big football (soccer for Americans) fan. I regularly attend matches for not only my team but others as well as watching any football I can find on TV. I love the game, and the thing I love most about the game is the managers. I am often asked by my girlfriend why it is that when a team is having a run of poor form, instead of replacing the 11 men on the field they fire and replace the one man off the field? Simple, he is there to facilitate them achieving all they can, removing any impediments that stand in their way, similar to an agile coach.

For example, any person who has made it to the rank of professional footballer has a good level of skill at the game. We can assume they are able to kick a ball in a straight line and know what they are doing. It is the manager however that coaches them at putting their requisite skills together in the right way, of freeing the team’s mind of anything else than how they can effortlessly do what they do best. By setting the team up in a way where they feel they are as prepared as possible and can use their skills in the fullest manner possible, things can be achieved (Blackpool and Holloway I am looking at you).

The “best” football possibly ever played was by The Ajax team from around 1970 – called Total Football. This tactical system can be stated as follows:

“Total Football” is the label for an influential theory of tactical association football in which any player can take over the role of any other player in the team.

Now to me that sounds like a team that is cross-functional! No specialisations, everybody able to pitch in where needed at any time and all working cohesively together towards a common “goal” (sorry for the pun!)

So why should I have mentioned this quite evidently obvious fact? Playing the best most attractive football won’t necessary win you matches. You have to work hard improving as a team before you can get there, you will not just become a team going from playing route one (hit it up field and hope) football to suddenly being a team that is playing such glorious football. You have to train the players in the right way, alter their thinking and work hard at it. More importantly perhaps, you have to get them into the habit of winning.

Winning is a habit, and this is the same for an agile team, winning is habitual. Winning in football means scoring more than your opposition and taking home 3 points. Sometimes however, a victory can mean getting a draw, and sometimes it can just mean survival. In an agile team often people focus too much on “becoming agile”, “being an agile team” etc. You need to understand where you are starting from, and get the technical skills being improved upon, working on the process of development (your tactics and strategy) and accepting your victories as they come on the journey. For a team with no unit test coverage,  adopting TDD and achieving 75% on all new code will be a major achievement,  for a more experienced agile team, anything less than having obtained 100% coverage and completed all signed upto stories (being the ideal team we read about) will be classed as a failure.

The job of the agile coach is to put the team on the right track, helping them to start passing the ball more fluidly and moving in a more co-ordinated manner. It is not a job that is the coach’s alone, everyone in the organisation needs to prepare and practice for success, but it is the coach who will have to bear the brunt of this.

I want to finish this article by talking about Jose Mourinho, the Special One. As a Man Utd fan, he is a man I have loathed greatly, but he is someone who I look to as an inspirational coach, and as a brilliant agile coach. He diverts all attention from his team by being loud and brash removing the impediment of the media and allowing the players to focus on football. He consistently reiterates his philosophy of winning, of training right and playing in the most effective way against his next opponent (and it isn’t often/always pretty football). Most importantly is the moniker he has given himself, “The Special One”, which he truly believes he is, and after his successes, so now does every manager and player on the planet. He has garnered a respect and aura amongst his team that they are instantly uplifted by his presence and believe they are champions. A good coach knows how to inspire their team. You don’t have to do it in the same way, but you have to be able to get that belief instilled in the team members that they can do this. Remember it is about helping the team to do the best they can, and a person who has belief in their system and skills will always perform to the best of their abilities, and write some damn good software.

Be Champions!

Looking Retrospectively

Recently I had the opportunity to run the latest release retrospectives for both our UK based team and was also fortunate enough to be flown to Spain to run it for our teams there. I had run a number of sprint retrospectives before which was something I had enjoyed doing and found very rewarding. I had found the key to them was to allow the team to air the grievances that they had but to try and always end with some positives and a set of goals we were going to focus on achieving during the next sprint.

I had a bit of free thinking time so I thought I would just note down and summarise here a few key points I have learnt or would focus on utilising after reviewing my own performance, a release retrospective retrospective you might say.

  1. A day s a short period of time. It will disappear quickly so timeboxing and keeping things moving are very important.
  2. Short team based activities work best as they keep people focussed for short intensive bursts and this also should allow everyone to voice their opinions.
  3. Make the aim of the retrospective to be new stories and tasks for your process improvement backlog.
  4. Make sure the last thing you do is sign  up to at least one of these stories.
  5. Start the day with generalised problems and refine them down to good solutions and actions by the end of the day.
  6. Don’t worry too much about something important being missed out. The team will naturally filter down to their most important issues and solutions throughout the day.
  7. Allow some time for an open floor discussion.
  8. Do some preliminary data gathering for the retrospective. This will allow you to gauge what sort of issues need to be surfaced and what questions you need to ask.
  9. Enjoy it. Not everyone will b pleased by some of the discussions, suggestions or output, but you should aim to enjoy it as much as possible, which I found helped others open up and enjoy it more too.

Relative Strength Index and Scrum

I very recently had an article published in the Agile Record magazine in which I discussed how we could adapt the idea of a share chart to a scrum team to become a good indicator of how we are progressing over time. We would hope to see a generally increasing trend (not too fast – nearly level in fact). In that article I said I would be uploading a post here on howto adapt the Relative Strength Index measurement to scrum also.

To calculate an RSI value we must have 14 days worth of data. Each day our stock chart either has a gain or a loss in terms of burn. Firstly we calculate our initial average gain U0 and initial average loss D0 as:

U0 = total of gains over past 14 days/14     D0 = total of losses over past 14 days/14

Note that is we have a drop of -4 for a day then we have a loss of 4. Thus both U0 and D0 should be positive values. We then divide the average gain by the average loss to obtain a value R0. Our RSI value is then:

RSI0 = 100 – 100/(1+R0)

Everyday we recalculate our values on day n as RSIn = 100 – 100/(1+Rn) where Rn = Un/Dn and

Un = (13*Un-1 + daily gain)/14 and Dn = (13*Dn-1 + daily loss)/14

Our RSI values are between 1 and 100 and depending on this value indicate how our process is going. The aim of the RSIvalue is that it gives an indicator to us of where the direction of the burn may be going before it happens.

A value between 1 and 15 means that on average we are losing a large amount everyday and so something is going wrong in our scrum process that needs addressing. We could for example have massively underestimated on our workload or have an extenuating circumstance leading to mass loss of burn, but if we get to this point in our RSI, something needs to be done. A good suggestion is to call an emergency 1 hour timeboxed team meeting with the intent on finding out what the issue (if not immediately apparent is) and resolving it. Between 15 and 30 means that we are in dangerous territory of possibly dropping below zero and being underbought where some investment into the team in terms of resources will lead to a good increase in burn rate. For example we may be working on some difficult functionality in a new area and the extra investment of time into this will pay off dividends later when we can resue a more efficient method in our project.

Between 30 and 50 means we are just falling short of an even burn where we on average gain and lose the same amount (good days and bad days). This should be treated with some caution as it does mean we are losing more than gaining but generally can be similar to above with some bottleneck in resources temporarily.

Between 50 and 70 means that we are averaging just above even which is exactly the region we wish to be in. We are getting better at our process and just being a team. Be careful to look out for our burn rising too close to 70 as we will want to stay just above on the burn stakes meaning we have exactly the right amount of work.

Above 70 and below 85 is an area where we are burning very well and this should be carefully considered by the team. Are we estimating our cards correctly or have we found a clever way to speed up our development?(e.g. using LINQ as opposed to a million SQL queries, automating some code generation or testing). This should be watched carefully by the team but can be used as a good retrospective point for adjusting in a positive manner (we are over-performing, here is why, lets do that more and increase our velocity).

Above 85 is a big red danger zone indicating that on average we are burning at nearly double the rate. We have either not got enough work for the team, lied in estimation (finding all files containing the phrase “static TestMothod” and replacing it with “static TestMethod” is estimated as a 4 hour not 4 minute job – and if you disagree go learn about grep) or generally not been performing as required.

This is a very good system as it uses the previous average in its next calculation so takes in a larger scope of yesterday’s weather the further we take the calculation. It should be stressed that this is an indicator for the team (as is the burndown chart and my suggested scrum team share price chart) to see how they are doing. For me the essence of agile development processes are the focus on the team as the key part. Agile methodologies are for the development (including testing) team allowing them to do their obs (and for most developers at least this is their passion – I cannot talk for testers) in the best way possible for the team. Any team where this is adopted and it becomes an exercise in number crunching for a project manager is bound to lead to problems.

Where have all the Kata gone?

Okay, so there have been no Kata updates for a while. Firstly I would like it known that at least mentally I did come up with the other solutions. I sadly however got sidetracked by working on work at home and thus becoming a bit burnt by the weekend.

I decided therefore to have a weekend off to setup my PS3 online and enjoy some Army of Two and to give myself a break.

The Kata will continue from tomorrow onwards with Kata 3.

In other news I was published in the Agile Record magazine with an article on Financial Analysis applied to Scrum. I will in the future be adding some further writings to this blog based upon this idea. I have already reformulated the idea of a “Relative Strength Indicator” to be applied to Scrum and will hope to do more technical analyses over time.

“Hello World!”

Hi!

This is the inaugural post for the new blog on my new website. This is intended to be a temporary setup whilst I design and code my own site and its functionality. The sort of stuff I will be posting about is maths, technology, programming, software development methodologies and anything else I fancy writing about.

Eventually I plan to have most of the site setup dedicated to my portfolio projects and work, but this is really more of an experiment and we shall see where it goes.

To kick this off with a bit of background information, my name is (funnily enough) Paul Battisson and I am a recent mathematics graduate turned developer. I have been a hobbyist programmer in numerous languages for about 8 years plus, but I am trying to become a (more) refined developer now. I am currently developing on the Force.com platform for FinancialForce.com. I am a Certified Scrum Master and enjoy practicing Agile development, however I am always looking out for new ideas.

Finally, please feel free to post any suggestions and/or comments that are constructive.