February 4, 2012

BigVisible Blog

Four Pillars of Agile Coaching

The Agile Super Coach

Of all the abused words in the Agile domain, none seems to be more abused than the simple word “coaching”. There are numerous people out there professing to be “agile coaches”, and while I don’t mean to denigrate what any of these people do, there is a very broad latitude in the types of things that they do. This can further confound our ability to work with organizations as there may be a disconnect between coaches and clients about what exactly they are doing.

Unfortunately, in the absence of a clear understanding, I have seen people begin to expect that the “Agile Coach” is nothing short of a super human being. The can swoop into any project, turn around the results, and simultaneously coach that group into effectively preventing all those problems from ever occurring again. Or they may have an unnecessarily narrow view of the role and try to put an Agile Coach in a box by insisting they only do training, for example. To be fair, when I encounter these missed expectations, they are usually my own fault. I did not do a good enough job of articulating what the role is I, or anyone else, would potentially be playing in that organization as an Agile Coach.

I can’t profess to be the keeper of truth on this topic, but here’s a model I’ve used to help organize my own activities and to make sure I’m articulating clearly what role I see myself playing.

[Read more...]

The Product Backlog, an Agile WBS

As one of the community leaders for the PMI Agile Community of Practice – unfortunately nicknamed “COP” – I’ve found myself writing articles that end up behind their log on. This article is one of those such instances. For those of you who are members of the PMI, I would encourage you to join the community of practice, as it is becoming a very vibrant online community of project managers looking to apply Agile values and principles to their craft. For those of you who aren’t, I will cross-post here from time to time. Articles like his I find to be very important in helping to establish that much of the material presented by the PMI is not so much incorrect as frequently poorly applied. In this case, we see that there is nothing in the formal definition of a WBS that would prevent it from being used as a product backlog [Read more...]

All Models are Wrong, Some Are Useful

“All Models are Wrong, Some Models are Useful”

- George Box

I’m just coming back from vacation and will be resuming my personal goal of one meaningful post per week, but I came across this quote and thought it was incredibly relevant. With the continued discussion about Scrum vs. Kanban vs. RUP vs. whatever comes next, as well as some of the concerns raised about the PMI now getting into the Agile certification business, I think it’s important for us to remember that all these models, frameworks, sets of practices, and other simplifications of the complex craft of software development are wrong. It just so happens that some of them may be useful. Our goal isn’t so much to find a perfect model, or to obsess over the warts on someone else’s, but rather to put to use the ones we find useful so that we can help organizations improve.

Coercive vs. Enabling Bureaucracy

We all know that bureaucracy is bad, right? The tales of insanely complex, rube-golderg-like processes residing within large organizations are too numerous to cite. Most people universally agree that this type of overhead is a negative thing. More process is a hindrance on human creativity, something that should be avoided at all costs. Indeed, many Agile teams see their first big productivity boost from casting aside the detritus of unnecessary rules, roles, and other organizational straight jackets that were keeping a group of individuals from working as a productive team.

If we accept this truth, then does that mean the goal should be to eliminate all bureaucracy? The process rigor seen in most organizations is excessive, but many view it as a necessary evil. Necessary in order to maintain the scale, performance, or consistency required for there particular organization. With this in mind, managers may agree that organizational structure and rules can become stifling, and yet continue to implement it as a necessity for their organization. Quite possibly, they are right. What if the question isn’t about whether or not we have process, but rather what that bureaucracy should look like? Not all processes and organizational structures are created equally.

[Read more...]

The Building Blocks of a Project Pipeline

Scrum is a great framework for building systems, it is simple, elegant and effective. However, it has one limitation that most teams quickly run into: small team size. Invariably, most major initiatives and programs require more than 7, plus or minus 2 people, in order to complete the work in a reasonable amount of time. Or, some organizations face the flip side of this where they run so many projects that the idea of dedicating half a dozen people full time to one initiative is overwhelming. In either case, these organizations are facing the challenge of managing a product pipeline. Let’s take a look at some of the techniques available to manage this within an Agile program.  [Read more...]

Card-Free Planning Poker

This is a simple experience, but I’ve felt compelled to share it and see if other have had a similar one. Simply stated, I’ve stopped using planning poker cards. It’s not that teams I work with don’t use planning poker, but that the cards were too much overhead. [Read more...]

Clockware and Swarmware

Swarm of ants on a clockAt times both the Agile and traditional Waterfall camps get hung up in an unproductive game where they start digging through the details of a problem domain, find a specific circumstance and say, “ah ha! A purely [Agile / Waterfall] approach can’t deal with this situation, therefore that approach is wrong”

Indeed, this binary obsession – that you must pick one specific approach and apply it to all dimensions of a project – is entirely unproductive. In fact, it is usually not the reality in an Agile or traditional project, but rather a limit of our own thought process. The challenge being that if we find merit in one approach, the mind can take an absolutist value. Agile is useful for dealing with product visions, therefore we should apply Agile principles to every aspect of our project.

The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.
F. Scott Fitzgerald, “The Crack-Up” (1936)

Fitzgerald accurately describes the challenge facing us when organizing and executing projects; we must hold two opposing ideas within our head and continue to function. These two opposing ideas well well described by Kevin Kelly when he coined the terms clockware and swarmware as the two different approaches to managing work. They have since been embraced by many complexity theorists and I present them here as my own attempt to hold two opposing ideas and continue to function and show how one builds upon the other, and to argue that a project requires one or the other will inevitably lead to failure. [Read more...]