How green actions cut businesses’ costs

Let’s end up 2009’s National Green Week with some tips on greening your business. Here are green practices that can cut business costs, compliments of two project management consultants, Cheetah Learning’s Michelle LaBrosse, founder, and Erica Edmond, CAPM. They’re urging project managers, who are born leaders, to get their co-workers and executives involved in greening their companies.

Since the recession began, more businesses have been forced to look closely at their waste and found that a long-term commitment to using green practices reduces costs dramatically, LaBrosse and Edmond told me this week.

“Simple practices like empowering employees to work virtually from home can save a tremendous amount on office space and, at the same time, reduces pollution spent on commuting,” said LaBrosse. “It can also make your carbon footprint smaller.”

During this recession, energy costs have rightfully come under fierce scrutiny, particularly in data center settings. “There are now over 1.1 billion computers in operation worldwide, collectively producing about one billion tons of CO2 through their electricity requirements,” Edmond said. The computing age has also been the garbage age, and outdated computer equipment, mobile phones and electronic gadgets now make up five percent of the world’s landfills.

To cut energy costs, keep an eye on the small things. The consultants suggest turning off overhead electric lights if there is natural light in an office. Also, make sure that furniture does not block the radiators as otherwise the heat will be wasted.

To conserve water, fix leaky faucets. People sure fix leaky faucets in their homes, because they get billed for the water used. Businesses should, too. ”Post a number to call near sinks so someone may fix it right away,” LaBrosse said.

Create collection points for waste such as aluminum, glass, plastic and paper. Be sure that once people deposit the waste into the proper trash cans that they are, in fact, disposed as intended. Meanwhile, cut down on how much stuff goes into those cans by eliminating amenities like disposable coffee cups. Also, use printers that can print on both sides,

Many companies have cut down on business travel during the recession. Keep doing that, even after the economy recovers, the consultants said. LaBrosse added:

“Rather than traveling to meetings, have you invested in suitable technology for conference calls? It is worthwhile investigating alternatives such as using iChat or SKYPE for meetings that require face time?”

LaBrosse and Edmond told me about some multinational businesses that received the 2009 Natural Health Magazine “Green Choice” Awards for their green initiatives. They are Verizon, Starbucks, Whole Foods, Aveda, Discovery Channel and, surprisingly, Wal-Mart. Some of their accomplishments underscore the suggestions above.

• Verizon’s HopeLine initiative saved more than 5.6 million cell phones from ending up in landfills. Also, Verizon Wireless’ ongoing deployment of smart power grids and new fiber-optic network equipment will result in emissions reductions equal to keeping as many as 16,000 cars off the road annually.
• Starbucks’ post recycled cup-sleeves saved more than 78,000 trees in 2006.
• Whole Foods buys enough wind-energy credits to compensate for 100 percent of the electricity the company consumes.
• Aveda employs wind power in their manufacturing facility to reduce electricity consumption and uses 100 percent recycled packing materials.
• The Discovery Channel uses energy-efficient lighting, architecture and water systems in the company headquarters.
• Wal-Mart’s large-scale environmental plan should lead to powering every store with 100 percent renewable energy. The company is investing $500 million a year to increase fuel efficiency within their truck fleet, decrease energy consumption in their stores and decrease stores’ solid wastes.

These companies have taken large steps toward being green; but even small steps help. In their project management consulting, LaBrosse and Edmond always look at ways “going green” can cut costs and give project managers more money for core business projects.

Building an online community for software testers, an interview with Rosie Sherry

There are a lot of online places for software testers to collaborate, but one of the more recent and popular entries to the world of online communities is the Software Testing Club. The Software Testing Club (STC) isn’t even three years old, and already it boasts over 4,000 members and it’s growing every day. On STC you can participate in forums, join one of the almost 100 groups, post a video, post a job, start a blog, or you can get involved through STC’s LinkedIn Group, FaceBook page, or Twitter feed.

