Train 'em up

On Tuesday I ran the 59 Minute Scrum simulation for our team and the parallel team that will be adopting Scrum. From nothing but resistance to viral adoption of the practice is under three months. Quite impressive. The head of IT (above THUD, in our organization) sat in on part of it and she looked pleased. People are tangibly excited.

So now for some useful commentary on it. It was actually done as two hours instead of one - lunch was provided during the retrospective conversation. It consisted of about 14 people: two dev teams, the test team, and THUD and THOT(both of whom left periodically during the exercise for phone calls, etc.).

The presentation was easy for people to digest, but the exercise became chaotic (which was good). During sprint planning where people were selecting their tasks, one developer commented "If this is how Scrum actually works, it sucks." Their team ended the exercise delivering the most business value. Teams were not clear as to my role as the "Product Owner," leading me to feel I didn't adequately explain the exercise before hand.

During the retrospective we were all sitting and eating. I started out asking leading questions of the group instead of lecturing. Here were some of my questions:

• How did you feel about the exercise
• Did you have an adequate backlog ready or were you re-planning
• What was problematic in the exercise
• Do you thing this accurately reflects a software process
  

That did an OK job of eliciting comments, but not a great job. It also tempered people's excitment about the process (which is not wholly bad). It easily filled the two hours by including a discussion of how the process is working for our pilot project and the problems we're encountering. Overall, it was a very useful exercise.

Sprint Cycle Size

For Sprint 4 we shifted from a two week cycle to the recommended four week cycle. This was mainly due to requests/complaints from the test group for more time to work a test cycle (dev/build/drop/bug/fix).

There is an interesting sociological offshoot of this change. I have witnessed a plummet in the productivity and enthusiasm of the developers, myself included. Enough so that after one week I have serious concerns about our ability to deliver this cycle. The sense of urgency that comes with "less than two weeks to ship" is gone. Everyone has slipped back to a "put off to the end" approach to tasks. I, for one, find myself working on coding articles while doing an absolute minium to be able to say I'm focused on tasks at our daily standup.

The true test will come at the end of the sprint, tho.

What to do about testing?

After the initial elation of developers at being able to get something done, some interesting realities are settling in. For one thing, how do you perform quality assurance? The current state of the process art says things about using test driven development for addressing Quality by reducing overall quality problems, but little is said about the Assurance part of qa. It is an interesting question that is not really addressed by the community.

How do you write test cases against dynamic requirements? In some products it will be enough to state "Quality is Adequate". Our product has HIPPA requirements to adhere to and our customers require documented qa results. How do you change a test team used to being told what to look for via documents being pushed to them to one that will actively adapt and demand answers to shifting questions (pull).

How does bug tracking and resolution integrate with closed iteration cycles.

Should QA be integrated and absorbed by development or should it be run as a seperate, independant team operating as a crosscut or parallel scrum?

I smell a book deal for someone.

Agile testing roadmap

Agile testing resources

Back in the saddle

We had our baby! Right when I was setting up for the sprint 3 planning meeting I got the call to go to the hospital. I was off for the last two weeks, hence no posts. The guys soldiered on, but the process seemed to fall apart. No scrums, little structure. But things did get done the old way, so time wasn't wasted. It does show, however, that the process needs a strong and present advocate to continue. Something of a weakness. I need to identify and train a backup scrum master.

The one thing that was "supposed" to happen during that period was a hard set of requirements would be done along with a functional spec by the new PM. To what should be no one's surprise, this did not get done. The PM lives across the country and turned what was supposed to be a full week planning into a one day meeting. In all fairness, it was ridiculous to hire someone and expect them to do a full assessment and product redesign in one month. The fault is in those that made this the plan. It's amazing how so few things change between companies.