Agile Testing: A Practical Guide for Testers and Agile Teams

Wondering how to get testers engaged in agile development?
Wondering how to transition your QA team from a traditional testing cycle into an agile one?

Then look no further! My good friend and agile testing guru Janet Gregory and Lisa Crispin have just released their latest book:

Agile Testing: A Practical Guide for Testers and Agile Teams

In the book Janet and Lisa cover everything from organizational challenges to tips and tricks on how to get more of your tests automated. It’s a comprehensive overview of everything you will ever need to know about agile testing and a great read for those looking to transition traditional testing teams into more agile ones.

So if you are looking for one book which gives a really good view of a day in the life of an agile tester and valuable role they can play on agile teams, you should definitely check out Janet and Lisa’s new book.

Congrats again Janet and Lisa!

How does agile work on SAP projects?

It is with great interest that I was reading some passages from New-SAP-Blue-Book by Michael Doane, when I came across the following passages regarding SAP recommended practices, and principles around implementation:

When clients hire an SAP systems integrator, they are hiring the firm and their people. The core capabilities of the firm will remain over time – things like the methodologies, tools, partner networks, etc. The people, however, will change, as promotions, job changes, and retirements inevitably happen. Therefore, clients should place a strong emphasis on the systems integrators’ methodologies and tools during the selection process.

As someone who swims in the agile space, I found this quite fascinating that someone was has recommending processes over people. I then went on to read another interesting passage regarding the pitfalls of iterative development on SAP projects.

You do not want your team engaged in an iterative trial and error process in which you find yourselves moving between design and configuration across all modules until you are satisfied. Such a process will drain your budget and strain your nervous system. You should seek, where possible, to adopt best practices, especially those that are pre-configured.

What this means is that your organization will change to fit the system. This is, of course, not intuitive. Most firms believe that the software should be bent to fit their chosen processes. In some cases, this is a necessity but in many other cases it is simply organizational vanity.

Now, I have never had the pleasure of working on an SAP project, so all of my opinion is stereo-typical, third party, and not informed by experience or practical knowledge. But it did get me wondering what it would be like to work on this kind of project where the process was all important, and the business bent to the software (not the other way around).

Would there be a culture clash if you stuck a bunch of agilista’s onto an SAP project?

What would SAP experts think of agile’s free wheeling iterative nature?

Could the two co-exist on the same project and swim in the same swim lanes without bumping into each other?

I suspect the spirit of agile would indeed work on SAP projects. But the more I read the book, the more I became interested in understanding what, if any differences in attitudes there would be, between an agile and SAP team.

If you have any experience or comments on agile and SAP projects, please leave a comment.

I would love to hear more of your experiences.

The Toyota Way – You have a new assignment

The year is 1950. You are an up and coming manager at a young automotive company in Japan. Your county has just lost a world war. You’ve had two atom bombs dropped on you. Your industrial capability has been decimated. Your supply base is wiped out. And your consumers have little money.

Your boss comes back from the Ford River Rouge plant in the U.S., calls you into his office, and calmly hands you a new assignment. He wants you to improve your manufacturing process so that it rivals Ford’s.

Sound like something from mission impossible?

This is precisely the circumstances that Taiichi Ohno faced when he was tasked with this very challenge over 50 years ago. From which emerged the Toyota Production System (TPS).

Would you be up to the challenge?

The Toyota Way

Every once in a while you pick up a book you just can’t put down. This happened to me recently when I finally got around to reading The Toyota Way, by Jeffery Liker.

The Toyota Way goes deep inside the heart of the company. Jeffrey shepherds readers through the birth of the company, the development of its founding principles, and the ever so popular Toyota Production System (TPS) itself.

The book is full of stories about the birth of Lexus (Toyota exec’s basically got tired of driving European luxury cars into work everyday) and the revolutionary development of the Prius.

If there is one thing that is made apparent to me after reading this book, it is how young the agile software movement is, and how universal the Toyota principals are. They cross industry, transcend business, and could be used by many companies (more on this later).