Given the site’s popularity, I thought it would be interesting to hear a bit about how STC came about. With this in mind, I took some time to talk with Rosie Sherry, the founder of STC.

“I started it because as someone into software testing and after looking around I didn’t feel like there was anywhere online that I felt comfortable hanging out. To be honest, it was a bit of an experiment. I didn’t really think it would take off like it has. [...] I have had to rethink it all. I hope it’s going somewhere bigger than it is now. We’re trialling out some new ideas and concepts at the moment. This includes the Software Testing Magazine and The Exchange. Increasingly other people are getting involved too, which is great.”

Rosie Sherry is a bit of a social media and online community guru. Her current company Schux, does web development and online community building. Her other projects include Flash Mob Testing (a solution for crowd-sourced web testing), the STC Exchange (think of it as a StackOverflow for Software Testing), and Lewes Werks (a social collaborative workspace in Lewes, East Sussex).

If you’re new to STC, you’ll want to start with the forums. “The forum is by far the greatest attraction of the STC,” says Sherry. “There are always lively discussions and debates going on. The Testers Feeds are also hugely popular. I’ve spent the past few years collecting tester blogs, last time I counted there were over 120.” Sherry is also very focused on making STC and it’s content independent and unbiased toward any particular type of testing. “We also try to be fresh and fun, something much needed in the world of software testing. I think this is what makes it so popular.”

A few months ago, Sherry blogged about a difficult decision she made to move STC towards a paid membership model. I asked her about her decision to move in that direction.

“I’ve spent a good two and a half years working on STC. When something unplanned happens, it makes us rethink our positions. The current main forum is now still open for free, but am working on other things - which include membership - to make it sustainable as a business. I love the STC. It makes my heart tingle. But to keep it alive and stop it going stale, time, effort and money need to be invested.”

What are some of those “other things” Rosie is working on? Well, two of them are Flash Mob Testing and the STC Exchange.

“Flash Mob Testing is about using the talented crowd at STC to do testing in the real world. We’ve trialled out a few projects and are currently working towards figuring out the best way to proceed with this. Crowd sourced testing is most suitable for smaller companies who don’t do any testing or lack the resources to find someone who can actually test properly.

I think there is a market for it. uTest seem to be doing alright, though it is still early days. Flash Mob Testing will keep the ethos from STC. What this means has not been defined exactly, but we are trying to figure out how we can educate testers in the process whilst also providing a service that can guarantee great results. This probably means creating real relationships with the testers rather than making it an anonymous thing.”

While Flash Mob Testing focused on putting the communities knowledge to work in a very hands on sense, the STC Exchange takes a slightly different approach. The idea of the exchange is to be able to ask specific questions rather than to raise discussion. Discussion would instead happen in the STC forums or groups. “We’ve just launched the STC Exchange,” said Sherry. “I hope that will link in nicely with our ethos and help testers build up their reputation whilst also being helpful.”

Hot topics on STC right now include “Best tool for UI/Click based automated testing for Websites” and “Developers as Testers?” Or, checkout some of the community-developed content, like “What Do Testers Hate about Testing.” If you’d like to know more about Rosie Sherry, check out her website to read her blog, find her twitter feed, or to see what else she’s working on.

Testing databases, train yourself some new testing tricks

Yes, dear reader, while by day Matt Heusser is software tester for Socialtext by day, at night he is a mild-mannered instructor of information systems at Calvin College.

In neither case do I wear a cape, mask, or colorful outfit, but I have been learning a thing or two about teaching database programming - and what a tester might know about it.

Oh, I imagine a number of you are yawning and saying to yourselves “ho hum.  I work at a big financial services company and slice and dice SQL all day.  What’s the big deal?”

This post is not for that guy; it’s for for the one who read that and thought to himself “er, um, what’s SQL?”

