Winnipeg Agilist

Sea Star Wars: A lesson in organizational change

2012-01-24T14:49:00.000-06:00

Sometimes in order to make a change happen, all you need to do is change the environment.

This summer I witnessed a great example of this in a small but fantastic aquarium in Ucluelet, BC. When you see a sea star in the ocean or at the aquarium, you rarely or if ever see them move. However, the staff at the aquarium instigated a sea star race by changing the environment. They put the feared Morning Sun Star in the same tank with other sea stars including the very large Sunflower Sea Star. Once the other sea stars detected the presence of the Morning Sun Star they all started to move away from it as fast as they could. The sudden reactions and speed of those sea stars was a sight to see – a turtle would have been proud!

If you have analysts, developers, testers and users who don’t communicate very well you can help encourage better communication by changing the environment. Create a co-located space and then have them all work in that space together. The environmental change forces them to acknowledge each other’s presence and begin working together. Instead of “Hey, there’s a dangerous Morning Sun Star in here and I have to run away before it eats me”, you should get reactions like “Hey – there’s a user in here, I guess I’ll show them the changes I’m making to this screen to get some feedback”.

Subscribe to Winnipeg Agilist by Email

SOPA Blackout

2012-01-18T00:30:00.000-06:00

I couldn't find a SOPA gadget for blogger, so in solidarity with all the other blackouts today here is a link to an article on why SOPA should concern you:

http://blog.reddit.com/2012/01/technical-examination-of-sopa-and.html

Here is the conclusion of that article:

"In Conclusion

It is my strong belief that both PROTECT IP and SOPA:

Will not stop the piracy they are targeting
Contain language that is highly ambiguous and extremely broad making them ripe for abuse, and
Introduce regulation and enforce censorship on what should be a free and open internet."

Estimating tasks in hours is local optimization. Stop doing it!

2012-01-15T22:56:00.001-06:00

This weekend I was listening to Eliyahu M. Goldratt's "Beyond the Goal" where he expands on the Theory of Constraints. In chapter three I listened to him explain how estimating in hours is in fact local optimization and therefore "idiotic". Here is a portion of that chapter loosely transcribed:

"The way to ensure that the project will finish on time is to ensure that every task will complete on time. This is the local optima policy that leads to a huge conflict. Placing a person on such a project jeopardizes the most important thing for them - their own image.

Suppose you are this person and you are asked how much time will this task take? You are extremely reluctant to give any number. And when you give that number the Project Manager will try to squeeze it. Why are you reluctant? Because you know that the number you give is an estimate but that it will be converted to a commitment - because the project needs to finish on time.

So what situation does this place you in? This common procedure of turning estimates into commitments puts you into a huge dilemna. Why? The objective of every person is to be regarded as a reliable person by your boss, by your peers, by people. But what is the meaning of being reliable? For example, if you give a commitment and you don't meet it - once is ok. But if you give a commitment and many times don't meet them do you expect to be regarded as reliable? Of course not. So one of the conditions of being a reliable person is to meet your commitments.

Also - if you are fighting for something (an estimate) and then it turns out that you have exaggerated by a mile? If it happens once, fine. If it happens frequently, then you will get the name of someone who exaggerates wildly - so kiss goodbye the image as someone who is reliable. In other words, another consideration for being a reliable person is to not be considered as someone who exaggerates. Now look what is happening when I come and ask you how long it will take to finish this task?

Now look - whatever you do, you are doomed. This is a huge personal conflict. How do we in reality deal with this conflict? Let's face it - this conflict is so important we must find a way to break it. We want to not only be reliable, but to be considered reliable. How do we do it? We cheat.

So we finish our estimates on the nose and sometimes a little more. They become self fulfilling prophecies. If there is a danger of finishing too quickly we add some more tests, do a more thorough job, we add another function in, we check things a little more thoroughly, and we finish on the nose. Do you see what's happening?

Due to the result that our local optimization turns any estimate into a commitment, we have developed the habit of giving estimates which includes in it the safety. If murphy (i.e. Murphy's Law) doesn't hit, we waste the time rather than giving it to the next link in the chain or project. If we do give it to the next link then we are declared as exaggerating and next time they won't give us the extra time. So look what a horrible situation this is. And this... is what kills the project. This is totally idiotic"

When you read this story the first time you will likely notice there are several examples in there of how not to run a project, of poor leadership, and his concluding statement is a little harsh. As many commenters have pointed out, this style of project management is not similar to how we typically run agile projects. However, at the core of the story is the desire of each person to be reliable by meeting hourly estimates whether they are created by the team, by yourself, or by someone else. When I first listened to this argument I was fascinated by that part of it. So, if that part of his argument is correct, then what alternatives do we have if we need to estimate? (This paragraph has been updated based on the comments - thank you)

If your project requires an estimate:

Stop estimating tasks - hopefully the argument above has already led you to this conclusion.
Don't estimate user stories in hours or convert relative points to hours. OK - I do understand that it can be valuable to look historically at hours vs. points, but don't use this conversion for guessing how long a task or user story will take.
Where possible, avoid asking how many hours are left for a task or user story. I understand why and how this information can be valuable, but understand the risk you take when you ask this question.
If possible, estimate at higher levels (epics) rather than lower levels (user story).
Give broad project estimates with ranges like 1-2 months, 3-6 months, 1-2 years instead of doing detailed estimates. Most projects don't need a detailed estimate in order to determine if they should be completed or not. For many projects on our list we already have a good enough guess about their size to understand their value compared to the cost. (Unfortunately, as a consultant that usually doesn't include the projects I work on).
This logic also suggests that relative estimating might be dangerous. I still have to think about that one as there are significant benefits to exercises like planning poker even if estimates are not created as output.

If your project does not require an estimate:

Do a little song and dance!

In either case, continue to break down your project into smaller projects and small deliverable pieces of value and working code. Build the high priority pieces first in an iterative fashion. Make a decision about whether the project is done after each completed story or each iteration to avoid the problem described above - the temptation to finish on your estimated completion date. Continue measuring your progress using completed stories but consider using cycle time (average time to completion for all stories) vs. velocity (average number of points completed in a given time frame) to avoid some of the local optimization that could occur for each user story.

For further reading on the Theory of Constraints, check out any of Goldratt's books. I highly recommend starting with The Goal which is also available on iTunes Canada as an audiobook for $2.95.

Subscribe to this blog by Email

Silent Brainstorming

2012-01-09T10:11:00.002-06:00

I read an interesting article earlier this week that summarized some of the latest research on brainstorming. The research found that group brainstorming (out loud) doesn't restrict the amount of ideas generated, but it does restrict the variety of ideas. By contrast, brainstorming as individuals allows a greater variety of ideas to be generated. They also found that once the ideas were generated, having a group discussion about the ideas was beneficial in order to combine and improve upon the ideas. Here are some interesting quotes:

"Cognitive fixation causes people to focus on other people's ideas and are, inevitably, unable to come up with their own."

"If the goal is to come up with a bunch of unique ideas or solutions to problems, then the group should be split up so that individuals can come up with their own ideas and these ideas can later be combined with other members' ideas."

"...a group session after an individual session might be the optimal brainstorming technique."

So how can you combine both individual and group brainstorming? Here is an approach that I have been using that I've put together based on my experiences facilitating and participating in other sessions. This approach can be used for any brainstorming session whether you are trying to generate user stories, ideas for a retrospective, or strategies for your community group.

Step 1: Establish the goal.
Make sure everyone understands the purpose of the brainstorming session. For many sessions this can be communicated to attendees before the meeting begins.

Note: If your group is larger than 10, I would recommend splitting the group up into several smaller groups for steps 2 through 5. The groups can present their best ideas to each other at the end of the exercise and re-open the discussion and voting at that point if appropriate.

Step 2. Individual (and silent) brainstorming.

Hand out post-it notes to everyone in the group. Ask each person to write down one idea per post-it until they run out of ideas. This part of the session should be performed in silence. There are a few cues to look for to understand when the group is done but the most consistent one I use is to watch their body language. When most of the group is leaning back or looking up, they are probably done. If you are having trouble reading their body language, a good rule of thumb is to wait until most people have at least 3-5 ideas written down. Also - be prepared with extra post-it notes in case someone runs out. I once had a participant say "I stopped thinking when I ran out stickies" ;).

Step 3. Describe your ideas
Once everyone has finished writing down their ideas, choose one person and ask them to describe their best idea and then place that post-it on the wall or the table. Continue going around the table asking each person to describe their top one idea until all ideas have been presented. It should take several rounds and each person will have the opportunity to present several ideas - one during each round. While the ideas are being described encourage everyone to keep writing additional ideas down. This allows the group to combine and improve upon ideas presented by others.

Step 4. Group the ideas
There are several ways to group the ideas depending on your group size.

a) If your group size is five or less I prefer using silent affinity grouping because it is fast and collaborative. Ask your team to silently group the ideas. Things that are similar to each other should be moved closer to each other. Things that are dissimilar to each other should be moved farther apart. Groups should form naturally and fairly easily. Once again, body language will help you see when they are done - usually 2-3 minutes.

b) If your group size is more than five I prefer to have one person group the post-its as they are presented because it is faster. Simply put the post-it near other post-its with similar ideas.

Once the groups are created you can name each group with a short title.

Step 5. Silent Voting
If you need to vote on the ideas or on the groups, I prefer using silent voting. Number each post-it and then ask each person to write down their top three on a post-it. Once all the votes are in, tabulate the votes to identify the top ideas.

Summary
This method of brainstorming combines the best of both individual and group brainstorming techniques and is consistent with the latest research. However, I initially started using it not because it conforms to the latest research but because it allows everyone to have a voice - the loud people can't dominate the conversation and the quiet people are given a way to contribute. That it reduces the effect of cognitive fixation when generating the initial list of ideas is an added benefit.

References:

User Scenarios and Lean Solutions

2012-01-06T10:23:00.000-06:00

After reading the book Lean Solutions a few years ago it was easy to see that agile methodolgies are "Lean Solutions" in comparison to traditional methodologies, but I wondered how we could apply that knowledge to design and build Lean Solutions for our clients (yes, you can still build bad systems with agile). User Scenarios are one tool that can help.

Well written user scenarios put all the 'features' into a flow that is relevant to the user's value stream. They can help us design a solution as a unified value stream rather than just a bunch of features put together. From Lean Solutions:

"Companies must provide the goods and services consumers actually want, when and where they are wanted, without burdening the consumer."

For more information and an example, check out Jeff Patton's stickyminds article.

Is agile suitable for all projects?

2011-12-15T08:55:00.000-06:00

At some point in your agile journey you begin to ask and/or hear this question: "Is agile suitable for all projects?"

Here are some of the responses I've heard from both those who are still learning about agile and those who have a lot of agile experience:

Agile isn't necessary when you have a known problem and a known solution.
Agile doesn't work in regulated environments.
Agile doesn't work in government.
Agile can't work in a large enterprise.
etc.

In my opinion and experience all of these answers are borne out of legitimate concerns but none of these responses are valid. Let me explain why.

One of the significant differences between traditional projects and agile projects are the short feedback loops. These short feedback loops allow teams to validate assumptions sooner, identify and deal with risks and issues sooner, find and correct defects sooner, and deliver a solution sooner. Agile will be implemented differently based on the project types identified in the responses above, but I believe that all projects will benefit from agile's short feedback loops. To say otherwise assumes that we always get it right the first time - even in the uncommon situation where the solution is 100% known, we get everything right the first time about 0% of the time. Agile helps us discover that sooner so that we can correct our mistakes.

Additionally, any project can benefit from increased trust amongst team members, increased trust between teams and customers, increased trust between teams and management, and increased trust of project status.

