Is agile suitable for all projects?

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.

Agile outside of software
Wikispeed - Joe Justice and his volunteer team designed a 100+ MPG car using agile techniques."We can swap out an engine in the time it takes to change tires".

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

Making the undesirable desirable - a lesson from Tom Sawyer

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

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

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

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

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

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

The vital behaviours for successful software projects (agile or not) are simply these: a) improve communication by co-locating, b) get access to the customer and c) have short delivery cycles. (Read part 1 of this post here). This is so simple, and yet agile adoption continues to be a big question mark for many people and a track is dedicated to the question at Agile2011. So how can we influence these three 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 to make sure the vital behaviours occur. But first, let’s look at some quotes from the book that describe strategies that we often find ourselves using, but that have been proven to be ineffective:

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

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

Understanding that I am a beginner influencer, here is a brief summary of the six influence strategies found in the book with concrete examples of how you can execute these strategies in order to bring about the vital 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 not likely to exhibit that behaviour unless you can convince them it is fun. One way to make the behaviour intrinsically satisfying is to turn it into a game. Keeping track of things like velocity and the number of passing tests in a visible area can be a fun way to keep score. As the team has early successes, find fun ways to recognize them for their accomplishments such as completed stories, iterations with decreasing defects and happier customers. One of our teams rings a cow bell when a story is completed and employees cheer when they hear the bell. The team also gives a syphilis stuffed toy to anyone that breaks the build (they can redeem themselves by buying donuts). These are simple ways to make new behaviours fun and desirable.

2) Surpass Your Limits (Personal Ability)

People need to be convinced that they have the ability to make the required changes. Send your team to a hands-on agile training so that they can experience what it is like to work on a project that exhibits these vital behaviours. Make sure that the training is hands-on rather than lecture based. Once the project has started, help your team to gain confidence by starting with short delivery cycles where they are producing working, high quality code (even if only in very small batches). Once the team sees early results 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-located area. According to one of the studies in the book, “one variable more than any other affected how people behaved: the presences of one more person”. Putting people in a common space with expectations set for the 3 vital behaviours will improve your team’s chances of changing their behaviours. Also, find the opinion 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 there are included in the process they will begin to share your ideas with the team and the vital behaviours will occur.

4) Find Strength in Numbers (Social Ability)

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

5) Design Rewards and Demand Accountability (Structural Motivation)

Any system of rewards can be dangerous. The book is very careful 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 would be to create a visual project management board where individuals can move post-its from one column to another as they progress through the steps required to complete each story. Moving a post-it is can symbolize a very small reward that happens during your daily stand-up meetings. Rewards such as the cow bell used above for completed stories can also be simple and effective.

6) Change the Environment (Structural Ability)

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

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

Agile Adoption - 3 Vital Behaviours

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 be helpful for guiding an agile adoption.

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

According to the authors, any change can be made inevitable if 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 were identified 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 marriage can be determined by looking for the following vital behaviours during arguments:  a) statements that communicate shared respect and purpose, and b) taking timeouts when required to halt emotional escalation. The best teachers a) reward positive actions often and 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 that we are looking for is to have successful projects. Agile adoption may or may not be required to meet that goal. If then our goal is to have successful projects, has anyone done the research to find the vital behaviours that are part of all successful software projects? Indeed – Alistair Cockburn did significant research into this topic and found three common behaviours amongst all successful teams. He described his findings in a 2006 Agile Toolkit podcast where he said: (starting at about 3:25) “Those that were collocating face to face, short delivery cycles, access to customers were delivering. Those that were following some process very carefully were not delivering.” In an article where he describes his research methods and results he writes that a) they improved their communication by co-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 that if you simply put four people in a room with whiteboards and computers, give them access to the users, and have them deliver running software every month or two, they would have a high likelihood of success in delivering useful, working software. Surprisingly, this hypothesis has not yet been broken." Reflecting on my own project history, I find that I agree with his hypothesis. You can read more about his research here. Notice by the way, that all 3 of these behaviours 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 included in the 7 properties of Crystal Clear. However, of the 7, only 3 are listed as mandatory and one of the above was not included in the mandatory list. “Easy Access to Expert Users” was excluded (still on the list, but not mandatory) and replaced by “Reflective Improvement” despite his findings and hypothesis. I’ve asked Alistair about this and look forward to his answer – I’ll keep you posted.

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

While these 3 vital behaviours may be the ‘key’ behaviours that will help your team be successful, they will also spawn other behaviours to improve your results. For example, in order to have short delivery cycles, you will need to deliver small increments of value which could lead your team towards the practice of user stories. In order to have short delivery cycles and not spend an inordinate amount of time doing manual regression testing for each delivery, your team will likely move towards automated testing. In order to have short delivery cycles and not spend an inordinate amount of time creating deployment packages, your team will likely move towards a continuous deployment practice.

In conclusion, if you are a manager, executive or coach wondering how you can make your teams more successful but have struggled with or without agile techniques, try encouraging and supporting these three vital behaviours as a starting point and then examine the results. Then, use something like reflection workshops to examine the results and start adding, deleting, or modifying practices over time to improve your results. Based on what we know about organizational change management, this iterative approach to process improvement has an increased chance of being successful. If the Influencer book is correct, (and there are lots of examples in the book to indicate it is) then these three behaviours should make a significant impact on your projects.

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

User stories and sandbag dikes

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.

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 its relationship to usability

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

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

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:

• http://www.agilemodeling.com/essays/agileDocumentation.htm/
• http://tynerblain.com/blog//2010/11/16/agile-documentation/
• http://watirmelon.files.wordpress.com/2011/05/specificationbyexamplealovestory.pdf

Agile Documentation - Part I

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

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

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

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

• http://blog.mountaingoatsoftware.com/how-do-story-points-relate-to-hours
• http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html
• http://www.sdtimes.com/link/35401
• http://www.targetprocess.com/blog/2011/04/5-reasons-why-you-should-stop-estimating-user-stories.html

Agile as a risk mitigation technique

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

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:

1. Gather team members for the exercise. Not everyone needs to participate, but you should have willing participants from each role including developers and client.
2. Decide on a focus for your UX design. This could be a specific release, user scenario, or some grouping of user stories.
3. Hand out 8up papers and pencils to everyone on the team.
4. Ask everyone to create 6-8 sketches of the different pages/screens in the app (see tips below).
5. 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.
6. 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.
7. Repeat steps 3-6 until the team reaches a consensus on the design.
8. 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"

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

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

Team 1 Discussing their strategy



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



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


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

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

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

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

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

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

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

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

Example 1 - double teaming:

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

Example 2 - helping:

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

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

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

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

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

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

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

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

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

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

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

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

Quit your belly-aching and try it!

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

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

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

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

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

Iterative Development and User Story Slicing

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

Here is a quick discussion on Iterative vs Incremental development:

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

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

Some of the disadvantages are:

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

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

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

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

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

A further release with more story slices implemented:

The final release:

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

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