So you’re an Agilist but you’re on a team that “doesn’t do Agile.” What do you do? Let me share with you the story of my first “Agile-like” project. For all intents and purposes, it was a traditional (i.e. waterfall) project that spanned nearly three years. I’d already worked in the organization for several years before this. This was my fourth product cycle with them, and while we reviewed our team’s processes at the end of each cycle and put improvements in place, this was

If dig into my LinkedIn page just a bit, you’ll see that I’m not only an Agile Coach, Consultant, and Project Manager, but also a published fantasy novelist. I co-wrote a novel with my spouse in 2017 that was published in late 2018. And yes, we’re still married, and have written many, many more pieces together since. And yes, we both take Agile so seriously that we actually applied several Agile techniques and concepts when we wrote our book. Here’s a rundown. Worked from a B

Last time I talked about how my team used Pair Programming on a several projects, how we found it beneficial to us, and a few of the downsides. But does that mean Pair Programming would work for you? Proponents of Pair Programming do tend to love it, but despite how excitedly we describe it, Pair Programming is not always the best choice. Depending on your project, it can be costly, unnecessary overhead. Pair Programming has a higher up-front cost, and, depending on your spec

Something I’ve discovered during team interviews for Agile Maturity Model Assessments is that a lot of people misunderstand what Pair Programming actually is. As a former skeptic who’s now a real fan, let me explain—and encourage you to try it out. A lot of people I’ve talked to think Pair Programming just means two or more developers working on the same user story together by splitting up the work between them, with each person working on certain tasks: maybe one writing tes

This week, Sarah Stewart has been unfortunately…tied up. Instead, we have a guest blogger this week: The Evil Agile Coach. -- So, you’ve bought your purple and green suit. You’ve constructed your secret lair. You’ve designed your doomsday device and acquired your hench-people. What’s next on your road to supervillainy? Villainous Agile! Yes, here is how you, as a supervillain, can use Agile for evil while following all* the rules (after all, you don’t want to get caught)! *No

They called me in to coach this Scrum team because their product owner wasn’t accepting their user stories. “I don’t understand it,” the Scrum Master told me. “Our burndowns are perfect!” And I looked, and they were. I mean text-book perfect. Going back at least six sprints, the team’s daily completed task rate nearly always matched the guideline set out by the tool. They rarely added tasks after the first day of the sprint and never after the second. Tasks totals matched the

Previously, I said that one way for teams to get better quickly is to make their User Stories smaller. 3-5 points, half a sprint or less. This is a great way to improve your team’s overall output, quality, and flexibility. But sometimes, User Stories can get too small. When I was still very new to Agile, I attended a workshop where they talked about writing your User Stories super small. Their team had shifted from counting Story Points each Sprint to the counting the number

Previously I’ve talked about basics: User Stories, relative sizing, and how new teams determine their velocity. Now I’m going to talk a little about how teams mature beyond the basics. First off, few Agile teams get to mature much past reaching a steady velocity. The longer a team stays together the more opportunities it has to improve, but few teams last long enough for that. Changing even one person on a team disrupts it. Maybe not to the point of starting over, but it can

Say you’re supposed to help some people get fish. You can just buy some fish and give it to them. Better, you can teach them how to fish—show them how to use a fishing rod or tie a fly. These ideas both go back to the old "teach a man to fish" cliché. Alternatively, you can offer them fishing poles, bait, and nets, and encourage them to figure it out for themselves. Good leaders help people to help themselves. But a true Servant Leader will ask the team what they need to star

When I first heard of "Servant Leaders" I imagined a literal servant, like the biblical Jesus washing his followers’ feet. Or my old VP serving burgers at a team barbeque. But that is not what Servant Leadership means (not to say those guys aren't also Servant Leaders). Servant Leadership inverts the conventional leadership model. Instead of driving your employees, assigning them tasks, and judging their results, you give your employees goals and then protect them from interr

When doing estimates with relative sizing techniques, we recommend using numbers in the Fibonacci sequence rather than t-shirt sizes (S, M, L), 1-10, percentages, or other similar values. While you can use any sequence you want, Fibonacci has specific features that help you do better relative estimates and make your estimates more useful. Numbers in general are useful because you can add them up to create a velocity value, which helps the team plan their sprint and can t

Brand-new Agile / Scrum teams (or teams with recent turnover) can’t say predictably what their velocity is. I see teams struggle with this a lot, and they struggle because there isn’t a clear answer. Formally, a team’s velocity for a sprint (or iteration) is the sum of the points for all completed user stories that have met the team’s Definition of Done. A team needs several sprints of working as a unit to produce enough data for a predictable, reliable velocity. Understandab

“Relative sizing with story points.” You’ve probably heard the phrase, but it can be hard to wrap your head around the idea. If you haven’t heard of it, here are some resources: Definition of Relative Size Using Story Points for Sizing It can’t be as simple as it sounds, can it? It seems vague. Imprecise. Arbitrary. Well, yes, in a way it is. That’s what makes relative sizing useful! Here’s an analogy that may help you understand how and why we size user stories with relative

Middleware developers often have a tough time writing clear user stories because unlike consumer software, middleware rarely has clear users. Developers may wind up either using the same vague “API Customer” user repeatedly or dropping the “user” from their stories entirely. But having a meaningful user in mind for stories can prevent a lot of problems. Here are some creative ways to use personas as your users for middleware. The “user” in a user story value statement gives u

As an Agile coach, I’m asked a lot of questions about writing user stories. At the top of the list: "how do I write a good user story?" and "Give me an example of a good user story." That second request is tricky, since what's good for one person might not make sense to another. But I'll tackle the first question here with some examples. First of all, I highly recommend using the "value statement" template to write all user stories, features, and even high-level items like ep