Agile Winnipeg Inaugural Event - "Shorten the Distance"

It was pretty exciting for myself and the other organizers to see a packed room of over 60 people attend the first Winnipeg Agile User Group event on Thursday, March 10, 2011. After a quick meal from Homers and some furniture re-organization, we kicked off the event with a word from several of our sponsors. Wadood Ibrahim spoke on behalf of Protegra and recalled giving a presentation to the local PMI group 10 years ago about agile techniques that was not well received and was delighted by the turnaround of opinions and interest 10 years later.

For the main presentation, Doug Kok and I split the attendees into groups of about 15 people and led them through the ball point game. The ball point game is a simple and fun exercise that allows teams to think about process * people through team decision making and the power of reducing hand-offs. Here are a few images from the event:

Team 1 Discussing their strategy



The scores of the game. Notice the significant improvements from most teams. Team 3 forgot to count during the last iteration, but based upon the process they were using, I think they would have surpassed their estimate of 160



And, thanks to Doug - here is a brief video summary of the teams playing the game: 


So how does the ball point game relate to agile? In both the ball point game and in software development, improvements in speed can be gained in similar ways:

• Focus on reducing hand-offs by having face-to-face conversations, dedicated teams, shortening the distance between a requirement and its implementation, a question and its answer, etc.
• Stop frequently to determine how to go faster.
• Measure your experiments through velocity and frequent feedback.
• Value and encourage cross-functional, de-centralized, self-organizing teams.

Homework: To take this further, read the 12 principles in the Agile Manifesto and think about how each of the 12 could be re-stated as a way to reduce handoffs, or as shortening the distance between [A] and [B]. Also, to see how these ideas can work in the 'wild', read this case study on facebook.

To close the event, we held a short open Q&A session. Some of the questions we discussed were:
 1. Can you do agile without TDD (Test Driven Development)
 2. When/how do you do requirements?
 3. How do you control scope creep when you aren't defining the requirements up front?
Lively discussion continued over drinks at Triple Bs on Scurfield.

Based on the survey responses, the top 3 categories for future event topics were Agile Testing, Agile Adoption, and Agile Estimating.

Finally, on behalf of the organizers I would like to thank you for participating and thank the sponsors for allowing this event to occur. To register for future event notification, please click here.

What I learned about agile teams from 8/9 year old girls basketball

I am a very fortunate daddy. I am one of the coaches for my eldest daughter's basketball team. The community league she plays in has a rule designed to promote team work that at first glance may seem counter intuitive - "No double teaming". This means that in most circumstances when playing defense each girl must cover her own 'check' and can not help out her teammate. To explain this a little more, I'll give you two examples.

Example 1 - double teaming:

Mary is new to basketball and is tentatively dribbling the ball over half court. Ann is playing defense on Mary and is doing a pretty good job of limiting where Mary can go and who she can pass to. Laura is a very strong player on Ann's team and notices that Mary is struggling and that she has an opportunity to make a play. Laura leaves her own check, runs over to Mary (who is now double teamed), steals the ball and races to her own basket where she scores an easy two points. Her team cheers loudly.

Example 2 - helping:

Amber is an experienced basketball player and is dribbling the ball over half court. Kari is playing defense on Amber but is having trouble limiting where Amber can go and who she can pass to. Deanna is a very strong player on Kari's team, but because she is not allowed to double team, she does not immediately race over to help Kari. Amber makes a quick move that allows her to get past Kari and race towards the basket. At this point, Kari knows she is in trouble and yells 'help'. Deanna races over and gets in front of Amber to slow her down just enough so that Kari can catch up. Once Kari has caught up, Deanna races back to her own check and Kari resumes playing defense on Amber. No baskets are scored and mild applause is heard.

The nature of community led basketball leagues is that there is a combination of inexperienced but willing coaches and inexperienced but willing referees. This means that most times example 1 occurs without the ref or the coach interfering. While our team has been mostly executing as example 2, many of the teams we play against have been executing mostly as example 1.

