We're Not "Special"

[article]
Summary:

Often, when I comment on someone's blog post or respond to a tweet with a story about how my team succeeded with some practice, someone replies, "Yeah, but your team is special." I interpret this as meaning, "You're a presenter and book author. You must be an expert, so of course your team can do anything." This frustrates the heck out of me.

Sure, after more than eight years of working together, we've had a lot of success and we've learned how to collaborate to solve problems. But, we didn't start out as intrinsically "special." It took a lot of time, experimenting, and learning. My ability to share helpful ideas through writing and presenting is because of my team, not the other way around. It's ironic that people discount my stories because they think my team got some kind of special pass to success.We’re Not “Special”

What's more, my own team isn't particularly impressed with my speaking and writing activities. I have to contribute value every day and argue for my point of view when there's a problem to solve, just like anyone else.

Starting Out
If you know my work, you probably know that the company where I work was headed for disaster in 2003. The business model depended on automating everything, and the software wasn't working. This was as dysfunctional a software team as you've ever seen.

The owners wanted their business to succeed. They knew nothing about software development, but they were smart enough to ask around and find alternative approaches. They heard about agile, found out the name of the best person to help a company implement agile, and worked really hard to recruit him. Yep, it is true that having Mike Cohn as your team’s manager for the first year of their agile transition is a big advantage. But, more important is the fact that the business owners hired the best person they could find, and he actually did what he said he would do. For example, the owners gave the software team all the time we needed to learn how to deliver high-quality software. That isn't magic; it's hard work and a huge investment, and it required a lot of trust on all sides. I don't want to bore any readers again with the story of how it took us so much time and work to learn how to be a self-directed team. It was the constant focus on quality, not speed, that let us start to have tiny successes and build on them.

Pride in Our Product
I recently happened to run across a few different articles and blog posts that talked about how pride in your work is really a key to success. My team made a commitment in 2003 that we would deliver the best code we possibly could and, over the years, we have made that commitment meaningful.

When we hire a new team member, we take the time to find the right person—someone we're proud to have as a peer. If someone on the team isn't able to buy into our desire for top-notch quality, our manager has to let that person move on.

It’d be easy to decide things are good enough and coast, but we don't. We look for ways to shake up our routine, make our retrospectives more useful, and improve our product.

Here’s a recent example. Our website UI was looking pretty old-fashioned—its look and feel were stuck back in the early 2000s. One of the developers experimented with Dojo and found that he could make improvements that helped keep users from making mistakes. The first time he used this technology, a problem for operations that occurred two or three times a week went down to only to two or three times a month. However, our automated GUI test tool couldn't interpret the Dojo code's generated Javascript correctly. We felt it was too risky to have a lot of GUI code that wasn't supported with automated tests.

We want the improved user experience provided by Dojo, so we tackled this problem as a team. We researched other test drivers and frameworks to see if they handled the Dojo implementation. We had a meeting to discuss whether we should hire an outside consultant to come in and help or try to spike a solution ourselves. This wasn't an easy or comfortable meeting. We all just looked at each other, and nobody would make a decision.

Finally, our system administrator popped up and volunteered to do the first spike. He had some success with a homegrown framework and an open source driver, and he turned it over to a developer. The developer compared the homegrown framework to an open source one, coded some example tests, and showed it to the team. We decided to go with the open source solution. Now, we are free to use Dojo to enhance our site's user experience, well-supported with appropriate automated regression tests.

User Comments

2 comments
Mohinder Khosla's picture
Mohinder Khosla

For a house to stand the test of time and provide comfort to the occupiers, not only require sound foundations but also the right foundations and material carefully laid down. That requires skilled people experienced in techniques or know how to experiment and find the right solution for the job. Such tradesmen are patient but want to be left alone to follow their extinct. They are more concerned about getting the things done right than doing the right thing. Lisa you made a good point that let technocrats get on with the job what is achievable with the resources available to the quality stakeholders want. Victory is theirs in the end.

February 28, 2012 - 11:22am
Margaret Gruen-Kerr's picture
Margaret Gruen-Kerr

Dear Lisa

You state in your first line "after more than eight years of working together" and leave out the fact that working together for eight years is very special these days. Human issues are critical success factors in projects. DeMarco and Lister write entertainingly to the topic in "Peopleware" as does Brooks in "The Mythical Man Month". Having a team with experience in working with each other is an enormous asset. I have seen enormous budgets for software system integration but never seen time budgeted for software project team integration. An integrated development team, one that has passed multiple load and stress tests , is needed to get a successful project out the door.

best regards

Margaret

March 2, 2012 - 10:05am

About the author

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03