Tag Archives: project management

It’s the Small Things

One of the things I’m noticing with some of my fellow coaches is their desire to work at the program and enterprise level. It seems there’s nothing like coaching a bunch of teams at once to really get your feet wet. Things look better at scale!

Well yes, and no. I’ve been fortunate to have several work experiences with teams and organizations of all sizes. Last year I worked with a team of two guys in a broom closet. A couple of years before that, I worked with an organization that had over 20K IT folks working almost a thousand projects. On six different occasions I’ve had the pleasure of helping to set up and run programs — teams of teams. A couple of times more than one program at a time.

I’m not trying to brag, just let you know that I have had the relevant experience to talk about this. I’ve been there, done that. While yes, it’s kinda cool working with groups of teams, it’s also very easy to make a lot of mistakes that you never realize you are making. Here are the most common ones.

  1. Premature optimization. The first thing large groups of teams want to know is: what’s the standard? Because you can’t manage a lot of people without processes and standards. (At least in their minds)

    Coming from Agile, many of us know better than to focus too much on process, but clients insist. They want job aids for everything from stand-ups to sprint closings. They expect coaches to all deliver identical advice on any topic.

    This is a really bad trap, because the entire premise of Agile is that individual teams and situations are so varied that we must push a lot of process decisions onto the individual teams. The purpose of our Agile rituals and delvierables is to identify the work and possible paths for solutions: what problems do we face? What types of actions might help the most?

  2. Us versus Them. One of the worst things that happens, often without the coach even knowing it, is that they begin to fall into an “us vs. them” attitude. Who are these teams? How come they keep doing stupid stuff? Why won’t they listen? Over time, you subtly stop being a servant for the teams and start wondering why the nincompoops just won’t do what they’re supposed to do.
  3. Tools will fix anything. Once we get sufficiently detached from the actual problems the teams are facing (and this can happen inside the team, you don’t need a program for it) we start buying into the idea that the tool can fix the behavior problem. Need folks to start making comments when checking code in? Just force it to happen! It’s magic — because you’re not actually dealing with the problem, just the symptom. You’re using a hammer that’s close-by to pound on a problem that’s close-by. Many times the thing you are pounding on is fitting a square peg into a round hole.

The more I work with both large and small groups, the more convinced I become that the vast majority of problems organizations face are at the team and individual level. If teams don’t provide timely and accurate information to people outside the team who need it? You’ve got junk. If teams don’t manage their quality and testing? You’ve got junk. If teams don’t communicate and problem-solve effectively? You’ve got junk. If teams keep trudging along punching the clock without creatively re-framing their problems in order to make life easier? You’ve got junk.

So yes, it’s lots of fun to be helping and working on a 100,000-hour+ program. It’s even more fun to be helping set enterprise policy. But those things are way less important — and way more likely to actually hurt things instead of helping — than the small things that the teams and developers do everyday.

Trust me, it’s the small things.

Note: One of the things most people fail to understand about groups of people is how naturally decentralized they are, even in highly-centralized organizations. People think “We’ll just make a policy to do X” without any idea of how it actually is going to play out. People think if somebody is in charge of a large group of people that they can just tell folks what to do. There’s a ton of myths about how large groups of people are actually led — enough for another entry!

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Ruined My Life

I read the reply to my comment on a popular hacker board with sadness:

(disclaimer: Agile consultants ruined the software group I work in.)

Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up

Reminded me of an email I received back in May:

[We] started working on [agile technique X] when [author]‘s [famous book] was just a draft. I was on that project and worked on Agile Projects for a decade. (Next time you meet [famous guy], ask about me, I just finished reviewing his forthcoming [another famous book]). I am a founding member of the Agile Society of [place] and have organized conferences on Agile. I’ve attended XP Conf as well. I’ve probably worked in more agile projects than you ever have (not that it particularly matters). So let us first dispense with the notion that your notion of what constitutes “true” agile and its scamsters is somehow the only standard….

Do you deny that the whole Scrum Master idea is a scam within the Agile Camp?

Scamster? Ron Jeffries the guru/founder of Agile couldn’t write a Sudoku implementation with his favorite technique “TDD” and refactoring over five weeks. Fraud.

Robert Martin (another “guru” and agile consultant) claims that any code not written with TDD is “stone age ” code including such things as Unix and such people as Norvig and Linus and Zawinski who’ve built more code than he can dream of. Dalke poked holes in his TDD “kata” which never got answered Fraud.