Over the course of the season, the result has been interesting. Teams that were beating us at the beginning of the season by taking full advantage of the skills of their best player through double teaming are now struggling to even have a chance to score against our girls. The girls on those teams are trying just as hard, but the double teaming strategy that worked so well early in the season is no longer effective.

We have a team of 10 girls who have each improved. Some of the girls are more skilled than others, but each girl has improved noticably from the beginning of the season. The net effect is that our team has also improved noticably from the beginning of the season. Maybe more importantly, this team supports each other, learns from each other, and trusts each other.

Note: It would be easy to credit our brilliant coaching strategy, but that would clearly discount the effort, teamwork, and skill of the girls on our team. They are a wonderful group.

The parallels for agile teams are pretty clear to me. If you expect your team to perform at a high level, you need to let them improve at every role and reinforce team ownership of the project.

• If you are the PM, don't take sole responsibility of the budget, tasks, project goals etc. Make these visible to your team and help your team own them and make decisions about tasks and priorities together.
• If you are the DBA, don't get upset when the database design is insufficient, teach the team how to improve their design the first time. Work with them rather than 'fixing' their work later.
• If you are a tester, don't assume full responsibility for testing, teach your team how to be better testers by testing every day and pair testing with the developers.
• If you are the UI expert, involve your team when designing the UI. Lead the exercise, but don't steal the design for yourself.

Of course, the converse of all of these is also true:

• If you are a developer, take responsibility for the budget and priorities
• If you are a tester, learn how to code a little
• etc.

There are other lessons to be learned from 8/9 year old girls basketball, like how to ask for help when you need it, but those are for another day.

Occasionally I meet former co-workers who inevitably ask me what I'm doing. When I announce my agile and lean passions and talk even briefly about the differences between traditional teams and agile teams, I often am greeted with a response something like "But someone still has to manage the team and the budget right?" My answer is usually "Yes, but it doesn't need to be you anymore. It should be the whole team."

As the African proverb says, "If you want to go fast, go alone. If you want to go far, go together."

Quit your belly-aching and try it!

I get a little frustrated whenever I hear people say things like:

"[Agile Practice X] is [insert doubting words here], prove it to me that it [is better/is more efficient/is cost effective, etc]".

Built right into agile is your own little test lab where you can try it yourself without needing the official research study.

1. Execute in iterations to determine your velocity.
2. As a team, determine to try [Agile Practice X] for one or two iterations.
3. See if your velocity went up or down and reflect on the results.
4. Decide whether or not to keep [Agile Practice X].

So, as I have often heard my dad say: "quit your belly-aching" and try it already!

Iterative Development and User Story Slicing

You may have seen Jeff Patton's slides showing iterative vs. incremental development using the Mona Lisa as an example (slides are here, page 80, 81). Iterative development suggests that you build each feature from the ground up increasing the subjective quality of each feature with each user story that you implement. This method is important for allowing you and your team to narrow in on the final solution rather than designing and understanding it all up front. It also allows you to deliver a full featured application earlier and to use methods like trim the tail to optimize your available budget vs the value that the project is delivering.

Here is a quick discussion on Iterative vs Incremental development:

The diagram to the left shows how a project could be completed using Iterative or Incremental development. In both cases, iterations were used to develop the list of features, but in iterative development we build each feature up a slice at a time rather than a feature at a time. Some of the advantages of iterative development are that it:

• Allows you to validate your architecture and solution early
• Allows users to see and test the whole application early
• Minimizes the affects of change to a feature
• Ensures important stories are built first
• Elicits improved feedback on the whole application early
• Allows you to deliver your application early
• Discourages "gold plating"
• It partners nicely with user story mapping (turn the diagram upside down and you have your story map)

Some of the disadvantages are:

• Your code and design has to be change tolerant
• You have to be proficient at slicing your user stories
• You won't know the final solution at the beginning of the project

User story slicing is an important technique in iterative development, but what does this look like in practice? Using Jeff's Mona Lisa pictures as a pattern, I've created a few images that show how a feature like "Send Email" could be completed iteratively.

