What should Miles do?
A software developer in California (I’ll call him Miles) wrote to me recently with a question about motivation. Instead of answering right away, I asked if I could pose his problem to all of you. Perhaps by combining our minds, we could be a free open source McKinsey & Company for motivation.
So here’s Miles’s question for us:
“How would you motivate a software team to reduce bugs in a product throughout the development process instead of just the end?”
And here’s my question for all of you:
What should Miles do?
Offer your answers in the comments section. I’ll weigh in with my own thoughts. And in a week or so, I’ll post our common solution.
Browse Similar Posts: Management, Motivation
63 Responses to “What should Miles do?”
Leave a Comment
Comment Policy: First time comments are moderated. Please be patient.
Avnet’s CEO Roy Vallee answered this well in a recent interview:
“Any time you want a group of people — whether it’s all employees, a specific segment, a management team — to buy into a new concept or an action item, if you give them the opportunity to participate in development of the item itself, or what action is going to be taken, then you have a lot of buy-in going forward. Any time the ideas are cultivated in a dark room, especially in the corporate office so to speak, and then you try to sell, it’s going to take longer to get implementation.” (full interview here: http://knowledge.wpcarey.asu.edu/article.cfm?articleid=1836)
This reiterates what many commenters have already said: let the people be part of the solution.
Crowd source the solution from them just as you have done with us. I suspect that developers are problem solvers and when presented with the problem and some broad parameters and autonomy to solve it, great things will happen.
I would certainly advise against any type of incentive. This can create competition among team members if there is any attempt to single someone out and “reward” them. It will also focus their attention in the wrong direction. My question for Miles is why does he think he needs to motivate them? I realize this question may sound like a simplistic or even flippant question but it is not. It is the fundemental question.
TO give full disclosure. I know nothing about code or developing. The question I have is WHY are the bugs built in. Is there something built into the management system of the business that causes them to aim for completion of the project without as much consideration for “bugs” in the code? If so, this is a management issue not a developer issue. Is the timeline for completion realistic? Are they clear that “no bugs” is in their job description and not just a part of QA? There are many questions to ask here to uncover the root cause. People generally behave logically based on the system they are provided.
The question of why the bugs are being built must be asked and if the developers are given an opportunity to discuss it without fear of repurcussions you may find the answers surprising. Once the answers are known then a solution can be found. I agree with many of the above comments that the developers must be a part of the conversation to create the solution. Who else could be?
Incentives and rewards will not work. They will cause a different type of problem and they will not cure the current one.
To bang on the agile drum just a little more: Forrester Research has a good current summary of the state of Agile QA:
http://www.forrester.com/rb/Research/few_good_agile_testers/q/id/55596/t/2
I also like to discuss things up front in terms of the “iron triangle” of software quality — Scope, Schedule, and Resources. Pick two and recognize the third will be compromised, and make sure all stakeholders (including development) are on the same page about these decisions. Of course, finding bugs early is a way to mitigate expense and time if you are putting less emphasis on schedule or resources.
I assume the bugs exist because people are doing the coding. Eliminating human error is a tough pursuit. Here are some quick ideas that could help motivate the reduction of bugs.
1) Let coders come up with the incentives (motivators) to do their jobs better. Then link that motivator to their job.
2) Offer flex time, let developers code when they are at their best (which could be 3am).
3) Delineate the development process starting at the end.
4) Spend more time in the hiring process to identify people who LOVE to code and have a high inclination towards excellence.
5) Open up the conversation to discuss why it’s worth avoiding the bugs and doing it right the first time , rather than coming back to fix it.
PS: Hey Dan, just bought your latest book while buying gifts for “others.” This one is for me!
Happy Holidays!
Perhaps the following approach would work:
1. Before the project begins, the project manager invites the programmers in and hosts a discussion on the pros and cons of debugging as you go vs debugging at the end of production. I would also suggest that an end user be in the room to explain his/her experiences/frustrations with dealing with a program that hasn’t been adequately debugged.
2. Briefly instruct and inform the programmers on the differences between “discussion” and “dialogue”. Discussion brings all possibilities to the table without fear of judgment or ridicule. Dialogue is the process of talking through each option and finding the best one.
3. I would suggest that daily or weekly Discussion/Dialogue sessions would be beneficial at first. After the initial session, they probably won’t take long because they can become item/problem specific.
The simple process above allows the programmers to identify the problems and work through them as they go. Perhaps they will find that debugging as you go AND debugging at the end are necessary to the process.
One more thought: it would seem to me that debugging as you create would provide more learning opportunities for the programmers. I would suspect that the more serious programmers love to learn from their mistakes or from the unexpected surprises that pop up. Perhaps turning the debugging process into a process of inquiry and learning would help them be more proactive in their approach to development of a product.
In addition to finding the most effective system (non-waterfall) I use techniques similar to Heidi Kraft #47.
Keep sharing new learnings between members along the way.
1) Brainstorm with the whole team a vision of how they would love the project to look at the end (including Q&A/debugging).
2) Prioritize the vision ideas so there are 5-7 top components of that vision.
3) Ask them to describe vividly how this would look and feel to achieve this. (This creates appealing internal imagery that guides fact-driven and emotion-driven decision-making.)
4) Imagine the coding process is completely open to redesign. Brainstorm how to handle quality issues (connectivity, bugs, etc.) in an ideal way to ensure the desired outcome.
5) Choose the ideas that make the most sense to the group. Highlight the interesting and new ideas.
6) As a leader give frequent (particularly at the beginning) reinforcing feedback when you see the new great ideas being applied.
7) When unexpected mistakes happen, bring them as challenges to solve to the team.
This process tends to support high motivation and easier innovation. Making problems into group challenges tends to increase collaboration and much faster learning.
Best wishes!
6) Decide how to implement
“HOW would you MOTIVATE a software team to REDUCE BUGS in a product THROUGHOUT the development PROCESS instead of just the end?”
Miles is asking for an algorithm.
Background: software people are into the trees of a process. We need to show them the forrest. “Show” is helping them use the right side of their brains, see new patters, make new connections. Visualizing is key here. (see NYT interview with Daniel Schwartz, ceo Timberland http://bit.ly/8Ozo1j )
Steps to helping software teams see both their process and the big picture, which will then enhance their right brain to work with their left brain and result in reducing bugs during process development.
1. Place two large white boards in both the “working room” and “eating/conversation” room (kitchen or lounge).
2. On one giant white board A, show a stunning, imaginative, dominant illustration of the finished product by a skilled artist.
2b. On same white board A, show series of subordinate illustrations, in black and white, showing various architectural, blueprint-like perspectives of product.
3. On different white board B, placed to left of board A, have the team come up with and name this board based on a fun, game-like “team name” based on their particular team’s function in the process. Example, if the product was a new Nike basketball shoe and my team was involved in the bottom outer tread, we might name our team “The Burn Blasters.”
3b. Under their fun, competitive team name is the line consistent with all teams’ boards: “Zero Bug Tolerance”
3c. Under ZBT line, are 3-5 bullet points that the team determines for HOW they in their particular part of the overall process CAN IDENTIFY and DE-BUG THE BUGS.
3d. A small, separate red box titled “BUG BOX” is where team keeps count of the bugs they’ve identified and de-bugged (e.g. 10 / 8 shows they’ve i.d.’d 10 bugs and de-bugged 8 of them. Thereby, establishing the reality of bugs that will just have to be addressed at end (remember, the goal was to reduce, not eliminate” — even though the “zero tolerance” aspiration is to motivate.
3e Under bullet points, there’s plenty of working white space for team.
(NOTE: THESE BOARDS ARE WIRELESSLY CONNECTED TO A PRINTER FOR SAVING AND PRINTING OUT IMAGES, SO TEAM CAN DOCUMENT AND ERASE)
3f. At very bottom of board, on a colorful banner, is the teams’ own voted-on destination for where they would like to go, anywhere in the world, as a reward for being the team to do the best “bug-id and debugging” (e.g. CABO, MEXICO in orange, pink and blue marked text and any little design elements like waves, palm trees, drinks, etc they want to draw in).
3g. Smaller, but still done with a flair, and under the destination desired by the team if they win, is their voted-on hotel-spa and/or restaurant within 100 miles that they would win time at for coming in 2nd.
3h. Each “bug” identified earns a team (and so motivates them to simply i.d. as many bugs as they can) $200 per bug or whatever is reasonable but motivational for a team to collect and split and significant sum, especially should this be the only prize they win, a likely scenario the larger the number of teams. A bonus of $100 per de-bugged bug is awarded.
4. At end of process, when all teams come together, the winning and 2nd place team may confer to award a 3rd MVP (most valuable players) team and that 3rd place team wins an additional $$$ prize to be split among them.
5. T-shirts and hats and light or heavy motorcycle jackets, depending on weather and team choice) are given to each team member, as well as temporary tattoos: the team name/logo and t-shirt/hat/jacket/tattoo are designed and implemented by top, name designers brought into the company to meet with teams to get their own particular vibe and personality and input.
The master company logo is complementary yet can be subtle and subordinate to the team name/logo, per the team-designer discretion
6. The winning teams photos and/or videos are put onto a separate website and internal social networking site (e.g. Tumblr).
7. Each quarter, the teams participate in some kind of other, totally work-unrelated competition (e.g. bowling, softball, Top Chef, music/bands, etc) they vote on together.
8. End of Year/Holiday: prizes to top 3 teams and individuals from all/any teams for pre-determined achievements ranging from technical to social and comical (e.g. Best Dressed, Worst Jokes, Most Likely to Go AWOL)
Miles asked for motivation. You can’t shortcut the process of motivation any more than the process of their technical endeavor…and expect success. It’s got to be remarkably conceived and executed. It will matter.
- Jan Zlotnick
Dear Miles, you ask the impossible.
The larger the product, the greater the frequency and complexity of the bugs. The occurrence of bugs in software is like gravity: there’s no sense in trying to eliminate gravity, you have to learn to live with it. And the way to live with the inevitability of bugs is to build less and test more frequently.
There are two ways to accomplish building less and testing more frequently.
1. Reduce the number of features to the essential minimum, develop, build, test, debug, release, maintain (gather user reactions, design new features, develop, rinse, and repeat).
2. Divide your project into units, and test the units, also known as, unit testing (everyone has heard of it, no one does it). The earlier unit testing is introduced into a project, the sooner bugs can be identified and destroyed.
Building less and testing more frequently won’t produce motivation, but it will help your developers to maintain their motivation by
1. Helping to reduce the duration of the development life cycle. Nothing kills motivation like three months of work on the same project, except perhaps for being buried beneath the landslide of bugs that will ensue at the end of such a marathon.
2. Creating an opportunity for competition and/or collaboration within the development team. Breaking a project into units smaller than FRONT-END and BACK-END will require the following: more design (never a bad thing), and more communication (sometimes a bad thing, unless someone capable is in charge of the meetings).
The holy grail of building less and testing more frequently is to get real. If you’ve never read it, the 37signals publication Getting Real is not to be ignored. Getting Real plays to the build less, release more often approach to mitigating the severity and frequency of bugs.
The next best approach, playing to unit-based development, is test-driven development – something else I’ve never encountered in the wild. Start with a functional spec – what does this program do? Then write some code that pretends the functional spec has been implemented (unit testing frameworks make this possible). When you run the test code, it should fail on every single count. Next, implement the functional spec. The development cycle is complete when the test code executes without error.
Once you’ve decided upon a mode of operation – a choice that will likely be dependent upon your team’s skills – then you must match individual talent to project role. Nothing breeds motivation like a passion for one’s work.
Good luck!
As a developer, I don’t introduce bugs into the code because I am lazy, or because I don’t see the value in fixing bugs early instead of later (1:10:100 rule; for those non-development types
is the ‘cost’ to fix a bug in Development, Test and after Release).
For me, I think the main reason bugs usually get introduced is either (a) unclear requirements and I make an assumption, (b) I haven’t thought of all the possibilities of a section of logic in a program, or (c) carelessness/I missed something (I’d like to think this doesn’t happen, but sadly, I still have my ‘D’oh’ moments).
I think for your team, the development team (developers, requirement gatherers, testers) need to meet (perhaps without the glaring eyes of management) to discuss why bugs slip into your organizations code. For arguments sake, I’ll assume the problems are the same as mentioned above.
After identifying why you have bugs, the next step is how to fix it. For the reason I have bugs, I think the biggest potential solution would be to introduce pair programming (as previously by other readers as well). [Pair programming is when 2 people sit side by side infront of one keyboard working on the same problem-- writing code for a portion of the application]. Pairing between developers is good, but so would be pairing with a developer and a business requirements person (whichever term you use for the person that understands why the program should work in a certain way).
The catch with pair programming is the perception that you’ll get only 1/2 the work done (2 developers working on something instead of one). While I don’t fully by thats the case, I do appreciate the perception.
Now, the question is not just if you have asked your team to make the commitment to bug free code, but is the organization on the same page. There will [probably] be a cost, but lets just for argument sake assume the organization is on the same.
Introducing pair programming (and potentially its additional cost), should help to eliminate at least some of the issues listed above (a) requirement misunderstanding, (b) additional possiblibles, (c) carelessness.
It would also show the team that you understand that the reason their are bugs isn’t that the developers are not good developers. They could be excellent developers and there would still be bugs. Just that the team is stronger when it works together (ouch, that sounds very cliché, but its true), and the organization is there to support the team.
And as a developer, kick-ass machines never hurt too…
…and at least 2 monitors.
[Totally agree with you their Scott Smith!]
I should have mentioned, that while I agree Agile would be great to use, if the organization is a pure Waterfall shop, it might be unrealistic to expect that the team is going to start producing better code right off the bat with the new process. It might be better to try baby steps.
I know thats heresy, but depending on Miles’ timelines, if he is looking for results in the short term, switching fully to a brand new development process across the board might do more harm then good.
Unless Miles can ‘un-limit’ beliefs, he can develop his people’s skills all he likes, but they will be hard pressed to actually use them under pressure, and with any degree of sustainability.
Apart from identifying what it is that limits people, we should also recognise how critical it is that we discover what their real talents and passions are. If we can un-limit their currently limiting beliefs, and stir life into their passions and talents, then we create an environment in which they are inspired to, literally, unleash themselves for personal and organisational success.
These kinds of questions Miles could ask his team, as a means of catalyzing change in thinking and behaviour are:
• What inspires me?
• What am I passionate about?
• What is my purpose and personal vision?
• How do I make the shift from being so powerfully driven by habit, to operating from a place of awareness, self direction and choice?
To engage the whole person in a work context Miles needs to focus on creating the space for individuals to find the ‘True You’ or ‘meaning to my life’ connection. Their work and leadership role then becomes a vehicle through which they are able to live what is important to them. In return the business will get the potential and energy that flows from engaging an individual’s physical, mental, emotional and spiritual quotients.
This aspect of engagement has less emphasis on the ‘doing’ of work and leadership and more emphasis on the ‘being’; the self awareness and self belief to harness intuition, talents and strengths. This falls into the SQ/EQ domain and is therefore more transformational than transactional in nature.
What weknows works best is engaging and growing people in a way that makes sense to them, wherever they are at in their lives, leaving them with a renewed sense of hope, possibility and self-belief to engage with and live the change they desire, and which the business needs. No matter what the required business outcome is, if people are able to approach it with strong sense of self and see the same context through new eyes, the possibilities for engagement and the sustainable delivery of strategy and process are so much better.