I would like to suggest that if you are a tester and don’t work directly with databases, it might be helpful to learn a little - just enough to be a little more effective as a tester.  After all, from google to twitter to my cell phone to my iPod, databases are everywhere, and being able to get “under the hood” for testing can make us that much more effective.

Here are a few techniques that might be possible with ’just a little bit’ - maybe a couple hours - of database training could give you:

- To test reports, write your own, and compare them

- To test correctness of mass adds and updates of your software

- To do before and after checks on a large batch operation

- To get “under the hood” to test stored procedures and other business logic encases in the database

- To test import/export from contact management software

- To test the integrity of the database after an upgrade, or a restore from backup

- To create ad-hoc reports and queries for any particular need

And, while direct coding might be a bit much, most databases support Open Database Connectivity (ODBC) and connect right into Microsoft Access.  From Access you can drag and drop tables and design queries visually.  My class, mostly college sophmores, were off to the races in an hour or two.

Oreilly even makes a book in it’s award winning “Missing Manual” series for Microsoft Access. You know, the books you wish came in the box but don’t? It’s one of those.  (And by the way, SQL, or Structured Query Language, is a programming language for databases that can often be avoided by using Access.  Just don’t use it to write queries against a large production database!)

A couple of years ago I wrote an article on professional growth for software testers.  Learning about atabases is one way to go.  If you woud like to hear more about databases for testers, or something else, just leave a comment.  I would enjoy hearing from you.

Why true flexibility, teamwork is a sign of Agile team maturity

To create deliverable and timely projects, Scrum leaders and Agile teams need to figure out how to calculate goals, figure out iteration deadlines and then begin creating quality deliverables, according to Bob Galen, president and principal consultant for RGCG, LLC. Galen’s session at the recent SQE Application Development Practices conference in Orlando was an informative evaluation on mature Agile teams’ best practices, designed to show how the best of the best use Agile to succeed.

“My work in Agile has been focused on teaching proven implementation tactics,” said Galen, who has logged 20-plus years in the software industry. His career started in research and development, where he began noticing inconsistencies in how projects are assigned, worked on and completed. Eventually, his search for solutions to those problems led him to Scrum. He has spent the latter half of his career as an independent Agile consultant.

Galen told the audience that Agile leadership is not a top-down practice or dogma. In Agile, the leader is a coach and not a monarch, and Agile practices should be flexible. “To be truly Agile, you need to collaborate and cooperate. No single voice should prevail or lead the project in any one direction,” he said. “Agile is the culmination of everyone’s best ideas.”

The first step in any Agile project is gathering the team to define a publishing system, asking such questions as: How are the completion of iterations going to be documented? How will approved iterations be reported to the rest of the team? To keep organized, some teams choose to use vendor tools, and others devise a sort of internal data submission calendar. Some even rely on covering common company walls in Post-It notes. All three of these schools of thought were represented well in this session.

“Making the team aware of where the project has progressed, or in some cases digressed, should always be a major consideration in the project pipeline,” said Galen. “How else will your co-workers know when to start the next serial iteration?” This practice is never fully appreciated until it is too late. Team members should voice any concerns with goal setting, iteration deadlines and project function before it is underway.

There are other important prerequisites mature teams should use. During planning, include the whole team in system metaphor definition and setting project guidelines. When everyone on the team paints the big picture, everyone has clear idea on goals and how project can reach completion.

A key characteristic of mature Agile teams is collaborative productivity. “I love when I see Agile teams broken down into smaller groups, normally three or less,” Galen said. These groups normally consist of a tester and developer pair working on the same line of functional code. In his opinion, this sort of cooperation is one of Agile’s most underrated and least understood practices. The creation of iterations in this fashion ramps up efficiency, as code is checked for flaws as it is written.”

Making sure that solo work is high in quality is critical, Galen said, as a chain is only as strong as its weakest link. To assure quality, Scrum leaders and Agile coaches must ensure that developers keep one eye on their coding and a second eye out for potential bug risks.

