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 Will Somebody Please Kill This Project? | 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
It takes a strong leader to kill a bad project. This post is part of a series called Will Somebody Please Kill This Project?
If you’re a project leader on a project that needs to be killed, you’re likely looking for an exit strategy to make the decision a little easier. You’re looking for something to help the team swallow the bad news; you want to say it was worth the effort. You want to say there was some value in what the team has accomplished — even though the project did not meet objectives.
Look, there may not be much to salvage. Shelve the code. Facilitate and document the post-mortem. If you’re lucky, there’s a component you can use on another project.
But even if there’s nothing to salvage, put the project to bed.
This is difficult stuff. But if it needs to happen, you need to find a way to make it happen.
Take care of your team; rally them around their new direction; make it happen.
-Donny
Posted in Will Somebody Please Kill This Project? | No Comments »
January 24th, 2009
It takes a strong leader to kill a bad project. This post is part of a series called Will Somebody Please Kill This Project?
We may not say this out loud, but we are worried about how we look if we have to kill a project — to our management, our peers, and our team.
We want to be right, and killing the project probably means we were wrong.
So we keep driving down the wrong road (escalation of commitment). Go figure.
Look, if you’re on a project that isn’t likely to deliver bang for buck, you’re squandering company resources.
Yes, it looks bad. Suck it up and pull the plug.
If you don’t, it gets worse.
-Donny
Posted in Will Somebody Please Kill This Project? | 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 statements 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 Will Somebody Please Kill This Project? | No Comments »
January 24th, 2009
It takes a strong leader to kill a bad project. This post is part of a series called Will Somebody Please Kill This Project?
No Project Review Process
Companies and organizations that pride themselves on intellectual horsepower spend millions on software projects without establishing project checkpoints to review and confirm basic project criteria — even when business conditions have changed dramatically since the inception of the project.
Not smart. This is the stuff that kills companies.
For major projects, facilitate an objective business review with key stakeholders to guide the project and provide continue/stop/adjust-course decisions at the end of each phase. Questions to consider:
• How much more will we spend before this project delivers benefit?
• What is the value? How is the value quantified?
• Are we willing to spend this much for this value? Is now the right time to make this investment?
In other terms, would we spend this much money to buy this system if a vendor showed up on the doorstep with it today?
If you’re not asking the right questions about your projects, you’re probably squandering company resources and damaging your company’s capability to deliver real value and operate profitably.
-Donny
Posted in Will Somebody Please Kill This Project? | 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 Will Somebody Please Kill This Project? | 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 »
