From the Agile Transformation Trenches

Agile Testing: what does it take? Pt. 2

Hello again. This is the second in a three-part series on the most critical issues in Agile testing.  In my first post, I talked about how people are affected by a change to the Agile paradigm focusing on team integration and the required skill sets (Agile Testing: what does it take? Pt. 1). Now let's look at the role of testing tools, and more specifically the importance of test automation.

Striving for a high percentage of test automation is indeed another important aspect of Agile testing. In order to keep up - or accelerate -- the velocity of Agile teams, test automation becomes an absolute must. I'd even say it's impossible to keep up with quality in an Agile environment without test automation.

In Agile environments there is a serious need for speed! The best way to accelerate the Code-and-Test Process is with fast, automated test scripts. Automated testing enables you to achieve "Simplicity - the art of maximizing the amount of work not done," which is considered essential in an Agile environment. 

Once tests no longer have to be performed manually, teams can test much more rapidly and achieve more in less time. Automation also enables testers to create simple, reusable scripts, which they can deploy to save time and increase the consistency of testing across similar user stories, or requirements within and across projects. And, finally, automated testing allows "sponsors, developers, and users … to maintain a constant pace, indefinitely." It significantly lightens the workload of testers and eliminates the need for late-night and weekend testing marathons that can that burn teams out. 

In addition to automating the more common areas of unit testing and functional testing, automated performance testing gives teams the ability to address fundamental issues in the architecture of their application early on when it is easy to make changes.  

So, I've covered two key concepts:  integrating and automating. In the last post in this series, I will expand on this in the context of the "test early and often principle," which not only works well in Agile environments but is a key contributing factor to keeping quality levels high. 

Bye for now

Culture Change with Pigs, not Chickens

Last month David Anderson wrote a two-part article on why agile transformation initiatives fail. David’s suggestion to concentrate on cultural change reminded me of one of my favorite bits on process initiatives. From Peter Coad’s book, Java Modeling in Color with UML, it starts with ‘We think most process initiatives are silly’. I particularly like the paragraph that says, “No amount of process specification will make up for bad people. Far better:  Staff your project with good people, do whatever it takes to keep them happy, and use simple, well-bounded processes to guide them. ”  In fact, I would go so far as to say process over-specification gives non-performing people something to hide behind. Agile processes strip away that cover exposing weaknesses in the ways individuals and teams work and communicate.

However, exposing dysfunctional teams and working practices is not the same as fixing them. In part one of his article, David talks about the problems with management-imposed change that does not win the hearts and minds of those on which it is being imposed. I certainly recognize these problems and not just with agile transformations, but with any major process improvement initiative including standardizing on a new toolset.

In fact, there are some facets of such programs that I have come to recognize as patterns:

1. The ‘Sheep-dip training’ pattern:

   Most process improvement teams realize that staff will need training in the new process or tool set. However, with one eye on the budget, they opt for a training program that introduces everyone to basic the mechanics of the process or toolset.

   Unfortunately, this is a little like giving soldiers basic training in a new type of warfare or equipment and sending them into battle without trained NCO’s and field officers.

2. The ‘If we build it, they will come’ pattern:

   Some people seem to believe that if the process improvement team create the perfect  description of the new way of working on a intranet site (or worse, in a single large MS Word or PDF document), everyone will read it and follow it. I have even known one client that, on deciding to adopt agile, disappeared for a couple of months to write a large document to describe how to do agile in his department!!!

   This is like HQ addressing the lack of trained NCO’s and field officers by sending more detailed written orders to soldiers already under fire.

3. The ‘Centralized coaching team’ pattern:
   
   A team of experts, possibly external consultants, is set up to visit, assess and advise teams on issues they are encountering with the new way of working.
   
   To continue the military metaphor, at regular points in the battle, officers from HQ appear to advise briefly on the new tactics and then hurry back to the safety of the HQ.
   
4. The ‘The disappearing external consultant/coach’pattern

   End users of a new tool or process need expert guidance to get over the initial learning curve and to apply it within their particular project context. The easy solution is to parachute external expert consultants and coaches into these teams.  Unfortunately, again the budget often limits this to part-time or a few weeks only. 

Having your process documented on a website is not wrong. Giving users basic training is not wrong. Providing access to experts and coaching is not wrong … but it is not enough. The fundamental problem with the patterns above that turns them into anti-patterns, is one of pigs and chickens. 

Note: In the UK, we talk about ‘having skin in the game’. In other words, having grazes and bruises from being an actual player rather than supporting or coaching from the sidelines. It seems a more appropriate metaphor for a process called Scrum but the pigs and chickens thing has stuck. Pigs have 'skin in the game'. Chickens are well-intentioned, interested spectators willing the team on but not able to contribute in any concrete way to the final result.

In the patterns above, chickens, not pigs, are providing the expertise whether written or face-to-face.

Personally, I believe the key to effectively achieving a change in culture and a sustainable transformation is to:

1. Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).
   
2. Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong.  Either these people are not the real technical leads, you are not communicating the advantages of the change well enough, or the new way of working is actually a pile of ‘emperors new clothes’.
   
3. Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough. Providing initial training is simply not enough. When the pressure is on, the temptation to return to previous ways of doing things is often too strong to resist. If technical leads are to work for you, they need on-going support and coaching, and a means by which they can support each other.  Good external coaches (expert chickens?) can help here.
   