During a Q&A session, one tester said: “At my company, there have been times where we were forced to push Agile best practices aside in favor of a client or product owner’s request. So that’s what we did against our better intentions.” Galen said her team did everything right in that situation. Driving customer focus is one of the best Agile qualities a team can have. Going back to his opening statement, he said that sometimes satisfying the customer calls for “forfeiture of the manifesto’s guidelines.”

“Agile doesn’t dictate to do something one way and not even consider another possibility,” Galen said. “Agile, in my mind, has always represented the most intelligent execution to project problems. If you finished the project on time, pleased your client and were able to cash your paycheck you did your job correctly.”

Using Agile, scaling back helps software projects in recession

“You are about to embark on a dynamic quality endeavor. It is time to throttle down on your already oversized and over-budget test and development teams.” That was the opening salvo of Michael Mah’s (QSM Associates) SQE Agile Development Practices Conference session, Rightsizing your project in a down economy.

Project teams are just too large, Mah said. Sure, the poor economy has prompted downsizing in this industry; but that could be a blessing in disguise. After all, there have been many years of impractical spending, mismatched teams and dysfunctional workplace goals in software projects.

For too long, Mah said, executives and managers have emphasized speed over quality, judging success by whether teams turn out code lines on time, rather than on delivering in a reasonable time frame quality code that’s free of obvious functional flaws. He’s seen promotions being given to project leaders who met deadlines without ensuring quality. The results? We are paying the ultimate price in lost jobs and market share, he said.

“Now that I have pointed out where the trouble began, let me now explain where the trouble continues,” said Mah. Today, he sees many companies using the recession as an excuse for adopting seriously questionable practices, like trying to cut steps to recovery by cutting down on employees. In the short term, this does free up some cash; but once a company has rebounded or is recovering, new team members will have to be hired. Of course, it takes precious time and money to train new employees and pay for newbie mistakes.

On the other end of the spectrum, there are the overly-cocky executives who have spent more wisely over the years, they see this time where other companies are cutting back and pinching pennies as time to throw money and software at problems. This rarely works, and usually sends these companies into the downward spiral.

In a time of recession, throwing enormous manpower and software at problems will rarely resolve issues. It is more appropriate and intelligent to scale back, says Mah.

To scale back, project leaders should build strong relationships with a small core group of commited employees. Research your service and tool providers more thoroughly, gather references and check them.

“How many of you have some fear about loosing your job?” Mah asked the audience, and nearly all of them held up their hands. “And how does that make you feel? Bad, right?” Company and project leaders are responsible for alleviating fear, not creating it. Fearful teams don’t work productively. Often fear is responded upon with aggression.

The most effective way in managing concerned workers in a recession is by showing “concerned optimism,” Mah said. Explain the situation, but encourage the team. Leaders’ optimism and relationship helps team members feel confident in their abilities and have more belief that they are capable of working on innovative projects. A motivated and innovation-welcoming team is critical to success and growth. Optimism makes for more tolerable working environments and more creative problem solving.

“I remember a good many times I would work through 70+ overtime work weeks; partly because work needed to be done, but also because there was always a chance that the company president would see me there,” said Mah. “On the occasions when he did, he would always compliment me with a thumbs up and a ‘good job.’ That was all the praise I needed.”

More coverage from Agile Development Practices:
Early adopters, Agile philanthropy key points in ADP keynote

Agile philanthropy, one man’s ambition for a brighter future

Agile software tester’s volunteer group helps non-profits

I was intrigued by Code Green Labs CEO Bob Payne’s keynote on Agile philanthropy at SQE’s Agile Development Practices in Orlando. So, I talked with him afterward about that effort, called Give, which lends software assistance to non-profit organizations.

Give helps non-profits, but it can also provide contacts and a resume-building opportunity for college students and between-jobs coders and tester, as well as a charitable outlet for others software development pros.

