At what point in the project do you start your testing effort? In many project plans that I have seen, QA and/or UAT is added to the end of the project. The development team hands over the code to the testing team who then writes and executes the scripts. The bugs are passed to the developer and the test & fix cycle begins. What fun.
Here is an alternative to the test & fix cycle:
1. Write test scripts before development starts on any particular feature. Test scripts help confirm the requirements with the client and allow developers to have a full understanding of how the code must work. The test scripts function as executable requirements and answer "How will I know when I'm done".
2. Minimize the time between when a features has been developed and when it is tested. This allows you to find defects or requirement misunderstanding early so that developers do not re-build the same defects or misunderstandings into future features. This helps increase the quality of the system while decreasing the time spent in the test-fix-test-fix cycle. Complete testing of any feature should occur in the same iteration that the code is written and should be part of your 'done' criteria.
Both of these two simple steps are based on the Lean Principles of Eliminate Waste and Build Quality In. For more information, check out this article from NetObjectives.
Steve Rogalsky's thoughts on agile and lean in the contexts of software development and life.
Monday, June 7, 2010
Tuesday, June 1, 2010
PrairieDevCon Presentation links
Here are some additional links for my presentations at PrairieDevCon this week.
Introduction to Lean and Agile:
Planning Poker:
Introduction to Lean and Agile:
- Books
- Lean Software Development. Tom and Mary Poppendieck (2003)
- User Stories Applied. Mike Cohn (2004)
- The Art of Agile Development. James Shore and Shane Warden (2008)
- The Art of Lean Software Development. Curt Hibbs, Steve Jewett, Mike Sullivan (2009)
- Agile Estimating and Planning. Mike Cohn (2005)
- Sites
- Podcast Sites
- Newsgroups
- Other links to articles, blogs, videos
- www.martinfowler.com/articles/newMethodology.html
- http://agileinaflash.blogspot.com/2009/08/12-principles-for-agile-software.html
- www.infoq.com/Agile2009 (Videos from Agile 2009)
- http://www.netobjectives.com/files/BusinessCaseForAgility.pdf (requires account registration)
- http://groups.google.com/group/agile-developer-skills/web/draft-summary-of-chicago-meeting?hl=en&pli=1
- http://www.agilemanifesto.org/history.html - History of the Manifesto
- http://www.devx.com/architect/Article/32836/0/page/4 - comparison of seven popular agile methodologies
Planning Poker:
- Links
- www.planningpoker.com/detail.html
- http://www.youtube.com/watch?v=fb9Rzyi8b90&feature=PlayList&p=3F5BBA263D7DF99C&playnext=1&playnext_from=PL&index=2
- - Video of Mike Cohn explaining Planning Poker
Friday, April 30, 2010
List of Agile practices
I read an interesting list of agile practices at Naresh Jain's blog: Explosion of Agile Practices. I think there is a lot of overlap in his list, but it made me re-visit what I think the core list of lean and agile practices should be. My list is below in no particular order. Each item can be expanded - for example, Technical Excellence implies TDD, simple design, following SOLID principles, etc.
1. Daily Stand-ups
2. Visual Project Management
3. Customer Accessibility
4. Technical Excellence
5. Frequent Delivery
6. Frequent Retrospectives
7. Continuous Improvement
8. Continuous Integration
9. Co-located teams
10. Iteration Planning
11. Team Estimating
12. Acceptance Tests (and automation of those tests)
13. User Stories
14. Self Organized Teams
16. Iteration Demos
Update 8/15/2010:
- And one more... Deliver Value!
1. Daily Stand-ups
2. Visual Project Management
3. Customer Accessibility
4. Technical Excellence
5. Frequent Delivery
6. Frequent Retrospectives
7. Continuous Improvement
8. Continuous Integration
9. Co-located teams
10. Iteration Planning
11. Team Estimating
12. Acceptance Tests (and automation of those tests)
13. User Stories
14. Self Organized Teams
16. Iteration Demos
Update 8/15/2010:
- And one more... Deliver Value!
Saturday, March 27, 2010
Agile scope completion techniques
One of the questions I've received in the past about agile techniques is how to ensure you've captured enough detail about your requirements in order to proceed without missing major scope elements.
Whether you are using story cards, features or other techniques to capture your requirements, you need to answer this question: "How do I know when I've done enough requirements gathering?" In waterfall this is ‘easy’ – gather all the detail and sign-off (ok – I’m simplifying). In agile, we depend on features or stories, but many are concerned that major scope elements will be left out which will either cause many items to grow exponentially in size or that feature X is really feature X, Y and Z. For example, when the registration screen has 50 fields instead of the 10-15 that we might have assumed, but didn’t write down. It is hard to understand how this can be done in 1 or 2 days using feature or story cards that contain only one line of description, a few lines of acceptance and a few assumptions.
Three things for you to consider to help you solve this dilemna:
1. In waterfall techniques, although we hold some comfort in our massive requirements documents, we know from experience that even then things will change and things will be missed.
2. My teams estimate using planning poker with the full team including the client and we have found this has helped to uncover hidden or unknown scope. We discuss each item together before estimating and talk about the number of screens, inputs, outputs, services etc involved. This discussion itself often uncovers additional scope, but so does the estimating that follows each discussion. For example, when most of us say ‘2’ and one person says ‘8’, the person who said ‘8’ enlightens the team on the complex caching required to meet the performance requirements listed as an Acceptance test. This is especially important if your client is the one with the highest estimate. Don't ignore it.
3. Lastly, I attended a virtual class on agile estimating that suggested another technique. For every feature or story, categorize the requirements certainty as high, medium and low. Keep challenging your client until the requirements certainty on each story is 'low'.
I'd be interested in other techniques you may be using to keep the initial requirements gathering phase light weight, yet complete. I think as an industry we are getting better at embracing the changes that are inevitable on all projects, but our clients still require us to have a good understanding of the known scope and the resulting estimate before starting the project.
Whether you are using story cards, features or other techniques to capture your requirements, you need to answer this question: "How do I know when I've done enough requirements gathering?" In waterfall this is ‘easy’ – gather all the detail and sign-off (ok – I’m simplifying). In agile, we depend on features or stories, but many are concerned that major scope elements will be left out which will either cause many items to grow exponentially in size or that feature X is really feature X, Y and Z. For example, when the registration screen has 50 fields instead of the 10-15 that we might have assumed, but didn’t write down. It is hard to understand how this can be done in 1 or 2 days using feature or story cards that contain only one line of description, a few lines of acceptance and a few assumptions.
Three things for you to consider to help you solve this dilemna:
1. In waterfall techniques, although we hold some comfort in our massive requirements documents, we know from experience that even then things will change and things will be missed.
2. My teams estimate using planning poker with the full team including the client and we have found this has helped to uncover hidden or unknown scope. We discuss each item together before estimating and talk about the number of screens, inputs, outputs, services etc involved. This discussion itself often uncovers additional scope, but so does the estimating that follows each discussion. For example, when most of us say ‘2’ and one person says ‘8’, the person who said ‘8’ enlightens the team on the complex caching required to meet the performance requirements listed as an Acceptance test. This is especially important if your client is the one with the highest estimate. Don't ignore it.
3. Lastly, I attended a virtual class on agile estimating that suggested another technique. For every feature or story, categorize the requirements certainty as high, medium and low. Keep challenging your client until the requirements certainty on each story is 'low'.
I'd be interested in other techniques you may be using to keep the initial requirements gathering phase light weight, yet complete. I think as an industry we are getting better at embracing the changes that are inevitable on all projects, but our clients still require us to have a good understanding of the known scope and the resulting estimate before starting the project.
Wednesday, February 24, 2010
Planning Poker and Buckets of Hockey Pucks
The teams I've been working with over the past while have been using planning poker for project estimating. Despite initial and fleeting skepticism by a few when we bring out the cards, as a whole our teams and our sponsors are finding value in this approach. I was reminded today that we should look at poker points as buckets of sand. That is, when deciding between a 5 and an 8, if something is a 6, you can probably still put it into a size 5 bucket if you think of the points as sand that can be heaped at the top of the bucket. Also, a 7 would overflow a size 5 bucket but would fit easily into a size 8.
In light of Canada's 7-3 victory over Russia in Olympic quarter finals, I've decided to change the metaphor to buckets of hockey pucks instead of sand. Go Canada!
P.S. I'll be presenting on Planning Poker in Regina in June at http://www.prairiedevcon.com/
In light of Canada's 7-3 victory over Russia in Olympic quarter finals, I've decided to change the metaphor to buckets of hockey pucks instead of sand. Go Canada!
P.S. I'll be presenting on Planning Poker in Regina in June at http://www.prairiedevcon.com/
Subscribe to:
Posts (Atom)