The first story slice is simply a form with little or no validation with text boxes To, Subject and Body with Send and Cancel buttons. When the user fills in the text boxes and clicks Send an e-mail is sent provided the e-mail addresses entered are correct. But, this e-mail has no extra features like support for HTML formats, RTF, attachments, e-mail priorities, etc. Once this story is implemented, the team will implement similar slices of each feature for Read Email, Create Appointment, View Calendar, Create Task, Edit Task, Create Contact, Edit Contact, etc in order to create a minimalist working model of the whole application.

The next slices of this particular feature would be to implement stories such as implementing Carbon Copy (CC) and taking e-mail addresses from your contact list. You can also see that the form has changed slightly - the Cancel button has been removed and the Send button has been moved to the top.

As we continue to iterate through this feature by adding story slices, the form takes additional shape, adding tool bars and tool bar items. At this point, the application may be finished enough to release to production and start earning revenue for the organization while we continue to add new features and use that revenue to help fund the remainder of the project.

A further release with more story slices implemented:

The final release:

Iterative development is an important tool in your agile toolbox to help your teams deliver early and adapt to change while keeping the project's end goals in mind. User story slicing is one of the important techniques you can use to help make this happen.

Want to receive future blog posts in your inbox? Enter your email address here.

For lunch - an agile story

The speaker list for PrairieDevCon 2011 was published today and I'm really looking forward to it. Some great speakers and talks are lined up and D'Arcy Lussier as always will arrange for some great food. But... let me tell you a story of what might have been at PrairieDevCon 2010.

In the spring of 2010, D'Arcy Lussier (the conference organizer) and I were talking about the conference and he confessed to me that he was trying to cut costs. We brainstormed some ideas and prioritized them using a risk assessment matrix. Just before D'Arcy brought out his MS Project gantt chart, I suggested a new idea - Why don't we make the food ourselves! Knowing my reputation as an accomplished food critic and noted chef, D'Arcy quickly agreed and called the hotel to cancel his lunch orders.

I took on the responsibility of planning the meal in advance; purchasing and delivering the ingredients from the finest markets in Regina. The morning of the first day of the conference, D'Arcy and I met in one of the unused conference rooms to prepare the meal. We knew that our gourmet Ham & Cheese sandwhiches would be a huge hit.

Here was our work break down structure (straight out of MS Project)

Task Name	Start	Finish
Setup 8 preparation tables	8:15am	8:30am
Open 100 loaves of bread	8:30am	8:40am
Layout individual bread slices on the tables	8:40am	9:10am
Spread gourmet mayonaise on the even slices of bread	9:10am	9:30am
Spread garlic butter on the odd slices of bread	9:30am	9:50am
Put smoked ham on top of the even slices of bread	9:50am	10:10am
Put Trappist Monk Cheese on top of the even slices of bread	10:10am	10:30am
Put 3 slices of pre-smoked bacon on top of the even slices of bread	10:30am	10:50am
Put Emerald Frizz lettuce on top of the even slices of bread	10:50am	11:10am
Put the odd slices of bread on top of the even slices of bread to create each sandwhich	11:10am	11:30am
Put a toothpick topped with an olive through the middle of each sandwhich	11:30am	11:50am
Test the sandwhiches	11:50am	12:00pm
Serve!	12:00pm	1:00pm

We proceeded and followed this plan to the tee (our project manager would have been proud!). As it turned out, our estimates were fantastic and we started the testing phase at exactly 11:50am. Both D'Arcy and I eagerly grabbed a sandwhich, took a few pictures to put on twitter and took a huge bite. It was... awful. It turns out that my mayonnaise supplier gave us some really rancid mayo. Each and every sandwhich was ruined.

Fortunately, when we sheepishly went to report this to the catering staff at the Delta, they kindly informed us that they were pretty sure we would fail and had prepared a wonderful lunch anyways. So, the attendees were spared, and D'Arcy and I graciously thanked the Delta for being such great hosts.

The lesson? If we wouldn't make lunch that way, why would we create software that way? Instead, shorten the distance between a possible problem and its resolution by frequently delivering working software and testing every day. First-Time-Right for the win.

Enjoy your lunch! Hope to see you at PrairieDevCon.