In the video below, Payne shares some views on Agile and the rewards of working on the Give project.

Early adopters, Agile philanthropy key points in ADP keynote

“With great power comes great responsibility.” Those were Ben Parker’s dying words, spoken to a young Peter Parker, alias Spiderman. It was also the subtitle of Electroglide Bob Payne’s keynote on the opening day of Software Quality Engineering’s Agile Development Practices Conference in Orlando, Fla.

The keynote’s focus was Agile philanthropy, a term Payne uses to describe the benefits of Agile. Payne discussed the new Agile Philanthropy project, whose volunteers from the open source and commercial software industry assist non-profits with application coding, development and delivery. “This industry has been very kind to me,” says Payne, “I felt obligated to give back.” If you would like to speak with Bob Payne about volunteering, contact him at bob@codegreenlabs.com.

Payne’s other project is transitioning Electroglide, a Washington, D.C.-based consulting firm, and rebranding the company too CodeGreenLabs, a new brand name but one still focused on Agile software development and transitioning companies to Agile. Payne has been an Agile user since 1999, before the publication of The Agile Manifesto.

Typically Electroglide’s ideal clients have been large financial service providers and video game development companies. He’s seen that financial companies are early adopters of Agile. Indeed, he thinks the financial service provider market is in the greatest need for Agile business practices. They usually are already working together on coding projects and only need slightly more-focused guidance to fully work with the upmost agility, he said.

While financial firms are definitely interested in Agile, they can be reluctant to engage in Agile practices. Transitioning normally takes one-to-five months to complete, Payne said, but transition included two Agile projects: one related to technology and practices; another in which the company works cooperatively with Payne to learn the Agile mindset.

In Payne’s experience, the gaming industry has been the most open to Agile practices, largely because the way in which game developers have been creating games already closely mimics the Agile methodology.

While Payne is an Agile evangelist, he did not sugarcoat the Agile way, noting that the Agile approach just isn’t going to yield companies the desired results in every situation.

How testers can handle switching to Agile’s short iterations

Software testers today are under a lot of deadline pressure due to Agile development’s shorter iterations. I recently hosted a panel on time management for a local software testing group, and attendees asked for advice on how to handle the frustrations associated with moving to short development iterations. While the theme of “making sure you have team buy-in” underlay the entire discussion, there were some particularly insightful nuggets related to making sure people understand why the work is structured the way it is in short iterations.

Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, set up the problem this way: Most software professionals in highly-tactical roles — whether they are authors, developers or marketers — are used to the idea that their work is a representation of professional capacity. So, the pro has this self-concept, and then their deadlines are changed to weeks from the traditional span of three-to-six months. Instead of working on one larger task, the task is broken up into 20 smaller pieces.

“All of a sudden that way in which you represent your own professional capacity, your expertise, is now violated. Now it’s being divided up.”

Slaughter’s main point is that the work is no longer yours. It’s the team’s. The individual parts that you work on or someone else works on are not as important as the overall result. Many times people working in iterations are dealing with that frustration. They no longer have the same level of ownership of the piece that they’re working on.

Brian Ball, software engineer with Software Engineering Professionals, had a slightly different take on how you might illustrate the same point.

