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.

energized work session

While I feel like I know clearly what isn't agile, the title of this blog represents the transition I'm trying to force upon myself. Even though it sounds like I'm saying "don't say it's agile" instead it's time that I learn to say what is agile... and these words are the evidence that I can be the change I wish to see in the world. That being said, I found it an enormous challenge when my company asked me to prepare a 3-hour session on energized work... something that I recognize when I see it, but I couldn't imagine how to explain sufficiently with words. In New York I tried for months to get the team to understand the idea of energized work, and that was in my native tongue! Now I'm being asked to focus on it for 3 hours and I just thought that words wouldn't do it. So I decided to find some games to get the idea across.
Well, I looked and looked, read online about all the agile games I could find, and nothing really seemed to fit the topic. So I made up some games, briefly described below. I got really good feedback from the group, saying they enjoyed the meeting format, the rhythm, and the energy. Good, mission accomplished. Now if I can only get them to do that during the work week. Here's an outline of agenda items and take-home lessons:

• 2pm, break into two groups. One group gets tiny paintbrushes, the other gets huge paintbrushes. The tiny-brush group is told to put their toes against the wall, and never move back. Then, I ask the groups to paint a 5-pointed star, 1-meter long on each side. Oh, and it all has to be done in less than 5 minutes. Go!
  
• 2:10pm, remarks: The point here was to show that it makes a difference, working at different levels of abstractions. With a large brush and the perspective of stepping back, the star turns out a bit more even, and its essence is captured faster. I hope that it's clear that when we're doing story cards, we need to work at a fine level of detail for only short bursts, then jump back out to higher-level abstractions to make sure we're on the right track
• 2:15pm, form pairs, sitting face-to-face. One side of each pair is given paper and pencil; the other is supposed to observe the drawing in progress. Behind the navigators, so they can't see what I'm doing, I hold up a photo of a local monument (it's pretty intricate and hard to reproduce with only a few pencil strokes). I ask the drawers to copy this picture with the objective of making it as accurate as possible for the observers, and that they're done as soon as the observers recognize what the picture is.
• 2:20, remarks: this one didn't work quite as I planned. I figured it would be lower energy but everyone was so excited to be playing games that it was still fast and fun. Still, I described the idea of self-similarity and how I was going to repeat the following pattern throughout today's workshop: high-energy work followed by low-energy work, and that overall we'd see the pattern repeat on a larger scale as well... that we'd start out with lots of games and end with lots of talking.
• 2:30, mind map of energized work: a lot of people hadn't yet seen mind maps, so it took longer than I expected to explain this--but I started with the explanation that I don't really know how to solve our problems with energized work--and so I asked for their help. I suggested the place to start from was a map that shows the things that give them energy and the things that use it up in the workplace; we ended up with a nice mind map on the dry erase board with a few things I didn't know. We then talked about what each of these items meant and/or why they gave/burnt energy.
• 2:45 pictionary
• 2:55 remarks, contrasting these drawings with those of earlier in the day... here we were expressing our ideas much more quickly than when the task was to copy a complicated picture. Hmmm, is it always necessary to make a story chock-full of features? Or can we reduce the scope and do just the bare minimum to get feedback?
• 3:00 Estimation / Promises / Budget workshop: (in light of the mindmap I felt it wasn't as important as the next workshop, so we canceled this and moved on).
  
• 3:00 Scope and Slices workshop: we were to brainstorm to make a flip chart to remind us what to do when a story card is in danger of not being done on time. My notes indicate outside in / inside out / vertical / quick win & cleanup & feedback.
  
• 3:15 Yet brainstorming is of limited value... I think it's the real story cards that can be hard to slice. So I handed out cards from previous iterations... big cards... and we broke down into little groups to practice ways of slicing these stories. Each group got 15 minutes to slice a story, then they passed it to the next group. After two rounds of this, we then had a review of the whole session... i.e., our group sliced this card into these N stories... how did your group slice it? By comparing different results we found new tools for our story slicing toolbox.
• 4:00 break
• 4:15 parking lot (general discussion)
• 4:30 whisper down the lane (point being, if you send one-three words at a time, it's practically a lossless signal, so obviously slicing stories is a good way to go)
  
• 4:45 feedback
  

just got a book review published

A couple of years ago I was selected by Sticky Minds, the online companion to Better Software Magazine, to be one of their book reviewers... so every once in a while I write one and (eventually) get published. My reviews thus far are:

http://www.stickyminds.com/books.asp?ObjectId=957&Function=DETAILBROWSE&ObjectType=BOOK

http://www.stickyminds.com/books.asp?ObjectId=1054&Function=DETAILBROWSE&ObjectType=BOOK