lean startups

After thinking about how Kent Beck has recently been working on his $2/month subscription model for JUnit Max, and pondering how that may give him the opportunity to build the software at his own pace (and I assume that means impeccable quality), I bumped into this article: http://venturehacks.com/articles/lean-startup saying a similar thing but on a larger scale. The idea is that if we minimize startup expenditures, thereby keeping the whole operation lean and mean, it gives us more opportunity to really explore the customers and the features they would like to see. I need more time to ponder this all, but if I had a killer app to build I might start experimenting with this right away...

real slack

Last week I learned something about slack... something I'd forgotten about in my over-scheduled high-performing team in Philly. I think at one point we had some slack in Philly, but it quickly got eaten up by our software-process-improvement tasks and next-iteration planning (we fit it all into Wednesday mornings, because the iteration ran from Wed noon to Tue when we left the office). For a couple of months I've been trying to get my team here in Besançon to buy into the idea of finishing the iteration cleanly before the end of the week, to ensure we have real slack. Well, last week we did it... in a way I hadn't anticipated. We had 8 story cards and 11 programmers; by the time we split into pairs, we got 5 teams working on cards. Here our iteration begins after a planning game Monday morning; everyone was hustling Monday afternoon, and 3 of the cards were done by late Tuesday morning. Those 3 teams reshuffled and we again had 5 pairs working Tuesday afternoon... and we were all out of story cards. Wednesday morning, there were pairs that had no new work to start, and it was difficult to find something productive they could do to assist with the already sliced story cards in progress. So starting Wednesday morning, a third of the team moved into slack time! I had imagined that when we got to slack time, it would be like it was in Philly--everyone finishes at basically the same time. But no, it was much more chaotic. Some people were still doing the disciplined energized-work hustle of their cards, and others were doing who-knows-what.

Then something magical happened. Thursday morning people started talking about their ideas, and their conquests, during slack time. Some people were working on clean-up, some were doing exploratory testing, and others were innovating the next great features for our product. I knew slack was important for maintaining quality and a sustainable pace, but I forgot about the innovation side. In Philly we started saying that innovation was still there--all you had to do was write up a card and get the customer to buy it. All we had to do was convince the customer? Well, that worked well enough for senior members of the team, but new members just didn't seem to have the sway to get their story cards picked. So they'd sneak off in the dark and do their prototypes or proof of concept, then show it to the customer. This got in the way of collective ownership and the spirit of a team of equals.

Last week, we had a new excitement brewing as the iteration was winding down. People were signing up to do interesting little projects, and getting excited about all the clean up they'll be able to do in slack. This will hopefully carry over to this new iteration and help people move the cards fast!

So anyway, having a significant buffer of slack (hey, why not 20-30%) is critical to the health, sustainability, and innovation in the team. Here's to finishing the iteration on Wednesday or Thursday!

flash cards

In general I hate memorization, and flash cards, but over the last week or so I've seen a few I really like. This series of pages about Robert C. Martin's SOLID principles of OOP is really catchy (thanks to Steve Freeman's blog for the info). I also like this summary of the lean seven wastes.

clean slate at the end of each iteration

Unfinished stories mean:

• stories that won't be part of this iteration's deployment, and may have to wait another full iteration for full feedback
• no slack time and therefore wear and tear on the team
• no clear moment in time when all work-in-progress was done-done, so it may be meaningless to tag a release. That is, partially implemented features infect the iteration's release since there is no moment where all committed work has been fully acceptance tested. Yet another way to say that is the code base is left with inconsistent horizontal/technical components added along the way to implementing a story/vertical slice.
  
• no clean slate at the beginning of an iteration, so it can be harder to "turn on a dime" with a new slate of stories--the client will want to finish the ones already partially paid for
• "yesterday's weather" is much more muddy--how much work is left on these unfinished cards?
  
• loss of credibility/accountability
• treadmill effect (without the punctuation of a clean finish, where's the energy of a clean finish and fresh start?)
  

the agile treadmill

I have found that shorter iterations are easier to manage (my team in Philly got down to daily deploys and essentially, 1 day iterations), BUT along with that there's the treadmill side-effect. If you don't have something to punctuate your work, the continuous flow of value becomes about as remarkable as running water, something that's often taken for granted. We still need something, like release parties, theme planning, or regular retrospectives, to keep the human element, the emotional health of our teams, in good shape. I think we also need circadian and monthly cycles, with times to work hard and times to relax (slack) and reflect.