September 23, 2011

How to Engage an Agile Coach

I'm often asked by companies how they can engage me as an Agile Coach. What would you do? For how long would you be there? How long would it take? My response is always tailored given their specific context. Each situation is different. However, here's an attempt to give a very general response to that question.

In short, you can pretty much design your own ideal engagement with an Agile Coach. I'm sure there is a coach out there that will be willing work with you toward your goals or activities, whatever they are. Although some coaches only do deals of a certain size or of a certain type of work, there is generally lots of flexibility to be found.

For example, depending on what you are after and on your budget, the number of days and the frequency of involvement can vary.
  • Very limited: A day or a small number of days
  • Regular or periodic: A day or three each iteration
  • Full time but temporary: like 1 to 6 months
  • Full time permanent: unbounded
A single small team that just wants some outside eyes once, or once in a while, can get help with a small budget. Involving the coach with more teams and more people typically means more days are needed to accomplish your improvement or transformation goals. An organization looking for coaching for many large non-collocated teams is a much larger deal.

The engagement can be just as simple as "hey, I think we're doing pretty good, but we'd like to have a fresh set of eyes to point out what we're overlooking." That could lead to any number of recommendations that the team is free to tackle on their own. Or that could lead to an additional engagement designed to address some specific issues. Or an engagement can be as broad as be here every day and work with us for three months.

As for the type of work that a coach may do for you, the work of the coach may be in the form of training and workshops, mentoring, coaching, consulting/advising, or getting his hands dirty.

Here are some examples of what you might engage a coach to help you with. This is not an exhaustive list.
  • Limiting WIP and setting limits
  • Using Kanban and Lean metrics
  • Eliminating delay, prioritizing work via cost of delay, and improving flow
  • A3 problem solving
  • Demonstrate many retrospective techniques, lead retrospectives, mentor others as they use these techniques
  • Spotting and removing impediments and managing risks
  • Creating and sizing / estimating the release backlog, using velocity
  • Identifying the MMF set
  • Story mapping
  • Project chartering, vision casting
  • Planning and preplanning
  • Communicating
  • Using BVCs and information radiators, addressing why they are stale and not being used
  • Space and facilities
  • Pair programming, SOLID design, emergent architecture, TDD, CI, continuous deployment, etc.
  • Defining Done
  • Coding katas
  • Design patterns, refactoring, etc., for example through lunch-n-learns
  • Designing and tasking-out of stories; design review; shared task list and working as a team on each story
  • A myriad of dysfunctions
  • Issues with interpersonal relationships, working agreements, appreciation, active listening and working as a genuine team instead of as a simple working group, team accountability
  • Team goals, rewards, recognition, MBOs and other HR/management policies
  • The management role, including management influence and interference, people management
  • Scrum of scrums, multi-layer scrum and kanban
  • Working effectively with remote workers
  • Project portfolio management
  • Documentation
  • Q&A - Address the team's concerns and questions such as:
    • "How should we handle defects and minor changes in our specific context? Plan them and estimate them? Treat them as high priority and don't plan/estimate?"
    • "What should we do if we don't finish a story in the iteration?"
    • "On what day of the week should we have planning?"
    • "We're considering changing the way we do xxxxxx, what do you think?"
    • "We have work left over at the end of each iteration. What do we do?"
This list could go on and on and on. Each coach has their specialties and strengths and would come up with a somewhat different list.

Give me a call and we'll set up a time to craft an engagement of your own, suitable for your needs and your context.

September 22, 2011

What is an Agile Coach?

This is an unusual post for me in that it's just a quote from someone else. I wanted a pointer to it from my blog, so here it comes. Brian Bozzuto over at BigVisible describes an Agile Coach thusly:
An Agile Coach is a professional, working internally as a full time employee or externally as a hired consultant, who is working to help realize a profound organizational change to better embrace the values and principles espoused in the Agile Manifesto. Specifically, this is a person who is doing a blend of a number of activities based on the situation to help that organization overcome barriers to change – be they technical, organizational, or skills based. One of the key values of such a person is their ability to play different roles based on the context, and a high level of awareness of these different potential roles can be a critical factor in their effectiveness.
You should go read the rest of Brian's article.

September 19, 2011

Compact Crank: You Want One #roadcycling


Earlier this year I finally had Atlanta Cycling put a compact crank on my road bike. I'm here to tell you about it. If you know all about bicycles and cranks and stuff, this article isn't for you. This is for those who are wondering if they should change out their standard for a compact crank. If you are wondering this as you struggle climbing hills, then you could just stop reading now and go ahead change your crank. I can say with confidence that you should. Read on if you want to understand what this is all about.

