TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Pack Up Your Troubles



A StickyMinds.com Original
Article Picture
Pack Up Your Troubles

By Fiona Charles

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Who likes working on troubled projects? Fiona Charles does. In this week's column, find out why Fiona sometimes seeks out such projects and how she maintains the right frame of mind to allow her to solve problems creatively and devise tactical solutions to project issues. More importantly, you, too, can learn how to enjoy troubled projects and develop your project skills.


TechExcel, Inc.
I like troubled projects. You may think that's crazy, but troubled projects offer tremendous opportunities for creativity and accelerated learning. The more problems a project has, the more opportunities for problem solving!

I've worked as a test manager on several troubled project "rescue teams," and discovered a few strategies for surviving--thriving, even--while playing my part in a turnaround.

The Testing Hot Seat
Troubled projects are difficult for everyone, but present particular challenges for testers and test managers. When a project management team has skirted issues, testing often exposes the cracks. If the project has a history of missing or poorly understood requirements, cumbersome architecture, design problems, or overly-rushed coding, issues will accumulate, resulting in a system full of bugs. When the bug rate of arrival goes off the scale, testing slows down, and everyone’s anxiety level goes up. Also, troubled projects are usually late; once they get into testing, the delay increases.

Just the Facts, Ma'am
When the emotional temperature is rising, only a clear and calm presentation of facts will bring it down.

Testers tell you they can't test; everywhere they turn, there's a bug blocking them. All the while, everyone else says, "Why is testing taking so long? Test faster!"

Your first priority is to get clear information about the quality of the system (or the current build) across as broad a range as possible. What's the smallest number of tests that will give you the most information the most quickly? Taste every significant component fast--run a simple end-to-end test through an application, such as the most vanilla sale and return through a Point Of Sale system; or, for a Web-based system, a series of quick dips into every page.

How you present the resulting information is critical. Ideally, use a format that gives a clear and comprehensive picture of system quality up front, and then keep using it to show progress and status. I use a colorful graphic table, designing it carefully to show simple categories of information across the entire application. Wherever possible, show the information in business terms, so it's meaningful to all stakeholders.

Play Nice With Others
To turn a project around, team members need to trust and be open to each other's ideas. Nothing destroys openness faster than blaming or dropping bombs on colleagues in meetings.

It can be very tempting for testers to be self-righteous about poor quality. Talk to your testers about the importance of avoiding blame, and talk it through with each of them individually if it comes up.

If it looks as if others are blaming you for delays when the issue is really poor software quality, you may need to prove your point. Be very careful how you do this; testing can't adequately compensate for quality problems, but it doesn't help a fraught situation to be too blunt. Stick to the facts, deliver them as unemotionally as you can, and share your report with the development lead before going public.

Take Care of Your Team
Troubled projects take a toll on everyone, but they're particularly hard on those with the least power. If you manage a team, make sure you support them through these rough times.

Empower team members. Share information. Seek their input on important decisions, and encourage their participation. Give them responsibility for their testing decisions and the obligation to explain them. Encourage them to manage their own stress.

Offer your team as much flexibility in work hours as you can. Ensure they know you support their personal obligations. If ignored, even small things like getting a haircut can become flash points.

Build in treats. I'm not big on artificial "team-building" events, but work with your team to make the days fun. Sometimes small gestures are the most appreciated; bring in a box of chocolates or a special team breakfast.

Most importantly, don't let your team be abused, particularly with mindless overtime. Long hours shouldn't be the automatic answer to every project delay. If they are essential to get over particular humps, manage them carefully and judiciously.

Secure Your Own Oxygen Mask First
Taking care of yourself can be the hardest thing to do, but it's critical. Your greatest assets are your heart and head. Empathy, logic, and creativity will help you through a difficult time and offer value to the project. You can't access them effectively if you are short of sleep and cranky.

Get regular, daily exercise. Walk all or part of the way to work, or ride a bike. Swim or work out. Allow yourself the odd indulgence (say, from that box of chocolates), but make a point of eating healthy, nutritious food that boosts your energy and makes you feel good. Give yourself breaks. If you find you're losing perspective, get out and do something you enjoy, even if it's only for half an hour.

Keep Your Knees Bent
If you want to stay in problem-solving mode, stay flexible. A troubled project is not the time for rigid process over progress. Keep thinking of ways to solve problems rather than constantly falling back on "the rules." For example, if a build is bad, pair testers with developers to work through the problems rather than throwing it back. Use or encourage crisis management techniques where appropriate.