I could go on and on. And these are the gurus. But that isn’t the point. i *saw* “agile consultants” evolve from some naive but well meaning people (like Kent) to scamsters like X and co and tose are just at the top. Practically every single “Scrum MAster” is a fraud. The more intelligent among them admit that two days of listening to a higher level shyster teach nothing and it is just a signal to dumb managers to improve their chances of getting a project. Yet they go along. That in my eyes is a scam like chiroproctors or reiki people claiming to be doctors. Agile was amovement founded by scamsters and propagated mostly by scamsters.

I’ve had many such conversations over the years.There are some seriously pissed off people about Agile out there. Why? Isn’t agile supposed to be warmth, apple pie, motherhood, goodness and all of that? Why so much anger?

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Project

In the Beginning was the Project

And then came the Assumptions

And the Assumptions were without form and void

And the customer conversation was completely without substance

and the darkness was upon the face of the workers

and they spoke among themselves, saying

“It is a crock of shit and it stinketh.”

And the workers went unto their Supervisors and sayeth,

“It is a pail of dung and none may abide the odour thereof”,

And the Supervisors went unto their Managers and sayeth unto them,

“It is a container of excrement and it is very strong,

Such that none may abide by it.”

And the Managers went unto their Directors and sayeth,

“It is a vessel of fertilizer, and none may abide its strength.”

And the Directors spoke amongst themselves, saying one to another,

“It contains that which aids plant growth, and it is very strong.”

And the Directors went unto the Vice Presidents and sayeth unto them,

“It promotes growth and is very powerful.”

And the Vice Presents went unto the President and sayeth unto him,

“This new project will actively promote the growth and efficiency

of this Organization, and in these areas in particular.”

And the President looked upon The Project,

And saw that it was good, and The Project continued many generations, and many were overpowered at the size, ineptness and illogic of it

And this is why you are here

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Does Not Mean Doing the Impossible

One of the questions I commonly face as an agile smart-ass/wonk/nerd goes something like this: “We have a year’s worth of work to do and 3 months to do it in. Agile is going to make it happen, right?”

Well yes, and no.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

How to Really Measure Software Teams 2

I teach a lot of project and program managers in my business. And I’ve been there, done that — I’ve ran a lot of projects and programs. One of the things that fascinates me most is the difference between theory and practice.

In theory, you have this value structure from the organization — what’s important to it, what the plans are for next year, what fires need to be put out. In theory you simply define and prioritize these things, create and allocate a strategy, and end up with a list, matrix, GANTT chart, or something similar that gives you the next things to do. In theory, by having a value tree and using SWOT and a bunch of other stuff, like QFT, you end up with the next chunk of work for the next time frame. In theory it’s even better than that, because by comparing your structure with your results, you can create metrics that show when you’re not doing what you want to do.

In practice I have yet to see this work from top-to-bottom in anything but the minds of the creators. This doesn’t mean I consider these things valueless — far from it. A lightweight, cyclical system of work prioritization, allocation, and measurement is absolutely necessary for large organizations to survive.

But in practice, things get messy quickly.

In practice, you have multiple competing priorities that block one another yet each must be done first. In practice, you don’t have enough time to put out the last fire before the next one pops up. In practice, department X wants you to do things one way while department Y requires an exactly opposite way. In practice, you have no support and you’re on your own. In practice, the business can’t make the decisions required of it in a timely fashion. In practice, Congresspeople ring up any time they like and it’s a fire drill until they are made happy. In practice, you have no idea what the market will like and you’re lucky to have some idea of how the next week is going to play out.

Practice is much different than theory.

It used to be the answer was simple — blame the practitioners! And still see this from people from all corners of the development world. I had a TDD proponent tell me last month that the reason developers weren’t adopting TDD was that they were lazy. A friend that creates process models for organizations confided that things would be a lot better “if management would just crack down on those knuckleheads”

I’m not saying that everybody is perfect, and sometimes “cracking down” or “bucking up” or whatever is exactly what’s called for. Sometimes, of course, it’s not. But what I AM saying is that a good set of measurements to take is the perceived problems the teams are having with getting their jobs done. Perhaps by looking at the things that are preventing the teams from getting what they want, you can get what you want too.

It’s good for me. It’s good for you. It’s not the dawning of the Age of Aquarius, and we all don’t have to start singing Kumbaya and wearing tie-dyed shirts , but it’s at least a few steps forward in having a productive conversation about what to fix.

Sounds great but very nebulous, Daniel. What’s it actually look like?

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.