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

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

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

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

Adopting Agile Development Is Disruptive. It Just Is. Here’s Why.

Is your goal to preserve and protect or change and convert?

Going from a traditional software development approach like waterfall to an agile approach like Scrum, Kanban, XP or Lean, will be stressful and risky. The dangers aren’t hidden in the agile approach you select. The dangers lie within the people you assign to the project. It’s not their fault though. It’s yours!

Your company surely struggles with the forces of maintenance versus the forces of change. Every enterprise company does. There are employees who are tasked with maintaining the status quo, and there are those tasked with driving change. Both types of people are essential to your company — and they will clash.

When a process works well, it needs to be preserved and protected. When the process no longer meets the needs of the company, it needs to change regardless of how long it’s been in use or how successful it’s been.

To meet both needs, companies employ two types of people — those who preserve and protect the status quo and those who change the current state and convert it into something new. Sometimes companies expect an employee to fit into both roles. This rarely works because the required personas are vastly different. Let’s examine them.

The Preserve and Protect Persona

This persona loves repetition — determine how to execute a process well, document it, and do it over and over. Repeatability is the daily bread and butter of every company. They establish policies and procedures expecting that everyone will conform. This creates uniformity that’s intended to deliver predictable and repeatable results (a.k.a. profits).

This persona isn’t opposed to change. However, the employee will insist that change be disciplined, structured and measured. This means that changes must be well thought out, documented and vetted prior to implementation. Changes must also be properly adapted to existing procedures and interfaces. Lastly, changes must be implemented in small doses so that there are no unintended consequences.

The Change and Convert Persona

This persona loathes repetition. The employee’s goal is to make things better by introducing changes to existing policies and procedures. The changes may be driven by cost efficiencies, competitive pressures, or new business opportunities. This is how companies strengthen and evolve.

This persona thrives on change. The employee is willing to take risks to the point of trying something new in a production environment, even as an experiment, so the results can be evaluated. While such actions can be disruptive and stressful, they hold the promise of rapid process conversions that are responsive to rapidly changing business needs.

The Persona of Agile Developers

It should be apparent that software developers and their managers who follow a traditional approach like waterfall tend to have the preserve-and-protect persona. (Isn’t that why you hired them?) They are trained to follow a process that contains structured documents, reviews, approval cycles, sign-offs, etc. There is even a change-control process that the business must follow to request something new.

Agile software development shuns most — but not all — of the formality and controls associated with traditional approaches. Rather than start with controls (phases, gates, reviews, approvals, etc.), agile teams prefer to start simple and add controls only if needed. People must be willing to embrace major changes to the way they operate at the outset. Then, they must accept additional changes as the team seeks continuous improvement.

An agile development conversion is disruptive and unsettling by definition. Are you prepared for the disruption? If you’re serious about being agile, get serious about dealing with disruptive change.

photo credit: TechCrunch via photopin cc

Great Teams Satisfy Everyone’s Priority Needs

As a software development blogger, I often write about ways for teams to adopt agile practices or be more agile. There is no single way to be agile. There are many. There is no best way to be agile. There are multiple. What can your team do?

Ultimately, software development teams must establish rules and procedures that work for them. They have to be able to embrace the development process and make it their own. If they can’t do that, they won’t succeed.

Here’s a true story about revising a business process.

Recently, I was involved in a series of meetings where we reviewed an established business process and discussed ways to improve it. There’s always room for improvement, right? There certainly was in this case.

It quickly became apparent that there was a fundamental problem. The business stakeholders and the process implementors were in conflict. They had different priorities and interests.

The highest priority for the stakeholders was maximizing revenue. The highest priority for the process implementors was customer care. I could argue that you can’t have one without the other but that should be obvious. Two things became crystal clear:

1. If the financial objectives of the stakeholders couldn’t be met, the business initiative would be cancelled and the process implementors would be out of work.
2. If the implementors couldn’t provide the level of customer care that they were committed to, discontent would prevail and employee turnover would be high.

