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.
Tuesday, 13 October 2009
Tuesday, 11 August 2009
Agile metrics / Scrum Metrics
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 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.. ;)
Monday, 10 August 2009
Twenty tips to write a good stored procedure (RB)
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!
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!
Friday, 17 July 2009
The Wessex Scrum User Group
Our local Scrum User Group based in the South of UK has a new name - The Wessex Scrum User Group!
After months of exchanging emails with the Scrum Alliance, talking to the guys from the London Scrum User Group and discussing how to recruit more members we finally agreed on a name, the SA published our group profile here and we can also list all our events. We also have a new SA designed logo and some arrangements are in place to get experienced people (like CSTs) to visit us!
We have not yet created any website though and the only group place on the web is still the linked in group. Hopefully this will be the next thing on my list after the holiday season.
In the meantime looking forward to the next few meetings, especially the August one when we'll have a special guest - Geoff Watts! Also something to think about is the London Scrum Gathering in Feb 2010 which we may get involved in by contributing to the program and the organization.
Hope to get a good rest next week, as with Scrum Fest and Ken's visit last week it has been quite hectic.. not to mention the kick-off of the new project at work.
Wednesday, 10 June 2009
Effective coaching styles
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.]
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.]
Thursday, 4 June 2009
Value, Flow, Waste
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.
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.
Thursday, 21 May 2009
Unit Testing ASP.NET? ASP.NET unit testing
Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.
The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.
Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.
The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.
Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.
Go ahead, click the following link for more information on how to get your free license.
The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.
Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.
The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.
Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.
Go ahead, click the following link for more information on how to get your free license.
Wednesday, 29 April 2009
South UK Scrum User Group, 27th April 2009
Getting an acceptable definition of done
[Notes from 27th April 2009, South UK Scrum User Group]
The level of granularity is important, which is why we define the definition of done at four levels: release, sprint, story and task.
At the task level we look at the following:
- Developer says it is done
- Unit test exists and passes
- The code is in the trunk
- Code coverage is above the target (e.g. 90%)
- More criteria can be used as function points, analysis coverage, cop type coverage
- Tracking system is updated
- Check-in is reviewed
- The work is reviewed
At the sprint level we define the following:
- All agreed stories are done
- Held a retrospective which is documented
- Show and tell demo
At the Release level the criteria are:
- All sprints are done
- Media is produced (e.g. CDs, marketing materials)
- User documentation has been reviewed (e.g. by the user community)
- Install and release notes are ready
- External testing or audits are performed (e.g. security audits)
- PO signs it off
The definition of done for Story include:
- All tasks associated with the story are done
- The story is integrated and tested
- Acceptance criteria is met
- Installation works
- Documentation is done
- Product owner accepts the story
[Notes from 27th April 2009, South UK Scrum User Group]
The level of granularity is important, which is why we define the definition of done at four levels: release, sprint, story and task.
At the task level we look at the following:
- Developer says it is done
- Unit test exists and passes
- The code is in the trunk
- Code coverage is above the target (e.g. 90%)
- More criteria can be used as function points, analysis coverage, cop type coverage
- Tracking system is updated
- Check-in is reviewed
- The work is reviewed
At the sprint level we define the following:
- All agreed stories are done
- Held a retrospective which is documented
- Show and tell demo
At the Release level the criteria are:
- All sprints are done
- Media is produced (e.g. CDs, marketing materials)
- User documentation has been reviewed (e.g. by the user community)
- Install and release notes are ready
- External testing or audits are performed (e.g. security audits)
- PO signs it off
The definition of done for Story include:
- All tasks associated with the story are done
- The story is integrated and tested
- Acceptance criteria is met
- Installation works
- Documentation is done
- Product owner accepts the story
Friday, 20 March 2009
First UK South Scrum User Group Notes
On 18th this months in a nice pub in Ringwood we had the first ever UK South Scrum User group meeting.
I tried to take as many notes as possible for the benefit of the group members and hopefully the entire Scrum community.
Here's what I managed to write down:
What do we want to achieve with this group?
- Get people to come along and chat (about Scrum and Agile)
- Meet once a month every 3rd Tuesday (this has not changed to last Monday of the month)
- Talk about common issues and ways to resolve them
How do we do it?
We will experiment and pick one of the following or perhaps something else if these are not suitable:
- Open space discussions
- Goldfish bowl
- World cafe
How do we make people aware about this group?
- Ask people who do training for contacts
- Blog about it
- Announce it to NextGen members
- Make it regular – regular day and location
How big do we want it to be? The bigger it is the more structured it has to be.
- Could have perhaps a “learn about Scrum” session
- Talk to big Scrum/Agile consultancies like Conchango/EMC or RallyDev about sending speakers.
- Clive and Plamen to talk with Roman on 8th April (London Scrum User Group) about getting the group listed on the Scrum Alliance website.
We then talked about the biggest challenges that each of us recognises. I have recorded hopefully most of these:
- Getting acceptable definition of done – everyone to sign up for it [This has also become the topic of our next meeting on 27th April)
- Guiding/Coaching ScrumMasters that are new to Scrum and making them become Scrum advocates
- Getting full Senior Management support in a big organisation
- Change process as a whole and trying to implement it into large organisations
- Requirements – getting the definition of them, making them agile requirements.
- Technical gold plating – when to do just enough architecture, design ,etc.
We then went on to talk about positive experiences and again I hope I recorded most of them:
- Team refused to estimate as no answers were given to important requirements questions
- Team no longer delivers the wrong solution
- Team response to HR attempt to impose individual performance reviews.
- Team managed to isolate maintenance to overcome problems with delivering
- The “War room” and winning it from the business just for Scrum use by the teams
- Throwing away the concept of in-sprint defects and no longer wasting time to log them into some system. Get the testers talking rather than typing.
Other thoughts or discussions were around:
- Getting people to understand what is realistically done and optimistically done
- Tech authors could be key as while wanting to know more they lead the information sharing and steer teams towards delivering the user stories
- Important thing is to have the right ratio QA/Developers
- Tools in use include: Rally, TFS, Version One, Target Process (also has helpdesk) and xProcess.
Overall a very good evening and lots of ideas have been discussed. We also managed to set up date for the next meeting, agree on actions about making people aware about the group and identified the main topic for next time.
I hope to see you all there and hopefully a few more people will turn up as well!
I tried to take as many notes as possible for the benefit of the group members and hopefully the entire Scrum community.
Here's what I managed to write down:
What do we want to achieve with this group?
- Get people to come along and chat (about Scrum and Agile)
- Meet once a month every 3rd Tuesday (this has not changed to last Monday of the month)
- Talk about common issues and ways to resolve them
How do we do it?
We will experiment and pick one of the following or perhaps something else if these are not suitable:
- Open space discussions
- Goldfish bowl
- World cafe
How do we make people aware about this group?
- Ask people who do training for contacts
- Blog about it
- Announce it to NextGen members
- Make it regular – regular day and location
How big do we want it to be? The bigger it is the more structured it has to be.
- Could have perhaps a “learn about Scrum” session
- Talk to big Scrum/Agile consultancies like Conchango/EMC or RallyDev about sending speakers.
- Clive and Plamen to talk with Roman on 8th April (London Scrum User Group) about getting the group listed on the Scrum Alliance website.
We then talked about the biggest challenges that each of us recognises. I have recorded hopefully most of these:
- Getting acceptable definition of done – everyone to sign up for it [This has also become the topic of our next meeting on 27th April)
- Guiding/Coaching ScrumMasters that are new to Scrum and making them become Scrum advocates
- Getting full Senior Management support in a big organisation
- Change process as a whole and trying to implement it into large organisations
- Requirements – getting the definition of them, making them agile requirements.
- Technical gold plating – when to do just enough architecture, design ,etc.
We then went on to talk about positive experiences and again I hope I recorded most of them:
- Team refused to estimate as no answers were given to important requirements questions
- Team no longer delivers the wrong solution
- Team response to HR attempt to impose individual performance reviews.
- Team managed to isolate maintenance to overcome problems with delivering
- The “War room” and winning it from the business just for Scrum use by the teams
- Throwing away the concept of in-sprint defects and no longer wasting time to log them into some system. Get the testers talking rather than typing.
Other thoughts or discussions were around:
- Getting people to understand what is realistically done and optimistically done
- Tech authors could be key as while wanting to know more they lead the information sharing and steer teams towards delivering the user stories
- Important thing is to have the right ratio QA/Developers
- Tools in use include: Rally, TFS, Version One, Target Process (also has helpdesk) and xProcess.
Overall a very good evening and lots of ideas have been discussed. We also managed to set up date for the next meeting, agree on actions about making people aware about the group and identified the main topic for next time.
I hope to see you all there and hopefully a few more people will turn up as well!
Thursday, 12 February 2009
Scrum User Group in the South (outside London)
A fellow scrummer based in dorset has posted this yesterday and emailed the scrum development yahoo group with an idea to organise Scrum UG in close proximity to BH, SO, PO. I then decided to join him in an attempt to gather enough people and created this linked in group. If you happen to somehow find this post and live in the area and are interested in participating in a Scrum UG please join the linked in group.
Subscribe to:
Posts (Atom)