In my opinion and experience, the only question you need to ask has nothing to do with the type of project, the type of problem, or the type of solution. Instead, here is the key question:

Does the team want to use agile and have the support to do it?

If the answer is yes, then it can work. If the answer is no, it is not likely to work.

P.S. Here are some examples of agile being used in projects and organizations where "agile won't work":

Agile in a regulated environment.
Abbot Labs experience report - Development of a nucleic acid purification platform and companion real-time analyzer
Agile in a Regulated Environment - Linkedin Group

Agile in government.
Public sector case study - Social Security domain, software to support change in legislation.
Manitoba Parks Reservation Service - Agile case study as told by Terry Bunio.

Agile in a large enterprise
The agile experience at John Deere's Intelligent Solutions Group.- presentation by Chad Holdorf at Much Ado About Agile VI - Vancouver 2011.
Plus an article talking about the John Deere agile experience. "I figure if John Deere can test working software every two weeks on a tractor in a field, then Agile will work anywhere."

Agile with a known solution and a known problem
I recently completed a project with a known solution and a known problem - converting a VB6 application to dotnet "as is". We used agile and the project was very successful.

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

Making the undesirable desirable - a lesson from Tom Sawyer

2011-11-30T07:41:00.001-06:00

Today's Google home page celebrates the birthday of Mark Twain with images that tell the story of Tom Sawyer convincing his friends to whitewash his fence for him. It is an example of making the undesirable desirable. You can read more about the story on wikipedia and here are some pictures of the story courtesy of google:

Tomorrow an article I wrote on Agile Adoption will be published by InfoQ. One of the strategies and patterns for change in that article is to "make the undesirable desirable". Here is an excerpt from the article:

"A colleague of mine recently experienced some resistance from his team when he asked them to try pair programming. Instead of forcing them to do it, he simply asked ”What would it take to get you to try it?” When they joked that they would gladly try it if they had a big screen TV to use for paired programming, he quickly obliged and the rest was history. The new behaviour became fun – it became desirable."

Although Tom used this strategy for selfish gain, this strategy can also be used to affect positive change in your organization. You can find more strategies and examples useful for your agile adoption in the InfoQ article.

An alternative to bug tracking tools

2011-11-14T08:43:00.001-06:00

One of my pet peeves is working in and with bug tracking tools. I am well aware of some of the arguments for the importance of these tools and I am not trying to address those here. Instead, I'll show you an example of an alternative that I have found useful.

First, using an approach like Specification by Example can reduce the need for bug tracking tools because communication goes up and defect counts go down. But even using this technique, defects still occasionally occur. Here is an example of how to use Specification by Example not only for 'requirements', but also for defects.

In June of this year I spoke at the Prairie Developer's Conference in Regina, Saskatchewan. Some of the speakers and volunteers were involved in creating the website, services, and mobile application for that conference. Since I was doing a Specification By Example talk I decided to use the conference web services to illustrate how easy it is to create your first automated test against a web service using FitNesse. As I was working with the services I found a small defect. Instead of writing up a defect in a bug tracker with the steps to re-produce it, I wrote a test in FitNesse to confirm the defect:

This example calls a service that returns a list of sessions and does a few basic C# calculations on that list. It counts the number of sessions (allSessions.Count) in the conference and FitNesse maps that to the NumberOfSessions variable above. It then counts the number of unique abstracts (allSessions.Abstracts.Distinct.Count) and FitNesse maps that to the Number of Unique Abstracts. FitNesse then compares the numbers and displays the results. In this case, 63 does not match 62 so it displays an error with the expected and actual results as above.

Once the test confirmed the defect, I simply communicated the failing test to the developers. When the developers reviewed the test they could clearly see what the problem was. No back and forth was required to understand the issue or to confirm the steps required to reproduce it. No one had to set the status of the defect to "working", "fixed", "duplicate", "resolved", "more information required", or anything else. One of the developers fixed the issue and even added an additional service that we could call to address the root cause - Are Session Abstracts Unique? I added the new test, ran all my tests again and was pleased to see them all go green.

This process improved communication between tester and developer, ensured that the defect would always be tested and re-tested for, and kept us from spending unnecessary time in a bug tracking tool.

Are we agile yet? Applying fuzzy logic to the manifesto

2011-10-05T10:49:00.000-05:00

Some background on logic from my brother who is a math professor:

In Greek logic (the logic of Plato and Aristotle) there are only two truth values. Any statement is either true, or false, but not both. Truth is absolute. This works nicely except for when we say things like:

"This sentence is false"

If this statement is true, then it is also false, and if it is false, then it is also true, and if it is true, then it is also false - a 'fun' logical circle which causes trouble for Greek logic. This liar's paradox was ignored for about 2500 years. Since sentences are either true or false, then the sentence above obviously isn't a sentence. Case closed.

In the last century, mathematicians started to realize that things were not so simple. A quote from my brother:

"There are contradictions in the laws of physics – We have Einstein’s relativity that explains planetary motion, gravity, all these big things. And we have quantum mechanics that explains subatomic energy and matter, all those tiny things. Unfortunately, they contradict each other in the middle. Because the one requires physical reality to be absolutely smooth and continuous, while the other requires quantum bumps, which are profoundly non-smooth and discontinuous. Right now the laws of physics are both true and false (and by false, I mean true.)"

More common examples of statements that can be both true and false include: "I am young", "I am tall", and of course, "We are agile". Truth becomes fuzzy. The truth of those statements can lie somewhere in between absolutely false and absolutely true depending on who is saying them.

"A newborn is young" = truth value of 100%.
"A 20 year old is young" = truth value of 80%

Thus, fuzzy logic was born. Statements can have a truth value in between true and false.

Now let's apply this to the question "Are we agile yet?" by looking at the four tenants of the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Many of us have read articles or have been in discussion groups where these statements are discussed at length and usually someone tries to apply Greek logic by making statements such as: "Agile has no documentation" and "Agile means no planning". However, the word "over" in the middle implies that fuzzy logic is at work. The manifesto authors are saying that for agile teams truth should be closer to the left than the right. We should focus more of our time on working software and less of our time creating documentation. Planning is still important but responding to change is more important so our plans need to be more flexible. For each statement, we want the left side to be more true than the right - the truth value should be above 50%. Additionally, having a truth value of 100% for any of the statements above can be a dangerous thing. We should stay fuzzy.

So when answering the original question for your team or organization - "Are we agile yet?" - don't expect a checklist of practices to give you the answer. Instead, ask your team this question: "Given the statements above, which direction are we moving?" If you are moving to the left and have committed to staying on the left side of each equation, then you've joined the club - you are agile. Agile is a direction, and that is absolutely true.

My brother Tim's bio: http://www.cmu.ca/facultystaff/trogalsky.html

A short story about co-location

2011-09-29T10:35:00.000-05:00

The post I created yesterday reminded me of this story:

A team I was working on was asked to sit together in a rather cramped area. Five of us (two developers, one application architect, one tester, one business analyst) were asked to share a very small area about the size of a typical office. The business analyst had desk space equivalent to the size of a typical end table; there were monitors perched precariously above us on small shelves; we shared one phone; and the limited wall space we had was covered with our visible boards and stickies. Fun!

As we reflected on our space at the end of the project, this comment was made from one of the developers: "On the bright side, I don't think I looked at the requirements document once. I just turned to the business analyst beside me and asked her what needed to be done!" Co-location for the win.

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" - Agile Manifesto

Strategizing to solve a communication problem

2011-09-28T09:58:00.000-05:00

My wife spent part of this past weekend on a leadership retreat. Her team was asked to participate in the following game to help them develop their team strategy and communication skills:

Setup:

One person acts as a builder.
One person acts as the architect.
Two people are observers.
The builder and architect sit back to back in chairs. The two of them are not allowed to look at each other, but they are allowed to talk.
The two observers stand on either side and watch and are not allowed to talk or interfere in any way.
The builder is handed a blank piece of paper and some shapes that have been cut out.
The architect is handed a drawing where the shapes are already put in place - the blueprint.

Playing the game:

Round 1

The architect's job is to have the builder re-create the drawing by putting the shapes in the correct placements on the blank piece of paper. The architect is not allowed to turn around, but is allowed to talk.
The observers are instructed to watch - no talking or gesturing.
The builder is also not allowed to turn around but is allowed to talk.
Time how long it takes for the team to correctly finish replicating the drawing.

Rounds 2-n

A rule change: For this and any subsequent rounds the observers are allowed to 'tap in' during the round. That is, when they tap the architect's shoulder they can trade places with the architect who then becomes an observer. You can 'tap in' as many times as you want during the round.
Before starting the round the team is asked to strategize together on ways that they could improve their communication and their results.
Once again the team times how long it takes for them to correctly finish replicating the drawing.

The teams enjoyed the challenge of working together to improve their communication strategies. The best solution that any team found was to have the observer 'tap in' whenever the builder put one piece in the correct spot. This strategy enabled the builder to easily understand when they had done something right (improving communication) and helped the team to improve their time. Hurray for the team!

This was a great exercise to promote team building, continuous improvement, strategizing, and to encourage the team to actively work on their communication skills. It reminds of some of the ways I have seen and used to help teams improve communication between roles. Does the developer have a hard time understanding the requirements document? Let's work on our documentation skills to make our writing clearer. Does the team struggle to meet it's project deadlines? Let's increase the project management rigour and status reporting. Are bugs found during user acceptance testing? Let's write a better test plan.

Or... have the architect (customer/business analyst/tester/project manager) turn around and talk to the builder (developer) directly. Break the rules (and your cubicle walls). Shorten the distance.

The role of a business analyst in agile

2011-08-09T01:06:00.001-05:00

I ran into Kevin Brennan tonight at #agile2011. I was glad for the chance to talk to him because I've received quite a few questions from BAs in Winnipeg about how their role will change when they work on agile projects and Kevin has been doing a lot of work with the agile extension to IIBA's BABOK.

Here are is a summary of our conversation:

How many BAs can articulate the goals and objectives of their company, team, or project? Start here if you cannot.
Even if you are able to articulate the goals and objectives - can your team? Without understanding the project goals and objectives the team doesn't have enough information to help them make decisions about scope and priorities and often makes decisions based on 'Is this helping somebody?' which can increase the scope of the project.
BAs can help facilitate the alignment of priorities and goals - enabling the business to speak to the development team with one voice.
Facilitate requirements and a common understanding of the proposed system through inclusive modeling techniques (eg. user story maps, silent brainstorming, product box - see more here)
Facilitate the acceptance of change (rather than the restriction of it).
BAs don't do any less analysis, but they will end up doing less documentation. This reminds me of this tweet:
“Documents we write communicate our good thinking. You can write one without thinking. You can communicate good ideas without a document.” – Jeff Patton (Jan. 19, 2011 - twitter)
As a BA, if you need to create a document, it will more likely be after the story is complete rather than before creating the story. Some additional guidelines for documentation on agile projects can be found here.

Plus, here are a few more that I thought of after our conversation:

Collaborate with testers who share many of the same concerns about priorities, goals, scope, and requirements.
One thing that doesn't change is the need to work with the business as any software produced by the team may change the business processes. Even with iterative delivery, there will be adjustments to be made.

If you have others to add or even disagree with some above - please comment or find Kevin or myself during the conference and we'll chat.

Agile Adoption - 6 Influence Strategies

2011-08-05T08:41:00.001-05:00

The vital behaviours for successful software projects (agileor not) are simply these: a) improvecommunication by co-locating, b) get access to the customer and c) have shortdelivery cycles. (Read part 1 of this post here). This is so simple, andyet agile adoption continues to be a big question mark for many people and atrack is dedicated to the question at Agile2011. So how can we influence thesethree behaviours?