Make sure you know your bottom line, preferably before you need it. Mine is simple: I will not lie or provide misleading information. (Flexibility doesn't extend that far!) That means all important information about the system and project must be captured. Bugs must be logged. We can classify them as "found during development" if that makes people happier, but we can't just find and fix without keeping track.

Remember--It Can Happen To You
You may not seek out a project rescue. But you can end up on a troubled project without trying. Even the best-run organizations can have an occasional lapse, and some companies make a habit of troubled projects.

Note this article is about "troubled projects," not "doomed projects." You can learn lots on doomed projects, but I doubt you'll find the gain worth the misery. The best thing I ever learned on a fatally wounded project was to say goodbye. It's not always easy to tell the difference, but the chief indicator for me is whether my interventions, and those of my colleagues, are making a positive difference. If a project begins to turn around when the team makes a concerted effort to get it under control, then there are good reasons to stay with it. If you keep your head clear, you will know when that is happening and when it is not.

The strategies I've described can help you maintain the right frame of mind to access your own creativity and devise tactical solutions to project problems. If you can do that, you, too, can enjoy troubled projects and develop your project skills.


About the Author
Fiona Charles is an independent test project manager and consultant, based in Toronto. With over twenty-five years of experience in systems development and integration projects, she specializes in managing large-scale systems integration tests, and in test management at the program level on multi-project integrations. Fiona is on the board of the Toronto Association of Systems and Software Quality and co-founder and host of the annual Toronto Workshop on Software Testing (TWST). She is a regular contributor to StickyMinds.com and Better Software Magazine. Contact Fiona at fccharles@sympatico.ca.

Back to Top
 

StickyMinds.com Weekly Column From 2/18/2008 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Meredyth Mackay 2/22/2008

I was once told by a manager that you don't learn from good projects, and although that is not strictly true, you do learn more from the bad ones.

I believe the role of a manager is to make sure that the people working for them can do their job. On bad projects that is often clearing away obstacles (people or rules) so that testers can get through their work; it is sometimes putting obstacles in place so there is time to work out a strategy, and it is always listening to the testers and then going into bat for them once a plan is agreed. Getting people to work harder is not a successful long term strategy as everyone gets...Read On

Author's Response:
2/24/2008    
Thanks, Meredyth -- I agree absolutely with your comments. You've crystallized something for me that I hadn't quite articulated before, by saying that one of our jobs is to raise obstacles so we gain time. (Maybe it's a trade secret we don't quite want to go public on!) On a difficult project, tactical test management means constantly maneuvering to preserve the time and space our testers need to do a good job. I, too, find immense satisfaction in the work we do together as a team.

 
 
Comment:    
by Sanat Sharma 2/22/2008

Definitely, working on a troubled project is a challenging task but sometimes it creates more trouble for you also. In my opinion, you should have at least some good level of authority and power to battle with the challenges.
-- Sanat Sharma

Author's Response:
2/24/2008    
Having sufficient authority certainly helps. As in any endeavour, those with the least power can suffer the most stress on software projects, because they may feel they can't do anything to alleviate the pressures on them. The next best thing is to have a manager who exercises authority to protect his/her team from undue pressure. But whether or not you are in a hierarchical leadership role, there are things you can do. You can take care of yourself. You can eat properly, get daily exercise, and attend to your personal obligations. And you can say NO to unreasonable demands, particularly demands for overtime. You can lead from behind, by questioning the need and value of overtime, each time there's a demand. You'll find a guide to doing that in my article on this site: "Overtime Under Control", which lists a set of conditions that must be satisfied before it makes sense to test in overtime.

 
 
Comment:    
by Peter Hawkins 2/20/2008

One of the best articles that I have read for a long time. This is spot-on. Look after your testers, don't let them get beaten up, facilitate their sucess. Those who have a passion for testing and a professional comittment are hard to find. Don't waste them!

Author's Response:
2/20/2008    
That doesn't only apply to testers, of course. I think that for any team, creating a space where they can do good work is the most important part of a leader's job.

 
 
Comment:    
by Sherry Heinze 2/20/2008

One other thing I like about troubled projects is the bond it builds between team members who do work together. I had lunch with a friend last week and he was reminiscing about a troubled project we worked on a few years ago. It is that project that built a bond between us, not the less troubled projects we worked on before that.

Author's Response:
2/20/2008    
I've found that, too. I met some of my best friends on troubled projects. Though I've also seen the opposite: virulent and lasting emnities.

 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


MicroFocus




STAREAST 2010 


Better Software Conference