In a previous post, I lamented people who were rewarded for heroic efforts despite their earlier actions causing the problems in the first place.
A couple of people commented that these “heroes” usually didn’t intentionally cause the near-disaster situation. More often, they caused the situation by neglecting to follow a proven process or by simply not being proactive. I agree with these comments, and I believe that this points to a common problem. People tend to celebrate the visible, novel, and dramatic rather than the smaller, more important actions that keep things running smoothly.
When I spoke at Agile Austin a number of years ago, one of the panelists mentioned that his team’s agile processes were working smoothly and his team was more productive than ever. However, several of his team members were becoming bored and unmotivated because everything ran too smoothly.
Around the same time, a friend on Facebook expressed frustration with the fact that people who lose weight “can brag about weight loss and exercise regimens and get praised by all, but a person talks about her workout and expresses pride, and they are met with sarcasm or daggers.”
This made me realize that people are rewarded more for the visible, novel, and dramatic in many areas of life beyond software projects.
This addiction to drama seems to undermine efforts to implement processes such as Embedded Quality that help projects run smoothly. Personally, I prefer to keep drama in the movies and out of my projects.
Is there any way to supply teams with the excitement and adrenalin rush associated with the visible, novel, and dramatic while still implementing processes and procedures that keep things running smoothly? It’s definitely a challenge, but there are some techniques that can help.
When a project goes smoothly because talented, dedicated people adhered to a good process, make that success visible. Celebrate the success publically and enthusiastically, and point out that the reasons for the success.
Talented, dedicated people crave novel challenges, so it’s important to provide productive challenges so people don’t fall back on the challenges of heroic efforts. The challenge might be to improve on the success of a previous project or it might be to learn a new skill, technical or otherwise. Any extra time or risk invested in team members learning a new skill on a project will pay dividends in employee motivation and skillset in the future.
If a team is forced to work ridiculous hours to save a project due to failure to follow a process, thank people for their efforts and point out how the drama should have been avoided. Don’t celebrate the efforts as something to be emulated in the future.
You do need to be careful to determine the true cause of the drama, though. Every project can’t be perfect, and you do want to reward heroic efforts when they’re truly justified.
I’m interested in hearing about other ideas for keeping teams enthusiastic and motivated when processes are running smoothly and efficiently. I’d love to hear about any techniques that you’ve tried and how they turned out.
A number of years ago, I read a headline that said, “Ex-Forest Lake fire fighter pleads guilty to arson“. The story went on to say,
“Once considered a hero as a firefighter, John Berken was accused of starting a fire that burned 2,000 acres of nature area.”
This story got me thinking about a common pattern that I have seen on software development projects.
Many teams glorify the team members who take heroic actions to save a project. These team members, who work nights and weekends for weeks, or even months, at a time to pull a project success from the jaws of defeat, are held up as positive examples for the company and lavished with praise.
However, too often, the very same people who perform the heroic deeds are the people who created the near-disaster in the first place.
As a QA Sherpa, one of my top goals is to prevent the need for heroic actions at the end of a project. I feel happiest when we successfully implemented Embedded Quality and find no important bugs during the last few weeks before going live. In this role, I’m particularly attuned to those “heroes” who actually created the problems in the first place.
These are the people who dramatically underestimated their work, skipped unit testing, refused to work with the testing team to practice Embedded Quality, and generally eschew any form of teamwork or foresight. Despite all these negative traits, they end up being celebrated for “going above and beyond the call of duty”.
True firefighters do need to be heroic at times, and it’s important that they are ready and able to be heroes when necessary. However, their bigger goal is to prevent fires in the first place. In addition to preventing fires, they work hard to put measures in place to limit the damage of fires when they do occur.
The bulk of a fire department’s efforts are not spent putting out fires. The bulk of the time is spent educating people about how to prevent fires, ensuring that the fire code is effective and that buildings follow the fire code by implementing fire walls, fire doors, sprinkler systems, alarms, and fire extinguishers.
Similarly, a solid development team should be spending their time implementing automated unit testing, working with the test team to implement Embedded Quality, performing peer code reviews, and getting feedback from key stakeholders throughout the project. All of these actions work both to reduce the odds of a disaster and to limit the damage when a disaster occurs.
As I said earlier, heroes are still needed at times, but you should take a second look at those heroes when the disasters are too frequent. If a city has way more fires than the norm, the fire department probably isn’t doing their job well. If every project requires heroic measures, it’s time to look a little closer at why that’s the case.
I’m interested in hearing about your experiences with fire fighters who may also be arsonists. Have you worked on a project where team members who seemed to sabotage the project early on were held up as heroes at the end of the project? If so, do you think it was due to the individuals on the project or due to a broken system?
There are a number of blogs that I enjoy reading about all areas of the software development process. The software development process includes project management, business analysis, development, and testing, of course. In addition, delivering software that works requires consideration of concepts around management, sales, and business organization.
I’d like to share some of the blogs that I find influential when thinking about how to build software that works.
One of my favorite blogs is James Bach’s Blog. He is the creator of Rapid Software Testing. I first became interested in his blog because he wrote about exploratory testing in a way that made sense to me. I knew from experience that exploratory testing was one of the best ways to find important bugs, but I didn’t have a great way to communicate the high value of exploratory testing to teams that were focused heavily on mechanizing the testing process. James Bach has written a lot on the topic of exploratory testing. This particular post about the history of Exploratory Testing captures many of the concepts that drew me to the blog.
What do you think of James Bach’s blog and the concepts he writes about? What blogs and resources do you find particularly interesting and useful for building software that works?
Embedded Quality is a Quality Assurance (QA) technique that I’ve introduced on many projects with great success. Embedded Quality has some of the following benefits:
The basic concepts of Embedded Quality are nothing Earth-shattering. The concepts draw from standard software development techniques and seem like they should be common sense. However, in the 20+ years that I’ve been working in software development, I’ve found that these concepts are not commonly practiced.
QA starts on Day 1
I have found that on many projects, Quality Assurance is an after-thought. Involving QA as part of the core project team helps prevent nasty surprises at the end of the project.
QA is part of the Core Project Team
Too often, the development team and QA team are completely separate entities who send their work “over the wall” to each other. Quality and speed increase exponentially when we break down the barriers between these groups and work as a team.
QA is performed by qualified experts
One of my clients used to hire people out of high school to test their software. If they did well, they got promoted to doing phone support. Eventually, they realized that they could drastically decrease phone support and increase customer satisfaction by hiring qualified people to do their Quality Assurance work.
Just as building inspectors need special knowledge and experience to do their jobs well, software QA experts need special knowledge and experience to do their jobs well.
General User Acceptance Testing (UAT) does not begin until Core Project Team QA is complete
A common practice on projects is to rely on UAT as the only form of testing. This results in the end users seeing a large number of the flaws in the software. Invariably, I have seen the end users permanently lose confidence in the development team when using this QA strategy.
I liken this to a builder turning over a new house to a buyer without having any inspections and saying, “We don’t really know if the plumbing is solid, all the electricity works, or the roof leaks. Just try everything out and let us know what the problems are.” (In fact, this does happen: http://abcnews.go.com/GMA/Consumer/story?id=2630414&page=1.)
Strong Foundation – No code is “Complete” until it is tested and works correctly
Many project schedules track code as complete when the developer completes their initial delivery. This can give a false impression of the project status.
More importantly, this ensures that new code is built on a strong foundation. When developers build new code on untested code, it is very similar to building an office tower on a foundation that has not been inspected. If a problem exists in the foundation and is not identified early, the building will fail.
Embedded Quality – Next Steps
Over the next few months, I will post tips on how to implement Embedded Quality on your next project. I’ll share stories of my experiences over the past 20+ years, and I would like to hear your experiences as well.