The second half of the book “Influencer:The Power to Change Anything” (Patterson, Grenny, Maxfield, McMillan,Switzler) is devoted to the six types of influence strategies you can use tomake sure the vital behaviours occur. But first, let’s look at some quotes fromthe book that describe strategies that we often find ourselves using, but thathave been proven to be ineffective:

“When it comes to resistant problems, verbal persuasionrarely works” (No kidding eh?)

“People bet onsingle-source influence strategies all the time (and fail)”

Understanding that I am a beginner influencer, here is abrief summary of the six influence strategies found in the book with concreteexamples of how you can execute these strategies in order to bring about thevital behaviours that will improve the results of your software projects.

1) Make the Undesirable Desirable (Personal Motivation)

If people find the behaviour undesirable then they are notlikely to exhibit that behaviour unless you can convince them it is fun. Oneway to make the behaviour intrinsically satisfying is to turn it into a game. Keepingtrack of things like velocity and the number of passing tests in a visible areacan be a fun way to keep score. As the team has early successes, find fun waysto recognize them for their accomplishments such as completed stories,iterations with decreasing defects and happier customers. One of our teamsrings a cow bell when a story is completed and employees cheer when they hearthe bell. The team also gives a syphilis stuffed toy to anyone that breaks thebuild (they can redeem themselves by buying donuts). These are simple ways tomake new behaviours fun and desirable.

2) Surpass Your Limits (Personal Ability)

People need to be convinced that they have the ability tomake the required changes. Send your team to a hands-on agile training so thatthey can experience what it is like to work on a project that exhibits thesevital behaviours. Make sure that the training is hands-on rather than lecturebased. Once the project has started, help your team to gain confidence bystarting with short delivery cycles where they are producing working, highquality code (even if only in very small batches). Once the team sees earlyresults they will gain confidence that they can change their approach.

3) Harness Peer Pressures (Social Motivation)

Use peer pressure to your advantage by creating a co-locatedarea. According to one of the studies in the book, “one variable more than anyother affected how people behaved: the presences of one more person”. Puttingpeople in a common space with expectations set for the 3 vital behaviours willimprove your team’s chances of changing their behaviours. Also, find theopinion leader on your team (the one that has the most respect and influence)and spend a lot of time with that person addressing their concerns. If thereare included in the process they will begin to share your ideas with the teamand the vital behaviours will occur.

4) Find Strength in Numbers (Social Ability)

We are more likely to be successful when we have a littlehelp from our friends. Create a dedicated team that is responsible for theresults and hold the team accountable rather than an individual. Teams thatwork together are more likely to come up with a plan that will succeed.

5) Design Rewards and Demand Accountability (StructuralMotivation)

Any system of rewards can be dangerous. The book is verycareful to describe that if the other influence strategies are properly used,rewards need only to be small in order to influence change. A simple strategy wouldbe to create a visual project management board where individuals can movepost-its from one column to another as they progress through the steps requiredto complete each story. Moving a post-it is can symbolize a very small rewardthat happens during your daily stand-up meetings. Rewards such as the cow bellused above for completed stories can also be simple and effective.

6) Change the Environment (Structural Ability)

Make use of the physical environment to influence thedesired change. Create your co-located space so that it encourages people towork together by removing the cubicle walls, office doors, etc. Increase the“propinquity” of your teams and your customers by having them work in the samespace. “The best predictor of whether two people will work together is thedistance between them.” Additionally, make sure your visual project managementboard is in a central place and displays some of the common metrics such asvelocity, wip limits, and burn down charts. This helps make the invisiblevisible.

To recap, the Influencer book has some great ideas andstrategies on how to influence change. If you are considering how to influenceyour team to improve their software project results, promote the three keybehaviours identified above by using all six influence strategies to make thechange inevitable. If your teams are struggling to exhibit the behaviours,consider changing your influence strategies rather than giving up or targetingother behaviours.

Agile Adoption - 3 Vital Behaviours

2011-08-05T08:38:00.003-05:00

One of the books on my reading list this year was “Influencer:The Power to Change Anything” (Patterson, Grenny, Maxfield, McMillan,Switzler). As I read it, I was struck by how the ideas in the book can behelpful for guiding an agile adoption.

The book is split into two parts. The first section outlineshow any change can be made inevitable by looking for the vital behaviours thatwill bring about the change. The second section outlines six different types ofinfluence strategies that you must use in order to make those vital behaviourshappen. In this post, I’ll just be talking about the first section on vitalbehaviours.

According to the authors, any change can be made inevitableif you can find the correct set of vital behaviours. For many common problems,these vital behaviours have already been discovered by various research teams.For example, the vital behaviours for losing weight and keeping it off wereidentified by a U.S. government research project: a) weigh yourself every day,b) eat breakfast every day, and c) exercise with home equipment. A strong marriagecan be determined by looking for the following vital behaviours duringarguments: a) statements thatcommunicate shared respect and purpose, and b) taking timeouts when required tohalt emotional escalation. The best teachers a) reward positive actions oftenand b) alternate frequently between teaching and testing.

So what are the vital behaviours for agile adoption? First,let me suggest that agile adoption isn’t the goal at all – rather the goal thatwe are looking for is to have successful projects. Agile adoption may or maynot be required to meet that goal. If then our goal is to have successfulprojects, has anyone done the research to find the vital behaviours that arepart of all successful software projects? Indeed – Alistair Cockburn did significantresearch into this topic and found three common behaviours amongst allsuccessful teams. He described his findings in a 2006Agile Toolkit podcast where he said: (starting at about 3:25) “Those thatwere collocating face to face, shortdelivery cycles, access to customers were delivering. Those that werefollowing some process very carefully were not delivering.” In an article wherehe describes his research methods and results he writes that a) they improved their communication byco-locating, b) had access to their customer and c) had short delivery cycles.He also commented in his article that “I ran the seemingly odd hypothesis thatif you simply put four people in a roomwith whiteboards and computers, givethem access to the users, and have them deliver running software every month or two, they would have a highlikelihood of success in delivering useful, working software. Surprisingly,this hypothesis has not yet been broken." Reflecting on my own projecthistory, I find that I agree with his hypothesis. You can read more about hisresearch here. Notice by the way, that all 3 of thesebehaviours are about shortening the feedback loops.

If you look at Alistair’s work and writing on Crystal Clear,you’ll notice something interesting. These three behaviours are all in includedin the 7 properties of Crystal Clear. However, of the 7, only 3 are listed asmandatory and one of the above was not included in the mandatory list. “EasyAccess to Expert Users” was excluded (still on the list, but not mandatory) andreplaced by “Reflective Improvement” despite his findings and hypothesis. I’veasked Alistair about this and look forward to his answer – I’ll keep youposted.

Another interesting observation about “Easy Access to ExpertUsers” is that for external products with external customers, it would bedifficult or impossible to have access to those users. It makes sense then thatthe Lean Startup movement is heavily focused on tools and techniques to findand measure feedback from your external users.

While these 3 vital behaviours may be the ‘key’ behaviours thatwill help your team be successful, they will also spawn other behaviours toimprove your results. For example, in order to have short delivery cycles, youwill need to deliver small increments of value which could lead your teamtowards the practice of user stories. In order to have short delivery cyclesand not spend an inordinate amount of time doing manual regression testing foreach delivery, your team will likely move towards automated testing. In orderto have short delivery cycles and not spend an inordinate amount of time creatingdeployment packages, your team will likely move towards a continuous deploymentpractice.

In conclusion, if you are a manager, executive or coach wonderinghow you can make your teams more successful but have struggled with or withoutagile techniques, try encouraging and supporting these three vital behaviours asa starting point and then examine the results. Then, use something likereflection workshops to examine the results and start adding, deleting, ormodifying practices over time to improve your results. Based on what we knowabout organizational change management, this iterative approach to processimprovement has an increased chance of being successful. If the Influencer bookis correct, (and there are lots of examples in the book to indicate it is) thenthese three behaviours should make a significant impact on your projects.

Read part II of this post to find six possible influencestrategies to make these behaviours inevitable.

User stories and sandbag dikes

2011-08-03T21:37:00.067-05:00

This year on the Canadian prairies we experienced a lot of flooding and residents banded together to support each other - building sandbag dikes to help keep the water out. During this ordeal, I had a small aha moment in comparing user stories to sandbag dikes. User stories and sandbag dikes are similar because:

1. They are both boundary objects. Well constructed dikes keep water out and contain a dry area. Well crafted user stories contain scope and keep additional scope out.

2. There is no value to the user unless all layers are complete. To build a dike, you need to pile the sandbags on top of each other in layers and also weave in the plastic. Leave a layer out or forget the plastic and the dike is useless to the homeowner. To complete a user story, you need to build all layers or tiers of the system. A new database table doesn't provide any value to the user.

3. Size is important. If you want to protect a home from flooding, the dike only needs to surround the home, not the whole property. In fact, if you build it too big (for example, to protect the house, the shed, and the swing set), there are more potential points of failure, it takes longer to build which increases the risk of the dike not being completed on time, and you could have spent more time building dikes to protect other homes. If your stories are too big (for example, to implement logging in for a site, you build the login w/ password, forgot password, password reset, max login attempts, etc before building other stories), there are more potential points of failure, it takes longer to build which increases the risk of the story not being completed on time, and you could have spent more time completing other stories to increase the value of your project.

4. Priority is important. If you build dikes around the homes that are less likely to be affected by the flood, then when you run out of time it is likely that more homes will be flooded. If you complete lower priority user stories first, then when you run out of money you may not have accomplished the goals of your project.

I don't know, but you probably do.

2011-08-02T22:03:00.001-05:00

Sometimes, the best answer to a question is "I don't know, but you probably do". Let me explain...

I occasionally have the opportunity to speak at user groups or to groups of employees to introduce them to agile - what it is, why it is important, how to start, etc. The presentations vary depending on the audience but always end in an open question period to answer any and all questions about agile. I can usually provide an answer to most of the questions, but I try to use various strategies to draw answers from the audience instead of answering each one on my own. Many times, their answers are better or more convincing than my own. If I'm not sure of the answer, I *usually* tell them I don't know but point them to some resources that might help. However... sometimes I forget.

