User Scenarios and Lean Solutions

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?

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