Every so often I meet someone who asks, “Don, what do you do?” Over the years I’ve found the best way to answer this question involves asking what that person does, and then share part of my coaching experience that relates to what they do. You see, an agile coach does many things. What I do falls into one or more of the following categories: Coaching/Facilitation Consulting/Giving advice Mentoring/Guiding Training/Teaching Some Examples I once worked with a product owner who’s team hadn’t quite jelled. Four

I settled into the visitor’s chair across the desk from Nate. Looking at Nate I said “So tell me about your project.” RULE II: START WHERE THE SYSTEM IS1 Nate smiled and wistfully said: “Well, I’m the project manager and ScrumMaster. John will be the Product Owner. He works in our North East office. He should be able to represent the user community. He used to work in it. The tech lead and development team work in Europe.” Pausing he continued, “From what I’ve read,

In Better Process, Better People I talked about retrospectives as a process for learning and improvement. My colleague Esther Derby and I will be conducting two one day workshops on Effective Agile Retrospectives. If you want to make the retrospectives you lead more effective, we would enjoy having you participate in the workshop. We’ll be in North Carolina in March.

One of the great questions in software development revolves around “Is it done yet?” And since the answer is usually “No” the follow on question gets asked, “Well, when will it be done?” I recently chatted with a ScrumMaster looking for estimating training for his teams. The teams work on a 4 week sprint cycle. I don’t have all the details, but it seems the teams have problems estimating how much work they’ll get done in a sprint. The following could be wrong, but in

You can tell a lot from how a story starts. If you hear “Once upon a time …” you’ll probably hear a fairy tale like “The Three Little Pigs” or “The Little Red Hen”. Around camp fires, kayakers like to tell stories that begin with “No kidding, there I was …” and a tale of heart thumping excitement and harrowing escapades of misfortune or lucky escape. In software development stories often begin (or end) with “I’m serious. You can’t make up stuff like this.”1 I

Hear me out. It may not be as far fetched as it may first seem. I’m not going to say how long I’ve been around, but I have two copies of The Mythical Man-Month. I have the Anniversary Edition and the 1982 edition of the original 1975 book. I’m not sure why someone on Amazon is trying to sell the 1982 book for $ 129.95. The Anniversary edition contains four chapters not in the original edition including “No Silver Bullet”. Brooks concludes “No Silver Bullet”

The biggest room in the world is the room for improvement. Officially author unknown, but I heard it from my mother, more than once. Reading Better People, Better Process may make it seem like I’m one of those touchy-feely “people over process” types. I confess I have a fondness for people but I’m also a big fan of process. Luckily, people and process don’t exist as either/or. People and process exist as both/and. Here’s a process that can both improve your other processes your people,

Joe Little does a marvelous job recruiting speakers for the Agile-Carolinas meetings. This month was no exception. Israel Gat from BMC Software discussed “Leading the Disruption”. This presentation focused on releases 2.3 and 2.4 of their distributed system management software. Near the presentation’s end Brooks’ Law was mentioned and the question posed, “Does Brooks’ Law still apply?” Adding manpower to a late project makes it later. ”Brooks’ Law” Why is it so? Jerry (Gerald M.) Weinberg chose to use Brook’s Law in Quality Software Management:

The current mantra for software development hinges around “better, faster, cheaper.” To support these efforts, companies attempt to improve their development process. While helpful, improving the current process has two negative side effects: diminishing returns. The more improved a process becomes the less room for improvement exists. Eventually the process will be as good as possible. over adaptation. The development process becomes highly adapted to the existing system leading to problems when the environment shifts. I say if you want to improve your process, improve

One of the smartest things I did as Interim VP of Engineering for Padcom was let Don talk himself into coming to play with us over the course of several hours overlooking the Puget Sound one weekend morning. Padcom was a small tech company with some unique internetworking technology in the process of building-out into the bigger-time. The unique IP was in software but one of the challenges was shipping a next generation ruggedized client as a delivery vehicle to access markets in public safety.