At a recent speaking engagement I was asked a question about how to apply agile principles to address specific operations and maintenance issues. I answered the question, but I'm pretty sure my answer was too vague and largely unhelpful - some useful comment about reducing wip I think ;). So, here is my attempt at answering the question again using both the principles and the knowledge of the group to solve the problem. Of course, that group isn't here, but hopefully this will help anyways (I'll be e-mailing this to them).

"Thanks for the excellent question! I don't know the answer, but you probably do. Yes, it is true that reducing wip will likely help improve your situation, but since I don't at the moment understand the specifics of your problem, let me give you a few ideas to try. You probably have or can start tracking some metrics of how long it takes maintenance and operational issues to be solved. Using this as a baseline, try a few experiments and measure their results. To determine what experiments to try, have regular meetings with your team and ask them a) what has worked well in the past, b) what hasn't worked well and c) what would they recommend. Based on those recommendations, pick one or two experiments to try and then measure the results. Over time, I'd bet that your team will be successful in solving this problem together."

Colour and it's relationship to usability

2011-07-08T03:21:00.005-05:00

This June I had the priviledge of doing some travelling in Saskatchewan - speaking at both PrairieDevCon and MosoConf. At PrarieDevCon, I was fortunate to have the time to attend a UX session by David Alpert (who will also be presenting at SDEC11 in Winnipeg this fall). I haven't spent a lot of time doing UX research, but his presentation opened my eyes to a few things. One of these is the targetted use of colour to direct the user to what is most important to you (and maybe to them). In the presentation David demonstrated this concept with several examples from live sites where the use of two colours is used to direct the user to certain actions.

As I returned to work the following week, I noticed that a change was made to our internal dashboard at Protegra. A reminders and announcements section was added and highlighted in yellow/green while the rest of the site remained in blue. Everytime I looked at this site and my eyes were drawn to the words highlighted by the use of colour I thought of David's presentation.

Here are few other examples that David showed to us to demonstrate how the use of colour could be used to influence user behaviour effectively:

1. Twitter
What are they trying to get you to do?

Sign-Up is highlighted in yellow to attract new users while Search and Sign-in are blue like the rest of the site. Twitter is assuming that if you are already signed up then you are committed to finding the Sign In button on your own.

2. JetBlue
What is important to them?

Fly Now and Find Flights are highlighted in orange and they are using other more subtle UX strategies so that you will know the first bag is free and that they now offer vacation packages.

3. Facebook
What are they trying to influence you to do?

Sign-Up is highlighted in Green for new users, while Log In is smaller and in blue - just like twitter, facebook is assuming if you are already signed up you are committed to finding the Log In button on your own.

David's presentation has peaked my interest and I'll be looking to find other ways to use colour like this on projects (external facing or not) to guide the user to the actions we would like them to take and discourage them from unwanted actions or workflows. Also, as the Dashboard example shows, it isn't just about highlighting buttons - it can also be about highlighting sections of the site.

Thanks David.

You can find more positive and negative examples and other UX strategies in his presentation found on his site - or join us at SDEC11 to hear him present.

Assessing your process - 6 great questions

2011-07-08T02:19:00.000-05:00

Recently, I was asked to work with a client to help them improve their process. In some of my other readings I found a list of 6 questions used by Alistair Cockburn in his research to search for the most successful properties of software methodologies. We used his questions to interview the team and found the results to be fascinating and useful. The interviewees took on average 3 hours to answer these 6 questions:

1. Please give me a brief history of the project: timeframes, changes in project size, problem domain, technology used, key events in the life of the project, the general approach.

2. What would you say are the things that worked in the project?

3. What would you say are the things that did not work well?

4. If you were going to start another project, or give advice to someone starting a similar project, what things would you be sure to put in place (recommend)? What are your priorities for those?

5. If you were going to start another project, or give advice to someone starting a similar project, what would you work (recommend) to avoid, or keep from happening?

6. What else?

Pretty simple list - I hope you find these useful as well.

Agile Documentation – Part II: Guiding Questions

2011-05-24T16:47:00.000-05:00

In Part I of this topic I asked you to consider how and why you currently use documentation and posed some questions for you to consider as you think about the place documentation may or may not have on your project. In this post I will list some additional guiding questions that I have found helpful when deciding on the level of documentation to include in a project.

While it is true that agile projects often produce less documentation, some documentation is still useful in order to communicate project scope, progress, and ideas. However, teams are asked to embrace some additional realities:

We rarely know everything up front and that producing high quality documentation about requirements or design that may not be implemented is wasteful.
A document isn’t the only vehicle for expressing or transferring good thinking and ideas

The tension between creating just enough documentation and too much documentation is part of the discipline that is needed for agile team members. Here are a few things to consider before your start writing that document:

1. Is this document for internal team use only? (example, for hand-off from one person to another) If so…
Can you communicate the information through a conversation instead?
Can you communicate the information through code instead?
Can you communicate through a drawing, picture, or other lite weight model instead?
If the answer is no to the questions above, what is the minimum amount of information you can capture in the document that would serve as a reminder for a future conversation?

2. Is the document for now or later?
If the document is required now, consider simplifying or replacing with a conversation, white board pictures, paper prototypes, code snippets, or brief videos summarizing decisions. If the document is for later (ex. Help Documents, regulatory documents, etc), then consider creating it later or adding it to your done criteria for each item in your backlog. Documents for ‘later’ do not need to be created up front but can be continually updated throughout the project. If the document is for later, how often do people actually use it?

3. Who is the audience for this documentation?
Ask your audience about the minimum set of information they require.

4. What is the business value of this documentation?
If it has little value, then it doesn’t need a lot of information. If it has a lot of value (like a required regulatory document), then make sure the level of detail accomplishes the required value and no more. Why are we producing this document? Would you pay someone to create this document? Is it worth the investment?

5. Is this information available through another means?
Instead of creating API documentation or SOA documentation, consider using one of the many tools available to generate your documentation. Instead of asking someone to read a design document, ask them to read and run your tests.

6. Does this document specify requirements or design in detail?
Since requirements change on our projects, capturing this level of detail up front may not be providing value to the project.

7. How often have I had to change this document in the past?
This is often a clue that your document contains too much detail.

8. Can I specify this information through an automated test instead?
Specification by Example (also known as ATDD or BDD) promotes writing your requirements as automated test cases (examples) instead of requirements bullets. This allows you to have an executable yet readable specification that is developed throughout the project in cooperation with your client and the development team. Test Driven Development is a technical practice that developers can use to write unit tests that describe and validate their code and design. This practice has lots of advantages, but one of the side effects is that the unit tests specify how and why the code works so that future developers viewing this code can understand this information without having to rely on out of date documentation.

9. How should I create the content for this document?
Consider creating the content using inclusive models. Inclusive models allow others to easily contribute as active participants in creating the content of the document and often involve paper, post-its, and whiteboards. A 35 page word document draft is not an inclusive model - you are more likely to get grammar and formatting edits than suggestions for improving or even re-doing the content.

10. Is this document so big that no one will read it?
“An attempt to avoid this ambiguity by writing everything down often leads to a document of the type Winston Churchill was working on before he was Prime Minister. Mr. Churchill described it as follows: ‘this document, by its very size, ensures that it will never be read.’”- Allan Shalloway in “The Role of Quality Assurance in Lean-Agile”

For additional reading on this topic, take a look at the following links:

Agile Documentation - Part I

2011-05-19T16:02:00.004-05:00

Agile Documentation. These two simple words represent a common question and concern for professionals who are new to agile. Many IT professionals who work in traditional environments are accustomed to spending a lot of their time carefully crafting documents to support the planning, requirements, and design of their project. They are often measured and compensated by their abilities to communicate ideas through documentation. After spending much of their career perfecting their communication skills through MS Word, Visio and MS Project, it is natural for them to wonder how projects can be successful without significant investment in documentation. Since one of the common early misconceptions about agile development is that documentation is no longer needed, you can understand how agile adoption would cause them to be concerned about both their careers and their projects.

For those who share this concern, let’s start by considering the following quote from Jeff Patton:

“Documents we write communicate our good thinking. You can write one without thinking. You can communicate good ideas without a document.” – Jeff Patton (Jan. 19, 2011 - twitter)

Before you sit down to write your next document, ask yourself these two questions:

1. Do I use the process of creating a document as a vehicle for good thinking? If so, what other ways could be used as a vehicle for good thinking?

2. Do I use documentation as a means of storing and then transferring good ideas to other team members (current and future)? If so, what other ways could be used to store and transfer those ideas?

In part II I’ll talk about some additional guiding questions and suggestions to help you make decisions on when and how to use documentation in agile projects. Before you read that post, please consider Jeff’s words and the questions above as you think about the place documentation may or may not have on your project.

Agile Testing - a response to The Golden Rules of Testing

2011-05-10T23:32:00.003-05:00

Today someone sent me a link to a Software Test Professionals (STP) article on the Golden Rules of Testing as applied to an agile project. I'm pleased that the testing community is embracing agile more and trying to figure out how to fit in. However, I was troubled by some of the statements I read. It appears I'm the "that's not how we do it in agile" guy who has some objections to his views. Commenting on the article directly required giving my name, address, occupation etc which I was unwilling to do so I'm posting my comments here. Interestingly, the author wrote a post on his personal blog “Am I an agile tester?” that is much closer to the views that I hold.

Ray's words are in normal text below. My replies are italicized and in blue.

***************************

Switching from Waterfall to Agile is known to directly impact testers.

Yes. But not just testers - everyone.

It's true; the change can be difficult for some of us. However, fear not, some things never change regardless of the development approach.

Agreed.

I've put together what I think are the golden rules of testing that still apply. So when someone says "that's not how we do it in Agile" (and believe me - they will) don't take none of it and stick with the basics.

<spidey senses tingling>Depending on how you interpret this statement, this is either ok, or a recipe for failure.</spidey senses tingling>

Read these simple golden rules for software testing based on my own experiences.

It’s all about finding the bug as early as possible:

Close. It is actually about preventing the defect from being found rather than finding it as early as possible. Finding it earlier is better, preventing it is best. For more on this topic, check out this fantastic go-to article on agile QA: http://bit.ly/aOfJM5

Start the software testing process by analyzing requirements long before development. I object to the word “long” here. It implies that we do big requirements up front. It also more than implies a process smell - the long gap between anaylsis and implementation. Rather, let’s take a look at a story together as a team right before development begins on that story to analyze the requirements and create our tests before we start coding. Then, repeat for the next story.

Make sure you have these 3 software testing levels:

Integration testing (performed by IT) performed by the team.
System testing (performed by professional testers) performed by the team.
Acceptance testing (performed by business users) performed by the team.

Don’t expect too much of automated testing:

First let me state this: Automated testing can be extremely useful and can be a real time saver. But it can also turn out to be a very expensive and an invalid solution. I tried to find more some information from Ray on what he means by automated testing but couldn’t find any additional info despite the fact that he has written a few blog posts about automated testing. This statement is usually delivered by someone who has attempted and struggled with automated UI testing. Automated UI testing can be more difficult and more expensive, but I'm not sure how it is an "invalid solution". However, automated service testing is comparably simple, not expensive, not invalid, and a consistent time saver. Automated UI testing can still be valuable, but the ratio of service to UI tests should be heavily weighted toward service testing IMO.

Deal with resistance:

If you like to be instantly popular, don’t become a software tester! You’ll find out that you are going to meet a great deal of resistance. It is very likely that you will end up being the sole defender of quality at a certain point. Other participants in the project will be tempted to go for the deadline, whatever the quality of the application is. This is one of the reasons the agile testing community preaches a whole team approach to quality. Being the sole defender of anything on a project is a problem. We want our teams to own the budget and schedule, not just the PM. We want our teams to own quality, not just the tester, etc.

Kanban Boards - What Restaurants and Agile Projects Have in Common

2011-04-27T09:46:00.002-05:00

I recently finished reading the book "Influencer: The Power to Change Anything." Among other things, the book describes several influence strategies and one of them is to use physical things to promote the desired behaviour. To illustrate their point they provided a simple example that I'll summarize in the next paragraph before drawing similarities to how a kanban system can influence good behaviours for your team.

The 1940s saw an increase in people eating out at restaurants after the end of the war and a surge in growth and prosperity. During this time restaurants struggled to keep up with the demand and tension grew between wait staff and cooks. Orders were late or confused and customers were annoyed. Dr. William Foote Whyte was invited to help. His solution was to install a simple 50 cent order spindle - a basic kanban system that later evolved into the order wheel. Wait staff wrote their detailed orders on paper that were skewered onto the spindle and the cooks would fulfill the orders generally in a first in first out sequence. This simple system worked wonders and still exists today. Cook staff could clearly understand the priorities and requirements for the meals while still being allowed some flexibility to make the meals in an efficient order. Wait staff could detail the order expectations and gain a better understanding of when meals would be completed. For more of the story, you'll need to read the book (Influencer, pages 220-222).

If your organization is experiencing similar issues and frustrations between your customers and your IT staff, then implementing a simple kanban system like the spindle could be a first step to improving your results, communication and behaviour. If your requests are sized appropriately (think meals for individuals vs. meals for everyone in the restaurant), then your customers can decide which stories are important enough to put on the kanban board and put them on in the order they would like them completed. Use index cards or stickies with detailed instructions on them (acceptance tests) as a way of keeping the requests small. Keep the board small enough so that only a limited amount of requests can fit. As one request moves off the board, the customer gets to add another. Measure the average time it takes for a request to enter and exit the board so that your customers can understand how long it will take to complete an average request. Making this process visible in a physical and tangible way can help encourage communication and cooperation between your customers and your IT staff.

For another view of a simple kanban board and how it works, check out Henrik Kniberg's cartoon here: http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

If you are already doing some agile development but have not yet experimented with kanban, consider using a kanban board within each iteration. Our team had discussions today for how we are going to set up our iteration kanban board for a new project and here is the draft plan with 5 columns left to right:

Iteration Backlog (limited to the points we think we can achieve in this iteration)
WIP - Tests Defined (limit of 3)
WIP - In development (limit of 5)
WIP - Testing (limit of 3)
Done (limited to the number of stories we can actually complete in an iteration)

This simple board helps improve communication and expectations between team members and stakeholders. It also encourages behaviours that we value - blurring of specializations, team cooperation, team ownership, and getting things to 'done'. Enforced wip limits will inevitably mean that developers will need to help testers/analysts and vice versa, and that one story has to move to done before a new story can begin. Also, a board that visualizes your process can increase ownership of the process and the results. I expect the columns and wip limits to change as we use our board but we find this mix of scrum and kanban to be valuable.

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

The debate about agile estimating

2011-04-13T10:45:00.003-05:00

There has been a lot of noise recently about eliminating estimating for software development projects. I'd like to thank Terry Bunio for putting out his thoughts as a rebuttal here. (Note - Terry sits right beside me so we've had a lot of discussion on this topic recently - especially since we thought someone was wrong on the internet #gasp)

To summarize my understanding of the issue:

Estimating is a waste because we are going to be wrong anways.
Estimating is a waste because we could be delivering value instead.

While these two statements have caused a lot of debate, there is a ring of truth in both of them. So, if we are going to do some form of estimating, can it a) help us be more truthful about our estimates and b) increase our ability to deliver value? This is the beauty of relative estimating through planning poker - and here is my main point, bolded and centered for emphasis:

Planning Poker is not just an estimating exercise.

Yes, one of the main outputs of planning poker are points estimates. But it has other results that address the concerns above.

a) It allows us to be more truthful about our estimates:

Relative estimates in concert with user stories and managing to done enable you to track the velocity of your project so you can predict actuals sooner (i.e. tell the truth about your estimates as soon as possible). In turn, this allows us to make better choices about the future of the project (like helping the marketers decide when to launch a campaign about the project), and measure the results of our continuous improvement experiments.

b) It increases our ability to deliver value:

Planning Poker is also a scope discovery tool (see my thoughts here). After a planning poker session our team will have a much better understanding of what the client wants and expects - therefore enabling us to deliver it to them sooner and with less misunderstanding and frustration.
Planning Poker creates team ownership of your estimates - including joint ownership with the client.
Planning Poker allows your client and users to have a much better understanding of what it takes to build what they are asking for and informs their choices when prioritizing.

In closing, so far all of our clients have required us to create estimates and we'll continue to do that. But, we like to start with points through planning poker because of the value added as above and then take a few stories and extrapolate to hours. After that, we ignore the hours and focus on velocity. This feels like a balanced and professional approach.

**************

Some additional reading on this issue if you choose. The last one contains some ideas that I strongly disagree with and that Terry responded to in the post above (despite his affection for TargetProcess in general).

Agile as a risk mitigation technique

2011-04-05T15:10:00.003-05:00

When I first started using and investigating agile principles and practices, I didn't immediately realize how well these techniques worked in order to reduce project risk. As I talk with others about adopting agile, many fear the 'risk' of moving to agile techniques. Here are a few thoughts on how agile practices reduce risk on your projects (I'm sure I've missed a few):

Project Risk	Agile Practice
Addressing schedule and estimate risks	Manage to done, Velocity, Relative estimating, User stories
Addressing the risk of building the wrong thing	Deliver early and often in small increments, Iteration demos
Addressing the risk of validating your architecture	Steel thread, Iterative development
Identifying risks and issues as soon as possible	Daily stand-ups, Frequent retrospectives, Iterative Development, Manage to done
Addressing scope risks	Iterative development, User stories, User story slicing, Relative Estimating, User story mapping, Trim the tail
Addressing people risks	Paired programming, Team ownership practices
Addressing quality risks	TDD, BDD, ATDD

This list doesn't address the risks that accompany any change initiative, but it does underline that many agile techniques are directly targetted at averting project risk. Agile practices help us shorten the distance between guessing (planning, designing, estimating, etc) and knowing.

See also - Chris Matts wrote about this topic recently and gave some nice examples of how he talked about risk during a methodology audit.

http://theitriskmanager.wordpress.com/2011/12/12/the-language-of-risk/

Team Ownership through the UX Design Studio Approach

2011-03-27T23:03:00.000-05:00

A few weeks ago I was added to a new team that had already spent some time working on the technical challenges for the project but had yet to do much UX work. One of the first things the team asked me to help with was to create the User Interface design. I think what they expected was for me to ask some probing questions, go draw some pretty pictures in Visio or some other tool and then present (and dictate) the results. I've certainly taken this approach on previous projects. However, in this case I went to my agile improvement backlog and decided to try the Design Studio approach I had learned at Agile 2010 in a session by Todd Zaki Warfel.

The Design Studio approach is a team approach to UX design. When I first asked the team if they would consider doing the UX design as a team, they were surprised and delighted to be asked (cool!). I had high hopes for this approach because I was excited to see the results of using the collective imagination of the team to create a cohesive and well thought out design. Before I share the results, here are the details of this technique:

Prerequisites: You should have already created your initial backlog of user stories. Creating other artifacts like personas and user scenarios first would also be useful. In our case we had the stories and some scenarios, but no personas yet. You will also need to print out several 8up sheets like the one in the image below and bring along several pencils. You can download the 8Up here or create your own in Excel.

Steps:

Gather team members for the exercise. Not everyone needs to participate, but you should have willing participants from each role including developers and client.
Decide on a focus for your UX design. This could be a specific release, user scenario, or some grouping of user stories.
Hand out 8up papers and pencils to everyone on the team.
Ask everyone to create 6-8 sketches of the different pages/screens in the app (see tips below).
Once you start, tell them they only have 5 minutes to complete their 6-8 sketches.
- You could tell them this before, but it seems to help crystalize their thoughts when they hear this.
After 5 minutes, review each set of drawings:
- Each person has 3 minutes to pitch their drawings to the team.
- The team then has 2 minutes to identify 3 things that worked and 2 things to change.
Repeat steps 3-6 until the team reaches a consensus on the design.
Once your design is complete, keep the final sheets as your UI reference model.
- You won't likely need to transfer this to Visio or any other tool. The model should contain enough information and brief notes so that you can develop straight from the paper and make final adjustments in your development tool while having a conversation.

Some tips:

Gloss over details in your drawings. You need just enough detail to communicate your design.
Aim for quantity not quality.
When doing this for the first time, don't tell your team they only have five minutes until after they start.
Do steal ideas from each other.
As always, include your client in these sessions.

Results

Four of us met in a conference room to try out this new approach. For a user scenario that included about 10 stories, we executed three rounds. As a team, we were very pleased with the results and how quickly the final design emerged. Despite starting with very different ideas, we discovered that by the third round our drawings were nearly identical and represented the best work of the team. Using this approach helped generate ideas none of us would have thought of individually and resulted in team ownership of the design. We also found that we identified a few new 'excitement' user stories to add to and enhance our existing backlog. Additionally, as we walked through each other's drawings we discovered one or two basic stories that we had missed while generating our initial backlog. Time will tell if the resulting UX design will be successful, but as a whole the team is confident in both the approach and the result.

In summary, this approach was fast, promoted team ownership, and produced a great result. You can learn more about the Design Studio approach here: http://unify.eightshapes.com/page-pattern/sketching-design-studio-page-patterns/

I thought the success of this team approach was appropriate to write about on a day where this quote was found in @ThisIsSethsBlog - "I'm not going to believe that only a few people are permitted to be gatekeepers or creators or generous leaders". Indeed.

Update April 1, 2011: I introduced this approach to a larger group of my fellow employees this week. Someone asked "why we should continue with round 2, 3 etc - why not just have the group consolidate the good ideas and produce one design together after round 1?"

My answer: If you consolidate your ideas after round one then you are risking two things: 1) That the 'loud' voices will be the one driving the ideas and design. The practice of having everyone re-drawing the design allows each person's ideas to be incorporated. 2) As you repeat the process of re-drawing your design, the ideas from your team members will seep into your ideas and birth new ones. If you consolidate your design too early, you risk losing those new ideas that can only form in the act of putting your ideas down with paper and pencil.

Agile Winnipeg Inaugural Event - "Shorten the Distance"

2011-03-21T22:21:00.000-05:00

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

2011-03-09T08:56:00.000-06:00

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!

2011-02-09T11:17:00.000-06:00

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

2011-02-01T12:13:00.000-06:00

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

2011-01-20T13:41:00.000-06:00

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.

How to wrap a gift card (hint - it involves power tools)

2011-01-06T16:53:00.000-06:00

Note: This post has nothing to do with agile, but hopefully it will add some excitement to your future gift card giving experiences.

This Christmas I was tasked with buying gifts for three of my nephews. I bought two gift cards from West 49 and another from Chapters. For some of you these may be fine gifts to give and you are happy to check off three more items on your list. However, my goal in giving any gift is to first give them what they want and second to try and surprise and delight them with something unexpected. A gift card is not surprising or particularly delightful.

So... what to do? For the first gift card, I took a typical approach and wrapped it in ever increasing sizes of boxes with lots of duct tape and topped it off with pretty ribbon and a bow. It was a very delightful looking gift. But, in the end I decided this was a little too typical and unwrapped it while I pondered other ideas.

It was while wandering through the garage that I received my inspiration - an old eight foot 2x6. Here are the steps that followed.

1. Using a circular saw, cut a slit about 3 inches deep and 6 inches long into the edge of the 2x6. After making the cut, make sure that the gift card will fit inside the slit.

2. Next, decide on a shape to create out of the wood (for this example I used a Christmas bell ornament) and cut the 2x6 into pieces accordingly and nail or screw the pieces together to form your masterpiece. Depending on the size of the gift card you may need to cut an additional slit in a second piece of the 2x6 so that the card will fit properly 'inside' your wooden ornament.

Before wrapping your ornament you may want to secure a ribbon to the top so that you can hang it up. At the top of the ornament, hammer in a nail half way. Now wrap a small piece of ribbon around the nail and then bend the nail over completely so that it holds the ribbon in place.

3. The finished and fully wrapped product!

4. Now repeat with other shapes as necessary until all your gift cards are wrapped. I created a Christmas bell, a Christmas tree, and a Christmas ball.

The reactions you get may vary, but my nephews used the words 'best' and 'ever' after opening their gift cards. Also, the look on their faces after they unwrapped their homemade 'ornaments' and before they realized there was more unwrapping to do was priceless.

Hopefully I can wrap more gift cards next year. My brother has already promised it will involve acetlyane torches.

Perfecting your process

2010-12-09T00:24:00.000-06:00

“Eliminating delays between what you do gives you a better return than getting better at what you do.” - Alan Shalloway (Dec 2, 2010, twitter).

I was recently introduced to the ball point game as a way to introduce agile concepts. A colleague of mine had decided to try it out for a larger group so I volunteered one of our teams in order to ‘test drive’ the game and the facilitation of that game.

