Software Testing

It’s Not A Factory

DevelopSense - Michael Bolton - Mon, 04/18/2016 - 22:38
One model for a software development project is the assembly line on the factory floor, where we’re making a buhzillion copies of the same thing. And it’s a lousy model. Software is developed in an architectural studio with people in it. There are drafting tables, drawing instruments, good lighting, pens and pencils and paper. And […]
Categories: Software Testing

The key first step for successful organisational change

The Quest for Software++ - Mon, 04/18/2016 - 16:00

Last week, while helping a group of product managers learn how to get more out of user stories, I asked the participants to list the key challenges they’ll face trying to bring all the new techniques back to their organisations. “We’ve always done it this way”, “We already know how to do it” and “If it ain’t broken, don’t fix it” kept popping up. People who suffer from those problems then often explain how they’ve tried to propose good ideas, but their colleagues seemed uninterested, defiant, obstructive, resistant, ignorant, or any of the more colourful NSFW attributes that I’ll leave out of this post. And even when their colleagues commit to try a new idea, changes in internal processes rarely happen as quickly and as successfully as people expect.

Whether you subscribe to the Adam Smith’s invisible hand or Herman Daly’s invisible foot, something magical directs the behaviour of a whole group of people, even if each individual’s contribution can be rationally explained. In many cases, the key issue is that various participants in the group don’t actually agree on a single problem. That’s why offering a solution in the form of good practices rarely creates big results. Sure, any process change in a larger organisation suffers from complacency, fear and petty kingdom politics, but it also competes with people’s individual priorities, short-term goals and division targets. While someone is arguing for iterative delivery, other people care more about reducing operational cost or meeting sales quotas. And so, instead of an overnight success, change initiatives end up being much more like Groundhog Day.

The FutureSmart Firmware story is one of the best documented successful large-scale organisational agile adoptions. Gary Gruver, Mike Young and Pat Fulghum wrote about it in A Practical Approach to Large-Scale Agile Development. Unlike unknown thousands of mediocre attempts that resulted in water-scrum-fall and desperation, or installing pre-packaged four-letter acronyms that don’t really change anything, the LaserJet group division didn’t start by trying to ‘become agile’. They visualised the problem, in a compelling way that sparked action. By adding up all the different categories where the delivery teams spend time, the authors came to a chilling conclusion: the firmware development group spent 95% of their time just on getting the basic product out, and invested only 5% on ‘adding innovation’. The numbers shocked the stakeholders, and it was pretty clear to everyone that continuing on the same path won’t allow the organisation to stay competitive. Visualising the problem also provided something that everyone can rally around. People didn’t waste time on stupid questions such as should the daily scrum be at 10AM or 4PM, or if pair programming is required for everything. Instead, people started thinking about how to change the process so that they can get the basic product out cheaper and faster, and leave more time for new product development. All the tactical decisions could be measured against that. At the end, the FutureSmart group adopted a process that doesn’t sound like any other pre-packaged scaled version of Scrum. If you’ve been doing agile delivery for a while, you’ll probably disagree with a lot of the terminology in the book, and occasionally think that their mini-milestones stink of mini-waterfall, but all that is irrelevant. What matters is that, at the end, they got the results. Gruver, Your and Fulghum describe the outcome: development costs per program are down 78%, the number of programs under development more than doubled, and the maintenance/innovation balance moved to 60-40, increasing the capacity for innovation by a factor of eight.

Visualising the problem is a necessary first step to get buy-in from people, but not all visualisations are the same. Raw data, budgets and plans easily get ignored. Too much data confuses people. To move people to action, choose something that can’t easily be ignored. Based on a research of about eighty highly successful large-scale organisational changes, John Kotter writes in the Heart of Change that ‘people change when they are shown a truth that influences their feelings’. Kotter advocates creating a sense of urgency using a pattern he called ‘See-Feel-Change’. The best way to do that, according to Kotter, is to create a ‘dramatic, look-at-this presentation’. One of the most inspirational stories from Kotter’s book is ‘Gloves on the boardroom table’, about Jon Stegner, a procurement manager at a large US manufacturing company. Stegner calculated that his employer could save over a billion dollars by consolidating procurement. He put together a business case which was promptly ignored and forgotten by the company leadership. Then he tried something radical – instead of selling the solution, he found a typical example of poor purchasing decisions. One of his assistants identified that the company bought 424 types of work gloves, at vastly different prices. The same pair that cost one factory $5 could cost another factory three times as much. Stegner then bought 424 different pairs of gloves, put all the different price tags on them, dumped the whole collection on the main boardroom table, and invited all the division presidents to visit the exhibition. The executives first stared at it silently, then started discovering pairs that look alike but with huge differences in price tags, and then agreed that they needed to stop this from ever happening again. The gloves were sent on a road show to the major factories, and Stegner soon had the commitment to consolidate purchasing decisions.

One of the most effective ways to shake up a system is to create new feedback loops. Kotter’s ‘See-Feel-Change’ is great to provide an initial spark. Fast and relevant feedback motivates people to continue to change their behaviour. In Thinking in Systems, Donella H. Meadows tells a story about a curious difference in electricity consumption during the 1970s OPEC oil embargo in Netherlands. In a suburb near Amsterdam, built out of almost identical houses, some households were consistently using roughly 30% less energy than the others, and nobody could explain the difference. Similar families lived in all the houses, and they were all paying the same prices for electricity. The big difference, discovered later, was the position of the electricity meters. In some houses the meters were in the basements, difficult to see. In the other houses, the meters were in the main doorway, easily observable as people passed during the day. The simple feedback loop, immediately visible, stimulated energy savings without any coercion or enforcement.