Note that I'm assuming that you don't already have a three-ring crank. If you have a three-ring crank, the only thing a compact crank might do for you is save a very small amount of weight. It will not make it easier to get up hills because a compact crank's smallest ring is going to be larger than your triple's smallest ring. Stick with what you have.

Background

The crank-set is the two or three rings with teeth connected to the crank arms. The crank arms are connected to the pedals. The pedals are connected to the cleats. The cleats are connected to the shoes. The shoes are connected to the foot bone. The foot bone's connected to the...

Anyway, a regular crank typically has 39 teeth on one ring and about 52 teeth on the other. A compact crank typically has 34 and 48, or maybe a couple more. The lower number of teeth in the compact crank-set allows you to spin faster in your lowest gear, making it easier to get up hills.

Notice that I didn't say easy. I said easier. Don't set your expectations too high or you'll be disappointed. A compact crank will not make a hard hill easy. But it can help you make it up the hill without having to mash as hard.

As an aside, developing a fast cadence is good. 'Fast' is, say, faster than 90 RPM. A compact crank isn't going to help you have 90 RPM up a steep hill. I'm just saying that a fast cadence everywhere else is better for your knees and muscles (it's easier n them). It's also better for your heart and lungs (gives them a better workout, which they could probably use). Your heart and lungs can recover more quickly and take punishment for longer periods. There are other benefits to a fast cadence such as the ability to respond and accelerate more quickly. Coach Levi wrote a nice article on this topic.

The Verdict

I like my new crank. As I said above, if you are thinking you might want a compact crank but you are just not sure, just be sure. I'm sure; you want one. I can get to the top now with less fatigue. Not "no fatigue"; less fatigue. If you don't ride much, you might not even notice how much easier it is. I ride the same hills every week and have done so for 4 years or so. That's enough riding that I can notice the difference. If you ride some big hill only once per month, you might not notice the benefit of the compact crank, but it's there.

I also enjoy the 3-gaps North Georgia mountain route much better with a compact crank.

Concerns Debunked

Some people say that a compact crank will make you run out of gear and cut your top-end speed. Eh, well, maybe. They note that you'll "spin-out". Spin-out isn't wiping out, thankfully. Spin-out is when you can't or don't want to pedal any faster. With the compact, I spin-out north of 37 MPH (though I don't remember when I ran out of gear with the standard -- sorry). And I can still coast down hill at 40 miles per hour on my rides. That's fast enough for me. Besides, I'd just as soon coast down hill to rest up for the next climb. I don't need any more top-end. I'd rather enjoy the easier up-hills than the faster down-hills.

Another concern you might have is that you'll run out of gear on the small chain ring and that you'll therefore need to spend more time in the big chain ring. You may be concerned about having to do more shifting. Well, I guess this is true. I do spend more time in the big chain ring. And I do change gears using the front derailleur more often. However, it's not quite as much as you might think. Besides, with the compact crank I can start off from a standstill in the big chain ring as long as I'm not pointing up hill. You need to get good at shifting anyway and if your bike doesn't shift well, fix it.

If you are young, strong and getting stronger, a compact crank may make you slower and cause you to plateau. If you find a mountain climb strenuous, but you can do it and enjoy it in a standard crank, then keep using the standard. It will make you stronger. But if you are young, strong, and getting stronger, then this article probably isn't for you anyway.

Cadence

I wasn't expecting to have a faster average cadence with the compact, but it looks like I do. I was expecting my cadence on most of the route to be the same, with a faster cadence only on the worst hills. I thought the time spent in the lowest gear would be short enough to not impact the average over the length of the ride.

My average cadence on my regular ride used to be 84 to 88. Now it's 87 to 90. Nice. But I do not think it has impacted my pace.

Here's an example with the regular crank: http://connect.garmin.com/activity/29757090

Here's a comparable example with the compact: http://connect.garmin.com/activity/72575356

Same pace, same time of year (winter), faster cadence.

My Dunwoody Cycling group does a faster pace in the summer and fall. My otherwise comparable rides with the regular crank have a lower cadence: http://connect.garmin.com/activity/55940780

But I'm Not Mechanical

I'm quite mechanical and am confident that I could have figured out what to buy and how to change out the crank-set. But I'm not really interested in bicycle maintenance these days. Too many other time demands. If you enjoy bicycle maintenance, then you probably know whether you could do this yourself. If you are unsure, then take it to a bicycle shop. That's what I did and don't regret it.

What's it cost?

I paid less than $350 (January 2011) for a new compact chain ring and crank arms and new shifter cable guides, including labor. It would have been more like $500 if I went with a Shimano Ultrega crank-set, but I went the cheaper route. There are certainly lots of variables, so your cost could be much different.

Recommendation

Just do it. If you switch (or have switched) to a compact crank, share your experience in the comments.

September 13, 2011

Partial Points and an Unstable Velocity

Years ago, back when I was dumber…

Once every three months or so we'd have some incomplete story and we'd split the points, allocating some to this iteration and some to the next iteration. That's dumb.

Instead, for the last couple years when this happens I give no points to this iteration and points remaining (we estimate the remaining work) to the next iteration. Back then, the lower velocity would have caused angst in upper management, but read on.

We estimated our stories in points. We did not estimate our tasks. Our tasks were very fine grained. Most tasks were half an hour to half a day. We did not come up with tasks in planning. I wouldn't change any of that. In fact, it's what I currently try to get my clients to do. The difficult part seems to be the very fine grained tasks.

For us, 0 and 1 point stories were trivial. Normal estimates could be 5, 10, 15, 20, 30, or 40 points. If it was 40 or below, the story could go into an iteration. We would also use 60 and 100 point estimates, but those stories had to be split. Our problem was that the 30s and 40s were always underestimated relative to the 5s through 20s. The scale wasn't linear. We knew this. Knowing it didn't fix it. That made our velocity unstable.

Our unstable velocity caused lots of heart-burn in the upper management ranks and contributed to a lack of trust. If I had a do-over, I would solve this by narrowing the range of estimates allowed which would drive more of the larger stories to be split. I'd limit the range to, say, 5 to 20.

I've also considered solving an unstable velocity by clearly setting a high level of commitment for each iteration. Not stretch goal. Not aggressive goal. A high level of commitment. The team would of course still say what they would commit to. But I would have expected them to meet it. (This has sense been deemphasized in Scrum, and I didn't do it then and I wouldn't do it on most teams now, but it might have helped in this situation, as I describe next.) This surely would have initially led the team to commit to a smaller amount of work. And it would have eventually led to more care being made at the start of the iteration and in advance of the iteration in order to have a well thought out plan. We would have gotten back to committing to the normal amount of work over the long term, but would have given us a much more stable velocity and more predictable pace. Maybe. If done wrong it would have just angered the programmers.

Another way of getting at smaller stories and better planning would have been for us to drop from two-week to one-week iterations. That would also force us to split the larger stories. We already had a great design/task-creation/review approach, but we did that design just in time, during the iteration, immediately before development. With one-week iterations, we could do that work for each story on the 1st day of the iteration between planning and commitment.

And yet another way to crack this nut would have been to switch to a cycle time metric (as in Kanban) or publish only an average velocity measured over four to six iterations.

September 12, 2011

A BVC for Tech Debt

Thinking back to some of my days in management years ago, if I had a do-over, I would create a better big visible chart for our technical debt. What we had was a list of code examples to not follow, some cleanup tags in the code, the occasional debt reduction story card, and sometimes a list of debt-full areas written on the whiteboard.

What else we needed was a consolidated list of our debt on a single Big Visible Chart (BVC). We'd write each technical debt on the BVC as we either encounter it the first time or when we knowingly introduce it. Then each time we encounter it thereafter we could put a dot next to it. A dot for each day it slows us down or for each day of impact it causes.

Most teams I've seen could benefit from quantifying technical debt in this way. You've got to make the impact visible. Otherwise it can be difficult to get the understanding of, or even support from, others in the business. It easy for those who don't interact regularly with the developers and who don't have a recent development background and experience with better practices to lack trust. Not only that, quantifying debt can help a team prioritize their debt reduction efforts and keep them on top of it.

September 6, 2011

Off the Road Again

I'm back! I'm definitely back in Atlanta and hopefully back into my blog as well. As of this month I'm once again focused on the Southeast, but now as an independent lean and agile coach.

Working with Pillar Technology was fun. They are a great bunch of people and have some amazing programmer talent. I'm glad I followed Mike Cottmeyer to Pillar and really enjoyed working with him. I can't thank him enough for the help he gave me early on. I'm appreciative of the slack and the support Matt VanVleet gave me. Working with Pillar also gave me lots of opportunity to work with and be challenged by Matt Barcomb. Always a plus. But going independent gives Pillar and I some relief from the costs and pressures of my travel to the Northeast.

I am engaged with a great client here in Sandy Springs but my calendar through the end of the year isn't full. Help me fill it! I’d enjoy talking through your projects and the challenges they bring and how we can work together. Let's meet up. Give me a call or drop me an email.

These last couple of years I've re-learned how passionate I am about coaching and training. I've never had more joy from work than when I help a team improve their environment and see their appreciation. I've been blessed to be able to do that as part of my job from '99 through '09. And I have been even more blessed to make it my sole focus since then.

Each context is different, a unique challenge requiring a unique prescription. I'm looking forward to bringing this passion and experience to new challenges, in your context, to your environment.