The game itself is pretty straightforward. If you want to read about it, check out Declan’s link above or one of the many other sites describing the game. One of the objectives of the game is to show how teams can dramatically improve their process just by stopping, reflecting, and re-planning.

This particular team improved from a velocity of 28 to 57 in four iterations (see the image). However, if you read about this game from other sources, this kind of improvement is ok, but not great. The team focused their iteration planning efforts on perfecting their style rather than changing their process. They did discuss some alternative processes but ultimately rejected them and decided together that their best course of action was to perfect their current method.

To make matters worse, as facilitators we were terrible project managers as we told them stories of great improvements by other teams (“I bet you can get to 150, I’ve seen other teams do it”) but all this did was make them frustrated as they continued to try and perfect their process with only small gains. Plus, even though they doubled their efficiency in a short period of time, they were frustrated that they couldn’t go faster and started to slow down at the end of iteration 4. They suggested that if an iteration 5 would have been held, they would only have gone slower as the realization sunk in that they would not be able to achieve 150.

The exercise up until this point did not achieve what we had hoped for. We had hoped that they would find huge jumps in productivity each iteration and that they would get more and more excited each iteration. Instead, they only achieved modest gains and got more frustrated each iteration. So, what did we learn from this?

1. As the quote above says, it confirmed that focusing on improving and perfecting your current process is only going to give you modest gains. Practice doesn’t make perfect if your process is flawed. Continually practicing a bad process isn’t going to result in the benefits you are looking for and will likely slow your teams down over time as apathy builds. We need to give teams the lean tools and techniques to help them find their delays. One of the ‘tricks’ to this game is to reduce or eliminate your delays instead of perfecting your throws.

2. We need to give teams enough time to not only re-plan the next iteration, but to ask them to reflect upon and challenge both their process and their assumed constraints.

3. Teams who are pushed to achieve incredible productivity gains by well meaning leaders under the guise of empowerment or encouragement may see short term gains, but in the long term those teams will likely be negatively affected - especially if the teams haven't been given the tools and techniques to achieve those gains.

The team we tried this with did not at first come away with tools that they could use to improve their current project. In fact, we may have scarred them forever ;) We are trying this game again in a few weeks with a different group and we’ve made some changes with the hope of enabling the teams to see the ‘ahah’ moment before the end of the game. I’ll keep you posted.

Agile Retrospectives - a Rising Patton Fusion

2010-11-24T00:09:00.000-06:00

The last session of Agile Vancouver 2010 was a unique opportunity to watch Linda Rising conduct a conference retrospective with the Agile Vancouver organizers. It was interesting to watch how she facilitated and I wrote down some of her techniques so that I could try them out. The following day during the tutorials Jeff Patton led us through a mini retrospective with his own interesting twists based on his story mapping experience. What follows is the fusion of their ideas.

Note: This retrospective works nicely using index cards that can easily be sorted and grouped around a common table. If you are using walls and stickies, you can adapt where required.

Step 1 - Set the tone:
Recite Norm Kerth's Prime Directive (Linda was able to recite this by memory):

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

After reciting, ask each team member one by one if they agree to uphold this statement during the meeting and to avoid blame. A simple verbal "yes" indicates agreement. The verbal agreement is a simple influencing strategy or pattern that helps set the tone for the retrospective.

Step 2 - Framing the Retrospective:
The facilitator tells a story of a co-worker meeting you in the hallway of your company. The co-worker asks: "I know you were on project [X], how was that?". Each person responds with "It was great because...". Instead of speaking the answers out loud, give each person 3 index cards and have them write their answers down in silence. This allows input from each person regardless of personality type and keeps your team member's answers from influencing your own.

When each person has filled out their 3 cards, they read each one out loud and place them on the table. Once all cards are on the table, ask the group to silently group the answers together. Cards that are similar should be close to one another and cards that are different should be farther apart. According to Patton, the simple reason for doing this in silence is because it allows the work to happen quickly and without much discussion. In our exercise, we found this to be true.

Now that the good things are grouped together, take a different coloured index card and have the group summarize each grouping with a new card. For example, summarizing items like "team worked well together", "Bob collaborated to help me with my task", "Team rallied to complete the stories together" might be summarized with a card called "Great team work".

Step 3 - Do Differently:
Now that we have acknowledged the good things about the last period, remind the team that it is only a perfect project if they would do that project or iteration again in exactly the same way. In reality there is always something we would do differently. Ask the team to silently fill out 3 more index cards with what they would do differently. They may not write cards that associate blame, describe what wrong, or try to problem solve. In this part of the retrospective we are only identifying what we would do differently.

Once everyone has completed their cards, we again read them aloud as we place them on the table, group the cards in silence, and summarize with a different coloured index card. As the cards are read or summarized, the facilitator may need to remind the team to refrain from problem solving or directing blame.

Step 4 - Voting:
The next step is for the team to agree on which items on the "Do Differently" list are the most important. To keep the voting impartial and independent, have each team member write their top 3 items on an index card and hand the cards to the facilitator. The facilitator then tallies the votes and records the totals on the summarized cards. An alternative is to use dot voting, but I've found that dot voting can be 'gamed' too easily and that initial dots influence those who vote later (group think).

Step 5 - Experiments:
Using the top 1 or 2 voted items, ask the group to split into groups to discuss them - 1 group per item. Instruct the groups to discuss small experiments or tweaks that the team could try in the next iteration. If you practice frequent retrospectives, this discussion does not need to be about problem solving or even root cause analysis. The goal is to quickly agree on small experiments to try to resolve the issue you are discussing. For those dedicated to root cause analysis this may be a problem, but give it a try and do what works for your team while avoiding blame or delving deep into problem solving. This part should be time boxed to 10 or 15 minutes maximum.

After deciding on the experiments, have one person from each group present the idea to the group. This idea needs to be included in the backlog for the iteration and the team (not an individual) commits to completing the experiment during the iteration and examining the results.

Step 0 - Review Experiments:
At the beginning of the next retrospective, add a new step at the beginning to discuss your experiments to see how effective they were and use this information as input into future experiments.

Other notes:
If you are doing a retrospective for a larger period of time, then consider starting the retrospective by building a timeline of events. For more info, check out this blog: http://www.thekua.com/rant/2006/03/a-retrospective-timeline/

Thanks Linda and Jeff for sharing your methods and ideas.

What is your top 1 agile tip? @AgileVancouver

2010-11-05T14:59:00.000-05:00

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.

Why is collective team ownership and commitment better than individual ownership and commitment?

2010-11-05T11:25:00.000-05:00

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.

My top 12 agile podcast episodes

2010-10-25T22:16:00.000-05:00

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 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.

Hope you enjoy them. Let me know if you have other favourites - I'd love to listen to them.

FitNesse and today's date with .net

2010-09-18T07:03:00.000-05:00

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:

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);

}

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:

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.)

Agile readiness assessments at Agile2010

2010-08-15T11:44:00.000-05:00

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.

Agile2010 - My Conference Summary

2010-08-14T11:48:00.000-05:00

My user stories for the conference were:
- Learn more about coaching and agile assessments (done)
- Get ideas for promoting and increasing agile adoption (done)
- Find better ways to use FitNesse and Selenium (done)
- Acquire some new tools for expressing user needs (done)
- Meet many of the people I’ve been following over the years (done)
- Meet some of the AA-FTT folks (done)

In addition, I encountered a passionate community that is willing to share their time, skills and ideas with anyone who asks. In addition, I encountered a troubled group of leaders that is legitimately concerned about the lack of technical content at the conference. In addition, I encountered leaders advocating for agile in all its flavours instead of promoting any specific one (hurray!). In addition, I encountered people passionate about taking what they have learned in agile and using that to improve communities outside of the business world. In addition, I encountered a few technical folks who undervalue mastery of the ‘soft’ skills over the technical skills. In addition, I encountered new friends that I hope to see again next year. In addition, I encountered a dedicated and friendly volunteer staff that helped make the conference run smoothly. In addition, I encountered a community willing to volunteer their time and money towards a cause (mano-a-mano).

Finally, I encountered a growing and dedicated community that has a lot of success stories to share, some challenges in the road ahead, and hopefully a commitment to continue the fight together.

Thanks all.

Day 5 at Agile2010

2010-08-14T11:40:00.000-05:00

The final day of the conference contained three general sessions. I found a few people who skipped out on these sessions - too bad for them as the sessions were a great wrap up for the entire week.

Dave West talked about Product-Centric Development and the move away from the separation of business and IT (yes please!). He asked us to start measuring ourselves and our teams by how much value we deliver and not by on-time, on-budget, # of defects, # of stories, lines of code, etc. We can’t make our teams act as part of the business unless we change our measurements.

Ron Jeffries and Chet Hendrickson provided both comic relief and poignant commentary. I think Chet's comment sums up their talk: "there’s lots of ideas out there and we need to look at every damn one of them”.

Finally, Mike Cohn's talk was a great ending to the conference as he challenged us with some practical ideas of how to spread what we’ve learned using the ADAPT model. Create Awareness of the problem by communicating using metrics and stories. Focus on one or two reasons to change. Increase the Desire to change by communicating that there is a better way. Get the team to take agile for a test drive and focus on addressing any fears. Develop the Ability to work in an agile manner by providing coaching and training. Promote agile by publicizing success stories or holding agile safaris where people can drop in to agile teams for a short time to see how it works. Transfer agile to all non development teams, departments, divisions, etc. Align promotions, raises, HR, and Marketing. Finally, don’t expect an agile transition to happen all at once. Create an improvement backlog and improvement communities and work on a few stories that are important to your community before tackling the next ones.

A final call to action from Mike: “Now we’ve upped our skills, up yours!” Well said.

Day 4 at Agile2010

2010-08-14T11:38:00.000-05:00

Two of today's sessions were more about aquiring ammunition and ideas for my own future talks than about aquiring new skills. In confessions of a Flow Junkie, Dave Rooney introduced me to the coin flipping game which contrasts the flow in Agile vs Waterfall. In the final session of the day, James Shore and Arlo Belshee made us laugh and cry with their Bloody Stupid Johnson routine. The highlight of the session is the soon to be framed certificate that I attained as an "Agile Software Specialist" or A.S.S.

The session with Gerry Kirk and Michael Sahota was designed to create a knowledge base of methods and tools for doing agile readiness assessments. It was great to see ideas from other coaches and I look forward to the compiled results.

The conference party at Epcot was also a lot of fun and I enjoyed some non-agile time with my agile friends.

Day 3 at Agile2010

2010-08-12T00:33:00.000-05:00

Here is a summary of another satisfying day:

I was introduced to some powerful team wireframing techniques that could be incorporated into the discovery phase of a project as another tool to aid in creating and defining the backlog. I wonder what my UX friends would think of doing UX as a whole team. It definitely fits the agile model where every team member provides input and takes responsibility for the whole process, not just their specialty.

The 11am session reminded me of the Trident Splash commercials - I wasn't prepared for the amount of information I received from Jeff Patton and I'll have to review my notes and his slides several times. What I do know is that there was a lot of valuable information on how to do agile discovery. The techniques were designed to help you get to a definition of ready - ready to start sprinting. Some quotes I wrote down: "Our job is to minimize output, and maximize outcome"; "Most agile practives emphasize delivery, and not much discovery", and as an example of that second quote: "velocity is a measurement of output, not outcome". A good reminder to focus on why the project was started in the first place. Update 8/31: The slides are now available here

The first session after lunch I joined the presenter up front as a timer object. Brian Marick was explaining OO programming practices to non-programmers by using volunteers who acted as objects. He explained SRP, encapsulation, MVC, etc. You can see a partial video of a previous talk he did on the topic at http://vimeo.com/13506935

