July 11th, 2009
This morning, a group of our software engineering interns worked with their mentors and managers to build a wheechair ramp for a local octogenarian. (See The Texas Ramp Project.)
One of the college interns arrived about 15 minutes late, shortly after the ramp building process was explained and the project started.
He says loudly so everyone can hear: “Hi everybody. My name is Mike. I just got here, so I don’t really know what we’re doing. Who can I help?”
He didn’t receive the response he hoped for, so he approached one of the crew leaders. “You have the best tool belt, so I’m thinking you’re someone that can tell me what to do.”
The crew leader gave him a cordless drill and a handful of deck screws and put him to work.
After finishing the assignment a few minutes later, he proclaims: “I’m just standing here! Somebody tell me what to do next!”
For the remainder of the project (the project lasted less than 3 hours), Mike was busy and productive. When someone needed an extra hand to plumb a post, drive a screw, or mark an angle, they shouted, “Hey Mike! Can you give me a hand over here!?!”
In Mike, I see several leading indicators for a bright future:
- He is willing to do whatever it takes
- He aligns himself with the team and objectives
- If he doesn’t know what to do next, he finds a way to find out
- He is tenacious
- He dispatches obstacles effectively
- Once he begins to understand how things work, he self directs
- He contributes high entertainment value and is good with a drill!
With a team of Mikes, you can make anything happen!
-Donny
Posted in Balance, High-Performance Teams | No Comments »
June 27th, 2009
Everyone knows — good engineers are not necessarily good managers.
In fact, some great engineers turn out to make terrible managers.
So, how do we know if an engineer is tracking to a leadership role?
We use the following questions to help assess whether an engineer is ready for a management or team leadership role:
- How does the engineer provide leadership from their current position as an individual contributor?
- Is the engineer recognized as a leader among peers on the team and on other teams?
- Prioritization - Do they have a good sense of what is critical vs what is somewhat important. Do they cut through the noise (non issues) to focus on the critical issues? (vs they are distracted by less important issues)
- Do they dispatch obstacles effectively and efficiently?
- Time management - Are they using their time effectively?
- Organization - Do they know how to organize and plan?
- Peer relationships - Are they collaborative? Do they have good working relationships with their peers and managers? Do they help others succeed?
- Self aware - Are they aware of their weak spots? Do they know their strengths?
- Learner - Do they know what they don’t know? Do they listen and learn from others?
- Driving for results - Do they effectively balance focus on objectives and results with engineering and technical considerations?
- Dealing with ambiguity - Are they flexible? Do they handle incomplete direction or information effectively?
- Judgment / decision skills - Do they make good decisions? Do people ask for their opinion?
- The drama factor - Do they operate without creating distractions and disruptions on the team?
Identify your future leaders. Develop them to do these things well.
-Donny
Posted in High-Performance Teams | No Comments »
June 26th, 2009
This can be a tough question. The desire to rebuild a software system from scratch is difficult to resist, but duplicating complex software is almost impossible. (from Grady Booch’s On Architecture podcast series). The software industry’s project failure rate has improved in the last decade as software teams adopt agile methods and iterative strategies for improving their software systems and architectures.
In general, rewriting your system from scratch can be an appropriate decision when:
- You have no other option. The legacy app is too brittle. You can’t touch it without significant risk of disruption
- Failure is an acceptable option. You have unlimited resources or a solid portfolio of projects to hedge the high-risk, clean slate, long-term project
- The primary project objective is self-actualization
With ‘clean slate’ projects:
• Delivery of new capability is deferred, along with the ROI of the new capability (consider the time value of new capability)
• Hidden costs include the substantial effort required for parity capability and stabilization of new code, new issues, and new constraints
• Accurate schedules and cost estimates are virtually impossible
With iterative transformation of your software system:
• Your resources focus on new capability (vs parity capability and stabilization of a new system)
• Uncertainty and risk are managed through short, well-defined iterations
• Your customers realize the value of new capability sooner
• Early and frequent delivery provides an effective feedback loop, leading to course corrections and additional value
-Donny
Posted in Uncategorized | No Comments »
February 20th, 2009
Excellent visual from Ralph Lengler and Martin J Eppler.
Effective visual communication aids in alignment, analysis, shared understanding, prioritization, decision quality and other critical organizational capabilities.
This powerful and practical visual from the folks at visual-literacy.org describes 100 visual communication tools in a single chart patterned after the familiar Periodic Table of Elements.
Each element is coded with colors and symbols to communicate the tool’s type and purpose. Mouse over the element for an example of the visual tool.
If you influence, drive consensus, decide, develop strategy, plan, analyze or inform, do yourself a favor and go to:
www.visual-literacy.org/periodic_table/periodic_table.html.
-Donny
Posted in Speak Visual | No Comments »
January 24th, 2009
The new solution will be based on newer technology and will have a better architecture. The old system is not scalable and it’s hard to add new features.
You’ve heard these lines. Maybe you have even used them to justify a project.
These satements are code for:
We would rather write new code than fix the old code.
We would rather build a new architecture than refactor an existing architecture.
We would rather develop on a new technology.
I’m not being completely fair. No doubt, the old system is messy and the new system will be designed to do things better.
But technology and architecture do not deliver value directly and are insufficient criteria for project viability.
The real question is:
What business value does the project deliver — above and beyond what you have today?
-Donny
Posted in Uncategorized | No Comments »
January 24th, 2009
Software development projects are hard to kill. Even when they are ill-conceived, poorly executed, and deliver insufficient value for your company.
Why? Several factors and mental traps can prevent us from shelving projects that need to die.
Sunk-Cost Bias
“We would kill the project if we hadn’t already invested so much.”
Sunk costs have no basis in future decisions, yet engineers, managers and executives fall blindly into this well-documented thinking trap.
This may be the first excuse you hear (or use) to continue escalation of commitment to a bad project.
Debunk this fallacy quickly and move on to the relevant factors.
-Donny
Posted in Uncategorized | No Comments »
January 16th, 2009
“We can’t log the data because it would affect system performance.”
How many times have you heard this statement? Maybe you’ve said it yourself. This is faulty thinking. Challenge your team to find a way to capture system performance information without affecting system performance.
Visibility to system performance trumps performance.
If you choose not to capture system performance measures for performance reasons, you’re crippling your organization’s system improvement capabilities. Without visibility to performance data, you’re hiding critical system problems and improvement opportunities.
So stop using ‘performance’ as a false rationalization not to capture data. Implement an efficient framework for capturing system performance information.
-Donny
Many changes never yield their expected improvements. This chart shows the average daily cycle time for a key subprocess. The subprocess is part of a complex system with a high level of variation in overall cycle time. Because performance data on key subprocesses are captured and plotted, a configuration mistake made during a June 2 database upgrade was detected and corrected. With this chart, it took almost two weeks to isolate the root cause. Without this chart, the misconfiguration is an invisible anchor on system performance.
Posted in Hidden Anchors, Speak Visual | No Comments »
January 11th, 2009
Posted in Balance | No Comments »
December 18th, 2008
Some observations on ITIL:
The Good
ITIL establishes a common language. Common nomenclature and shared understanding is valuable in a complex environment.
ITIL is comprehensive — it covers everything. The courses force you to think about all the stuff that an effective IT organization needs to do.
The Bad
Looking at ITIL from the perspective of effective organizational leadership, ITIL is overweight.
No, it’s worse than overweight: ITIL is obese — as in can’t-get-off-the-bed-without-heavy-equipment obese.
When teams discuss implementation of ITIL processes, I hear an incessant sucking sound in the back of my mind — the sound of company resources and energy being consumed by the ITIL machine, until nothing is left but a huge ITIL Jabba beast.
I can’t help but feel that ITIL will mark the beginning of the death spiral for more than one company. ITIL will help companies reach the point where more effort is spent holding the ship together than is spent powering the ship to its destination.
Don’t get me wrong — the procedures and practices described by ITIL range from important to critical. But implementation attempts will overburden companies in cost and bureaucracy.
ITIL will become known as a model of organizational bloat.
Just my two cents…
-Donny
Posted in Hidden Anchors | No Comments »
November 12th, 2008
With a nod to Edsger Dijkstra and aplogies to Eric A Meyer, auto retries and restarts are shiny rings that lead to pain and suffering!
Auto retries are frequently implemented as work-arounds for processes or requests that fail intermittently. Auto retries address the symptom rather than the cause. They chew up system capacity and hide problems. With every automatic retry you implement, you are adding invisible anchors to your system’s performance.
Resist the temptation to implement auto retries and auto restarts. Identify and address the root cause.
If you feel you *must* implement an auto retry, establish a performance counter that automatically alerts the right team when the auto retry count spikes or trends above normal levels.
-Donny
Posted in Hidden Anchors | No Comments »