“There are principles to why you do things in Scrum,” said Ball. “So if they’re uncomfortable with why we’re only doing a short section of work here, why we’re breaking this up and I’m not doing the entirety of the feature, [or] why I’m only dong this little unimportant subset; then when you start throwing stuff out of the backlog because the customer changed their mind…celebrate that. Say this is work we didn’t do and we no longer have to do. Just throw it out…So they see a concrete result of why the principle was there in the first place. They get the payoff of, ‘Oh yeah, we delayed it and we didn’t have to do it.’ [That's] because it wasn’t important — really important — at the time. It just left us with this uncomfortable and unfinished feeling at the time. “

If buy-in might be part of your problem, the panel offered a question checklist for helping understand what might be blocking buy-in.

“How do you set it up to provide it to them?” asked Francine Carter, founder of Action Coaching & Training. “How do you roll it out? Because the rollout’s the important piece to get people to begin to think about how they’re going to approach it. And if you’re thinking I can’t, then you’re not going to. What about it don’t you feel good about?”

Brian Ball recommends looking at your planning meetings and making sure all the work is being accounted for in the estimates — something that takes practice and measurement. Make sure everyone understands why the work was broken up the way it was, he said. In other words, paint the big picture.

Cory Mausolf, a career coach with Authentic Business and Career Coaching, pointed out that it can be important to make sure people are separating their feelings about the work itself from how the work is being done. Are they uncomfortable about the work? Or are they uncomfortable, he asked, “because that’s not how you did it before?”

You can find the complete audio for the panel members response to this question on the IWST website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.

How software testers can get deliverables without nagging

How can software testers get development team members’ firm commitments for deliverables? That question came up while I recently hosted a panel on time management at a local software testing group meeting. As testers, we rely on a lot of people: developers for code; system administrators for environments; business managers for data and oracles and so on. A big part of testers’ day-to-day life can be spent waiting on getting what we need to start test execution.

“Sometimes I feel like I’m nagging other people to get things done,” said one tester in the audience. “Do you have any techniques to help get commitments out of people to help make this process less painful?”

Panel member Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, provided some ways to move from nagging and silence to empowerment.

“I think that all of us have the experience of nagging, and we all know that nagging does not work. It doesn’t work to be nagged; you don’t have any desire to do the task. In fact, if you’re nagged you’re less likely to do something. If somebody calls me three times in the course of a day and asks me to do a project, I’m not going to do it for them. Because I know they’re going to keep reminding me until the deadline comes up. They just created an expectation that I don’t have to remember any more. They’re now my human to-do list. So nagging is the worst thing you can do to get something done.”

Take away nagging, though and what persuasion option do you have?

“The opposite seems like silence,” said Slaughter. “Just hopping that it happens doesn’t really work either because you really haven’t communicated what it is you need. So, I think the most helpful strategy is to try to empower the person you’re work with. And to say, ‘Hey, if you can do this really great thing that I can’t do, that would be fantastic because then I can do my job, and make you look even better.’ So if you can find a way to empower them, they’re more likely to want to get the task done for you.”

Slaughter, wanted to be clear about the difference between empowering and enabling somebody, noting that:

“If you empower someone then you’re imbuing them with the authority and the responsibility to provide you with their work that you need to do your job. And that authority and responsibility translates into satisfaction, satisfaction translates into productivity, productivity translates into a sense of ‘I can know what I do.’ If you enable them, then what you’re doing is you’re allowing them to not complete their job. Empowering is more about ensuring they have tool and resources, ensuring they have information, ensuring you understand their challenges. Whereas enabling means I’m you actually say, ‘You know what, I’m going to come and do some work for you, or come and make your life easier directly by doing the things you’re suppose to do, so I can get the things I want.’ And if you do that, the danger is that you try to take work away from them. And you give yourself more work to do. And you establish a culture in which you doing people’s jobs for them.”

Francine Carter, founder of Action Coaching & Training, extended what Slaughter said, to include getting buy-in. “If they know why you need what you need,” said Carter, “and how it will move everything else along, then you’re going to have much more buy-in.” Buy-in, she said, isn’t always as simple as saying, “I need this because….”

Carter also pointed out that you need to consider where the other person is coming from.

“You never know what they’re thinking. They may be hesitating in getting it done because they’re afraid of doing it [or] they’ve never done it before. You don’t know what their story is, either. So the more that you can go at them and try to understand where they’re coming from and why they’re not doing it, [the more you can] maybe help them and empower them along. Think about where that other person’s story is. What are they thinking? Why are they hesitating and procrastinating on this?”

Brian Ball, a software engineer with Software Engineering Professionals, gave some advice on getting commitment:

“You want to put them on the hook for what it is that you’re trying to get them to commit to, and the easiest way to do that is to let them hook themselves. If you say, ‘Hey I need this as soon as possible.’ that’s one thing; but if you turn around and say, ‘So, I need this. Here’s why. When can you have that by?’ then they’re creating a commitment to you. And if they say, ‘I have no idea.’ then say, ‘I need to know, so I can plan my schedule.’”

“The other thing is that, if it is the case that they do start blowing you off, then you at least have something to go talk to somebody about. Say, ‘They said they were going to do this and have not given me a reason, and refuse to give me a reason, as to why it hasn’t happened.’ And I hate to bring out the big guns and bring somebody else involved into it, but usually it helps just to say I got them to commit to something.”

Ball also pointed out the other side of asking people to do something for you, which is thanking them. “Conversely, when they finally do actually get done what it is you ask for them, sit there and go ‘Sweet! That’s awesome!’!!” said Ball. “Pronounce it with three exclamation points even if you don’t feel like it, because you’re trying to make them feel good about what it is they did for you.”

Chris Wingate, a principal software engineer for Liberty Mutual, provided some of the easiest advice about managing commitments. In short, get the project manager to do it for you.

“Most of my performance test engagements [are situations where] you’re always waiting on somebody,” Wingate said. “Or, you’re trying to get another resource to get more information, or do more monitoring or track down this issue or that issue. The most effective thing I’ve found to get the team focused and moving forward on things is a 30-minute meeting twice a week. The project manager is there, the developer, the lead developer is there, the architect is there, the lead tester is there, so everybody knows what’s going on, everybody knows what the delays are. Let the project manager do that work for you.”

You can find the complete audio for the panel members response to this question on the Indianapolis Workshops for Software Testers website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.

Some tips for one-person software test teams

Last week I hosted a panel on time management for a local software testing group, IWST (Indianapolis Workshops on Software Testing). One of the questions asked during the meeting went like this: “I just started a new job and I’m at a company where I’m the only tester. Any tips for making that work?”

The entire panel was quick to point out that you’re never alone, and that you always have a team to work with. Brian Ball, a software engineer with Software Engineering Professionals, said that it’s important for you to realize you’re part of a larger team — whether they feel like it or not. He said you need to let the rest of the team know that you’re concerns are really their concerns.

Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, pointed out the following:

“What you really need to do in those situations is identify who are the stakeholders around you who care about the results of your work and the results of what’s happening, and find a way to leverage their expertise, their ability, their commitment and their passion towards what you do. Now that’s a problem that is magnified when you have technical expertise in some area of what you do, and the people around you — the stakeholders — don’t.”

Slaughter also pointed out that one of the most important things you can do is to help people give you information in a way that enables you to do your work better.

“You need to realize that you might have this expertise or this area of technical facility [and they do not]. You need to go back to the stakeholders and identify ways to communicate better. Maybe they need a form to fill out. Maybe they need a tracking system, your ticket tracking for the request. Or maybe you need to find a way to give them information in a more organized fashion, so they can find it more easily so they are not constantly calling you.”

Chris Wingate, principal software engineer for Liberty Mutual, summed up his thoughts on the question the following way:

“To me is seems to come down to two things…and those are trust and education. So you’re the only tester in your organization at the moment, and so it’s very important to build the trust in your competence with the rest of the team — with the developers and the managers. That way when you say, ‘Yes I can do that.’ or ‘No I can’t do that for these technical reasons.’ you don’t have to spend a lot of time explaining all of that and rehashing all of those things that you continually do.

“The other thing is educating the rest of the team about what your capabilities are, what timelines are, and they go together… you have to educate your customer in terminology. Educating your customer is going to help improve the communication and help make you more efficient.”

You can find the complete audio for the panel members’ advise for one-person test teams on the IWST website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.