I am also starting to appreciate how difficult it is to copy Toyota (I don’t believe you can). Toyota’s been practicing and refining these practices for over 70 years. It’s no wonder Ford and GM can’t catch these guys. It’s much more than the practices.

If you are looking for a great read, and hunger for more after reading Mary and Tom’s Implementing Lean Software Development, this book is for you.

Share, learn, and grow!

Bloomberg on Agile Part II (Risk Analysis)

Continuing on the theme of sharing agile project management techniques in the wild, here is another example of Bloomberg’s approach to risk management and planning. For Part I (on the benefits of working from a heap) click here.

As quoted from his book, Bloomberg by Bloomberg:

Don’t think, however, that planning and analysis have no place in achieving success. Quite the contrary. Use them, just don’t have them use you. Plan things out and work through real-life scenarios selecting from the opportunities currently available. Just don’t waste effort worrying about an infinite number of down-the-road possibilities, most of which will never materialize.

Think logically and dispassionately about what you’d like to do. Work out all the steps of the process – the entire what, when, where, why, and how. Then, sit down after you are absolutely positive you know it cold, and write it out. There’s an old saying, “If you can’t write it , you don’t know it.” Try it. The first paragraph invariably stops you short. “Now why did we want this particular thing?” you’ll find yourself asking. “Where did we think the resources would come from?” “And what makes us think others – the suppliers, the customers, and potential rivals – are going to cooperate?” On and on, you’ll find yourself asking the most basic questions you hadn’t focused on before taking pen to paper.

As you discover you don’t know it all, force yourself to address the things you forget, ignored, underestimated, or glossed over. Write them out for a doubting stranger who doesn’t come with the confidence in the project’s utility – and who, unlike your spouse, parent, sibling, or child, doesn’t have a vested interest in keeping you happy. Make sure your written description follows, from beginning to end, in a logical, complete, doable, path.

Then tear up the paper.

That’s right, rip it up. You’ve done the analysis. You’ve found enough holes in the plan to drive your hoped-for Bentley automobile through repeatedly. You’ve planned for myriad what-if scenarios. You’ve presented your ideas to others. You’ve even mapped out the first few steps.

But the real world throws curve balls and sliders every day, as well as the fastballs you practice against. You’ll inevitable face problems different from the ones you anticipated. Sometimes you’ll gave to “zig” when the blue print says “zag”. You don’t want to detailed, inflexible plan getting in the way when you have to respond instantly. By now, you either know what you can know – or you don’t and never will. As to the rest, take it as it comes.

I like Bloomberg’s approach to risk analysis and mitigation. Worry about the stuff you can handle, and don’t sweat the rest.

You are always going to be able to find reasons for not going forward with a project. And you can rest assured your plan won’t have events like loose lead programmer here, or have primary customer be poached by competitor here (both of which have happened to me). You just gotta deal with it and move on.

As the lord’s serenity prayer says:

Grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And the wisdom to know the difference.

Bloomberg on Agile

Bloomberg by
Bloomberg

A couple months ago I got tired of hearing Michael Bloomberg’s name and not know much about the guy. So, over Christmas I went out and picked up a copy of Bloomberg by Bloomberg – a self styled autobiography.

Turns out Bloomberg is a pretty interesting guy. Before becoming mayor of New York, he was a partner at the now defunct Salomon Brothers on Wall Street. After being let go (with a severance of $10 Million), Bloomberg went out and started up his own financial information company. Thus was born the Bloomberg terminal (a dedicated computer for bringing stock and bond traders market information rapidly). To make a long story short, Bloomberg did very well, and almost ran for president this year.

So what does all of this have to do with agile?

Read the following passage from the book, and observe the parallels with agile in how Bloomberg handles classic too much to do, and not enough time problem.

