Any Agile project depends on fearless change because Agile values responding to change over planning. Identifying, isolating, and removing non-deterministic tests is important to the success of an Agile team but it is often overlooked.
Martin Fowler always has something interesting to say. I ran across his article from April 2011on non-determinism in tests. I think the whole article is worth reading but here is a summary for the tl;dr crowd:
Non-deterministic tests fail ambiguously -- either because of a real failure or because of a set up issue or a timing issue.
This ambiguity undermines confidence in the test suite.
Without confidence in the test suite, the developers become fearful of change.
The fear of change prevents the kind of continuous improvement needed for Agile to work
His solution is to quarantine the non-deterministic tests and convert them to deterministic tests in short order.
Wednesday, August 17, 2011
Wednesday, July 13, 2011
HTML5 and CSS3
I saw Todd Anglin of Telerik speak at the Dallas ASP.Net user group on June 28th. He covered HTML5 and the technologies that can be used now. There were problems with the recording but his slides are here.
I recommend keeping an eye out for any of Todd Anglin's speaking engagements. I've been to two and both were worth it. His more recent presentations are focused on the presentation layer but he is skilled at working at all layers. This helps make his UI presentations more accessible even to programmers that do not work at the UI layer very often.
My interest in HTML5 has been sparked by Todd's presentation. During the presentation, he asked the audience to choose one technology and start using it today. I chose local storage. Local storage combined with manifests could help make web sites less vulnerable to spotty network connectivity. I expect it local storage will be a good launching point for other, sexier parts of HTML5.
I recommend keeping an eye out for any of Todd Anglin's speaking engagements. I've been to two and both were worth it. His more recent presentations are focused on the presentation layer but he is skilled at working at all layers. This helps make his UI presentations more accessible even to programmers that do not work at the UI layer very often.
My interest in HTML5 has been sparked by Todd's presentation. During the presentation, he asked the audience to choose one technology and start using it today. I chose local storage. Local storage combined with manifests could help make web sites less vulnerable to spotty network connectivity. I expect it local storage will be a good launching point for other, sexier parts of HTML5.
Tuesday, May 24, 2011
Deliberate Practice for Expert Performance
I am reading SuperFreakonomics. In Chapter 2, they mention K. Anders Ericsson and his research on how "Deliberate Practice" is key to gaining expertise. SuperFreakonomics lists three key components of Deliberate Practice:
Ericsson also notes that deliberate practice has to be sustained to be effective. His paper cites a study of Morse code operators who hit a series of plateaus that seemed to indicate their performance had peaked. With sustained effort, the operators could restructure their work to overcome a plateau.
Programmers should use things like code katas or other regular deliberate practice to move towards expertise. An expert programmer, and especially a team of expert, can accomplish things faster or better than a group of normal programmers.
In the paper's conclusion, the authors note:
- Setting specific goals
- Obtaining immediate feedback
- Concentrating as much on technique as on outcome
Ericsson also notes that deliberate practice has to be sustained to be effective. His paper cites a study of Morse code operators who hit a series of plateaus that seemed to indicate their performance had peaked. With sustained effort, the operators could restructure their work to overcome a plateau.
Programmers should use things like code katas or other regular deliberate practice to move towards expertise. An expert programmer, and especially a team of expert, can accomplish things faster or better than a group of normal programmers.
In the paper's conclusion, the authors note:
Talent is not enough. Only through deliberate practice can we hope to achieve steller performance.We agree that expert performance is qualitatively different from normal performance and even that expert performers have characteristics and abilities that are qualitatively different from or at least outside the range of those of normal adults. However, we deny that these differences are immutable, that is, due to innate talent. Only a few exceptions, most notably height, are genetically prescribed. Instead, we argue that the differences between expert performers and normal adults reflect a life-long period of deliberate effort to improve performance in a specific domain.
Sunday, May 15, 2011
White Elephant Sizing Game
I went to a informal Open Spaces-type conference yesterday. It was my first time at this sort of self-organizing conference. I had a great time discussing common issues and finding common solutions with a bunch of sharp folks. One of the topics for the conference was a demonstration of a sizing estimation game called the "White Elephant Method". It is an alternative to the Planning Poker estimation game.
Like planning poker, the goal of the white elephant game is to get a quick estimate of the size of an agile project and the size of the individual stories before the project starts. The white elephant game attempts to do this in a way that can be reliably fit into a given amount of time and keeps the focus on getting the overall estimation done rather than disagreements on the sizing of particular stories.
Overview
The name "White Elephant" comes from the group gift-exchange game, also known as Yankee Swap. In place of gifts, the team has stories.
Each team member takes a turn. A team member is allowed a set amount of time to complete their turn, normally 30 to 60 seconds. During their turn, the team member may:
The game ends when all the stories are in a sized estimation category and everyone on the team passes.
The game's duration is easy to timebox. A rough formula is 2 x turn-duration x number of stories. If you have a turn duration of one (1) minute and thirty stories to estimate, you should be able to get a sizing estimate for all the stories in an hour. Some stories will take almost no time to estimate. Other stories or high-priority epics require more questions or interaction. Overall, they should balance each other out.
Components
In order to play the White Elephant sizing estimation game, you need:
Preparation
Play the Game
The product owner, or scrum master, gives the first story to the first player. Be sure to remind the player of the time limit. The sizing categories are relative, so any placement is the correct placement.
Move to each subsequent player in turn, offering a chance to place another story or move an existing story.
If a story bounces back and forth between two categories, it is in contention. Here are some ways to deal with contention:
A story may be too large to estimate or its estimate may be too large to work on in a single sprint. As normal practice, decompose the story into smaller stories, add them to the story deck, and continue the game.
Players will have a tendency to break the rule around talking amongst themselves. If the talking is leading to contention and arguments or is consuming too much, the team can remind them of the no-talking rule. Otherwise, the talking is probably not a big deal.
Analysis
The White Elephant estimation game should help the team estimate stories faster. It should also help the team feel more confident in completing their estimation work in a set period of time.
Introducing one story at a time helps limit the amount of uncertainty. The first player does not have to consider everything; he only has to consider one story. The complexity builds as more stories are added but the prior players' work help build "scaffolding" that helps the current player make their decision.
The no talking rule helps keep the interactions focused on product owner and team rather than a intra-team focus. It seems that the product owner/team member conversation is the more important during estimation exercises.
Like planning poker, the goal of the white elephant game is to get a quick estimate of the size of an agile project and the size of the individual stories before the project starts. The white elephant game attempts to do this in a way that can be reliably fit into a given amount of time and keeps the focus on getting the overall estimation done rather than disagreements on the sizing of particular stories.
Overview
The name "White Elephant" comes from the group gift-exchange game, also known as Yankee Swap. In place of gifts, the team has stories.
Each team member takes a turn. A team member is allowed a set amount of time to complete their turn, normally 30 to 60 seconds. During their turn, the team member may:
- Get a new story from the product owner and place it in an estimation category
- Move an already-placed story to a different estimation category
- Pass, if all the stories are placed and they are satisfied with the story placement
The game ends when all the stories are in a sized estimation category and everyone on the team passes.
The game's duration is easy to timebox. A rough formula is 2 x turn-duration x number of stories. If you have a turn duration of one (1) minute and thirty stories to estimate, you should be able to get a sizing estimate for all the stories in an hour. Some stories will take almost no time to estimate. Other stories or high-priority epics require more questions or interaction. Overall, they should balance each other out.
Components
In order to play the White Elephant sizing estimation game, you need:
- A product owner
- A scrum master
- A team
- A stop watch
- A story card for each story in the project
- A set of category labels including:
- Size estimates (1, 2, 5, 8, 13, 20, 40, 100)
- Uncertain (?)
- A place that can display the category labels and the estimated stories as they are added.
Preparation
- Post the category labels around the area in a logical order so the whole team can see the category labels and all placed stories
- Get story cards for each story. Put them in random order. Be sure to note the priority of each story on the card so it is not lost when the stories are reordered
Play the Game
The product owner, or scrum master, gives the first story to the first player. Be sure to remind the player of the time limit. The sizing categories are relative, so any placement is the correct placement.
Move to each subsequent player in turn, offering a chance to place another story or move an existing story.
If a story bounces back and forth between two categories, it is in contention. Here are some ways to deal with contention:
- Remove the story under contention and place it on the bottom of the deck
- Move and lock the story into the larger of the two categories
A story may be too large to estimate or its estimate may be too large to work on in a single sprint. As normal practice, decompose the story into smaller stories, add them to the story deck, and continue the game.
Players will have a tendency to break the rule around talking amongst themselves. If the talking is leading to contention and arguments or is consuming too much, the team can remind them of the no-talking rule. Otherwise, the talking is probably not a big deal.
Analysis
The White Elephant estimation game should help the team estimate stories faster. It should also help the team feel more confident in completing their estimation work in a set period of time.
Introducing one story at a time helps limit the amount of uncertainty. The first player does not have to consider everything; he only has to consider one story. The complexity builds as more stories are added but the prior players' work help build "scaffolding" that helps the current player make their decision.
The no talking rule helps keep the interactions focused on product owner and team rather than a intra-team focus. It seems that the product owner/team member conversation is the more important during estimation exercises.
Thursday, May 12, 2011
Getting things done with a tomato
I want to be more effective at getting things done. I already use a daily task list but it does not seem to be effective. On the other hand, most time-management processes seem to be more work than they are worth.
Recently, I read an e-book about a simple time management process called the Pomodoro Technique that Matt Sell pointed out to me. It has the organization and task timeboxing I want without a lot of overhead. It only requires a timer, some paper for lists and the e-book. Better, yet the e-book is free to download.
I am going to try the Pomodoro Technique for a month and then review how I am doing.
Recently, I read an e-book about a simple time management process called the Pomodoro Technique that Matt Sell pointed out to me. It has the organization and task timeboxing I want without a lot of overhead. It only requires a timer, some paper for lists and the e-book. Better, yet the e-book is free to download.
I am going to try the Pomodoro Technique for a month and then review how I am doing.
Tuesday, May 10, 2011
Hands-On Coding Tonight
Hands-On Coding meets tonight. The exercises cover parallel extensions generic delegates. I have not had a chance to use those in production. I want to build some "muscle memory" around the parallel extensions and hope this helps.
The group filled the room. Rob Vetter was prepared and offered excellent examples. The examples were targeted at a more basic level than I'd like but it suited the group. I had to leave early because of a work commitment.
Hands-On Coding meets the 2nd Tuesday of every month from 6-9 pm at Improving Enterprises. It is open all skill levels. It gives developers a chance to learn new concepts by writing code. Be sure to bring your laptop.
The group filled the room. Rob Vetter was prepared and offered excellent examples. The examples were targeted at a more basic level than I'd like but it suited the group. I had to leave early because of a work commitment.
Hands-On Coding meets the 2nd Tuesday of every month from 6-9 pm at Improving Enterprises. It is open all skill levels. It gives developers a chance to learn new concepts by writing code. Be sure to bring your laptop.
Todd Anglin on Building a Testable Data Access Layer
On May 3rd, I saw Todd Anglin present "Building a Testable Data Access Layer" at the Dallas C# SIG. His talk focused more on good design for data access and keeping the UI and other non-DAL areas free of data access dependencies. Once this is accomplished then mocking the data access is much easier. Building tests almost becomes an afterthought.
Todd is an engaging speaker with the ability to communicate about important concepts in simple terms. I recommend reading his materials for this presentation. I think it was recorded as well. If they post the recording, I recommend watching it as well.
Todd is an engaging speaker with the ability to communicate about important concepts in simple terms. I recommend reading his materials for this presentation. I think it was recorded as well. If they post the recording, I recommend watching it as well.
Subscribe to:
Posts (Atom)