I recently became aware of this experiment which Deming used to do in front of large audiences (e.g. 1200 people). Thanks to David and Benjamin the experiment comes to live again. It is worth watching at least the first 50 minutes and see for yourself this amazing story of processes, metrics, management, rewards and people.
http://skillsmatter.com/event/agile-scrum/demings-red-bead-experiment
Inspired by Mark Summer's post we decided to do a Cool Wall style joint team retrospective at the end of last sprint. These are scrum teams that work on the same project and often have cross team impediments or reasons to be proud.
It worked quite well, team said they liked it so we're doing it again. For more details on the technique check Mark's blog here
Geoff Watts will be holding a CSM training course in Bournemouth on the 23/11/2009 and 24/11/2009. For full details see here
While looking at metrics and what is appropriate I finally came across something that made sense to me and to the scrum masters in our department.
The information is from an article by Michael James which doesn't seem to be available any more unfortunately. The title of the article is An Agile ApproAch to “Metrics” and you may try to find it if you're more persistent than myself.
This article suggests to use a combination of 3 or 4 metrics. While I generally like the idea I am not sure all of them would work in our current environment. For example I would avoid using velocity in that sense although I would use it as a trend and not really related to the reports that Senior Management wants to do.
The two things that I reckon make sense are:
1. Delivered business value - i.e. every item has a business value and you count how much is being delivered
2. Running Tested Features which is something Ron Jeffries talks a lot about and we happen to do - e.g. a feature is RTF if it can be demoed from production build and passes automated tests (which should cover the acceptance criteria).
These two in combination make it difficult to game and also guarantee both business value and quality. While I am sure some people can still game them, I believe they represent a reasonable way to resolve the metrics problem.
I very often hear about metrics in agile or what metrics shall we use in Scrum?
I recently came across Mary Poppendieck's suggestion about using the following "holistic measures":
1. Average Cycle Time – how long things take to go through the system.
for example - requirements from capture to acceptance and defects from
detection to correction.
2. The Business Case – Is the project still viable? If this isn't the case,
everything else is irrelevant.
3. Customer satisfaction – are your customers happy?
I wish I could try these one day.. instead my managers ask me to calculate the time spent on stories/projects and all types of coverage reports. Oh well.. ;)
I came across a very useful list of tips for writing good Stored Procs by Arup Chakraborty here
I would say it can be combined with my set of best practices to include things like limiting the sets as early as possible.
Good read overall!
Our local Scrum User Group based in the South of UK has a new name - The Wessex Scrum User Group!
Scrum – Start sprinting, there is no faster way to fail and then correct the problems and then do it again to achieve continuous improvement.
Positive – You have to maintain a positive attitude. Accepting change isn’t easy for most people and there will be some that may find it difficult to adapt. Learn enough to be able to explain a lot but also continue reading and finding answers as you go.
Effort – you need to make an effort to make this work, and not only you. Everyone on the team must get out of their comfort zones and start thinking on how to improve every single detail of what they do. Many Scrum books recommend as a prerequisite having the right people and the right people must have the right attitude and be able to make that extra effort to succeed.
Communicate – communication is a key factor in the success of every agile transformation. Make sure you remove all barriers that may prevent communication. These could range from cubicles to avoiding conflict. You may need to learn a lot about dysfunctions and how to cure them and you may need to participate in difficult discussions with facilities managers. But without doing it you will be reducing your chances to succeed.
Inspect – regularly look back and think about the things that you did well and the things that you have to improve. Find a good retrospective technique that works for your team and make sure you look not only within the team but also for organizational barriers.
Adapt – identifying the issues would not be worth the effort if you’re not doing enough to resolve them. Things that slow you down should always be near the top of the list for stuff you need to do. Add them to your backlog and make them visible – this is an effective way to get them resolve and then identify more issues.
Learn and listen. Never stop learning, learn from mistakes, from the experience of others, from the people you coach and teach. Learning, just like improvement, never stops. Learn to listen, because the moment you started this transformation you’ve become destined to coach and coaching is all about listening and asking the right questions to help people around you do better.
Are you ready to do something S.P.E.C.I.A.L.?
Open space session notes from the Agile Coaches Gathering 2009 (Milton Keynes)
Key info:
- Facilitated by Xavier Quesada Allue
- Attendees that I remember: Rachel Davis, Manish Shah, Bob Marshal, David Draper, David Joyce, Manav Mehan (and many more + I hope all these guys really were there)
First we listed styles that we can think of including:
- Non directive style
- Leadership style
- Depending on what the person expects (adaptive)
- Trainer style
We recognized the fact that there are dimensions and styles. We looked at established coaching models like GROW (Goal, Reality, Options, Will), The Dreifuss model, The solution focus model based on getting the goals out of the coachee.
Then we talked about capability coaching and the thoughts I listed on this were various approaches and questions to ask like:
- Interesting! Tell me more? (instead of reacting negatively and directing)
- Why? – Perhaps replace with “what would that give you?” or “what would that result in?”
- What value does that give us? Is that what we want?
- Get going (not sure about this one, perhaps related to do and then inspect.)
- Look at all the issues (e.g. impediments, problems) and prioritize – perhaps phrase this as question
Somebody asked the question – Do you have to have all the styles? And the answer came that you certainly need a set of styles. How do you find out how effective your style is? Watch other people coach in action (Shadowing; Pair-coaching).
You need to ask yourself the questions – Who you are being and what you’re doing. You can have the same or different model and perhaps slightly different style.
You may want to think about 3 adjectives that you would use to describe this person like best at? Or worst at?
How to find out if you’re effective? Can remote coaching be effective? You rely on hearing only and lose the body language. Near coach/far coach model.
Coaches should not be part of the system – if you are then you’re missing coaching opportunities. Your goal as a coach should be the improvement of the team.
The team must respect you. You have to be visibly doing stuff. If you quickly show/add a bit of value then you get respect. You also need to show respect. Consider if the team has actually asked for a coach?
[An interesting related book is “The speed of trust”]
There are 3 factors:
- Character
- Competence (It has been noted that it is easier to coach if you’re less competent as you do not direct)
- Consistency (develops over time and sets predictable behaviour)
For example coaching a tester can be effective even though you don’t know anything about testing.
You perhaps need some basics – e.g. TDD, principles, knowing concepts and tools.
Coaching is to help someone move forward.
[A good book to check is Quiet Leadership.]
I heard somebody talking about these three in the same sentence a couple of weeks ago and accidentally (or perhaps now) used them in a presentation draft while trying to explain what in Scrum we'd separate as functional/non-functional.. and waste although it doesn't seem to come up that often as the other two.
Anyway so I had to explain what it is as the word Value seem to be causing hiccups with some of our managers and the shorter explanation I could think of was that value is what we get money for, flow is what makes possible the production of value and waste is all that doesn't add to any of the other two so we throw it away.
I then ended up searching for more info and discovered 5 principles of lean (as opposed to the more famous 7). Here they are:
1. Specify value
2. Identify the value stream
3. Make value flow
4. Let customers pull
5. Pursue perfection (e.g. identify waste and eliminate continuously)
Ok, so the connection is that these 5 principles well explain the title as well and I am going to use them when I talk about it in about 10 days time. I may even post something about the event as it is my first ever agile project initiation boot camp.