In computer terms, doing it whenever needed, on the fly, is working from a “heap”, not a “stack” or a “queue.” Working from stacks and queues is the rigid, bureaucratized method of operating; it makes you take out things in a pre-described order (i.e. last in, first out for a stack). But if you work from a heap, where input and output are independent, you can use your head, selecting what you need, when you need it, based on outside criteria that are always changing (e.g., what’s need now, such as responding immediately to a customer complaint or getting a gift for your spouse’s birthday when that day arrives and you’ve totally forgotten).

Michael definitely gets it. He knows things won’t go according to plan. He intuitively understands that priorities are going to change. And he places great value in being able to respond immediately to a customer (or significant others birthday).

Something I have grown to feel over the years is agile is nothing new. If anything it is as old as time. It is a natural way of working, that people instinctively do all by themselves.

This was just another example of an entrepreneur being agile back in the 80s.

Pottery class

Pottery class

Rob Austin’s characterizations of artful making (low reconfiguration and exploration costs) reminds me of a story of a teacher and a pottery class:

A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of the work they produced. All those on the right would be graded solely on their works’ quality.

His procedure was simple: On the final day of class he would bring in his bathroom scales and weigh the work of the quantity group; 50 pound of pots rated an A, 40 pounds a B, and so on. Those being graded on quality, however, needed to produce only one pot – albeit a perfect one – to get an A.

At grading time, the works with the highest quality were all produced by the group being graded for quantity.

It seems that while the quantity group was busily churning out piles of work – and learning from their mistakes – the quality group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of clay.

There is something to be said for failing your way to success.

Artful Making Part II – Prerequisite conditions for Artful Making

Continuing with my review of Artful Making, here are some things to consider when deciding whether an more industrial approach, or an artful one will better suit your needs.

I have attempted to make Rob Austin’s points (summarized) in block, with my own in clear text underneath.

Artful making (see previous post for defn) features rapid frequent iteration. This approach only makes sense when the cost of an iteration, is cheap compared to the benefits gained from the experience. If the cost of an iteration is high (as in integrated chip, or car manufacturing), you would be better off doing more upfront planning.

Here are two factors to consider in the cost of an iteration:

1. Reconfiguration Costs

Reconfiguration is doing something once, and then tweaking it ever so slightly to do something else. When you can do this cheaply you have a low reconfiguration cost. Car manufacturing doesn’t have a low reconfiguration cost. Reconfiguration of a car design would involve retooling, new equipment, and possibly changing the layout of a plant. Reconfiguration in software development can be relatively inexpensive. Theatre production arranges and rearranges the actions and interactions of the performers, also inexpensively. Hence, software development as well as other business activities can be, in this regard, more like rehearsal than like car making.

Rob is bang on with this point. It shouldn’t be any surprise that early on our industry gravitated towards industrial, or heavily planned waterfall like methods. When you program a computer with punch cards, and a run of the software takes an evening, you are naturally going to spend more time upfront getting things right.

Things are much different today. Just-in-time compilers, databases, Object Oriented design, continuous integration tools, automated regression tests have made the cost of reconfiguring software much cheaper than 40 years ago.

Agile software engineering practices (typified by XP) have low configuration costs.

2. Exploration costs

The second component of the cost of iteration is the cost of trying something that doesn’t work well enough to continue doing it. In an industrial setting, we might think of exploration costs as “scrap costs.” It’s expensive to throw away physical prototypes. When the cost of exploration is high, you want to avoid making too many throw aways. Similarly, a doctor must consider that iteration may have unacceptable impacts on patients. Software development, by contrast, routinely generates “bad” versions as a way to explore possibilities. These versions are not released and can be fixed as early as the next day. Here, too, software development is more like rehearsal than manufacturing; in theatre, there is not much lost when actors try something that doesn’t “work” because something different can be tried in the next rehearsal.

Rob quite rightly points out that agile (and software development in general) doesn’t suffer from the “scrap costs” described in car manufacturing. The scrap costs in software development are people’s time (which shouldn’t be ignored). Still the cost of exploring new designs, architectures, and patterns in software is relatively cheap, compared to the payoff that comes with a cleaner, more maintainable system that is less expensive to support.