Controlling Management or How the Grinch Stole Agile

We begin with a Poem:

No cute rhymes;
No clever gimmicks.
Domineering Managers
Really mess with things.

OK, so it doesn't rhyme.  It doesn't have any fun or funny made up words and generally sounds pretty negative.  It is.

I cannot count the number of times I've been working with a company where an experimental project is launch using some form of Agile Development, and the development managers say they'll support the experiment - and then proceed to take shots at every opportunity.

The common theme?  "How do you control that process?  It can't be managed."

Somehow, it amazes me when I encounter that mindset.

Consider, organizations realize that the size and nature of a project will not work well with their conventional software development approach.  They publicly state that because of the nature of the project and the lack of surety in the requirements defined in advance that a different approach is needed.  They recognize that people working on the project will need to dedicate the majority of their time to that project and that project alone - meaning they can be available for problems/support activities, but not other projects.

The project room is set up with whiteboards, an open environment and a relaxed schedule where everyone participating agrees on "regular" hours - meaning the hours when they will be there and available - recognizing that some folks like starting earlier in the day and some folks like starting later.  The daily "catch-ups" or "stand-ups" or whatever you choose to call them are at a time everyone agrees make sense, not mandated by someone.  The room is situated so that the people who will actually use the software can stop in, ask questions, check out what is going on or maybe just have a cup of coffee.  (I really push for coffee/treats always being present even if I'm the one bringing stuff in.)

People get together and for four or five hours a day work on stuff.  Together.  Working.  Talking.  Comparing notes.

The first sprint is a little shaky - I've seen that happen most of the time.  People are a bit uncertain what is expected of them and how things will work that the first sprint is almost always a bit shaky.   (Where I've seen that as a given is where "this Agile stuff" is new or an experiment at a more traditional organization.)  The first sprint wraps - those participating for the first time learn and the second goes much better.  Stuff get delivered and demonstrated and stuff works - OR - you've made progress and you know what it takes to finish that off and some other tasks.

About the third sprint, the management grumbling begins.

"What are they doing over there?  Is anything getting done or are they just screwing around?  Why don't we hear anything?  Why aren't they submitting the project documents like they should?"  on and on ad nauseum.

When the invitations are made to sit in on meetings, reviews, or simply come over and check it out - Or - at LEAST - actually attend the progress report sessions we have.  (The name varies by organization - essentially, the summary of what was finished at the end of each sprint.)

Yo! Managers!

If you are invited to attend a meeting where "your people" that are participating in an "Agile" (by some definition of Agile) are talking about and presenting what they have finished - then GO.  ATTEND.  PARTICIPATE.  This takes the place of the documents where you skim the "Executive Summary."

Stop for a minute.  Really.  Consider - We have an idea what the finished product is supposed to do.  We have an idea what the stuff we agree to do every sprint looks like.  We (developers, testers, business experts, customers) work together to make sure each piece does what we believe it is supposed to do.

Does it matter what the details that we did are?  What about "This is the work we have to do to finish this." instead?  If we focus on where we are going, and move forward in measurable chunks, does that not answer the question of "What are you doing?"


The Questions Begin...

What about the stage gate meetings?
Answer - We have them every morning.  You are welcome to attend.

What about the SDLC documents?  The design and architecture plans?  The requirements documents?  The estimates?  The test plans?  WHAT ABOUT THAT IMPORTANT STUFF?
Answer - Those are on the wall over there.  The stuff we have not started on or are going to be in future sprints are on that other wall.  We are tracking all of that real time.  And we talk about them every day.

But how can you measure this stuff?  Your tasks show up in the time reporting system and dare closed every two weeks.  How can that be?  You can't plan anything that way!  Tasks show up on Monday - they aren't even entered before then - and time gets charged against them and then they are closed in two weeks.  That's crazy!   
Answer - Actually, since we're working on pieces as we can, based on system availability, environment readiness and our mutual commitment to deliver top quality software each sprint, what you see makes sense.  The participants figure out what needs to be done, how we can do it and what it will take to make happen.  Then we make it happen.  Can progress be observed and measured by this?  Of course - as we complete tasks and they move from "Planned" to "In Progress" to "Done" we have a definite track of where the project is.

But you cannot really measure stuff unless you can show what you've DONE!  This stuff you're telling me makes no sense.  How am I supposed to know what my people are doing?  If I'm not watching what they are doing they will waste time and not do what I want them to do!
Answer - Is that the crux of the issue? Are you in such need of directing every piece of what the staff you hired - because they were "the best" - that you must treat them as if they are novices?

But they keep making mistakes!  I can't trust them to do the right thing! 
Response - Ah.  So that IS the crux of the issue.  The staff you hired because of their expertise and experience do things differently than you would.  So you intervene, and direct their actions.  You countermand their decisions and direct the architecture and the design you hired them to be able to do.  And there are still problems?

You don't understand!  I want to trust them but I can't.  They have proven that time and again!
Response - Ah.  So you hired the best, they don't do what you want and direct what they are to do and they do what you tell them to do and there are problems with the result.  Are the problems the result of the staff's efforts?

You don't understand!  Why do I waste my time with your questions? 
Answer - You asked me for suggestions and comments on the Agile practices of your organization.  Accepting or rejecting them is entirely your perrogative.

And so...

No.  There is no happy ending.

There is no singing around the spot where the Who-ville Christmas Tree stood.  There is no redemption of the Grinch in this story.  The staff continue in their drudgery and wonder and worry about the future.  The Manager(s) continue to mandate the minutiae of the work their staff does instead of allowing them to solve problems presented.