Responding to:

John Hebley said the following on 10/20/08 11:08 PM:

Philippe, Jon

May the force be with you. I was about to rant and rave about incompetent managers etc, but that would be just preaching to the choir.

That is a new topic, if you want to discuss it. How do you work with these, often senior managers, that have no idea what you are trying to do, and insist on applying 1970’s thinking?

John

I find it very common that many folks (yes, some of these are “older” managers) retreat to the comfort of what they were familiar with in the “good old days”. Probably human nature when confronted with being out of the comfort zone. I have been doing agile development since the early 90s and have been taking unique approaches to solving problems for longer than that. I am familiar with folks who don’t “get it” or who need a preponderance of evidence to be won over.

A partial list of my responses to an “older manager”:

• I have to suppress being impatient (see personality profile

  below)… You see, for me, many times it feels like battling the

  Flat Earth Society; or the “Gravity Points Up” mentality; or “The

  Ostrich Society”

  • By nature I have always been an early adopter.
  • By nature I am an engineer
  • By nature, I trust, but verify
  • By nature I am impatient to get results
• When I feel stressed by those that seem to “take issue” with what

  I am trying to do to achieve (largely their) business success, I

  take it as a sign I need to do more educating, show more, explain

  more, assume they have validity in their feelings.

• I ask them for things they would like to see that would “prove”

  (to them) whatever the particular matter is at hand

• Funny thing, many times they can’t think of what to ask for, they

  just know “it doesn’t feel right”… Sometimes I find myself

  moving the level of thought “up” for them and I provide ways to

  achieve degrees of “proof” that never before existed at their

  company or in any other project.

• I am profuse in beating the drums of process, quality, testing,

  automation, and many small bits that make up a high-performing

  team and on-track project

• I will make uncertainty, variability, and risk more visible to

  combat the illusion that traditional Gantt charts or Work

  Breakdown Structure approaches to managing software feature

  development are better than the way I run iterative development.

• I will try all sorts of approaches to communicate if at first I

  don’t succeed

• The project wiki is a huge part of this
  • I blog about the project (“News”)
  • I stand up special pages when I have to address yet another

    “senior management” challenge

  • I ensure as many stakeholders and other managers as needed

    are in the loop and are helping to allow the whole extended

    group to “get it”

• When it might be “embarrassing”, I keep the education private (and

  when it would benefit all, I make sure the wiki post or blast to

  the development/project mailing list is not tied to the requestor).

• I work very hard to shelter the team from the details of these

  sorts of “senior management” moments. I let the team know if/what

  folks are “asking”, but I like to minimize those moments that are

  more distractions on the core development trajectory, than helpful.

At the end of the day, I know I am doing my best, often working harder than anyone to achieve the ultimate business goals that the project has been chartered to achieve. I live and breathe the project business goals. I let the chips fall where they may.

For obvious reasons (to me, anyway), in any complex project that I am involved with, there would be no chance of me doing it as fixed-price work. That would compromise being able to respond to the “human” parts of the project and client needs.

— jon

ps: My personal response can range widely, I am sure. Here is the beginning of one (of many) behavioral profiles for me:

Jonathan likes to be forceful and direct when dealing with others. His desire for results is readily apparent to the people with whom he works. He is driven toward goals completion and wants to be in a position to set policy that will allow him to meet those goals. He displays a high energy factor and is optimistic about the results he can achieve. The word “can’t” is not in his vocabulary. Many people see him as a self-starter dedicated to achieving results. Jonathan is aggressive and confident. He is deadline conscious and becomes irritated if deadlines are delayed or missed. He is a goal-oriented individual who believes in harnessing people to help him achieve his goals. He needs people with other strengths on his team. He is often considered daring, bold and gutsy. He is a risk taker who likes to be seen as an individualist. Jonathan may have difficulty dealing with others who are slower in thought and action.

Many times, we in the technical community are faced with well-meaning users and stakeholders that ask for something “their way.”

My wife and I stopped in a fine Italian restaurant for lunch. Sue ordered a risotto dish, while I ordered a grilled salmon over mixed baby greens. When the risotto was served, the waiter offered to sprinkle fresh grated cheese. I was ready to get a fresh spoonful of that cheese deposited right in my mouth, it looked so good.