The next time you feel the organisation around you is ignoring a brilliant idea, instead of selling a solution, try selling the problem first. More practically, visualise the problem so it can sell itself, allowing people to see and feel the issue. For the best results, try visualising the problem in a way that closes a feedback loop. Create a way for people to influence the results and see how your visualisation changes.

QA Music: It’s Sixx:A.M. Somewhere

QA Hates You - Mon, 04/18/2016 - 05:38


Categories: Software Testing

100% Coverage is Possible

DevelopSense - Michael Bolton - Fri, 04/15/2016 - 22:39
In testing, what does “100% coverage” mean? 100% of what, specifically? Some people might say that “100% coverage” could refer to lines of code, or branches within the code, or the conditions associated with the branches. That’s fine, but saying “100% of the lines (or branches, or conditions) in the program were executed” doesn’t tell […]
Categories: Software Testing

Do it *my* way, or do it *our* way

Alan Page - Thu, 04/14/2016 - 13:27

I was thinking about this on the way to work today, and thought I’d try to spit out a quick blog post before I got side-tracked again.

I’ve been very fortunate to have had success with organizational change with teams at Microsoft. Whether it’s getting programmers to run integration tests before check-in, or helping a team get to a daily zero-bug bar, my leadership style is the same. I believe that people will do things that they think are valuable. In fact, this quote from Eisenhower (which is, admittedly, overused) aligns tightly with my style.

Leadership is the art of getting someone else to do something you want done because [s]he wants to do it.

I talk with people to understand what their concerns and motivations are. I communicate plans and strategies to the team. Often, I “plant seeds” – for example, I may mention to a manager a few of the benefits of keeping engineering debt low and give a few examples. No judgement or decree – just an idea to put in their head. Later, I may mention that it would may be a good idea to keep pri 1 bug counts at zero, and maybe overall bugs below some arbitrary number. Often, a few weeks later, I’ll see that manager’s team with zero pri 1 bugs. Or, I’ll mention in a meeting that I’d like to get the whole team down to zero bugs, and I generally have support from everywhere I planted a seed.

The big advantage of this style of change management (in my experience) is that the team owns the change, and accept it as part of the way they work. The disadvantage, is that it takes time. To me, that time investment is worth it.

There’s a faster approach, but I don’t like it – yet I see it used often. It probably has a better name, but I’ll call it the do-it-because-I-said-so style of leadership. Eisenhower also said that leadership doesn’t come from barking orders or insisting on action (paraphrase because I’m too lazy to look it up). To me, leadership isn’t about your ideas, it’s about working with others and building your tribe. Too many so-called leaders think that leadership is being the loudest voice, or being the one that makes mandates to an organization. That’s not leadership to me. That’s being a dick.

That said, there’s a middle ground there, that I see often enough to respect, but not often enough to completely understand. I know some leaders who are able to make explicit mandates and have their team rally around them immediately. They don’t do this often, and I think it helps. They are humble and I think this helps. They have a relationship with their followers – and this helps too. Maybe the answer is that they’ve waited until they’re a real leader (rather than a self-proclaimed chest-thumper), and waited until circumstances were necessary before making a mandate.

What kind of leader do you want to be?

(potentially) related posts:
  1. Stuff About Leadership
  2. The Ballad of the Senior Tester
  3. What’s Your Super Power?
Categories: Software Testing

As Expected

DevelopSense - Michael Bolton - Tue, 04/12/2016 - 11:38
This morning, I started a local backup. Moments later, I started an online backup. I was greeted with this dialog: Looks a little sparse. Unhelpful. But there is that “More details” drop-down to click on. Let’s do that. Ah. Well, that’s more information. But it’s confusing and unhelpful, but I suppose it holds the promise […]
Categories: Software Testing

You Are Not Checking

DevelopSense - Michael Bolton - Sun, 04/10/2016 - 20:10
Note: This post refers to testing and checking in the Rapid Software Testing namespace. For those disinclined to read Testing and Checking Refined, here are the definitions of testing and checking as defined by me and James Bach within the Rapid Testing namespace. Testing is the process of evaluating a product by learning about it […]
Categories: Software Testing

GTAC 2016 - Save the Date

Google Testing Blog - Fri, 04/08/2016 - 18:22
by Sonal Shah on behalf of the GTAC Committee

We are pleased to announce that the tenth GTAC (Google Test Automation Conference) will be held on Google’s campus in Sunnyvale (California, USA) on Tuesday and Wednesday, November 15th and 16th, 2016.  

Based on feedback from the last GTAC (2015) and the increasing demand every year, we have decided to keep GTAC on a fall schedule. This schedule is a change from what we previously announced.

The schedule for the next few months is:
May 1, 2016  - Registration opens for speakers and attendees.June 1, 2016 - Registration closes for speaker and attendee submissions.June 30, 2016 - Selected attendees will be notified.August 15, 2016 - Selected speakers will be notified.November 14, 2016 - Rehearsal day for speakers.November 15-16, 2016 - GTAC 2016!

As part of our efforts to increase diversity of speakers and attendees at GTAC,  we will be offering travel scholarships for selected applicants from traditionally underrepresented groups in technology.

Stay tuned to this blog and the GTAC website for information about attending or presenting at GTAC. Please do not hesitate to contact if you have any questions. We look forward to seeing you there!
Categories: Software Testing