What’s the solution? The needs of both the stakeholders AND the implementors MUST be satisfied — whatever it takes. Thankfully, I was able to offer a solution that appealed to everyone.

Focusing on what people need makes a difference.

The same type of problem occurs in software development teams. Management wants the software delivered in less time, with better quality, at lower cost — no surprises there. The software developers want to solve problems, write good software, and avoid administrative impediments — no surprises there either.

Management needs the development process to be controlled and transparent. The team needs the development process to be lightweight and non-intrusive. The needs of both sides MUST be met and they CAN be met if everyone is willing to negotiate and compromise.

Conversely, if the needs of either side aren’t met, quality will suffer, costs will increase, and morale will decline. So, what can your team do?

The software development process must be openly discussed with all parties having a vested interest in it — developers, testers, stakeholders, end users, and managers. Everyone needs to buy in to the approach. Everyone needs to understand their roles and responsibilities.

I’d rather sacrifice some process agility in the interest of engaging the key players rather than argue for a more agile approach that alienates some of them. Here’s my recommendation:

1. Start small. Don’t try to change too much at once.
2. Move fast. When you obtain agreement on a change, take immediate action.
3. Demonstrate success. Make noise. Get the word out regarding improvements.
4. Keep evolving. Build on success and keep changing the process.
5. Keep succeeding. Focus on low-risk changes and a continuous improvement mentality.

photo credit: marsmet544 via photopin cc

Say It. Do It. Improve It.

Have you ever noticed that some people avoid the spotlight? That is, they like to work on low-key projects that don’t get a lot of corporate attention. I’m not in any way suggesting that they don’t work hard. They simply don’t like drawing attention to themselves.

Along comes an agile development approach using Scrum, Kanban, XP or Lean techniques and life changes. Suddenly, daily meetings, business involvement, and self-organization are thrust upon them. There’s no way to avoid the spotlight any more. It’s no wonder they don’t like agile software development!

This is precisely why we talk about agile development requiring a cultural shift. It’s not just a new technique for delivering software. Not everyone will succeed in an agile development shop just like not everyone succeeds in a waterfall shop. In the end, whether you succeed or fail is entirely up to you.

Think about it differently.

Scrum techniques such as splitting epics into stories, dividing stories into tasks, estimating tasks, getting to done, and meeting commitments are traits that every company wants in its employees. Whether your Scrum team succeeds or fails, you will be developing skills and experience that will reward you along your chosen career path.

While there is a lot of emphasis on the values expressed in the Agile Manifesto, enterprise companies don’t care. If your company has a set of corporate values — most enterprise firms do — they will trump agile values every time. Companies are focused on revenues and profits. They need all of us to meet our goals, keep our commitments, and support one another — skills we all need to master.

Let me tell you a story.

Many years ago, I worked at a small firm that was seeking ISO 9001 certification. They manufactured touch screens and touch pads. Being ISO 9001 certified was a prestigious accomplishment that many companies were eager to achieve at the time.

We hired a consultant with expertise in this area to help us prepare for the certification process. The most profound and useful advice he gave us was simply this — “Say what you do and do what you say.”

In other words, don’t get caught up in all the details around “best practices”, “process improvements”, and “operating efficiencies.” Simply document what you do and do it. We achieved ISO 9001 certification by following that advice.

Take the advice.

My advice to anyone who dislikes the development approach they are being asked to follow is to let others handle the process details. You need to be clear on your role and your commitments. Armed with that information — Say what you do and do what you say. That’s all any reasonable person can expect from you.

That advice — Say what you do and do what you say — encapsulates the essence of Kanban too. Start with what you do today. Don’t make value judgments. Just lay it out on the Kanban board and track it. Use the visualization to guide the team in improving the process. It really works!

One of the great features of any agile approach to software development is the ability to change the approach. Yes, any team member can contribute to changing how the software is delivered. Take advantage of it. Speak up. Make suggestions. Change is good.

