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
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.
(to them) whatever the particular matter is at hand
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.
automation, and many small bits that make up a high-performing
team and on-track project
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.
don’t succeed
“senior management” challenge
are in the loop and are helping to allow the whole extended
group to “get it”
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).
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.
Agile in a CMMI/Rigid Systems Engineering Process World
In a recent project, as a member of a large bureaucracy, I’ve had to deal with being held to a rigid systems engineering (SE) process. The whole nine yards, OCD, SRD, SFS, SRS, IRSs, the documentation list goes on and on.
SE Process can be a very good thing when implemented properly. My problem was that my team was being held to a higher standard than our customers and was being held there by the sponsors (an anonymous PMA).
So on one hand we had to adhere to strict documentation and review cycles but at the same time we weren’t getting spelled out requirements. We were getting the requirements in an Interface Design Specification (IDS) and were being told that the IDS represented complete requirements along with a PPS and User’s Manual. Can’t tell you what the project was but suffice it to say, it was massive.
In addition to all this, the schedules were compressed and money was tight as usual.
Question: How do you implement a more Agile approach when your neck deep in process and in a compressed schedule with limited budget?
My solution: slowly reduce the documentation within your own process and push back on requirements and hope the PMA doesn’t tell you to just get it done anyway and then start looking to blame you when the project gets into trouble, even though it was their fault for not listening to you to begin with.
Jon: I know for a fact you’ve dealt with this before…any advice?
Proposed next topic: “Agile-CMMI” It can be done but they seem to be at odds with “Working software over comprehensive documentation”
Hmmm. Tough situation for sure. Frustrating I bet, too. One idea… bring it up to the powers that be… See if there truly is a desire to succeed, or a desire to follow process regardless of actual success.
Another idea: make all of the tasks visible and blessed by the stakeholders. Make it clear as to what they are asking for and how much it costs.
And, be sure to check that you are doing truly useful documentation to the proper level to allow the team to do their best. But for “make work” documentation, try to get away with the bare minimum.