Then the waiter turned to me and my “salad” and offered pepper. I blurted out that I would like some cheese. (Sue cringed, as she always tries to remind me that Italian fish dishes should never be served with cheese with seafood. )

Back to the technical point… the waiter was very diplomatic:

“I would advise against that.” he said. “Oh! That’s right, no cheese on seafood! What was I thinking?” “Well, rules are meant to be broken, so you may do that if you like. I would just advise against that.”

He didn’t say I was wrong. He didn’t say I couldn’t have what I had asked for. But he carried a certain authority of being “in the know” and I trusted his judgment.

I hope to use this gentle technique the next time I need to respond to a user’s well-meaning, but “wrong” request. Maybe it will help you out as well.

In the agile usability forum, Steve Gordon astutely observed:

“Making these choices is a business decision that requires balancing strategic and tactical considerations in the specific context.”

i agree. imho, one of the roles we, as software professionals play, is to provide the business with some “cost” information and some potential alternatives. when a specific feature idea comes forth from the business side, we are to provide cost (in terms of effort, schedule, and even downstream ramifications). We can also discuss various variations on a theme. For example, many times the development team might say: “Well, providing X is expensive and would take 6 months. However, we could do Y — which seems like it would achieve nearly the same result — for a much smaller cost, and have it done in one month.”

Talk is (usually) cheap(er) than one-way (non)conversations.

That is, a non-agile “Company A” might simply spit out a new feature set idea in an email. Then, the dogmatic development team spits back a single answer (it will cost X). Business chooses not to go forward. Meanwhile, competitor B implements Y and drives Company A to lose business and go bankrupt.

Or, non-agile Company A accepts excessive cost X. Company B does Y, gets it done sooner and eclipses Company A’s much later release of an only slightly better feature X. Company B makes more money, Company A never recoups the cost of feature X.

Talk is cheap — and that’s a good thing when it comes to working as a team for a common goal. Company A did not have a discussion, and it cost them dearly.

a quip from the agile usability forum…

“But I still think that, in the early stages of UI design, in a project where the UI is critical, getting a usable paper prototype, as verified by user testing, is significant progress.”

as an agilist, i would agree.

i tend to run parallel tracks during initial development based on the project specifics. once i have gathered enough requirement details to have a good overview of where we need to go, i might begin some specialized “research” tracks, a.k.a. “spikes”, even as i may be gathering more requirements and building more of the object model. the overlapping activities may be any of these:

• requirements workshop
• a spike to work out technical architecture
• a spike to work out User Experience issues
• doing anything else in parallel that helps to reduce risk
• risk of missing important requirement details
• risk of producing an unusable app
• risk of producing a non-performant app

The challenge is knowing when to do these sorts of things, and not allowing any single “prong” of the attack to get too far or too deep compared to the others. The purpose being:

• you often get diminishing returns, you just need to investigate enough to get the 80% mark (for example)
• you don’t want to waste effort on something that turns out to be obviated by something you discover in another track

It may help you to understand I have a few very closely-held tenets about software development:

• The key to development is separation of concerns
• the core is the problem domain built to support the requirements.
• get this wrong, nothing else in the app matters. nothing.
• not the UI/UX.
• not the 5th normal form DB.
• not the worlds most articulate UML models.
• not the worlds best cruise-controlled, TDD, 100% test coverage,
• not the best joshua bloch-/steve mcconnel-blessed code.
• this core generally transcends UI, database, and even the language chosen to code the app. In other words, the “problem domain” reflects the relatively stable “business” world. I know it sounds trite, but despite all our wonderful software advances from green screen to now, the world of mortgage/insurance/banking has changed little, fundamentally, or relatively.
• the app is all about the “business” needs
• the User Experience/UI is a separate thing
• The persistence is a separate thing
• Carefully orchestrating the various tasks in parallel using agile approaches that hold dear doing the “best thing possible” given the business & development circumstances, constantly adjusting in a smart way.

it is about understanding risks, managing them, and using the elusive stratagem known as “good judgment.”