photo credit: orcmid via photo pin cc

Scrum Is Not Stressful But People Are

I’ve heard complaints that the Scrum approach to software development creates a lot of additional stress. Really?  That perception needs further analysis.

The team commits to a delivering a set of stories by a target date. That’s stressful. They have daily standup meetings to report progress and discuss impediments. More stress. They have to satisfy a definition of done for every story. Added stress. Finally, they have to sit through retrospective meetings and take criticism. I’m stressed out just thinking about it.

It’s important to understand where the stress comes from and how it can be mitigated. Scrum isn’t designed to be stressful. When done well, the Scrum approach should be a less stressful and a more enjoyable way to build software systems. Here’s the lowdown.

The Sprint

Starting at the beginning, the team is committing to the delivery of a set of stories by the end of the sprint, usually 2-4 weeks long. We all need to make and keep commitments. It’s part of being a professional. Problems arise when management expects the team to deliver exactly the same number of story points – or more – during every sprint.

That’s not realistic. Software developers are human. They have family obligations, get distracted, encounter problems, make mistakes, etc. The number of story points delivered per sprint will fluctuate. Measure the average number of story points delivered over several sprints. The average sets an expectation for what the team can achieve over time but it’s not a guarantee for any given sprint.

The Standups

Much of the stress around the daily standups comes from managers who attend the meetings and interrupt with too many questions. They may unwittingly turn the standups into status reports. Everyone is pressured to report progress and commit to making more progress by tomorrow. Of course, poor managers don’t want to hear about impediments at all.

The daily standups are team meetings. They are not management meetings. Managers who want status reports should consult the Scrum Master after the standup. Let the team do it’s job.

The DoD

The definition of done (DoD) should be a useful artifact. It should help team members verify that all the steps required to deliver a story to the business are complete. It really should be a simple, helpful checklist. Don’t include lots of administrivia in your DoD.

If the definition of done is too long and complex, it will frustrate the team members. Keep it simple. Also recognize that the team needs to work together. If someone has trouble satisfying the DoD for a story, that person should ask for help (or better yet, someone should step up and offer help). It’s a team effort!

The Retrospective

As for retrospectives, they are a great tool for continuous improvement when used effectively. Beating up on people during retrospectives is not allowed. Neither should people be allowed to whine and complain. The focus is process improvement.

The topic of retrospectives is too broad for this short post but in essence, keep the retrospectives impersonal. Focus the outcome on one or two areas for improvement during the next sprint. Determine how the improvements will be measured and make sure they happen.

Now, relax.

Scrum and other agile development approaches are not torture tests. They are designed to improve teamwork and minimize the need for management intervention. If you’re stressed out, don’t blame Scrum. Blame the people around you.

photo credit: freeflyer09 via photo pin cc

Retrospectives Work When They Are Impersonal and Impartial

Retrospectives are a terrific way to continuously improve any software development process. As long as the organization is committed to improving itself, rather than protecting the status quo, there is nothing better than regular retrospectives.

So why are project retrospectives often ignored or under used?

There are many articles across the Web describing how to do retrospectives. They are not hard, though there is a serious pitfall that can derail the best of intentions. Retrospectives must be impersonal and impartial.

That’s harder than it sounds. It seems that many of us are conditioned to place blame. At least here in the U.S.A., we see plenty of people not taking responsibility for their actions. They want to blame someone else every time there’s a problem.

We also tend to easily become defensive. Even if a problem is being discussed in general terms and no names are mentioned, some people will jump to the conclusion that they are being targeted. This usually prompts them to retaliate. The session can turn ugly, quickly.

If anyone comes out of a retrospective feeling beat up, picked on, or abused, the event was a failure. Even worse, no one will want to attend future retrospectives out of fear that they too will be abused.

Let’s examine a few situations that cause such behaviors and how you might handle them.

