Four months ago (March, 2006), I signed on to be Director of Operations at a small web company.
Tonight, I had dinner with a friend and former colleague. We’re both project managers and we both left an established XP shop in the beginning of this year. We compared notes on what we have tried in our new environments. Interestingly, we’ve been successful with different practices from the same set. She affirmed some of my experiences, and it was especially intriguing to hear where our experience differed. Here’s a little of my side of it. Sorry it is just a big list right now. I will expand certain parts of it sometime later….
Old place features
- co-located team
- war room
- no personal space
- daily standup
- weekly estimation
- interactive planning game
- iterative and incremental development
- test-driven development/unit testing
- formal roles and practices
- coach
- project manager
- interface/interaction designers
- developers
- paired programming
- time and materials contracts
- iteration status corkboard
- agile resource scheduling
- a mix of employees and subcontractors without long term commitments
- teams varying from 2-20 individual members
- “interchangeable” parts
- less emphasis on individual heroics
- not enough projects
- old role: subcontractor
New place features
- dislocated
- with remote team members in Berlin, Chicago, California
- have personal space/big office
- blurry roles based on talent
- PM/interaction designer/sales support/proto-coach (me)
- former PM/information architect/mentor/developer
- designer/developer/creative lead
- information architect/process coach (talltom)
- though there is one clear role: rainmaker
- fixed price contracts
- too much work for current resource base
- infrequent heroics required
- new role: employee
What I’ve tried that has worked
- daily stand-ups
- estimation (though not always weekly, especially with remote team members)
- interactive planning (though not always each iteration and only with time and materials client)
- iteration status corkboard
- hand-written storycards
What hasn’t translated (yet?)
- remote team members can’t see or use corkboard, and other systems (email, wiki) don’t seem to work well yet
What I’ve missed and am working to re-establish
- more people around,
- ability to flex well with demand (though I’m growing a small network),
- the counsel of my friends/former colleagues (but I’m working on this)
What I’m not doing well enough yet
- predicting resource needs for future iterations
- providing firm schedule milestone dates to clients and meeting them
- sharing the load of our lead developer/expanding the team
What has made me happy
- being reminded by someone else it was time for stand-up (simple pleasures…)
- when I heard that weekly estimating helped the lead developer think about the project
- request for additional corkboard space
- promise of homasote on the walls
Stephen says
More corkboard and homasote!
Wow, a small web company. Sounds like frontier medicine of the times. You even have your own rainmaker 🙂
Now that you’ve set up a blog, whenever you hear about bloggers blogging in the blogosphere, you’re in the know. And knowing is half the battle.
dunrie says
You can see in some of the other posts that we’re struggling with stand-up too…
Helene says
Ok, I’m the dinner colleague – so here are my comments/thougths on Agile practices:
One of the things in Agile that I’ve found is that people really LOVE story cards. I’ve seen them used in Corporate America and in small-town businesses alike, and the reaction is always the same, enthusiastic acceptance. Because the story cards provide so much more information than simple title and one sentence descriptions often found in project schedules, and that the story cards I use are hand-written, even the handwriting, the word emphasis, and the diagrams included on the card are all clues to what is being envisioned. Adding to this is the fact that these story cards can be added to, and removed from the project all along the way, people suddenly love the ability to work on what is there and not try to gather the perfect requirements right from the start. People love the concept of a “work in progress” approach which is essential to Agile practices.
The story cards I’ve found useful contain the title, the description of what is to be done and clarifying what is produced–how will one know it is done?, what category this story card fits into for the specific project (specific business process this supports or screen design) or what role this task is assigned to (subject matter expert or developer?), a diagram or attached screen shot when a visual is useful, and the date the story card was written. This date item turns out to be the single most important item on the card. This date tells us that the card was written in the first 2 weeks of the project, and four months into the effort, we realize that the undefinable activity described (despite our best effort to define it) was an early attempt to capture a thought that became clear as we moved through the project and learned from each other, and could now be cancelled.
Planning sessions work equally well in the corporate arena as well. The kind of planning sessions that I mean are those where all the story cards are estimated by pairs of people, then laid out on 11×17 planning sheets that make up a week of effort. This week of effort is usually less than 40 hours, since in the corporate environment, no one is dedicated to just one project, they are usually juggling 2 to 3 projects at any one time. So the planning sheets I’ve been using have 40 hours of effort on them, but the dates for scheduling this 40 hours of effort is in 2 week blocks of time. These planning sessions have been accepted almost as well as the story cards themselves. Again, I’m letting the team schedule their tasks as a team, and people really like having a say in what they do! Especially in environments where the usual situation is someone else tells you what to do and when. In my current contract in a large company and defines “Corporate America”, the team has become so excited by the planning session that they couldn’t wait for the planning sheets to come out and get into pairs to re-plan their tasks for the 3rd and 4th quarters’ work. When I stopped them to evaluate the current cards and estimate them, they were disappointed with the delay of playing with the sheets of paper! To paraphrase Eisenhower, plans are useless, but planning is essential.
What has not worked as well for me is stand up meetings in corporate America. The culture of separate cubicles and offices, teams where people sit scattered throughout the office area instead of in a clustered arrangement, closed doors, overly scheduled days through a calendaring tool, and utter quiet in the office area makes this dynamic and short meeting difficult to take hold. I can’t just put it on their calendars — people too often ignore their meeting reminders. People see it as another interruption into their day, and resist coming or find a way to be “on the phone with an overseas client” during the standup meeting. I have tried canceling the weekly status meeting and replacing it with a daily stand up, and guess what, no one came to the stand up except for the managers! Wow. Again, the corporate culture of loathing interruptions makes this dynamic and short meeting difficult to maintain. I’m interested in suggestions from those who have been able to overcome these obstacles in the corporate world. Then again, this may be one of the Agile practices that just don’t “compute” in the corporate realm.
Chris Gates says
I agree with Helene’s enthusiasm over story cards. Of all the agile tools and practices I have used, I think story cards are the fundamental unit of Agile. If you “get” story cards (that is, if your story cards are well-formed) then all the dependent processes and tools (status board, planning sheets, estimation, standup) may work brilliantly.
On the other hand, it’s easy to screw the works if your story cards are not well-formed. (I’ve seen it done, and I’ve done it myself.) This raises the question, “What does it mean for a story card to be well-formed?” I try to validate my story cards with a mental checklist, but in the spirit of collaboration, rather than spew my list as gospel, I’ll follow Helene’s excellent example by nominating my Most Valuable Aspect (MVA) of the story card.
I think the story card MVA is the *estimate of effort*. It’s a rather subtle thing to take an idea that you may not fully understand and assign it a number. Pragmatically, the process of estimation flushes out unclear or subjective requirements; it resolves mismatched expectations between analysts and developers earlier; and it exercises and develops the team’s collective “design intuition”. And I always felt that the excitement of development actually starts with estimation. It’s a little grain of shared commitment and the infinitesimal push that gets us started on the journey from what we have, toward what is possible.
Chris Gates says
I second Helene’s frustration at the corporate rejection of standup meetings. Often this is a reflection of the existing bureaucratic context. Helene, as a suggestion to ease adoption, you may want to consider this approach:
All Team Memo
Re: Standup
Starting Monday, for one week, the entire team will gather once a day (more-less-randomly) to hold hands circling a smoldering sprig of sage while singing “Kum bah yah”. After that first week, the team will decide by consensus whether to invite the rest of the company into the song-circle, or switch to daily standup meetings.
Sincerely,
Your Friendly Project Manager