Not shockingly, in the last session I learned I was using Selenium in the most basic (and mostly abhorred) way. I was able to spend some time with Patrick Wilson-Welsh after the session in a mini open jam to go through some coding examples of how to do it the 'right' way. Good thing I haven't given my Selenium SDEC presentation yet. Thanks Patrick for spending the extra time - you are one of many at the conference that have shared your time and energy with me and others.

The day ended when I didn't win an iPad, but I did thoroughly enjoy playing beach volleyball in the dark until almost midnight with occasional swim breaks. Thanks to everyone who participated - it was a great way to give my brain a rest.

We're at epcot tomorrow night until midnight so I don't think I'll be posting my Day 4 notes until Friday sometime.

Day 2 at Agile2010

2010-08-10T23:18:00.000-05:00

Today was another satisfying day at the conference in 'sunny' (I did see the sun this morning) Orlando. I started the day off with 11 other agilists going for a morning run on the paths and walkways around the Disney complex followed by a great breakfast. The catering at the Dolphin has been fantastic so far.

The first of two notable sessions that I attended was called "Effective Questions for an Agile Coach." The two presenters Arto and Sami from Reaktor were great and cleverly crafted the table discussions so that we would fall into common coaching traps and then helped demonstrate better alternatives. Here is a brief overview of some of the ideas from the presentation:
- By giving advice you are creating motivation from the outside. You need to ask effective questions to let them figure it out for themselves
- The four acceptance tests for good coaching questions are a) leads to exploration, b) aim at descriptive answers, c) avoids judgement and d) avoids unproductive states of mind
- Avoid the question 'why'. Try converting the question into a What, When, How Much or How many. For example, instead of Why, ask What benefit did you expect to receive?
- When trying to help the team solve a problem, follow the GROW model. Grow: first, find their goal. Reality: Second, ask questions to help them describe the current state. Options: Third, ask questions to find at least 3 options. Simply ask how would you solve this. What: Finally, ask questions to find agreement on a path forward.

Some other random thoughts:
- I attended an www.innovationgames.com seminar. After playing The Product Tree game and Scream, I want to explore how to introduce these games in my own projects.
- Dave Thomas was funny and poignant as the keynote speaker although I did wonder if his talk was targeted more at those not at the conference than those of us who have already 'taken the pill'. They videotaped his talk and I suggest looking for it in the next few weeks.
- I took some advice from other conference veterans and walked out of a session that was covering topics I was already familiar with. As a result, I had some great conversations about retrospectives and the intersection of agile and church.
- The 'soft skill' sessions at this conference have been great, but I wonder if there is room for more advanced developer topics.
- Played some beach volleyball at the end of the day with 2 other Canadians and a Swede. Are there any Americans at this conference?

More tomorrow... looking forward to the open jam on ATDD/BDD wording.

Some thoughts from day 1 of Agile2010

2010-08-09T23:01:00.000-05:00

I started the day with Mary Poppendieck's talk "Leader's Workshop: Making Change Happen and Making it Stick" which was based on the following book: Switch: How to Change things when change is hard. The talk was split into 3 parts. First you need to Motivate the Elephant, then you need to Direct the Rider, and finally you need to Shape the Path.

Mary suggested that in order to Motivate people, you need to treat them like volunteers. You need to treat them like they could leave at any time. A quote from Peter Drucker: "They need, above all, challenge. They need to know the organization's mission; believe in it, they need to see the results". As our table discussed this concept, we were able to easily relate to our own stories of leading youth at church or in boyscouts. I think this would be a great way to be treated and I can see how it would translate into energized and passionate employees. A volunteer team has to be engaged or they will disappear.

The purpose of Directing the Rider is to provide clear direction. One of the ways to do this when change is difficult is to find the bright spot. When you are having trouble implementing a change, look for some small success and then duplicate it. She gave a great example about post-it notes. When 3M first made the post-it notes, they could not sell them. They test marketed them in several locations and they only sold them in one ("the bright spot"). It turns out that the sales rep in Richmond Virginia decided to give them away and once he did everyone wanted one. 3M then followed this model in other locations and now post-it notes are a household item (and a valuable agile tool!). So, to direct the rider in difficult situations, find instances of success and clone it. A book that she references is: Positive Deviance: Influence: The Power to Change Anything"

Finally, she suggests Shaping the Path by looking at the long term and allowing local decision making. You also need to find ways to make the desired change the path of least resistance. "Change will only stick when the path of least resistance is the path of change." IBM's move towards agile was used as an example. Instead of forcing agile, they allowed it to succeed in smaller teams and then sold and promoted those successes. Soon, everyone wanted to do it.

In summary, to encourage change in a team when it is difficult a) treat your team as volunteers b) find the bright spot and clone it and finally c) make the desired change the path of least resistance.

In the afternoon I went to Hacker Chick and Dawn Cannan's hands on presentation "Better Story Testing through Programmer-Tester Pairing". We had fun doing developer/tester pairing of acceptance tests in FitNesse and Java. I learned a few new FitNesse tricks and also that I haven't lost all my dev skills. I played the dev role and our team was the first to complete the assigned task, beating some notable names in the room <cough>Brian Marick</cough>. The session also re-inforced ATDD and gave me some ideas I'd like to incorporate into a future presentation.

Also, I missed Janet Gregory's talk this morning on the Dance of QA in agile, but I managed to talk to her this evening at the mixer. She gave a quick summary of her talk and how she related it to dance. Agile team members need to be like contestants on "So You Think You Can Dance". On the show, hip-hop dancers learn other dance styles like ballet and vice versa. Similarly, agile team members (including QA) need to improve their skills in all of the disciplines in a project team. An interesting thought.

Thanks to everyone - a great first day.

In other news, Bob Payne is now following me. #Stalker.

Using Selenium for Meta tag testing

2010-07-05T21:43:00.000-05:00

I recently tweeted that I had figured out how to use Selenium to test for meta tag content. Here is in an example using http://www.protegra.com/. On the Protegra home page, I wanted to make sure the following 2 tags existed:

<meta name="title" content="Protegra.com" />
<meta name="description" content="Business. Technology. Solutions." />

Obviously, meta tags don't show on the page at all, but do exist in the HTML. To test this manually, I would need to open the page in a browser, click view source, search for 'meta' and then manually compare the results to the expected meta tags. To test this using Selenium, all you need to do is create a test case that opens up Protegra.com and then uses VerifyElementPresent to search for each meta tag. The VerifyElementPresent command allows you to enter the name of the meta tag and the expected content in the format of :

//meta[@name='name of the meta tag' and @content='the expected content']

The Selenium test case html for the two meta tags I'm looking for looks like this:
<tr>
<td>verifyElementPresent</td>
<td>//meta[@name='title' and @content='Protegra.com']</td>
<td></td>
</tr>
<tr>
<td>verifyElementPresent</td>
<td>//meta[@name='description' and @content='Business. Technology. Solutions.']</td>
<td></td>
</tr>

Now I can run this test repeatedly to test for the expected meta tag content on the home page whenever I want without using manual effort. I can also create similar tests for each page throughout the site and run them all consecutively. Additionally, I could use Excel to generate the Selenium test case html for all my pages and meta tags without having to write the html manually or I could export this test case into C# (or any of the other programming languages supported by Selenium) and transform this test to lookup pages and meta tag values in a database table. Fast and easy.

But does it work? - an agile metric

2010-07-02T11:43:00.000-05:00

I've said publicly at conferences and other gatherings that my passion for agile and lean began years ago after a particularly troubling project that tried to be agile. While that project had a strong team and eventually delivered a product, it had trouble with quality, scope and budget. In retrospect the biggest problem was that we had little knowledge of what it meant to be agile - our process was flawed. As a leader of that team, I took responsibility for the result and began a search to understand agile. Borrowing a phrase from the agile manifesto, I wanted to 'uncover better ways'.

After implementing several changes to our process, my projects over the years seem to have improved significantly. But how do you measure this? While no metric should stand alone, here is one quality metric that I'm experimenting with:

