I'm sure you've often heard people ask not to 'Play the Blame Game' when an issue comes up during a project (or after a project has launched). Typically, they are two types of people: 1) people who feel the blame game would end very poorly for them and 2) people who are actually interested in solving the issue as soon as possible, and don't want to wade through the morass of figuring out who did it when making it not exist is the company/team/group priority.
Note, the two types of folks opposed to the blame game are not mutually exclusive.
Those invested in the blame game--who dive immediately into "who did this"--are 1) trying to figure it out so they can assign someone to fix it, 2) trying to figure it out so that it never happens again, 3) feel impotent because they can't fix it and finding who did this is something they can do 4)know exactly who did it and are trying desperately to push blame elsewhere for reasons of their own or 5) some combination of these things.
When dealing with an issue that results in some version of the Blame Game--either people deliberately asking not to play it and then playing it like crazy or folks invested in it for other reasons as listed above--you have to consider two main things: 1) Everyone involved needs to escape with their face intact (ie: not losing face) and 2) getting through the process (or skipping it if possible) as fast as you can so you can address the issue; as much as upper management may wish to know whom to crucify, they are twice as interested in knowing whom to hoist on their shoulders for leading them out of this calamity.
I like to do the following to step around the entire blame game and all the emotional and political investment within it: postpone it. Explain to everyone you can have a review or a post mortem or whatever you want to call it (I've always thought calling it a post mortem was too akin to investigating a death, which is not really what I want people to think of when they think of me and my projects) AFTER the problem is solved.
People who are scared (either because this is their fault or their afraid it will be blamed on them) will try to force the issue now. Some very well meaning people may wish to push the issue to "prevent it happening again." I liken it to a group of Girl Scouts in quicksand. Yes, putting up a sign that there is quicksand here will really help the next pack of scouts, but probably won't save the lives of the current girls slowly descending.
That said, if you have to do so, you can work with those folks who are alarmed and create an investigation of some sort to keep them happy and occupied. For example, my preferred method would be to talk to a senior dev and ask her/him to "investigate" how things happened, to appease those who are very concerned, and then work with the rest of the team to fix the issue immediately.
Investigations can also be highly useful for getting rid of people who are not actually helping. That is to say, when the Titanic sank, there were a lot of people squabbling about the iceberg and how to avoid it blocking the exits for other people trying to get off the sinking ship. Give those people something to DO. Put boundaries around their investigation, such as not being able to talk to the team until the issue is resolved, and spend some personal time with them (so they don't go looking to talk to the team, anyway) with some suggestions for future prevention that they can write up and "explore" with others.
You'll have to sell investigations to avoid a blame game, but you'll find it much easier to sell an investigation than to actually PLAY the blame game. Also, having an investigation in place while the team works to resolve the issue sounds very good in status reports to upper level managers anxious to find out what's being done NOW.
Now that the game is postponed, work to fix the problem. Offer amnesty to the entire team. It is your job to take it on the chin so they can get their work done, and this is one of those cases where you should do that. Anything they say will be kept within the team unless they agree otherwise. Let the team be honest and open with each other about mistakes, forgotten features, misunderstandings in implementation, unclear requirements, whatever. This honest is the fastest possible way to get the issue resolved. Be available to get them anything they need, from additional technical expertise to a product manager in the room to answer specific questions for them (but not actually grilling them on what they're doing or why this happened).
Resolve the issue. Note I did not say "fix." Fixing things often takes additional releases and external input. But triaging and resolving the immediate issue will make consumers, management, and the team happy.
Next step, face the postponed music. I like to gather the investigators and the team and have the investigators start by declaring their "findings." These are abbreviated to three or fewer bullet points on a white board. Then I put up the categories of "What Went Well?" "What could have gone better?" and "Action Items." If people want, I include a column for "Kudos."
We go through the "What went well?" category, drawing in investigatory findings as appropriate, and we follow that up with "What could have gone better" in the same way. Once folks feel they've got a good amount of stuff in both columns, we move to Action items and try to derive what next steps will be taken based on what went well as well as what went poorly, for the next version of the product and/or the immediate future of this resolution. Finally, I like to go over the Kudos column and end the meeting on a high note, celebrating team members, investigatory team folks, etc., for their work on SOLVING the problem.
Take all the notes from the meeting and pass them to all attendees and upper management. Post the action items where they can be seen/used for future versions.
Note this process completely avoids blaming anyone. If people try to pigeonhole in on that, drive them right back out. I like to say "It's not the people we are unhappy with, it's the behavior, so let's mark the behavior and not the people. Behavior is easier to change." This is where you protect the team to avoid finger-pointing and blaming. Even at this phase in the process, after the issue is triaged, blaming isn't helpful. Knowing which individual screwed up isn't as important as knowing how not to screw up again, and this review/post mortem/whatever you call it is going to help you not screw up again, with findings that reinforce that and can be shared with any and all involved...thus shutting down the blame game entirely.
In summary, avoid the blame game in all it's forms, postpone the blaming, include investigation to keep people busy (and out of your hair), protect your team and encourage honesty and cooperation, resolve the issue, face the postponed meeting music, and walk away with next steps to avoid this in the future. Above all: don't let any one person be blamed for anything. Its counterproductive and if you plan on working with these people again--which you probably will unless you immediately quit your job--its in your best interest everyone continues to get along.
Tuesday, March 27, 2012
Tuesday, March 20, 2012
Don't Let Perfect Be The Enemy of Done
A problem not often discussed in management is employees that are too conscientious and so eager to make an excellent product/program/etc. that they may, in fact, blow right past deadlines in trying to put out the best possible thing they can produce. On the face of it, it's a good problem to have all things considered: folks working with and around you with little interest in the best outcome is a completely different, and very serious problem to have; its hard to get people to care, but it is easier to reign in folks that care too much. Many people would be stoked to be with a team that puts quality above all else.
However, there's a reason that Voltaire wrote "Le mieux est l'ennemi du bien," frequently translated as "The perfect is the enemy of the good." Even in his day, a missed deadline was a missed deadline, and it didn't really matter how seriously awesome the castle walls were if they weren't up by the day they were being attacked by the British.
It is a fine balance between focusing on quality and focusing on the deadline. Delivering a product on time with too many bugs and not enough features should be just as bad as missing the deadline, but having great quality two weeks later. Sadly, it typically isn't because most companies measure success by meeting deadlines. While bugs creeping into 'finished' projects at the end often cost the company considerably more than what they would have if they'd been eliminated in the design phase, the types of measurements for fixing critical bugs don't often factor into the review process for the folks setting the release cycle. Additionally, the bugs that don't get fixed--in favor of putting in more features, for example--have no easy method of measuring affect to the users of the product unless they are very severe, in which case they affect the trust relationship with the customer. Understanding of this affect goes from 'hey, nothing's wrong, we rock' to 'crap, they hate us, what now?' pretty darn fast.
Not all companies judge strictly by the requirements of the deadline; but in software, my experience has been that at least 75% respect the deadline more than just about anything else. So deadlines are important. However, so is quality.
While I've discussed that it's hard to quantitatively determine loss of productivity and money in terms of missing bugs, I can say that there are losses if not all features are implemented, and those are very easy to ascertain. In working on a banking application, for example, failing to complete the user creation portion of the process renders the rest of the program useless, because users cannot log in to access their account information and/or make transactions. For a social website, completing the e-commerce component but failing to provide the services promised by marketing--for example, forums for the users to discuss things--have immediate impact on sales and the future success (if there is a future) of the product being constructed.
Thus, the quandry: the item needs to be built and delivered on time to preserve you and your team's reputation and your livelihood within the company as well as the company's livelihood, but it also needs to be feature robust (at least to some extent of the promises made by marketing/sales so people will buy/rent/use it) and as bug free as possible (to avoid affecting future feature creation which would be delayed by mission critical bug fixes or, worse, loss of trust with clients over severity of live bugs).
Take this quandry to a team of professionals who are here to kick ass and chew bubble gum, who are now all out of bubble gum, and you are in a position where you have to balance their natural desire to kick ass with quality as well as to kick ass within the assigned time frame.
Whether your industry is computer/IT (like mine) or building ambulances, you need to build in quality as part of the construction process of the product. Including quality in the feature creation and description will help you estimate the time to complete those features, quality included. In my previous article on the iron triangle, you have three axis to play with in order to complete a product: resources, schedule and scope. Including quality in the construction of the scope gives you information about the schedule, and can let you know early on if you need additional resources.
Prioritizing the scoped features is another huge help. Folks concentrating on quality will feel good about knowing what the most important items are to be quality, versus the items cared less about product management. For example, in a software product, the additional work to completely redesign the existing UI is easy to prioritize below the new features being promised by sales; on the ambulance example, the length of time the red paint on the ambulance will last is not as important as building a car that can withstand an impact going through a red light with a patient in the back and getting hit by someone who cannot hear the siren.
This gives your quality folks a place to SHINE. It gives them focus to make things great, and to spec out the time for that greatness. It then gives you more to bargain with and discuss when you get to the less prioritized features; they may still want everything perfect, but you have given them an opportunity to get other things perfect. Now you can focus them on getting things DONE.
Even then, folks who like to do things perfectly are usually unhappy (at least a little), and that's really what you love about them: their devotion to the work. In this case, you write bugs for the imperfect parts. You prioritize the bugs and fix the highest impact/most important ones, and then set the others aside for the next version of the product. They feel heard. Their ideas aren't lost. They can let go of perfect, and get to good.
Sometimes, as the manager, its you who needs to confront your assertions around perfect and done. It can be overwhelming to feel that you have X amount of time to deliver Y amount of quality. 99% of the time, the way that schedules are created, that business folks come up with new ideas, that customers request things, that bugs are found, things are set up to prevent both quality and timeliness. Its not like a group of people organize it that way just to see what you'll do (though it can often feel like that), it's just how things fall out in business when multiple parties at multiple levels provide input and priorities.
To combat it, do the same as you would for your team: include quality in the feature creation and scoping process, prioritize the highest features that deserve the most quality, "let go" of your need for perfection in the lesser prioritized items, and keep track of defects/issues/bugs so that the imperfections can be fixed at another time, but you can release the product now.
Good enough sounds terrible to say: "This product is good enough to go out." But the truth of the matter is that if you built a quality product, it really is good enough to go out. And the next version will be even better, because of you and your team's committment to quality. Don't let perfect be the enemy of done.
However, there's a reason that Voltaire wrote "Le mieux est l'ennemi du bien," frequently translated as "The perfect is the enemy of the good." Even in his day, a missed deadline was a missed deadline, and it didn't really matter how seriously awesome the castle walls were if they weren't up by the day they were being attacked by the British.
It is a fine balance between focusing on quality and focusing on the deadline. Delivering a product on time with too many bugs and not enough features should be just as bad as missing the deadline, but having great quality two weeks later. Sadly, it typically isn't because most companies measure success by meeting deadlines. While bugs creeping into 'finished' projects at the end often cost the company considerably more than what they would have if they'd been eliminated in the design phase, the types of measurements for fixing critical bugs don't often factor into the review process for the folks setting the release cycle. Additionally, the bugs that don't get fixed--in favor of putting in more features, for example--have no easy method of measuring affect to the users of the product unless they are very severe, in which case they affect the trust relationship with the customer. Understanding of this affect goes from 'hey, nothing's wrong, we rock' to 'crap, they hate us, what now?' pretty darn fast.
Not all companies judge strictly by the requirements of the deadline; but in software, my experience has been that at least 75% respect the deadline more than just about anything else. So deadlines are important. However, so is quality.
While I've discussed that it's hard to quantitatively determine loss of productivity and money in terms of missing bugs, I can say that there are losses if not all features are implemented, and those are very easy to ascertain. In working on a banking application, for example, failing to complete the user creation portion of the process renders the rest of the program useless, because users cannot log in to access their account information and/or make transactions. For a social website, completing the e-commerce component but failing to provide the services promised by marketing--for example, forums for the users to discuss things--have immediate impact on sales and the future success (if there is a future) of the product being constructed.
Thus, the quandry: the item needs to be built and delivered on time to preserve you and your team's reputation and your livelihood within the company as well as the company's livelihood, but it also needs to be feature robust (at least to some extent of the promises made by marketing/sales so people will buy/rent/use it) and as bug free as possible (to avoid affecting future feature creation which would be delayed by mission critical bug fixes or, worse, loss of trust with clients over severity of live bugs).
Take this quandry to a team of professionals who are here to kick ass and chew bubble gum, who are now all out of bubble gum, and you are in a position where you have to balance their natural desire to kick ass with quality as well as to kick ass within the assigned time frame.
Whether your industry is computer/IT (like mine) or building ambulances, you need to build in quality as part of the construction process of the product. Including quality in the feature creation and description will help you estimate the time to complete those features, quality included. In my previous article on the iron triangle, you have three axis to play with in order to complete a product: resources, schedule and scope. Including quality in the construction of the scope gives you information about the schedule, and can let you know early on if you need additional resources.
Prioritizing the scoped features is another huge help. Folks concentrating on quality will feel good about knowing what the most important items are to be quality, versus the items cared less about product management. For example, in a software product, the additional work to completely redesign the existing UI is easy to prioritize below the new features being promised by sales; on the ambulance example, the length of time the red paint on the ambulance will last is not as important as building a car that can withstand an impact going through a red light with a patient in the back and getting hit by someone who cannot hear the siren.
This gives your quality folks a place to SHINE. It gives them focus to make things great, and to spec out the time for that greatness. It then gives you more to bargain with and discuss when you get to the less prioritized features; they may still want everything perfect, but you have given them an opportunity to get other things perfect. Now you can focus them on getting things DONE.
Even then, folks who like to do things perfectly are usually unhappy (at least a little), and that's really what you love about them: their devotion to the work. In this case, you write bugs for the imperfect parts. You prioritize the bugs and fix the highest impact/most important ones, and then set the others aside for the next version of the product. They feel heard. Their ideas aren't lost. They can let go of perfect, and get to good.
Sometimes, as the manager, its you who needs to confront your assertions around perfect and done. It can be overwhelming to feel that you have X amount of time to deliver Y amount of quality. 99% of the time, the way that schedules are created, that business folks come up with new ideas, that customers request things, that bugs are found, things are set up to prevent both quality and timeliness. Its not like a group of people organize it that way just to see what you'll do (though it can often feel like that), it's just how things fall out in business when multiple parties at multiple levels provide input and priorities.
To combat it, do the same as you would for your team: include quality in the feature creation and scoping process, prioritize the highest features that deserve the most quality, "let go" of your need for perfection in the lesser prioritized items, and keep track of defects/issues/bugs so that the imperfections can be fixed at another time, but you can release the product now.
Good enough sounds terrible to say: "This product is good enough to go out." But the truth of the matter is that if you built a quality product, it really is good enough to go out. And the next version will be even better, because of you and your team's committment to quality. Don't let perfect be the enemy of done.
Tuesday, March 13, 2012
Link it, Link it Good
This week, there was some cool stuff that came to my attention in the overall Internet news. I share it with you now, and we return to your regularly scheduled posts next week.
Enjoy!
Enjoy!
Subscribe to:
Posts (Atom)