The agile Vancouver conference wrapped up yesterday - a great Canadian conference if you are wondering where to spend your training budget in 2011. On Wednesday morning we held an open space similar to the agile panel at SDEC. We opened the floor for questions, ranked them, and then spent 10 minutes on each topic. Since the open space was largely filled with speakers and experienced agilists, I asked this question: "What is your top 1 agile tip". Here are our responses with twitter usernames where applicable:
@lucisferre - "Working towards continuous delivery"
@dbelcham - "Be agile w/ agile practices. Adopt what works"
@mikeeedwards - "One step at a time. Find small wins"
unknown - "Adopt pair programming"
Angel from Spain - "Make the change come from them - get them to see the problem and come up with the improvement"
@Ang3lFir3 - "Can't do it without the right people. One bad egg spoils the whole bunch. Get the right people on the bus"
@dwhelan - "Find the bottlneck in your value flow and cut it in half"
@srogalsky - "Uncover better ways. Never stop learning. You are never finished being agile"
@mfeathers - "Don't forget about the code or it will bury you. It will $%#ing bury you"
@robertreppel - "Recognize your knowledge gaps and bring in help if you need it"
@jediwhale - "Pull the caps lock key off your keyboard"
Next time I'm in a panel, the question will be: "I love agile because..." Feel free to comment with your answers.
Steve Rogalsky's thoughts on agile and lean in the contexts of software development and life.
Friday, November 5, 2010
Why is collective team ownership and commitment better than individual ownership and commitment?
Recently I've been pondering collective vs. individual ownership and commitment, the theories behind it, and how to respond to someone who many not have considered why collective ownership and commitment is important. If you are involved on a team that is assigning responsibility to individuals, you could respond in several ways. My own impulse may be to respond either with frustration or to smile, nod and wink to my more agile-aligned team members. However, I have never found these types of responses to be very productive ;). You could also respond by informing the team that the agile community is full of luminaries who tell us that individual responsibility is not compatible with good results over the long term. However, as you can imagine, it also won't be an effective strategy just to tell your team that Johanna, Brian, Bob, Esther, James, Jeff, Mary, (etc) and you don't think this is an effective way to manage the work. Instead, I suggest that you a attempt a face to face discussion on the pros and cons of assigning the work to the team vs. the individual. Here are a few things you might use in your discussion.
Team ownership reduces the risk of having or creating one 'smart person in the room' (i.e. bottleneck) who does all the work. Even though Jim may be the best person to complete the job, if Tim and Jane work on it together with Jim it will take a little longer initially to complete the task, but those gains will be realized over the long term as the whole team becomes better at accomplishing each task and filling each role. While a cross functional team isn't always easily or immediately created, eventually that team can function effectively to complete any task even if one or more team members are missing.
Collective ownership should result in less items that are in progress. Work in progress tasks have zero realized value to the organization's goals. If we commit to and own items as a team, we should work hard to get them done one at a time so that we can realize the value of those items sooner. Rather than 5 people completing 5 tasks individually that are finished together at the end of the month, task 1 is finished and creating value at the end of week 1, task 2 at the end of week 2, etc.
Quality has a better chance of being built in from the beginning when a team owns and takes responsibility of a task together. As the team works together on a backlog item, we will collectively discover our 'quality blind spots' earlier in the process and adjust accordingly. When I work on an item myself and then present it to the team for review after I'm finished, there will be more re-work required to incorporate the ideas of my team members in order to mark the item as done. It is critical to get feedback early and often in order to 'fail fast' and improve quality. Teamwork is an effective way to accomplish this.
Finally, collective team ownership promotes... teamwork. Individual accountability and responsibility tend to generate selfish behaviour (I'm working on my task that I'll be measured on so I can't help you with yours). Team accountability and responsibility builds a stronger team because if any one task is sub par it reflects on the whole team and not on an individual.
Of course, this doesn't work very well if we don't sit together - which is why we do.
Team ownership reduces the risk of having or creating one 'smart person in the room' (i.e. bottleneck) who does all the work. Even though Jim may be the best person to complete the job, if Tim and Jane work on it together with Jim it will take a little longer initially to complete the task, but those gains will be realized over the long term as the whole team becomes better at accomplishing each task and filling each role. While a cross functional team isn't always easily or immediately created, eventually that team can function effectively to complete any task even if one or more team members are missing.
Collective ownership should result in less items that are in progress. Work in progress tasks have zero realized value to the organization's goals. If we commit to and own items as a team, we should work hard to get them done one at a time so that we can realize the value of those items sooner. Rather than 5 people completing 5 tasks individually that are finished together at the end of the month, task 1 is finished and creating value at the end of week 1, task 2 at the end of week 2, etc.
Quality has a better chance of being built in from the beginning when a team owns and takes responsibility of a task together. As the team works together on a backlog item, we will collectively discover our 'quality blind spots' earlier in the process and adjust accordingly. When I work on an item myself and then present it to the team for review after I'm finished, there will be more re-work required to incorporate the ideas of my team members in order to mark the item as done. It is critical to get feedback early and often in order to 'fail fast' and improve quality. Teamwork is an effective way to accomplish this.
Finally, collective team ownership promotes... teamwork. Individual accountability and responsibility tend to generate selfish behaviour (I'm working on my task that I'll be measured on so I can't help you with yours). Team accountability and responsibility builds a stronger team because if any one task is sub par it reflects on the whole team and not on an individual.
Of course, this doesn't work very well if we don't sit together - which is why we do.
Monday, October 25, 2010
My top 12 agile podcast episodes
When I mentioned at SDEC10 that much of what I know about agile I learned from podcasts, several people expressed interest in my favourites. Here are my top 12 (now 13) podcast episodes in random order:
1. Hanselminutes 119. What is Done? A conversation with Scrum co-creator Ken Schwaber. An excellent conversation that answered some of my initial questions about Agile like - how do logging, security and other infrastructure tasks fit in the back log, and of course - what is done?
2. AgileToolkit - Allistair Cockburn interview at Agile2006. Allistair talks about his evolution as a Methodologist from a hardware guy, the Crystal family of agile methodologies, his writing and much more. Crystal recognizes that one agile methodology cannot be used in all companies and tries to identify the core principles and practices that are important for all agile projects.
3. Hanselminutes 145. An overview of the SOLID principles with Robert C. Martin ("Uncle Bob"). Excellent overview with examples.
4. LeanAgileTalk 20070118. Part 1 of a great conversation with Alan Shalloway on how to apply lean principles to agile development. A good start on how to implement practices - the 'how'. Some excellent sound bites in here.
5. AgileToolkit - Uncle Bob interview at Agile2005. A brief discussion with Bob Martin on the essential principles of Agile
6. Hanselminutes 23. A short introduction to scrum.
7. Hanselminutes 31. A good introduction on Test Driven Development and the benefits. Includes discussion of the pros/cons.
8. AgileToolkit - APLN Panel discussion. Long (2 hours), but good. Here are some of the highlights:
- Worst agile transition failures? - What is required for transition? Leadership, don't do partial agile, must integrate testers on the team, need to form teams that work effectively together - Self organizing teams - is this possible? The original XP team was full of architects, but our teams may not be - how can we do this? The original backlash against architecture was that architects were responsible to standards, not to the business problem. Also - it is important to move our experts out of the corner office and off the pedestal and on to the teams as active members producing code. - Level of up front architecture required? Depends on problem/project. With a new domain, or a junior team, more architecture guidance is required. With a known domain and an experienced team, less architecture guidance is required. - Is requirements a dirty word? No - signoff is the dirty word. Requirements are good - but waiting months before implementing is not, not accepting change is not. Don't penalize people from finding errors, omissions, changes at any step. - How to do fixed price projects? One suggestion - share the risk (i.e. cost) for the first 6-8 weeks (2 or 3 iterations) to measure your velocity and gain trust. Then if client is happy, you have enough info to fix the price, and you get your "risk" back. - Why is fixed bad? You give them what they asked for, rather than what they need. Never used + rarely used features = 64% of the code (Standish report)
9. AgileToolkit - Uncle Bob explains the agile manifesto. Robert "Uncle Bob" Martin answers the
question of "What is Agile?" He goes back to the start, to the Snowbird meeting, the formation of the Agile Alliance and the drafting of the Agile Manifesto. He also looks at the core principles and key practices of Agile software development.
10. Agile Toolkit - Poppendiecks at Agile 2006. Tom and Mary discuss several topics including:
- optimize the whole, not the pieces - don't neglect one of the pillars of lean: respect people - queueing theory. Examples a defect list is a queue that should not exist. We should be mistake free after each step. Don't build on top of bad software. Also, this helps eliminate interim artifacts like 'test strategy document'. - testing phase - this is testing too late - relating lean to cooking by a master chef
- describing how clothing store Zara implemented lean (very interesting)
11. IT Conversations - Ken Schwaber. Ken talks through many of reasons why agile SW development is such a necessary change in the industry.
12. Hanselminutes 169 - TDD with Roy Osherove. Roy Osherove educates Scott on best practices in Unit Testing techniques and the Art of Unit Testing.
13. DotNetRocks show 750 - While at Prairie Dev Con in Calgary, Carl and Richard chatted with Steve Rogalsky about User Story Mapping. Steve explains how User Story Mapping helps to visual your backlog beyond a serial list of features to allow you to improve your project decisions, priorities, plans, and delivery. (Sorry - had to add this one ;)
Hope you enjoy them. Let me know if you have other favourites - I'd love to listen to them.
1. Hanselminutes 119. What is Done? A conversation with Scrum co-creator Ken Schwaber. An excellent conversation that answered some of my initial questions about Agile like - how do logging, security and other infrastructure tasks fit in the back log, and of course - what is done?
2. AgileToolkit - Allistair Cockburn interview at Agile2006. Allistair talks about his evolution as a Methodologist from a hardware guy, the Crystal family of agile methodologies, his writing and much more. Crystal recognizes that one agile methodology cannot be used in all companies and tries to identify the core principles and practices that are important for all agile projects.
3. Hanselminutes 145. An overview of the SOLID principles with Robert C. Martin ("Uncle Bob"). Excellent overview with examples.
4. LeanAgileTalk 20070118. Part 1 of a great conversation with Alan Shalloway on how to apply lean principles to agile development. A good start on how to implement practices - the 'how'. Some excellent sound bites in here.
5. AgileToolkit - Uncle Bob interview at Agile2005. A brief discussion with Bob Martin on the essential principles of Agile
6. Hanselminutes 23. A short introduction to scrum.
7. Hanselminutes 31. A good introduction on Test Driven Development and the benefits. Includes discussion of the pros/cons.
8. AgileToolkit - APLN Panel discussion. Long (2 hours), but good. Here are some of the highlights:
- Worst agile transition failures? - What is required for transition? Leadership, don't do partial agile, must integrate testers on the team, need to form teams that work effectively together - Self organizing teams - is this possible? The original XP team was full of architects, but our teams may not be - how can we do this? The original backlash against architecture was that architects were responsible to standards, not to the business problem. Also - it is important to move our experts out of the corner office and off the pedestal and on to the teams as active members producing code. - Level of up front architecture required? Depends on problem/project. With a new domain, or a junior team, more architecture guidance is required. With a known domain and an experienced team, less architecture guidance is required. - Is requirements a dirty word? No - signoff is the dirty word. Requirements are good - but waiting months before implementing is not, not accepting change is not. Don't penalize people from finding errors, omissions, changes at any step. - How to do fixed price projects? One suggestion - share the risk (i.e. cost) for the first 6-8 weeks (2 or 3 iterations) to measure your velocity and gain trust. Then if client is happy, you have enough info to fix the price, and you get your "risk" back. - Why is fixed bad? You give them what they asked for, rather than what they need. Never used + rarely used features = 64% of the code (Standish report)
9. AgileToolkit - Uncle Bob explains the agile manifesto. Robert "Uncle Bob" Martin answers the
question of "What is Agile?" He goes back to the start, to the Snowbird meeting, the formation of the Agile Alliance and the drafting of the Agile Manifesto. He also looks at the core principles and key practices of Agile software development.
10. Agile Toolkit - Poppendiecks at Agile 2006. Tom and Mary discuss several topics including:
- optimize the whole, not the pieces - don't neglect one of the pillars of lean: respect people - queueing theory. Examples a defect list is a queue that should not exist. We should be mistake free after each step. Don't build on top of bad software. Also, this helps eliminate interim artifacts like 'test strategy document'. - testing phase - this is testing too late - relating lean to cooking by a master chef
- describing how clothing store Zara implemented lean (very interesting)
11. IT Conversations - Ken Schwaber. Ken talks through many of reasons why agile SW development is such a necessary change in the industry.
12. Hanselminutes 169 - TDD with Roy Osherove. Roy Osherove educates Scott on best practices in Unit Testing techniques and the Art of Unit Testing.
13. DotNetRocks show 750 - While at Prairie Dev Con in Calgary, Carl and Richard chatted with Steve Rogalsky about User Story Mapping. Steve explains how User Story Mapping helps to visual your backlog beyond a serial list of features to allow you to improve your project decisions, priorities, plans, and delivery. (Sorry - had to add this one ;)
Hope you enjoy them. Let me know if you have other favourites - I'd love to listen to them.
Saturday, September 18, 2010
FitNesse and today's date with .net
I have an acceptance test that says I need to validate the age of majority in each of the different states and provinces. Here is a simple example:
The test above is faily simple and I could write it like this in the wiki as a Column Fixture (using the fitSharp.dll to test C# code)
The problem of course is that this test will start failing on January 5, 2013 when Mary turns 18. Also, it does not perform the boundary testing that I would like it to do in order to test someone who is 18 today vs. someone who will turn 18 tomorrow. In order to improve this test, I investigated some other date functions in FitNesse and a plugin by James Carr that allowed you to add days to the current date. These work ok for smaller calculations like "Given document ABC, When it is 30 days old, Then archive it". However, this would be a little more cumbersome for birth dates when adding 18 years (esp. with leap year calculations) and the !today function in FitNesse does not work in ColumnFixture wiki tables. So, I found a simple way to meet my requirement.
First, I wrote a class in C# that accepts two parameters to Add or Subtract Years and Days to the current date. The class uses C#'s simple DateTime addition to add or subtract the years/days from today and returns the result. You could easily extend this to add months or add other functionality required in your tests:
Then in FitNesse at the top of my script for this story I call GetDateBasedOnToday and store the resulting values in FitNesse variables. Finally, I use the variable names through my script to reference the underage and of age birth dates. Here is an example:
In FitNesse, the final result including the acceptance criteria above looks like this:
(Note: The example above should probably be written as a unit test because it is fairly straightforward, but it simply illustrates how to use the date logic that I'm using as part of larger acceptance tests.)
Given Mary who is born January 5, 1995 and lives in Manitoba
When she asks if she is the age of majority
Then return no
The test above is faily simple and I could write it like this in the wiki as a Column Fixture (using the fitSharp.dll to test C# code)
!|Check Age of Majority|
|Province State|Birth Date|Am I Underage?|
|MB |5-Jan-1995|Yes |
The problem of course is that this test will start failing on January 5, 2013 when Mary turns 18. Also, it does not perform the boundary testing that I would like it to do in order to test someone who is 18 today vs. someone who will turn 18 tomorrow. In order to improve this test, I investigated some other date functions in FitNesse and a plugin by James Carr that allowed you to add days to the current date. These work ok for smaller calculations like "Given document ABC, When it is 30 days old, Then archive it". However, this would be a little more cumbersome for birth dates when adding 18 years (esp. with leap year calculations) and the !today function in FitNesse does not work in ColumnFixture wiki tables. So, I found a simple way to meet my requirement.
First, I wrote a class in C# that accepts two parameters to Add or Subtract Years and Days to the current date. The class uses C#'s simple DateTime addition to add or subtract the years/days from today and returns the result. You could easily extend this to add months or add other functionality required in your tests:
namespace FitNesseTutorial.Tests
{
public class GetDateBasedOnToday : ColumnFixture
{
public int AddYears;
public int AddDays;
public DateTime ResultingDate()
{
return DateTime.Today.AddYears(AddYears).AddDays(AddDays);
}
}
}
The FitNesse script:
''Get underage and of age dates for 18 and 19 year olds''
!|Get Date Based On Today |
|Add Years|Add Days|Resulting Date?|
|-18 |1 |>>UNDERAGE_18 |
|-19 |1 |>>UNDERAGE_19 |
|-18 |0 |>>OFAGE_18 |
|-19 |0 |>>OFAGE_19 |
!|Check Age of Majority|
|Province State|Birth Date |Am I Underage?|
|MB |<<OFAGE_18 |Yes |
|MB |<<UNDERAGE_18|No |
|BC |<<OFAGE_19 |Yes |
|BC |<<UNDERAGE_19|No |
In FitNesse, the final result including the acceptance criteria above looks like this:
(Note: The example above should probably be written as a unit test because it is fairly straightforward, but it simply illustrates how to use the date logic that I'm using as part of larger acceptance tests.)
Sunday, August 15, 2010
Agile readiness assessments at Agile2010
I've posted the images from the session "Look before you leap - Agile readiness assessments done right" at Agile2010. The images are here http://tinyurl.com/26bwlzw.
Some of the images are blurry in my browser (IE), but if you 'Save As' to your computer then you get more detail (not sure why). If there are any images you need more detail on, let me know - I still have all the originals.
Some of the images are blurry in my browser (IE), but if you 'Save As' to your computer then you get more detail (not sure why). If there are any images you need more detail on, let me know - I still have all the originals.
Subscribe to:
Posts (Atom)