4. Let the technical leads continue working on their projects. Some fail at the final hurdle by doing 1-3 above and then assigning or scheduling the technical leads to coach other projects, effectively turning them from pigs into chickens.

To summarize, if you can produce a change in the behavior of the lead pigs, the other pigs will, by definition, follow. However, pigs will not follow chickens for long because chickens are simply not pigs.

Out for summer, out 'til fall; We might not go back at all

Photo by sunchild_dd Watching my kids rejoice in their summer vacation I'm struck by the irony of our situations: as children we all disliked school; as adults we crave new learning opportunities. In the workforce, this usually means either conventions or training classes, but not always. Books remain a low-cost (and my favorite!) way of obtaining information, especially when coupled with a discussion group. Blogs, listservs, and podcasts are all excellent methods of finding new viewpoints and new voices in the community. A more social way of getting exposed to new ideas is to join a local organization such as a user group or technology incubator. Attending a BarCamp gathering is another great community learning opportunity. After all, meeting new people can be just as rewarding as understanding a new concept!

While my boys are excited they don't have any more homework for a few months, I look forward to my next opportunity to learn. What do you do to acquire new knowledge?

Post title is a lyric from Schools Out by Alice Cooper.

Agile is Fragile

I recently had the pleasure of seeing David Douglas and Raj Vaidyanathan presenting "Integrating into the whole...embedding agile processes into all aspects of S1's business model" at Agile Austin.  During that presentation, David was lamenting the fact that agile is fragile.  He related several experiences where, despite visible indicators of success, agile adoptions had ultimately failed to be sustainable.  This lack-of-sustainability pattern is certainly a familiar one, and we should look hard to find root causes so we can address them.

I think the lack of sustainable agility can be traced—in large part—to a loss of trust.  "The first thing to build is TRUST!", as Brad Appleton says.  Trust is critical to the proper functioning of an agile organization.  Where there is less trust, we see more dysfunction.  On the surface it can appear that everything is going well.  We all have a lot of real-world experience with putting on a façade of trust.  Ultimately the actions of the team will reveal how much, or how little, trust actually exists.

Trust is slow to build, and quick to destroy.  Since trust is a foundational element of agility, the fragile nature of trust makes agile fragile.  However, there is hope here as well.  Trust relationships exhibit a plateau behavior.  Once established, they achieve a degree of stability that allows trust to survive sort-term attacks.  A slow erosion of trust, or a catastrophic trust-breaking event, will still lead to dysfunction.  If you are feeling a loss of agility, it may be a good time to check on the level of trust in your organization.

Agile Scope: A picture and a few words

A couple of weeks ago, I was peer reviewing some work by a colleague. I was struggling to communicate what was and what was not covered by the popular agile processes  - what I call the scope of the process. For example, Scrum and eXtreme Programming essentially focus on a single small, cross-functional, development team. At a fundamental level, they do not cover larger teams or projects or organizations consisting of many small dependent teams. They say little about how customers or product owners decide on the business value and priority of the user stories or backlog items they create. Neither do they say much about working with a formal testing organization.

While there are plenty of suggestions and some popular approaches to extending Scrum and eXtreme Programming to cover multiple dependent teams, they are just that; extensions to the original core set of rules or practices. 

Anyway rather than try and explain this by waving my hands around I resorted to drawing a picture to communicate what was in my head. Although very simplistic, it seemed to help so I thought I'd share it. If I have done it correctly, you should be able to click on the image below to see it full-size (legibly in other words) in a separate, pop-up window.

The circles represent perpetual activities all running concurrently taking input off lists (or queues, backlogs, or whatever) and generating results on subsequent lists/queues/backlogs.

The green dashed box represents the scope of Scrum/XP and supporting tools like Borland TeamFocus today; sets of small independent teams working from their own backlogs.

The red dashed line represents the space where more and more organizations that have been using agile successfully for a while seem to be focusing. In these organizations individual development teams are working well. The result is that inefficiencies in working practices around the individual teams are starting to show up. This enlarged scope is closer to that covered by an approach like Feature-Driven Development (FDD) with broader demand management aspects informing the individual team product backlogs and collaboration across teams around an overall domain and technical architecture where appropriate. It is the space I see the combination of tools like Borland Team Demand and Team Focus being applicable, for example. Of course, we can't forget Borland Togetherfor recording and communicating the overall architecture as it emerges from collaborative design sessions.

Outside of the red dashed line are the activities that trigger new projects or changes to existing systems, and my colleague's interesting contention that this should all be inspired from a business process improvement perspective. He asserts that all IT development work should be about improving one or more steps in a process somewhere and if we understand our processes or our customer's business processes well enough we can use that knowledge to identify and prioritize development work. For example, Borland as a software tools vendor needs to understand the end-to-end processes involved with developing and delivering software. Identifying pain points, bottlenecks, opportunities for increased efficiency, etc,  in those processes enables us to deliver genuinely useful and easy-to-use products.

What the picture does not show explicitly is the current interest in more sophisticated agile testing with tools like the Borland Silk suite. The idea is included implicitly in the Design, Build and VERIFY activities.

Also not shown are the measurement and analytic aspects that I view as another dimension to the picture entirely.

All suggestions for a better picture would be gratefully received.