Agile methods like scrum and XP are very exciting, especially when you are first introduced to them. There is something very common sense about the ideas in them that seems to resonate for a lot of people. I know it was that way for me. I’d looked at a lot of different project management methods before settling on XP (thank you Steve McConnell). A lot of those methods looked interesting, but XP was the first one that just made sense. For a young project manager looking for a

OK, Mr. Peabody, where are we going today? Well Sherman, Any time I explain what Scrum or XP is, I start with time boxes. The time box method has been around a really long time. The earliest record I can find in a casual search is where they were used at DuPont in the 1980s. I suspect that time boxes are much older than that. The time box basically applies a constraint to the system. It creates an arbitrary start and end date, usually on the smaller side. You commit to a fixe

If you do a little reading about Scrum one of the first things that you learn are the 5 basic values of Scrum: Courage Focus Respect Committment Openness I’d like to examine one of those values that I watched a team wrestle with recently: commitment. These were really great folks. They were bright, energetic, friendly and passionate about the work they were doing. Within the team they took a lot of pride in their ability to “be agile.” They seemed to be doing a lot of good st

I used to be a weightlifter. All through college, and for much of my adult life I have been in gyms exercising in one form or another. I’ve had some modest success. The experience of joining a gym goes along some standard lines. You’ve probably done it yourself. You show up and they take you around the facility and orient you to the equipment. They may even go so far as to give you some very basic training. You get an introduction to circuit training and then they slap you on

I was asked the other day, “Do you use Scrum at home?” It’s not the first time that I’ve been asked this question. The honest answer is: no. Oh, I’ve used bits and pieces here and there. I’ve put together a taskboard to track work on the occasional big household project. I’ve even built a backlog from time to time. But that is about the extent of it. I’ve been married for nearly twenty years – I’m not about to screw it up with Scrum or any other method for that matter. You wo

This is the way the world endsThis is the way the world endsThis is the way the world endsNot with a bang but a whimper. – T.S. Eliot Did you ever wonder if this is the future of Scrum? Will it eventually go out with a whimper? I think a lot of people fear this fate for everyone’s favorite framework. Go to a conference or follow your favorite luminary on Twitter and you hear a chorus of “That’s Scrumbut!”, “It’s FrAgile”, or “Welcome to Scrummerfall!” And maybe that’s the way

The application of Swarming as a method can be broken down into four main contexts. For each context the process of swarming is different. Allowing for different contexts makes sense, because we really can’t expect the same process to work equally well in every situation. Even the simplest animals are able to exhibit variations in behavior based on the context, so why shouldn’t our processes? We change our behavior to match the circumstances. That is, unless we are using fixe

“Going against men, I have heard at times a deep harmony thrumming in the mixture, and when they ask me what I say I don’t know. It is not the only or the easiest way to come to the truth. It is one way.” – Wendell Berry I looked in the mirror the other day and guess what I saw? The grumpy scrum master. He comes by sometimes and pays me a visit. Old grumpy looked at me and I looked at him and together we agreed that perhaps, just this one time, he just might be right. We sat

When I talk to folks about Scrum, one of the points I make sure to cover is the holy trinity, the three basic roles in Scrum: Product Owner, Scrum Master, and Team. I’m starting to think I must be doing it wrong because when I talk about roles, somehow that role manifests itself as a job. Let me back up a step and see if I can explain what I mean. To me, a role is a transitory responsibility that anyone can take on. It’s akin to what actors do. Actors take different roles all

“If you meet the Buddha on the road, kill him!” This is a popular saying derived from an old Zen koan. When it comes to working with Agile projects I find this saying very appropriate. People who do Agile transformations typically talk about finding the Way (the road) and often speak with almost religious fervor regarding Agile processes. In fact, Agile is really just one short step away from organized religion. You have daily meetings, attend retrospectives where we examine

Recently I’ve been challenged by the question, “Can you change culture?” I think this is pretty common for folks who work in large organizations. The question of culture and how it blocks or allows us to get things done is a thorny one. There seem to be two opposing schools of thought in the agile community on the subject of culture: You can’t change culture, you can only adapt to it (customize your process to fit) You can change culture (through influence, good looks, and th

In the Agile world, coaches and trainers are distinctions that were created in order to create different ways of making money. They have no useful business purpose outside of filling the pockets of consultants with cash. How can I maintain this? Here’s how I see it now: I (used to) have friends who are trainers. They are normal people like you and me. They typically got their start as project managers and or scrum masters just like the rest of us. At some point they go throug

Day two of trying to live the first principle of the 12 principles of the Agile Manifesto (“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”). So far so good. I spent much of the day co-training a class. It was a unique training because we asked the attendees to pick the topics that were most valuable to them, prioritize them, then taught the material. Finally we finished up with periodic retrospectives throughout th

So, for the past week or so, I’ve been developing the Impediments Game. You can see some of my efforts: interation 1, iteration 2, Interlude, and Iteration 3. Now I have no experience or expertise designing games, so as you might imagine, there has been a great deal of trial and error involved in this process. Whenever you add a new element or change an existing rule or component of the game play you are doing it with some sort of hypothesis in mind. For example, If I add “Ac

So today was a day to make a few changes and take stock of where things are at. The first change I wanted to make was to double the length of the game from 20 spaces to 40: Changing the board like this actually raised a few interesting questions about the game for me. First, what does each space on the board represent? It could be: A square, just like on the sidewalk, just a position to advance to… It could represent a unit of time, like a day, or a sprint It could represent

I know what you’re probably thinking by now: MORE on this silly game? Well, yes (I’m so embarrassed). You see, it just gets more interesting as I continue to play with it. Today I decided that I needed to improve the impediments cards in the game. In previous iterations, the cards had the word impediment printed on one side and the impact or cost of the impediment was printed on the other side. I thought it would make the impediments much more interesting if I used some real

Recently I’ve been dealing with disengaged product owners. You know the type: they don’t show up for the stand-ups, when they come to the standup meeting they don’t bring any stories and instead simply review whatever the team has brought to them – and then leave early because they have more important things to do. When they show up for the demo, they obviously don’t recognize the stories and simply give tacit approval to the work that the team has done. And the scrum master

There is something about a well designed process that I find mesmerizing. It really doesn’t matter if it’s XP, Scrum, Lean, or Kanban the end result is the same: for some brief period I find myself seeing the patterns of the process everywhere I look. For example, a few months ago I finished reading yet another book on Lean (Poppendieck’s latest or something like that). There I was in the kitchen washing the dishes after dinner and wondering… …why I always did the dishes in s

Tired of doing the same old tired demos? Maybe it’s time that you tried a science fair format instead. When we first adopted Agile, we had six teams that were all synchronized on the same sprint cycle. This meant that at the end of the 2 week sprint there was a Friday that was full of demos all day long, back-to-back. Some of our project stakeholders found themselves in the unfortunate position of having to sprint from meeting to meeting, just to keep up with all the demos. O

I’ve been a certified scrum master for about 5 years now. I’ve learned a lot from the scrum community. There have been things that I liked and more than a few things that I had quiet reservations about or outright disagreements with. In my scrum master certification course, Ken Schwaber made it clear that we were joining a community and if we deviated too far from the accepted standards held by that group, we could be rejected by that community. If we were judged to have viol