Casting Adrift

It's amazing how quickly we forget what problems we used to have and why we were doing certain things. It's kind of like the schitzo who gets on meds, starts feeling better and decides they don't need meds anymore and stops taking them, then gets crazy again.

We relaxed our SCRUM structure when going into the final bug fix stage. It was going OK for a while, then management (who have between barely and never worked with the product) had the hubris to exclude all developers and all testers (including the leads) from the triage process. Needless to say, all progress came to a screeching halt, important issues were being ignored, and most of the staff started reading the newspaper. With all my newly found free time I used my powers of inductive reasoning to evaluate all tasks left for release/support/maintenance (client data load, disaster recovery plans, dry run installs, etc.) and inquired what the overall release plan was.

Answer: Well, we're going to release it, see what happens, then decide what to do.

No f*@#ing wonder every other product release here has been a disaster.

So we're reinstituting the backlog and sprint cycle with everything we know will have to be done. I'm betting it takes management about two more weeks before they realize they're chasing their tails since freezing out the product staff. Hopefully they'll get on board at that point and help get this product out the door.

Importance of Acceptance Tests

Every sprint we struggled with what carrot/stick could be used to get people to lay out acceptance tests. I pleaded. I begged. I did not force, but maybe should have. Now we have a concrete example of why they are important. We're two weeks before release, and one of the major search features was found to return invalid results. Why now? Well, no one had checked to see if it gave correct results - only if it would crash. And 10 days before ship is the first time a stake holder with knowledge of this feature actually looked at it.

Talk about a process breakdown.

Demos and Scheduling

So my peer in the other group is trying to to schedule his first demo. He solicited some advice from me on how to have the demo be useful and get good responses from the stake holders. Well isn't that just The Question when it comes to demos.

They've had to put off doing their demo until next week because he can't get everyone set up for a meeting. And he's not sure anyone will give good feedback. Here's my feelings.

• Don't expect wonderful feedback the first time. These are people who are used to status reports, not interactive meetings where they can influence current development decisions.
• Don't worry about the stake holders getting/giving value from the meeting. The development group gets tons of value just by being forced to honestly integrate the code and cross check what they did against the sprint goals.
• Don't reschedule your demo meeting except in extremely rare scenarios. If someone feels they're too important/busy to make the product demo meeting they're not going to give good feedback anyway. Our product owner lives and works on the opposite end of the country. I stopped even caring if she made the meetings and found a local agent to function as a stand in for her. But do invite (that's the old CYA behavior speaking).
• Do bring a checklist of sprint goals into the meeting. Check them off as the developers demo each item. Bring this checklist to the sprint retrospective.
• Do have your retrospective shortly after the demo meeting. As in half-hour break, then do it. That way it will be fresh in everyone's mind for discussion. After the retrospective, close the book on that sprint and move on to the next.