Since I last blogged about Agile I've been doing a lot of thinking about how some ad hoc project teams can come together swiftly and with great effect, and yet others will arrive ponderously to the scrum, Agile books in hand, and very little gets done despite all the issues being aired.
Since we all know project management needs yet another set of buzzwords, I’ve created a new concept: Plucky Project Management™ * .
Plucky, based as it is on cynicism, should not be confused with Keen (with all due apologies to Visual Studio community guy, Keen Brown). A Keen Boy Scout avidly shoots photos of a grizzly bear while hiking. The Plucky Boy Scout would throw the last remaining hamburger patty past the bear's nose, dragging the Keen scout to safety. Or maybe just get the bear rifle ready.
So, what is Plucky?
- Plucky requires that its teams all be a little nuts. My old Gotdotnet team certainly reflected this, running off every few months to get married.
- Plucky actually riffs off of Agile. You need an infrastructure to base your attitude around. You can’t be a badass without a warrior code.
- Plucky requires paranoia. If the project manager can’t be paranoid, hire the crankiest developer or tester to be “The Voice of Paranoia” in the daily Standup. Imagine those two guys who heckle the Muppets, Statler and Waldorf. If Waldorf ain’t chuckling, you don’t have a BS detector in your project and need to find one.
- Plucky also demands self-paranoia. Suppose you were going to be executed by a firing squad at dawn if your last code check-in broke the build. Would you check that in and cross your fingers…..or would you flag the need for more time to setup a damn dev environment where you can do unit and functional testing? (Thought so....)
- Plucky demands…well….a certain individual pluckiness on the part of individual team members. It goes beyond you owning the project as a team. It goes to you owning the team. Irreverently.
How Plucky works according to role….
Developer
You are a developer. Your team mate (also a developer) is a developer drowning in bugs he or she has to finish fixing before Friday. It is now Monday and you are actually ahead in your bug work.
You do not:
- Mock him or her and leave at 3 p.m. every day this week.
- Take the last coffee from the coffee pot without restarting a new brew.
- Loom over the young whippersnapper and pontificate about the days of yore when you wrote code better than that, faster.
Instead: Roll up your sleeves like the singing and dancing urchins in Les Miserables and help the poor bastard out. Sing musicals if you must. (The Windows Live QnA team has a satire of Oklahoma! going right now.) You are Plucky, man! (or woman) Take initiative!
Project manager/Program manager
You are a project manager or program manager. You have a marketing person or product manager type who is suddenly under executive pressure to get a Web feature out with Feature B. She or he does not answer the mail to your Web site, (you and your team do) where customers have thronged in the thousands, asking for Feature A.
Under Plucky, you do not:
- Throw the product backlog document at the marketing person and roar: “Where in this document does it say Feature B?”
- Promise both Feature A and Feature B. (….on that weaselly path, young grasshopper, lies danger….)
- Build Feature A by calling it Feature B. (Well, you might, but only as a last resort)
Plucky means instead of eye rolling a lot (Ok, maybe just a little) you sit the marketing person down and show them the customer data. You say in a kindly tone, I will go with you to Executive Big Dude and talk to him about customer impact and “how we will need x more developers and testers to build what you want for maybe another $100,000 and can we have the cash from that team over there?” Then, you watch their eyes.
If like a junkie seeking a next fix, they seem not to care about the peril of what you’d say to the executive, just that you make it stop hurting for the customer, you are pretty much safe. If they seem to be too eager to see an executive with bad news (maybe to bootlick), start worrying and prepare the slide deck yourself. If all else fails, do C. The customers will be happy and marketers can rename anything.
Tester
You are a tester. Each day, a developer risks the firing squad (see #1 under "What is Plucky?") and turns in code that they did not test. They even break the build more often than not. You tell them politely about the problems but they keep doing it, sure in their arrogance they do not need to do test-driven development….their code is perfect. You do not:
A. Send back sniping emails about how you coded better than that in college and here’s the fix.
B. Fix the build quietly without telling anyone each day at the daily standup. (on that path, lies danger….)
C. Stick your tongue out and turn off their privileges to the code source tree until they get it right.
Test if it wants to, can be the Pluckiest of all the disciplines, simply because under test-driven development it’s supposed to be driving some of the development before any tests are done. And as critics of the code, Test also has the highest responsibility for ensuring their criticism is constructive if not educational.
Walk into the developer’s office while they are gone for the evening (since you are working late filing bugs) with a ream of typing paper and set it down on the desk. For each bug you have filed against the developer’s code, write the bug name or ID on the sheet and then wad up one sheet of paper. Place wad on desk over keyboard. Write, wad, repeat.
If it’s a particularly hairy bug, you can use two sheets. Fill the seat if the desk overflows. Then put large sign on their monitor that says: “Open up the paper balls and read what they say. When you are done, please chat with me about regressions in your code.” Take a digital photo of your handiwork.
There are a couple of things that can happen.
A. If the developer is passive-aggressive, at the morning standup he or she won’t mention the paper balls in the office but they will say something shifty about the bugs. When you are asked what is blocking your work, you say: “This photo, as projected via my laptop onto the meeting room screen, is a visual representation of the work that is blocking me from closing those features. It is performance art.”
Pause while your team experiences a stunned silence. Continue:
“Ruthless acts of test art will continue until our needs are met. Can anyone else help this poor developer before he/she is buried in paper balls?”
B. If the developer is aggressive-aggressive (and we DO want honest communication in Agile, so this is healthier) they will talk snidely about someone putting paper balls in their office. You can stand up then and then say: “Test takes full responsibility for paper balls in the office and ruthless acts of paper ball terrorism will continue until our demands are met. “ (Throw a paper ball at the developer)
“Also, we’d like an Xbox 360 to play while we are waiting for feature code to pass acceptance tests. Thank you.”
Kindly Snickering
This brings me to the one and only management tool you will ever need in Plucky: Kindly Snickering. Snickering on an Agile team should be all that you need.
Agile’s problem is that it’s designed to expose critical issues and get you unblocked, shipping only useful things the customers want. That of course is a large ADVANCE over other forms of project management where those problems might stay hidden or the wrong thing might get shipped. But, Agile doesn’t address the bad egg on the team who hates the discipline of the project, perhaps has compromising photos of someone in the management chain and can’t be fired, or is simply delusional about their abilities. You can expose the problem, but exposing doesn’t solve it. You can escalate to the management chain, but again, what about the photos? And, how do you keep that one bad egg from destroying team morale as others pick up the load for them?
Hence, the Kindly Snickering. Yes, it is not nice to mock someone. Yes, your mother told you if you could not say anything nice, then don’t say anything at all. Yes, there is no such thing as a scapegoat in Agile and frankly it wasn’t cool on the playground either.
You have to be enlightened in your snickering. Don’t pick on someone just because you are insecure or haven’t seen your therapist. If you are a bully, you can’t be trusted with Plucky. See the example for Developer, where the developer doesn’t mock but helps the team-mate. That should be the norm.
But, frankly, if you have an underperforming team member and the exposure of their foibles (which usually happens in Agile) doesn’t help them get on the straight and narrow, then frankly I don’t see the point of wasting team morale on these bozos. They should be buried in paper balls until they submit. The team can SIGN the paper balls, and then snicker. The team can sing “The Paper Ball song” until their team-mate starts laughing, or crying, or leave for a team where at least someone can hit the high notes to “Kumabaya.” The energy the team would have spent bitching about, arguing with, or going around these people could be used creatively, if not getting the bad eggs loving Plucky, at least understanding that they are part of a tribe and the tribe has its values.
Why the sensory element to the Kindly Snickering?
Why go for weirdness in physical things? Singing songs, making crazy confetti showers in meetings, crumpling paper on someone’s desk? What difference does it make if you send a wisecracking email versus throwing a paper ball at a meeting?
In software development or Web site creation, we spend a lot of time working with things that cannot literally be touched. A person is reduced to an email identity or a photo icon on the instant messenger window. It is easy to stay detached, disengaged from your product, forgetful of the other person’s humanity – if there is nothing tangible to look at or work with. I think in the work software world of abstractions, sudden jolts into the sensory experience will have more impact.
This next example is a positive reinforcement, not the negative one of paper balls, but it shows an example of positive snickering…snickering that created tribal warmth.
One time, to support a co-worker’s birthday, Josephine, another MSDN co-worker brought in huge amounts of aluminum foil and we made hats.
Everyone got to design with their hands, molding the tin foil to fit themselves –you couldn’t go wrong because aluminum foil is so forgiving. Each person’s hat was different, representing their dexterity as well as personally. Everyone ate cupcakes and impersonated a crank, protecting themselves from the alien rays coming from space.
It was “in” to make fun of yourself and make a tin foil hat.
There wasn’t a lot of management overhead deciding the “tinfoil hat feature.” There wasn’t any real disrespect in it, either. It had moxie and it brought people together. We all went back to work feeling a little better.
It was Plucky.
* Yes, if I had big money I’d actually trademark this but I’m just a hack. Think of it as PM shareware – if you like the idea, send me a Starbucks card or something.
PPS - you will see me re-post this as I try to figure out why the image is not rendering as it did this afternoon.