My friend and former colleague Jay Boehm, a Senior Development Manager and I frequently discuss issues we face when working on development teams. Jay has been particularly interested in the daily standup that gets a lot of exposure in Scrum and XP. I gave him my usual rant about how all good things on a project flow from good communication, and some pointers on holding a successful standup, such as:
- Keep it 15 minutes long
- Limit discussion to:
- What I worked on since the last standup
- What I plan to work on today
- Any issues preventing me from doing my work
- Don’t use standups for employee evaluation
Jay reported back to me today:
We’ve been doing a daily stand up for about 3 weeks with my team, and I am really, really pleased with how it’s working out. I love how people talk afterwards and make plans to tackle problems. The shy ones on my team are starting to gain some confidence in their colleagues. It’s great. I’m becoming a convert.
I love hearing stories like that. Nice job Jay!
I get asked a lot about how QA folks or software testers can fit in a Scrum environment. I haven’t posted much on my blog, but InformIT asked me to write about my experiences. Check out “Conventional Software Testing on a Scrum Team” for more.
I was recently involved on a project and noticed something interesting. I was writing documentation for a particular feature, and had a hard time expressing it for a user guide. We had made a particular design decision that made sense, and it worked intuitively but was difficult to write about coherently. As time went on, we discovered through user-feedback that this feature was confusing. I remembered how I had struggled to write about it, and shared this experience with my wife who worked as a technical writer for several years . She replied that this is very common. A lot of bugs that she and other writers found simply because a software feature was awkward to write about.
I’ve found that story cards in XP, or Scrum backlog items can suffer from incoherence, like any other written form. Incoherently written requirements, stories, use cases, etc. are frequently a sign that there is a problem in the design. There is something about actually writing down thoughts that helps us identify incoherence. When they are thoughts, or expressed verbally, we can defend problem spots with clarifications. When they are written down, we see them in a different light. What we think we understand may not be so clear when we capture our thoughts on paper.
Some of the most effective testers I’ve worked with were technical writers. They had a different perspective on the project than the rest of us because they had to understand the software and write about it in a way an end-user would understand. They find problems in the design when they struggle with writing about a feature. Hidden assumptions can come to light suddenly through capturing ideas on paper, and reading them. When testing, try writing down design ideas, as well as testing ideas, and see if what you write is coherent. Incoherent expressions of product features or test ideas can tell you a lot about development and testing.
Edit: update. I wrote an article for InformIT on this topic which was published Sept. 30, 2005.
I’ve been getting asked lately about how a software testing or QA department fits when a development team adopts Scrum. I’ll post my experiences of working as a conventional tester on a variety of Scrum projects. Stay tuned for more posts on this subject.