Agile Self Development – Birmingham

In our daily meetings, we review the three questions.  Remember them?

• What did I accomplish yesterday?
• What do I plan to accomplish today?
• What are my obstacles?

Starting this month, we also listed out our small goals striving towards our Epics. My May goals are:

Velocity – the measurement of the rate and direction in the position of an object.

- Wikipedia

We were talking a few days ago about how to deal with stress. The best way to deal with stress is to not get stressed in the first place.  Snarky answer, but it’s true.  I find one of my major stress factors is overcommitting. I’m a people-pleaser – it’s hard for me to say no, hard for me not to volunteer, hard to not come to the rescue.  And what ends up happening is that I drop commitments and disappoint, and thus more stress (to myself and the interested parties) than if I’d simply said “no” in the first place.

When we meet in the mornings and go over what we plan to do that day, I listen and try to catch if someone rolls off a long list of tasks.  One thing we have to remember in this process is that we’re committing to doing things we know we can accomplish.  Agile Self Development is all about creating small successes that we can build on each day to create large successes.  We’ll fail occasionally but we need to make sure we don’t fail because we’ve taken on too much.

One of the hardest things to do in agile software development is to figure out how much work the team can commit to for a sprint.  On one hand, estimating how much time a particular task will take to accomplish can be difficult if not impossible.  In addition, we can’t foresee what interruptions, flare-ups, or schedule conflicts we’re going to encounter as we work.  Trying to balance between undercommitting and overcommitting is a tricky art. Undercommit and we won’t meet our deadline and thus lose money. Overcommit and we run the risk of burnout and poor quality, both of which cost money.  The good news is that as the team works through a project, if they monitor how much they accomplish in each sprint, they start to know their velocity – how much work they can expect to complete in a given time period.

Fortunately, what we do in ASD doesn’t usually translate into lost revenue but it can result in stress. Again, the only way to know our velocity is to track what we’ve accomplished.  Each morning, I log what each member completed the day before and what they commit to for that day.  We haven’t taken the time to review yet and I’m very interested in doing so.  That’s the only way we’ll all get better at this and reduce that stress of overcommitment.

*A complete ripoff of Dave Eggers. Sorry, Dave.

I have a 1966 Buick Skylark convertible sitting in my carport. It’s a gorgeous car and actually fairly rare in that it’s a V6 (yes car geeks, a V6 and not an inline) but it hasn’t been driven in years. The head gasket’s blown, the transmission needs work and I’m sure the tires have dry rot.  I walk past it every morning on my way out of the house. Why haven’t I fixed it?

It’s too big.

When we’re faced with a large project we can easily be overwhelmed. There’s too much to do, too much to think about, too much to worry about. When that happens the beautiful goal becomes the Sword of Damocles.

Combat this. Take the big project and break it into small, manageable projects. At my office, I coach my teams to break down projects into functionality that can be completed within a two week timebox, or sprint. There are two reasons to do this: 1) it forces the team to create smaller, acheivable goals and 2) it gives the team regular, repeatable “wins” – small successes upon which we can build.

“Fix the Buick” is what we call in software development an Epic User Story.  It’s large and fuzzy – there’s not enough detail to really get started.  It’s overwhelming. But consider:

1. Wash the car
2. Rebuild the carburetor
3. Replace the head gasket
4. Replace the points and plugs
5. Put on new tires
6. Drop the transmission and have it replaced/repaired (not sure I want to tackle that one)
7. Clean and refill the brake lines

If I can complete these seven small(ish) goals, I’m well on the way to cruising in my sweet ride.  I know I can do these small goals; they’re well defined and I’ve done most of them before.  I’ve turned a marathon into a series of sprints.

Now if the weather will just get warmer I can start…

As I mentioned, our group meets every weekday morning at 7:30 (yes, AM) at Urban Standard.  As I also mentioned, I’m not a morning person. (Did I mention that? I think I did.) It’s a challenge to get myself up each morning and get downtown in time for our meeting. But I haven’t missed a day yet and I don’t plan on it.

In Scrum, the software development methodology, the team relies on the Scrum Master (yes, really) to coordinate the project, remove obstacles, buffer the team against distractions, and generally enforce the rules.  Something tells me that whoever came up with the term had played D&D at some point.

In ASD, the concept of the Scrum Master doesn’t really work.  Since each of us in the group are working on different goals and not on a single project, there’s no need to coordinate everyone’s actions.  Obstacles to personal goals usually have to be addressed by the individual or by an unrelated party.  The same applies to distractions; the group can give suggestions but it’s up to the individual to avoid them.  And finally, while there are guidelines and suggestions for ASD, there are no rules per se.  In fact, we’re pretty much making this up as we go along.  The only rule so far has been to get together each morning and run the three questions.  Well, that and the meeting doesn’t start until everyone has coffee.

So while I’ve kicked this thing off, I’m in no way the Scrum Master for ASDBhm. Each of us is responsible to ourselves and to our own goals and tasks each day. I’ll chivvy and coach, make suggestions and connections, and generally be there for support. But if you want to join, you have to commit to it. It won’t work if you don’t.

You are your own Scrum Master.

Here’s the site! My goal for tomorrow is to actually write something useful here.