Meg Whitman and HP Can Do Better, Much Better

Hewlett-Packard is in the news a lot lately. The company has made a few truly horrific moves in the last 2+ years. Here’s my 2 cents worth on what went wrong and how to fix it.

[I'm not going to rehash the historical events at HP. If you want to read a good summary of recent missteps, check out this Reuters article, "Insight: How a desperate HP suspended disbelief for Autonomy deal".]

HP was (and in my opinion still is) a great company with even greater potential. Unfortunately, they’ve fallen into a classic, big-company quagmire. When you mix a hard-driving CEO with a slow, lumbering culture, you have a train wreck in progress.

HP has gone through three CEOs since 2010: Mark Hurd had a reputation as a cost cutter and replaced Carly Fiorina; Leo Apotheker was thought to be a software strategist and came from SAP; and current CEO Meg Whitman made eBay a household name. Each CEO change resulted in drastic strategy changes.

It seems that each strategy focused on acquisitions and spin-offs rather than internal growth. The most notable acquisitions were Compaq (2002), EDS (2008), Palm (2010) and Autonomy (2011). At one point, HP wanted to spin off its PC business despite being the largest PC manufacturer in the world. Go figure!

The Real Problem

It appears that HP’s strategies were flawed but I have to dispute that conclusion. The flaw was not in the strategies. The flaw was, and continues to be, in the culture. You can have the world’s best strategy but if you have a culture that is resistant to change and risk-averse, forget about it!

Many successful enterprise CEOs have strong personalities — all of the recent HP CEOs clearly do. They make quick decisions and have little patience. Conversely, many enterprise company cultures are deeply deliberate and willingly restrained. Does that sound like a formula for success to you?

Why is it that enterprise CEOs often buy companies to drive revenue growth rather than change the culture of the organization to grow the business? Because it’s much easier to buy a company than it is to change culture. Unfortunately for them, buying a company often demands cultural changes to make the combination work. Catch 22, right?

Okay, Meg Whitman, here are my suggestions for getting HP back into rapid growth mode in no particular order.

• Redefine your competitive advantages. They won’t last long anyway. Whatever competitive advantages you have today will be gone tomorrow.
• Find a way to extract new ideas and ingrain them into the business. Empower everyone to contribute ideas. Act on them — fast!
• Reward prudent risk-takers, even if they fail. Encourage them, to try again. Streamline the multiple approval layers and sign-offs.
• Eliminate narrowly defined personnel titles. Leverage everyone’s strengths regardless of title or seniority. People must fill multiple roles.
• Put the real power in the hands of product groups and centers of excellence. Fire the bureaucrats and those who add complexity.
• Inform your subject matter experts that they are obsolete. They better develop new areas of expertise or they’re gone.
• Practice social engineering. Offer continuous feedback and positive reinforcement. Trash those annual reviews. They’re useless.
• Convert your best customers into partners. Find out what they need and sell it to them. Turn them into advocates.
• Connect with your suppliers and outsourcing partners. Leverage them highly. Have internal and external providers compete for business.
• Standardize. Reduce duplication and redundancy … and … make it quick and easy to change the standards — often.

I know it’s easy for me to write this stuff and hard for you to actually do it. I get that. If you don’t like my ideas, do something else. Just do something. The business is dying while you weigh your options. The longer you take to decide, the fewer options you’ll have.

Forget About Value. Focus on Morale.

A lot of attention is given to the term value. We want to know how much value a software development team creates with each deliverable. Unfortunately, value is a difficult thing to measure so it may be better to view the problem differently.

What has value?

The simple answer is everything — everything is valuable to someone.

How much value does any particular deliverable have?

It depends. For example, some companies place high value on the document “thud factor”. What’s that? It’s the sound a paper document makes when you drop it on the desk of your boss or client. Other companies view such artifacts as kindling. So I can’t tell you the value of anything you produce. Only your boss, client or stakeholder can do that.

One thing I can assure you of is that the executable software you deliver has more value than any other deliverable — in fact, it likely has more value than all the other deliverables combined.

Don’t chase the value chain.

You could spend lots of time and money chasing the value chain, that is, trying to maximize the value of your team’s efforts. Don’t waste your time. Let the bean counters worry about value. You need to worry about morale.

Morale has a huge and often hidden impact on team performance and resulting value. Obviously, team performance directly impacts the quantity and quality of deliverables. You’re going to ask how to measure morale, right? Forget about measuring it. You’ll see morale in the way people behave. People with high morale have more energy. They speak up. They collaborate. They have fun. And most importantly, they deliver.

Consider this example. Let’s say a team with average morale can produce $100 of value for every $100 of sunk cost — a dollar of spending results in a dollar of output. Not great but not bad, right? (Actually, companies have to produce more than a dollar of output for every dollar they spend so they can grow the business. But I digress.) A team with poor morale might produce $50 or less of value delivered for every $100 spent. A team with high morale might produce $200 or more of value for every $100 spent.

How can that be?

Morale dramatically affects productivity and quality. It’s not just a matter of how much gets delivered. It’s also a matter of the quality of the deliveries. Teams with poor morale deliver less software with more defects. If the software is full of bugs, it has no value. (Actually, it may have negative value but let’s not go there.)

Focus on improving morale not increasing value. When morale is high, value will be too.

photo credit: mightymoss via photopin cc

Change Happens, Whether You’re Comfortable Or Not

Where is your comfort zone?

Everyone has (at least) one. It’s the place where you feel confident and comfortable. Once you’ve done something several times, you develop a comfort zone around it. That’s good — and bad.

The good part is that your comfort zone helps you develop a specialty. You get good at something and then you master it — all the while safe and in control within your comfort zone. You’re an expert when you’re in the zone. But eventually, it’s time to change.

That’s when your comfort zone becomes a liability. You get nervous about moving outside your zone. It feels uncomfortable and even unnatural. As the difference between what’s inside your comfort zone and what’s outside it grows, your stress level will too.

This reasoning applies to any business or software development process. Changing the way the team operates will push some or all of the team members outside their comfort zones. Making a major change to the process will push most people far beyond the limits of their comfort zones.

Examples of Major Development Process Changes

• Going from standard waterfall development to agile software development
• Moving from small-scale software projects to enterprise-scale projects
• Making major changes to technologies and tools (e.g. moving from .Net to Java)
• Evolving from centrally-controlled teams to self-organized ones
• Migrating from a document-centric approach to a working-software-centric one

You get the idea. Any of these situations will push the limits of the team’s comfort zone and create stress. If you want to succeed, you’ll need to work at expanding the team’s comfort zone. There are two fundamental ways to proceed.

Evolutionary Change

This involves making a few small changes, letting things settle down a little, then making a few more small changes, etc. Today’s “as-is” process evolves to tomorrow’s “to-be” process.

The approach makes sense though it carries a major risk factor. After a few change cycles, the team will have broadened its comfort zone and may feel that the newly evolved situation is “good enough”. If that happens, change will stop and the team will never achieve its envisioned potential

The way to avoid that premature ending is to lay out a change plan and communicate it early. Then keep reinforcing the plan each time new steps are taken so that everyone accepts the idea that more changes are coming.

The plan should not be too detailed. You want the flexibility to make adjustments as you go. You simply need enough detail for everyone to envision what the “to-be” environment will be like.

Revolutionary Change

Conversely, you can implement the “to-be” process immediately and deal with all the consequences up front. This is simpler in some ways because there are no interim states to worry about — one giant leap and you’re there.

The major risk with this approach lies in dealing with possible pandemonium. The “to-be” state could be chaotic at first and nerves could be frayed.

You may be tempted to analyze every possibility ahead of time and plan for every contingency. Clearly, you need to do some of that but I recommend placing more emphasis on communication and understanding.

Communicate what is being changed and why. Communicate that you expect problems. (To be clear: Don’t say that problems “may occur”. Say they “will occur”.)

Demonstrate understanding and compassion. When (not if) problems happen, don’t look for someone to blame. State that you expected the problem and you welcome it because everyone will learn and improve by solving problems.

The path you choose will depend on the scope and scale of the planned changes along with the risk tolerance of your company culture. Either way, stop agonizing and start changing.

photo credit: Eric Rice via photopin cc

10 Tips for Producing Documents That Are Lean and Agile

Some software development groups must document everything. This often results from legal, regulatory or compliance demands. Although, it can also be a cultural phenomenon — some managers simply won’t accept anything unless it’s in writing.

Do everything you can to minimize the volume of written exchanges. Information overload is not just a cute phrase. It’s real and it causes lots of confusion and errors.

Some reasons why you might need a (virtual) paper trail

Written artifacts are often used as a vehicle to get people to think. They also serve as verification that the thinking happened. The artifact itself isn’t what’s important. It’s the effect that it has on people that matters. The challenge lies in getting people to actually read the artifact.

Other written artifacts suggest or even enforce a process. For example, action “A” takes place and is documented. The document triggers action “B” (this scenario may be repeated multiple times during a project). This approach is particularly useful when different groups or even companies are involved in a collective effort.

Finally, written artifacts may serve as a historical roadmap depicting how the software evolved and describing the current implementation. As above, this can be particularly useful when multiple groups are involved.

Keeping the project artifacts from becoming a burden gives you a better chance of getting people to write them. Keeping the documents lean and agile gives you a better chance of getting people to read them.

If your team is spending significant time merely documenting as opposed to solving and delivering, you have a problem. I’ve observed many a developer spend vast amounts of time on document layout, formatting and pretty-printing. It doesn’t impress me and it won’t help your team deliver better software.

If you’re forced to produce large quantities of written artifacts, follow these tips for minimizing the burden.

Ten Tips for Writing Better Documents

• Focus on content not art. If fancy artifacts are required, use a simple, clean template. Be sure that the content captures the reader’s attention not the fancy fonts and artwork.
• Adopt the attitude that less is more. Deliver brief and direct documentation resisting the urge to write a novel. More of what you write will actually be read.
• Don’t duplicate content. Never copy and paste lengthy sections from one document to another. Always reference the source.
• Keep it informal. You may need some formal documentation but don’t write everything in a formal way. Make it informal unless formality is required. Often, a simple photo of a whiteboard is good enough. Why turn it into a fancy computer diagram?
• Avoid long, unstructured documents. Group related material into clearly defined sections.
• Use simple sentence structures avoiding long, compound sentences that are hard to follow. Also keep paragraphs short as whitespace improves readability.
• Use bullet points to slow the reader down and draw attention to important ideas that don’t need to be understood in a particular order.
• Use numbered lists to draw attention to information that should be read in the order presented.
• Include graphs, charts and photos for improved understanding but don’t go overboard.
• Take advantage of bolding, colored text and links to highlight words and draw attention to them.

Documentation is important. Formality and bulk are not. Keep it lean and agile.

Do Agile Development Teams Need Multiple Product Owners?

Enterprise agile development is different. Developing software using Scrum, Kanban, Lean or XP is just not the same on an enterprise scale. Consider the stressed-out, over-burdened, Product Owner.

Is it reasonable to expect one Product Owner to provide all the answers to the software development team’s questions? You can argue that it’s the Product Owner’s responsibility to seek out the right people and get the information. However, that adds a layer of indirection that could slow the team down or result in wrong answers.

Consider an analogy from the construction industry. Have you ever had a house built or had a major renovation done to your house? You hire a general contractor. That person hires specialists for each aspect of the job. For example, the general contractor may subcontract with the following businesses:

• Plumbing Contractor
• Electrical Contractor
• HVAC Contractor
• Carpenter
• Roofing Contractor
• Insulation Contractor
• Painting Contractor
• Flooring Contractor
• Landscape Designer
• Interior Decorator

Each business will have its own designer/planner to plan the work required, estimate the cost/time, and bring in the appropriate people. The general contractor relies on the specialty experts to provide answers and solve problems. No one expects the general contractor to have all the answers.

Product Owners Are General Contractors

In agile software development projects, we require that one person take ownership of the entire effort and provide all the answers. Is that reasonable? Here are a few areas that may require specialization:

Business Relationship Owner – This person builds trust with the business community (customers, clients, partners and internal users). Keeping all of these groups engaged throughout the project is critical.

User Experience Owner – Apple has proven that providing an elegant and polished user experience is a critical success factor. It’s a highly specialized skill that few can provide.

Technology Toolset Owner – The toolset used to build the software is often critical in enterprise development. Deploying a .Net solution into a Java environment (or vice versa) makes little sense. Someone needs to own the toolset decisions.

Information Architecture Owner – Many enterprises are drowning in data. They need solid information taxonomies and architectures to leverage their information and extract full value from it.

Externally Accessible Services Owner – If customers and partners will be accessing software services externally, someone needs to decide what the services will be and how they will be presented.

Externally Accessible Data Owner – If company information will be made available to outsiders, someone needs to decide what information will be offered and how it will be controlled.

Regulatory Compliance Owner – Every company faces legal, regulatory, industry and government compliance issues. It’s unlikely that anyone on the development team has this knowledge.

Documentation Owner – User guides remain critically important even if they are online and never printed. Good user documentation can reduce customer support calls and save money.

Marketing Owner – Someone has to convince people to buy the software or service. That person will need to define the value proposition to the customer and ensure that the software delivers it.

You get the idea. The Product Owner is not all of the above. The Product Owner is the general contractor. He brings in experts as needed. Not all of these experts will be needed for every project but they should all be identified and kept informed of the project status.

photo credit: Cayusa via photopin cc

Avoid a Project Blamestorm. Agile Development Can Help.

Have you ever been asked to deliver a software solution only to discover that the requester doesn’t know what she wants? In addition, she gives you a deadline, yet when you question the relevance of the target date, it becomes apparent that the deadline was picked at random.

It’s happened to me more times than I can remember and I have no respect for people that do it. They believe they’re assigning work and managing deliveries, when they are giving birth to a disaster.

It’s a blamestorm waiting to happen.

Fortunately, this is the ideal situation to use an agile software development approach like Scrum, Kanban, Lean or XP. There’s no better way to nail down what someone really wants (and needs) than to start building it. Throw together a quick mockup or wireframe. Try out a few ideas. Explore the solution space.

Tradeoffs have to be made

If there’s a good working relationship among the responsible parties, everyone will realize how big and complex the request really is. They’ll be able to rough out a solution and even estimate a target delivery time frame. Neither the solution definition nor the time frame will be precise because many details will remain to be worked out.

If the software is needed in a hurry, the requester will need to control the scope tightly. If feature set and quality are more important than timing, the initial deadline likely won’t be met. (You can’t have it all. Deal with it!)

Building trust makes it easier

The way to make this work is to build trust among the key players. You build trust by seeking areas of agreement. I’m often asked questions like “Is this possible?” or “Can that be done?“. The flip answer is “Of course, anything is possible.” The real and practical answer is more like “It depends.” — it depends on time, money, people, priority, etc.

I always try to offer a specific approach. For example, if I’m asked if the software can send an email message, I might offer that while it can, a simpler approach would be to log the item in an already existing log file. If the requester likes my suggestion, we’re good to go. If not, we can have a conversation around what’s needed and why.

This approach is far better than saying “No, it’s not possible” (none of us likes to hear ‘no‘). Also be careful with a simple “Yes, it can” response. It will likely leave the impression that the request is simple when in fact, it may be difficult and outside of time and cost constraints. Be clear. Be honest. Be agile.

photo credit: dave~ via photopin cc

Motivation Doesn’t Just Happen. You Need to Work At It.

If you’re married or have a close friend, you know how much effort it takes to maintain a healthy and positive relationship. Frequent interactions are mandatory. Open communications are essential. Slack off — even for just a few weeks — and the relationship suffers.

So why is it that many managers rarely interact with their teams. And when they do, it’s to give instructions or orders. Those managers don’t have a relationship with their people at all. The company controls the relationship and it amounts to “I’m the boss. Do as I say.”

That’s a buzz-kill!

Here are five suggestions for motivating your team members and building relationships with them. Try to keep it low-key and genuine.

1. Be generous with praise. Everyone likes to be praised. It doesn’t cost the company any money and it’s easy to do. Praise people privately. Praise them publicly. Encourage senior managers and executives to do it too. Praise from the boss’s boss is extra special.
2. Empower the team. Let them make their own decisions rather than constantly seeking approval from management. No one wants to let their team down. They’ll work harder and be happier. Lead, don’t control.
3. Take a team member to lunch occasionally. Make it a surprise not a policy. Walk up to someone and invite them to lunch with you. Minimize the shop talk and get to know each other.
4. Give recognition and small rewards. Offer a shout out to someone in a team or company meeting. Issue a challenge and make it a contest or a game. Have fun with it.
5. Have a party. Group activities go a long way. Have a picnic. Organize birthday parties. Hold a happy hour. Find a reason to celebrate. Don’t wait for a holiday.

It’s great if you can afford to offer rewards to people. This may be difficult as some companies are real tightwads. Here is a bunch of ideas for rewards. Some are cheap and some aren’t. Provide rewards and incentives as gestures of appreciation for an accomplishment. The reward should be timely, direct, personal and specific. Try to match the reward to the effort made.

Reward Ideas

• Bag (there are many options)
• Bonus
  • Gift card
  • Cash
  • US Savings Bond
• Clock (desk, wall or wrist)
• Dinner certificate for two
• Gadget (elegant or fun)
• Hat or cap
• Jacket or sweater
• Limousine service
• Mug or glass
• Pen
• Personalized reward based on …
  • Family Situation
  • Hobbies
  • Personal interests
• Pin with slogan or motto
• Pocket knife/toolset
• Points (to be accumulated and cashed in)
• Shirt
• Special event
  • Bowling
  • Group lunch or dinner
  • Group movie – rented or at a theater (supply food, popcorn & soda)
  • Paintball
  • Picnic
  • Pizza party
  • Roller/ice skating
  • Trip to the mall to buy a gift or have some ice cream
• Special project or time to work on a pet project
• Sweatshirt
• Tickets to a movie, play or event
• Time off with pay
• Trophy or plaque
• T-shirt
• Vacation trip
• Water bottle
• Weekend getaway

Surely there’s something on this list you can do? Be sure to engrave or embroider personal items. Use your imagination. Motivation doesn’t just happen. You need to work at it.

photo credit: rosipaw via photopin cc

Building the Software Right Doesn’t Make It the Right Software

Information technologists and software developers do not know best. We are not the definitive experts on what software systems to build. Simply building the software right is not enough. It has to be the right software.

I see too many projects dominated by IT or R&D. It often starts innocently enough. The technologists come up with an idea and implement a software prototype. They demonstrate it to the potential business stakeholders, who are impressed. There is a consensus to move forward and build the software system.

Sounds good, right?

So the technical team carries on until they reach a point where they have something that the target group can try out. (This often takes months, which doesn’t help matters.) The software is deployed into a test environment and a limited group of people are allowed to use it.

Inevitably, as more people get involved, more ideas are generated — some of those ideas will be in direct conflict with the work already completed. This is where things begin to go wrong.

The target group wants to change some aspects of how the software operates, how it looks, and how it responds. The technology team has become attached to the current implementation and resists significant changes. The battle lines are drawn. The project may wither and die or it may proceed after a long, drawn-out political battle. Both outcomes look and feel like failure.

Where did things go wrong?

The software developers built the software right but they didn’t build the right software. This situation didn’t have to happen. The project went off course at the very beginning. At the outset, the technology team should have built a quick and simple mockup of the software. This could have been as simple as a wireframe or they could have used a GUI design tool to create a more polished model.

Either way, little time would have been expended and no one would have become overly attached to the end result. Once approval was obtained to continue with the project, an executive sponsor and a core group of stakeholders should have been selected (hopefully, they would have self-selected).

Then the combined business and technology team could have defined requirements or stories, specified the target users, and established goals for a minimum viable system. This collaborative approach makes people feel valued and engaged rather than dumped on and manipulated.

How do you approach new software initiatives? Let me know.

photo credit: Dean Terry via photopin cc

Software Delivery Problems? Focus on Relationships Not Process.

Here’s how the situation unfolds. An enterprise company experiences problems with their software development efforts. Software systems are delivered late. They are poor in quality. They lack important features. Or in some cases, they are never delivered at all. What’s the solution? (This is not a quiz!)

Tighten the process! Institute more controls, more metrics, more reviews and more approvals. You’ve heard of “running a tight ship”, right? That will fix it … Or not.

Let’s ignore the effect of all that tightening on team morale and think about the process flow. More management oversight means managers will need to spend more time monitoring projects — they will need to be more involved. That likely means more managers will be needed. More managers means more meetings. More meetings means more administrative things to do. More … you get the idea. More of everything — except productivity.

Here’s the final result.

• Software systems will still be delivered late (unless schedules are greatly extended) and projects will surely cost more.
• Quality may improve but only if quality is more important than meeting dates (unlikely).
• Important features won’t get missed or forgotten but they will still be dropped to “get back on schedule”.
• And, yes, some projects will still never be delivered at all because all those managers won’t agree on specifics.
• Oh! And one more thing…there will be increased infighting and political battles resulting in poor morale and lost productivity.

Moral of the story: Throwing more process at a broken process introduces more break points.

You need to look at a broken process completely differently. Instead of asking, “What changes can we make to the process?”, ask, “Why is the process broken?” and “What caused it to break?”. Most often you’ll find that relationships are broken. Failed relationships cause processes to fail. Tightening the process does nothing to address the relationships that form the foundation for any process.

If those relationships remain broken, no process changes will ever fix the problems of late, poor and missed deliveries.

Fixing relationships can be difficult but it has to be done. Start by initiating a conversation among the stakeholders. Ask what each stakeholder needs from the software and the process. Then listen, really listen. If someone feels he/she has been wronged, apologize. Don’t be proud, just do it.

Relationships are built on trust. Work on rebuilding and strengthening trust. Collaborate more, don’t just communicate. (Copying someone on routine email messages or status memos is not collaborating. It’s throwing information over the wall.)

Once those relationships have improved, assess the development process with an eye toward simplifying and decentralizing it. Process should help people get their jobs done. As soon as it starts to get in the way, you’ve gone too far.

photo credit: lumaxart via photopin cc

7 Tips for Improving Your Software Development Process

Can we agree that writing great software is hard to do? Not just any software, great software. Every corporate situation is unique and there are no simple solutions for building great software. That said, here are seven quick tips for improving your software development process. Pick one or two and get to work.

1. To speed up your development cycle, slow down.

The harder you push to finish the software, the more mistakes you’ll make. Items will be missed, decisions will be wrong, shortcuts will be taken, technical debt will accumulate, and quality will suffer. Instead, prioritize and focus. You’ll get less done, faster.

2. To ease decision-making, keep it simple.

The more options you offer someone, the more questions they’ll ask. Confusion and bewilderment are the likely results. Evaluate priorities and needs, then offer fewer choices based on them. You’ll reach consensus easier and faster.

3. To be better at what you do, prepare, practice and deliver.

Basic agile principles are fairly simple — even obvious. Implementing them is hard work. Lots of preparation and some early failures are the price of admission. Don’t let the difficulties discourage you. It’s worth it.

4. To deliver big changes, start smaller.

We often try to do too much, too quickly. Change can be overwhelming when not handled in a structured and disciplined manner. Big changes carry big risks and extended approval cycles. Bite off small chunks. Digest them fully and keep at it.

5. To build better business relationships, stop telling.

Smart people often talk too much and listen too little. Business people don’t need you to tell them how to run their business. They need you to listen to their problems and concerns so you can help them find better solutions.

6. To learn quickly, fail faster.

The best way to learn is by doing. Anticipate rookie mistakes and leverage them to learn. Early sprints or iterations are good for experimenting, failing and learning. Take advantage of them. Don’t let perfection get in the way of greatness.

7. To differentiate your team, develop subject matter experts.

Writing great software is not enough. The business needs people who are experts in their specialized domains. These domains need to cover business and technical areas that are relevant to the business problem being solved and software system being delivered. Be a SME.

Got any other suggestions to share?

photo credit: cdw9 via photopin cc