1. There is one person on the team that is not carrying his weight. He is letting down the team and causing extra work for others. Is this a retrospective topic? No, of course not. This is a personnel issue and should be discussed with the team member in private.
2. One of the processes followed by the team isn’t working. It turns out that the process is always executed by the same team member but she is doing it faithfully as defined. The process needs to change. Retrospective topic? Yes, but! The issue must be discussed with the team member in advance. Explain that the process is flawed and ask for suggestions that can be aired at the meeting.
3. There is a process followed by most members of the team. But, a couple of folks take shortcuts resulting in unintended consequences. Retrospective topic? Maybe. There are two ways to handle this. a) Speak privately to those taking shortcuts and get them to stop; or b) modify the process during a retrospective so it works for everyone.
4. The Product Owner or Scrum Master is not fulfilling the requirements of the job or meeting the needs of the team. Retrospective topic? No! Again, these are personnel issues and should be discussed in private. If the PO or SM wants to seek feedback from the team, that’s fine, but only after a private discussion.
5. An end user, customer or client complains constantly and is difficult to handle. Retrospective topic? Yes, indirectly. The PO should engage the accused party in a conversation to uncover the real issue(s) and explore solutions. Meanwhile, the team can discuss how to better meet the needs of all people using the software.

The key points to take away are:

• No surprises. A retrospective is not an ambush.
• No confrontations. A retrospective is not a street fight.

Always keep Norm Kerth’s Retrospective Prime Directive in mind.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Walking into a retrospective and becoming the target of someone’s complaints is not fun. Retrospectives are for continuous improvement of the software development process. People improvement is valid topic as long as the improvements apply to everyone. Individual performance is off limits. Take it outside.

Software Outcomes Matter, Test Results Don’t

How do you determine the success (or not) of a software project? How do you measure the final outcome? How do you know if the project delivered what was expected?

You might be inclined to refer to the number of remaining known defects, the number of test cases, the improvements made in the code, the number of new features added, the feedback from the Product Owner, etc. Sadly, those are all the wrong metrics and don’t measure business outcomes.

What matters is end user perceptions and business value, not internal software metrics.

Real people, conducting real business with the software is the only true measure of outcomes. Here are a few real world examples where software teams thought they did a good job but the users disagreed. (I’ve avoided specifics to protect the guilty parties.)

• The software application functioned perfectly but was too slow to be useful by the large, target group. (Performance testing might have caught this.)
• The software worked properly but required too much manual data entry. (Useability testing might have caught this.)
• The software ran into a conflict with another desktop application meaning some people could not use it. (Additional analysis and testing of the target environments might have caught this.)
• The software worked fine but the new workflow actually took longer to get things done than did the old workflow. (Again, useability testing might have caught this.)

I’ve used the phrase “might have caught this” above because there is no guarantee that any laboratory testing will catch any particular complex failure scenario. Testing will catch the major problems and the expected ones. The subtle environmental issues are another matter.

This leads me to a more central question. If the ultimate measure of successful outcomes is the users’ perception, why aren’t teams doing more user testing? It’s not a simple thing to do. I get that. But, clearly we have to try harder. Here are a few suggestions.

• If you’re doing straight beginning to end waterfall, stop! You need to introduce interim deliverables. Break up the waterfall flow into a series of mini-waterfalls that each deliver useful functionality. Or, even better, dump waterfall entirely and switch to Scrum, Kanban, Lean or XP.
• If you’re already doing waterfall iterations, get the software into the hands of the end users sooner and more often. Draw them into the process. Engage them. Setup a small number of systems where users can stop by anytime and try out the latest build. Have lunch and learn sessions. Get creative. You need real feedback from real people.
• If you’re already using an agile development approach, focus more effort on the needs and concerns of the end users. It’s not about technology. It’s about them. Empathize more and they will respond in kind.

Recognize that software is a tool not an end game. Real people use software to accomplish something that adds value to their job functions or enhances their personal lives. Laboratory test environments can’t replicate every real work condition. There are too many variables.