((# of high defects * 5) + (# of medium defects * 3) + (# of low defects * 1) / Total project hours * 100.

The 'troubled' project had a score of 18.7. My most recent project score was 1.2 which is almost a 1600% improvement on quality. I think I'll keep doing this agile thing.

P.S. I'm heading to Agile2010 this summer. Give me a shout if you are going and we can find ways to de-brief together over lunch or dinner in Orlando.

User Stories in more detail

2010-06-08T16:34:00.000-05:00

Several people at the conference last week asked me for more information about how to write user stories. I could write a long blog with lots of examples and explanation, but someone has already done that. Check out Scott Ambler's post here.

While Scott recommends capturing stories on cards, I like to capture them initially in a spreadsheet because it makes it easier to organize and prioritize. Once the project starts I print out the cards - instructions are in one of my earlier blogs.

The last shall be first

2010-06-07T16:15:00.000-05:00

At what point in the project do you start your testing effort? In many project plans that I have seen, QA and/or UAT is added to the end of the project. The development team hands over the code to the testing team who then writes and executes the scripts. The bugs are passed to the developer and the test & fix cycle begins. What fun.

Here is an alternative to the test & fix cycle:

1. Write test scripts before development starts on any particular feature. Test scripts help confirm the requirements with the client and allow developers to have a full understanding of how the code must work. The test scripts function as executable requirements and answer "How will I know when I'm done".

2. Minimize the time between when a features has been developed and when it is tested. This allows you to find defects or requirement misunderstanding early so that developers do not re-build the same defects or misunderstandings into future features. This helps increase the quality of the system while decreasing the time spent in the test-fix-test-fix cycle. Complete testing of any feature should occur in the same iteration that the code is written and should be part of your 'done' criteria.

Both of these two simple steps are based on the Lean Principles of Eliminate Waste and Build Quality In. For more information, check out this article from NetObjectives.

PrairieDevCon Presentation links

2010-06-01T11:14:00.001-05:00

Here are some additional links for my presentations at PrairieDevCon this week.

Introduction to Lean and Agile:

Books

Lean Software Development. Tom and Mary Poppendieck (2003)
User Stories Applied. Mike Cohn (2004)
The Art of Agile Development. James Shore and Shane Warden (2008)
The Art of Lean Software Development. Curt Hibbs, Steve Jewett, Mike Sullivan (2009)
Agile Estimating and Planning. Mike Cohn (2005)

Sites

Podcast Sites

Newsgroups

leanagile@yahoogroups.com

Other links to articles, blogs, videos

www.martinfowler.com/articles/newMethodology.html
http://agileinaflash.blogspot.com/2009/08/12-principles-for-agile-software.html
www.infoq.com/Agile2009 (Videos from Agile 2009)
http://www.netobjectives.com/files/BusinessCaseForAgility.pdf (requires account registration)
http://groups.google.com/group/agile-developer-skills/web/draft-summary-of-chicago-meeting?hl=en&pli=1
http://www.agilemanifesto.org/history.html - History of the Manifesto
http://www.devx.com/architect/Article/32836/0/page/4 - comparison of seven popular agile methodologies

Planning Poker:

Links

www.planningpoker.com/detail.html
http://www.youtube.com/watch?v=fb9Rzyi8b90&feature=PlayList&p=3F5BBA263D7DF99C&playnext=1&playnext_from=PL&index=2

- Video of Mike Cohn explaining Planning Poker

List of Agile practices

2010-04-30T10:00:00.000-05:00

I read an interesting list of agile practices at Naresh Jain's blog: Explosion of Agile Practices. I think there is a lot of overlap in his list, but it made me re-visit what I think the core list of lean and agile practices should be. My list is below in no particular order. Each item can be expanded - for example, Technical Excellence implies TDD, simple design, following SOLID principles, etc.

1. Daily Stand-ups
2. Visual Project Management
3. Customer Accessibility
4. Technical Excellence
5. Frequent Delivery
6. Frequent Retrospectives
7. Continuous Improvement
8. Continuous Integration
9. Co-located teams
10. Iteration Planning
11. Team Estimating
12. Acceptance Tests (and automation of those tests)
13. User Stories
14. Self Organized Teams
16. Iteration Demos

Update 8/15/2010:
- And one more... Deliver Value!

Agile scope completion techniques

2010-03-27T20:00:00.000-05:00

One of the questions I've received in the past about agile techniques is how to ensure you've captured enough detail about your requirements in order to proceed without missing major scope elements.

Whether you are using story cards, features or other techniques to capture your requirements, you need to answer this question: "How do I know when I've done enough requirements gathering?" In waterfall this is ‘easy’ – gather all the detail and sign-off (ok – I’m simplifying). In agile, we depend on features or stories, but many are concerned that major scope elements will be left out which will either cause many items to grow exponentially in size or that feature X is really feature X, Y and Z. For example, when the registration screen has 50 fields instead of the 10-15 that we might have assumed, but didn’t write down. It is hard to understand how this can be done in 1 or 2 days using feature or story cards that contain only one line of description, a few lines of acceptance and a few assumptions.

Three things for you to consider to help you solve this dilemna:

1. In waterfall techniques, although we hold some comfort in our massive requirements documents, we know from experience that even then things will change and things will be missed.

2. My teams estimate using planning poker with the full team including the client and we have found this has helped to uncover hidden or unknown scope. We discuss each item together before estimating and talk about the number of screens, inputs, outputs, services etc involved. This discussion itself often uncovers additional scope, but so does the estimating that follows each discussion. For example, when most of us say ‘2’ and one person says ‘8’, the person who said ‘8’ enlightens the team on the complex caching required to meet the performance requirements listed as an Acceptance test. This is especially important if your client is the one with the highest estimate. Don't ignore it.

3. Lastly, I attended a virtual class on agile estimating that suggested another technique. For every feature or story, categorize the requirements certainty as high, medium and low. Keep challenging your client until the requirements certainty on each story is 'low'.

I'd be interested in other techniques you may be using to keep the initial requirements gathering phase light weight, yet complete. I think as an industry we are getting better at embracing the changes that are inevitable on all projects, but our clients still require us to have a good understanding of the known scope and the resulting estimate before starting the project.

Planning Poker and Buckets of Hockey Pucks

2010-02-24T21:51:00.000-06:00

The teams I've been working with over the past while have been using planning poker for project estimating. Despite initial and fleeting skepticism by a few when we bring out the cards, as a whole our teams and our sponsors are finding value in this approach. I was reminded today that we should look at poker points as buckets of sand. That is, when deciding between a 5 and an 8, if something is a 6, you can probably still put it into a size 5 bucket if you think of the points as sand that can be heaped at the top of the bucket. Also, a 7 would overflow a size 5 bucket but would fit easily into a size 8.

In light of Canada's 7-3 victory over Russia in Olympic quarter finals, I've decided to change the metaphor to buckets of hockey pucks instead of sand. Go Canada!

P.S. I'll be presenting on Planning Poker in Regina in June at http://www.prairiedevcon.com/

FitNesse gets the gold!

2010-02-17T08:33:00.000-06:00

I've been using FitNesse for just over 3 weeks and I am pleased with the value it is adding to our project even though I'm only using the basic features at this time. As a former developer I'm finding it fun to use because I have to write a little bit of code in order to create an interface between FitNesse and each service that I'm testing. Most of our testing on the project was going well and we were avoiding major errors - until last Thursday...

A change in the code from a newly completed work item resulted in 81 of our 191 tests failing. Imagine how long it would take to re-run all 191 tests manually to find out that 81 had failed. Imagine how long it would take to re-test all 191 tests manually to make sure they were fixed. As you can see from the image below, it took us 39 minutes to find, fix and re-test all 191 tests. Thanks FitNesse.

** Update 6/28: This project had the highest quality metric that I've ever been a part of in terms of defects / month / developer. FitNesse was a big part of that success.

Fitnesse with C#

2010-01-27T16:51:00.000-06:00

I've decided to try out Fitnesse on my current project so I attempted to find a complete tutorial on fitnesse with C# today. The best tutorial I found is contained in the following 2 links:

1. Installing FitNesse
2. Writing your first Hello World test

This is a great tutorial. Although in the end I figured everything out, there are a few steps that were implied in the tutorial that I missed on the initial pass. Here are those steps:

a. Leave the command line open. You need to execute this command line everytime you want to use Fitnesse. If you close the command line, Fitnesse will not work.
b. When downloading the FitSharp binaries from github, place the contents of the zip file in a "dotnet2" folder that you create as a subfolder in the folder that you downloaded/installed the .jar file to.

After adding those 2 steps, everything worked great. Thanks to Gojko for all the work you put into the tutorial at the links above. I found the Fitnesse User Guide to be lacking.

Delivering Bad News Early

2010-01-26T23:11:00.000-06:00

I was listening to a Controlling Chaos podcast today, and heard this:

Project Team to Executive: "When should we tell you if we have bad news?"
Executive (dumbfounded of a little): "Well, right away of course!"
Project team (Excellent - thanks for giving us permission)

Yes, I think we all realize that it is important to deliver bad news as soon as possible. And the technique above can be useful to gain permission to deliver it early and allow you to understand and negotiate what 'bad news' means. Bad news can be found on all projects regardless of methodology - resource changes, customers who aren't sure what they want, budget risk, schedule risk, etc. The sooner we can identify the bad news and deal with it, the better.

For bad news related to the budget, how do your teams know when you will be over budget or schedule? Traditional project management methodologies use "Earned Value" to measure project progress against a budget. What frustrates me about this method is that until your team has delivered value through working code, your actual earned value is... zero. If requirements or design is complete, what value is that to the business? Does it verify what % complete the project is? Does it verify your estimates? Does it ensure that the business is getting what they asked for? How useful is it to measure the "Earned Value" on a traditional project until that project is complete?

This is my favourite thing about agile. Once your backlog is complete, estimated using relative estimating, and your first iteration is complete with working code you can calculate your initial velocity and compare it to the budget and schedule. After your second, third and future iterations you refine your velocity and with it your cost and schedule. You have delivered value through working and implemented code and you can calculate actual Earned Value based on what you have delivered vs what is remaining in the backlog. In this way, you can verify your project process early and report budget and schedule issues to your executive or sponsor early and more accurately.

Of course, this depends on short iterations, a backlog of user stories based on the INVEST model that is relatively complete, and working to 'done'. More on these at a later date.

Generate index cards from your Excel 2007 backlog

2010-01-11T16:40:00.000-06:00

You have captured all your user stories in Excel 2007 and now you want to print them out as index cards. Follow these steps in Word 2007.

First, create the word document and select your data
1. Make sure you have headings in your excel document. Example: User Story, Points, User Story ID
2. Open Word 2007 and create a new document
3. Go to the "Mailings" tab
4. Click "Start Mail Merge" and select "Step by Step Mail Merge Wizard"
5. Click "Select Recipients" and select "Use Existing List"
6. Select your excel file and then the name of the sheet (eg. 'Sheet1$')

Second, setup your index cards
7. In the "Mail Merge" window (usually on the right), select the "Labels" document type and click "Next: Starting document" at the bottom.
8. Click "Label options…" to choose create a custom label size for your index cards
9. Click "New Label…"
10. Use the following settings for 4 index cards per page:
○ Label name: "Index Cards"
○ Top margin: 1.5 cm
○ Side margin: 0.6 cm
○ Vertical pitch: 13 cm
○ Horizontal pitch: 10 cm
○ Page size: Letter (8 1/2 x 11 in)
○ Label height: 12 cm
○ Label width: 9 cm
○ Number across: 2
○ Number down: 2
11. Click OK (Note - you can now re-use the new "Index Cards" label format the next time you print index cards. Look under "Product Number" on the "Label Options" window)
12. Click OK again to close the "Label Options" window

Now we add data to the index cards
13. Click "Next: Select recipients"
14. If you want to select only some of your stories, use the check box column to do so. Click OK.
15. The page should now show four labels, with the first one blank and the other three containing "<>"
16. Click "Next: Arrange your labels"
17. In the blank label, add the static text you want to display. I like to show Story ID, Points and the User Story on the card, but you can display whatever information is relevant for your project and process.
17. To add the fields from your product backlog, place the cursor where your field should go and click "More Items". Select the field you want to add and click "Insert". Repeat for any additional fields
18. Now format your fields (bold, size, positioning etc) within the first label.
19. When you are finished, click the "Update all labels" button to move your formatting to all the index cards.
20. Click "Next: Preview your labels". At this point, you should have four index cards per page populated with your stories.
21. Click "Next: Complete the merge"
22. Now print your index cards! (make sure they are not printing double sided…)

Bonus Tip: Use the "Scotch Glue Stick Restickable Adhesive" to turn your index cards into reusable sticky notes.

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

Agility on Waterfall projects

2009-10-15T14:10:00.000-05:00

So you find yourself on a strict waterfall project, but you want to inject as many Agile practices as you can, where do you start? There are many agile practices that can be incorporated into your day-to-day activities. Here is a start:

1. Acceptance Tests. Regardless of your role, you can write acceptance tests to verify your understanding of the requirements and to reduce the waste that is 'UAT'. Do this before you code.

2. Technical Excellence. TDD, SOLID Principles, etc can be used on waterfall projects even if you don't have official support to write your code that way. Depending on the development team make-up, you may have to find a way to refactor your tests when someone else changes your code, but since waterfall projects are sometimes silo-ed, this may not be an issue.

3. Customer Accessability. Find ways to get near your customers, analysts and testers to walk them through prototype screens, talk about the requirements, or discuss acceptance tests. Do this frequently (daily if possible).

4. Work to done. Make sure your code is shippable and passes all the tests you wrote, plus all the requirements. Be thorough.

5. Deliver Frequently. While you may not be able to put the code in production every 2 weeks, you can certainly put the code (prototypes, screen shots, diagrams, etc) in front of your customer frequently.

6. Be ready for change. Don't be upset when requirements change or new requirements are found. Make sure your code (and your mindset) is change tolerant. You'll still need to fill out the change request forms and follow the process, but at least your code will be ready for it.

7. Team of One. You may not be invited to help with the project estimate, plan the project, write status reports etc, but you can run your own tasks like an agile team. Create your own visual project management board, hold stand-ups and retrospectives with yourself, practice your planning poker skills by re-estimating all the tasks assigned to you, plan your iterations.

8. Suggests phases. If you can, suggest a phased approach to the project (rather than iterations). This may enable you to eliminate some of the waste and respond better to change.

In short, try to intregrate as many practices as possible, but don't necessarily ask permission to do so. Hopefully someone will notice and ask the important question: "Why are you doing that?"

Agility in Winnipeg

2009-10-15T13:29:00.000-05:00

Yesterday I presented at sdec09 (http://www.sdec09.com/) in Winnipeg. My two presentations were at the opposite ends of the Overview/Detail spectrum. The first presentation was an introduction to Agile and Lean using a Lego project to demonstrate the usefulness of the various agile practices as compared to waterfall. The second presentation was a hands-on Planning Poker exercise (one of many agile practices). The day was fantastic and we (as a team) received a lot of questions ranging from specific questions on agile practices to how do I start using agile at my company.

In this blog, I will try to capture discussions about agile that are happening in Winnipeg and elsewhere. I hope you find it useful.