Thursday, May 19, 2011

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.

Tuesday, May 10, 2011

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.

Wednesday, April 27, 2011

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

Wednesday, April 13, 2011

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

Tuesday, April 5, 2011

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 RiskAgile Practice
Addressing schedule and estimate risksManage to done, Velocity, Relative estimating, User stories
Addressing the risk of building the wrong thingDeliver early and often in small increments, Iteration demos
Addressing the risk of validating your architectureSteel thread, Iterative development
Identifying risks and issues as soon as possibleDaily stand-ups, Frequent retrospectives, Iterative Development, Manage to done
Addressing scope risksIterative development, User stories, User story slicing, Relative Estimating, User story mapping, Trim the tail
Addressing people risksPaired programming, Team ownership practices
Addressing quality risksTDD, 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/