Agile teams are fueled by trust – DeepAgile2010 is such a team!

May 11, 2010

It’s been a while since I last blogged here. I’ve been volunteering with a team that is preparing for‘s “Deep Agile 2010 Empowering Teams with Agile Games” professional development seminar. I’ve participated on agile volunteer teams in the past (other DeepAgile seminars as well as a school technology committee). The common factor to success has always been that the teams were open about any challenges and direction, and that the teams developed a strong sense of “trust” between members and any end stakeholders.

While this has been true for every volunteer effort I’ve been involved in, it is especially true of the team preparing for this weekend’s Agile Games. Even though we are a volunteer team, we’ve met weekly for 14 weeks (alternating between teleconferences and in-person meetings each week, with only in-person meeting for the last few weeks). Volunteer meetings are similar to Scrums, but (by necessity) they are longer (1.5 hours on the average). We don’t time ourselves – instead we just “meet until we’re done”. We keep a story backlog in Google Docs which everyone keeps updated. We communicate openly, honestly, and with brevity. The last of these cannot occur until the team has first established the trust I’m speaking of. It is a real joy to be a part of this team.

Our biggest challenge is yet ahead: conducting the seminar itself. I’m confident that something will “surprise” us but I’m also confident that this team will rise to the occasion. We also have a strong set of established speakers: Lyssa Adkins, Tobias Mayer, Michael McCullough and Don McGreal, and Portia Tung. Each of these people, plus many members and volunteers are experienced agile coaches or practitioners. Additionally we have another experienced agile coach (Ellen Gottesdiener) running our Open Space. We’ve surveyed our registered guests and, for over 50% of our attendees, this will be their first time experiencing an Open Space. I’m hoping the weekend will be a productive learning experience for everyone. You still have time to register! (Registered guests will receive more details about the weekend tomorrow.) If you can’t attend, be sure to follow #DeepAgile (or @BobClancy, that’s me) on Twitter. We want to extend the benefit of our work this weekend as far as possible!

Naturally I’m very excited about what we are doing. Mostly it’s because I highly value the team we’ve put together and the guests we’ve attracted. I hope to see you in Cambridge, MA this weekend!

Bob Clancy


Russel Hill’s presentation validated some of what I’ve discovered on my own about testing (in “inside-out” fashion)

April 26, 2009

I’m home after a weekend attending the DeepAgile Embedded professional pevelopment seminar held at Harvard University and hosted by

Many people put a lot of effort into producing and running the seminar: the speakers (Jack Ganssle, James Grenning, and Russel Hill), the host (Nancy Van Schooenderwoert), and many volunteers.

I never realized there were so many embedded software developers interested in understanding agile development practices. Nancy was brave to suggest this and she and the speakers organized an effective presentation of how such practices can be used in the somewhat longer-lived combined hardware/software development cycles typically seen on embedded projects. Russel Hill totally impressed me in how he embraced software testing and simulation of hardware failures in software. (We recorded the talks, so if the recordings come out well, we hope we can share these with you.) Both Russell and James seem to have completely nailed the art of acceptance testing. (I loved hearing that Russell was his own customer/product-owner. He used fitnesse tests to document and understand the current state of their software/hardware project and used tests to describe the project from the inside-out.) Before this weekend, I felt alone in taking that view myself. On the many projects where I’ve worked, I used this inside-out approach as a way of understanding the software I needed to release or test. I’ve used this approach to describe existing functionality and then I’d communicate that to the project owners and see if what they got is actually what they wanted,

Yes, this is a little backwards, but there are a lot of projects in the real world where order needs to be made out of chaos. You need to start somewhere. If you don’t do this on such projects, they never stand a chance of getting better. Russell took these ideas to an extreme and built a software model of the upcoming hardware under test. The result was a set of functional harware tests written in fitnesse in advance of having actual hardware. This gave everyone on their team a common understanding of what they were building. Achieving this common understanding of the product under test is what acceptance testing is all about. Russell’s success is inspiring me to continue on my quest of using tests both as tests and as documentation. I’m hoping the recordings come out well, and that we’ll be able to share a lot more of what was taught during this seminar!

Once again, I give a big thanks to the presenters and Nancy for compiling and sharing this information.

Bob Clancy

The “communicating” part of our work

February 28, 2009

In my last blog post, I discussed “standard work”, gave some examples of it, and explained why it is important. Standard work often helps within a team, but what about across teams? The next step is to make sure we are communicating efficiently with those at each end of our point in the value chain. I think we’ve improved this first order of communication on most of our agile teams, but that there is probably more room for improvement, and there is definitely room for improvement both further up and down the value chain. Agile Testers probably have more insights into these issues than many other members on the team. Ideally, we are communicating with all of the programmers, product owner, and end customers. Usually we work better on the first two of these than with our actual end customers. This disconnect and how to improve it is the topic of this post,

I believe any Agile Tester will look as far up and down the value chain as visibility and time allow on their projects. We work closely with product owners to make sure features for our current iteration is clear and that in the end are implemented in a useful way. We create test cases for these features and add them to regression test suites. We hope the team’s implementation will meet the customers’ needs, but sometimes we’re still not sure whether we’ve “nailed it” correctly until the product succeeds or fails in the marketplace. I believe we can use our existing acceptance testing tools to a greater purpose in facilitating communication both up and downstream both within our organizations and outside to our customers and prospective customers.

I believe one of the biggest advantages with tools like FIT and Fitnesse is that we aren’t limited by the user interface into what we can test. This makes writing and automating testcases less work and allows testing to efficiently keep up with development. It also allows specification of more testcases at any time (including before, during, and after development). Testcases before development express the desired feature more richly and give developers a way to frame how their work is progressing. Testers and end-customers can add more detail to these tests in parallel with development, and can even add some “what-if” testcases after the fact to see if the program will support capabilities that were not thought of or communicate at the outset. This sort of flexibility means:

  • Some important testcases that frame the problem concretely can be included in the user story at the beginning
  • Testers are free to add additional testcases as they explore the feature
  • If those accepting the feature think of more cases, adding them and seeing what happens is easy.
  • Pre-sales teams are able to try additional testcases to see whether the product will meet needs of some new customer
  • Customer support cases can easily be added to the mix in existing regression tests

I realize adding more testcases might seem like a scary thing to agile teams (or any team). I’ll counter by saying a smaller number of clear testcases in the beginning is more helpful in understanding the problem than an exhaustive set, but exhaustive sets of problems may exist in the field, just waiting to be found. Testcases should remain organized and understandable or they loose their value. They should be refactored into “equivalence classes” (a mathematical term) and sometimes they should even be refactored down into unit tests. My point here is that these testcases should serve as a communication tool. We hope that various domain experts will add testcases that matter to them and that such testcases will be shared and understood across the whole team.

Now I’d like to mention what prodded me to finally write on this topic. Rich Mironov (chief marketing officer at Enthiosys) gave a talk titled “Product Managers and Product Owners: Which Do We Need, and What Do They Do?” at Agile Bazaar’s February monthly meeting. Rich explained the difference between the job functions of product owners and product managers. Summarizing what he said: project owners are tightly integrated with an agile team while product managers are usually focused outward (both within, but more importantly, outside of the organization). They need to be evaluating business needs not only of existing customers, but also potential future customers. I never really understood the project manager job function very well, but some lights went off in my head as he described his duties. He showed about 21 different major areas of his job. I wasn’t concerned with all of these, but hearing him saying the equivalent of “you don’t get your testcases from enough places” rang very true with my experience. Rich’s talk was more focused on the role of the agile product owner, but I clearly saw a role for table driven functional testcases in facilitating the communication he said is often lacking.

I’ve also learned that I can amplify my effectiveness by writing programs that facilitate my daily work. If I can codify a body of knowledge for a task (think “standard work”) in a script, I can share the script with others and have them self-serve some of the requests they normally make to me. (The case that comes to my mind was copying selected images from the Helicsope DNA sequencers, but the general idea is transferable. I had to copy images as part of my quality assurance work, but other engineers needed these for advance scientific work and troubleshooting. By scripting this into standard work, others were able to see more and accomplish their jobs faster.) In essence, I was removing myself as the bottleneck in flows outside of my normal work, but important to the company.

We can use this same concept with Fitnesse testcases, but in this case, the collaboration among teams is much stronger (and two-way). Functional/Acceptance tests do not show the whole testing picture, but what they do show is important or more so outside of the development team than within. They communicate “intent” upstream and “behavior” downstream. Both of these are important, and they allow other stakeholders to determine both if the tests and the software under test are meeting their intended and actual needs. We need to use these tests as the communication tool they are meant to be. The effect will be software that better meets the needs of end-users and both internal and external stakeholders. Wikis are a great communication tool, and extending them with tests and sharing and improving these tests among the whole facilitates the communication issues I’ve addressed in this post. Agile Testers can greatly facilitate this communication by championing these tests within and across teams/stakeholders, and keeping the evolving testcases clean, documented, and understandable.

I’m interested in hearing your thoughts and experiences around these sorts of communication issues. Has this worked in your organization? Do you have additional ideas? Who do you see as the next set of stakeholders on each end of the value stream for your projects? Please share your thoughts and suggestions in the comment area of this blog post.


Bob Clancy (

Considering whether Standard Work has a place in Agile Software Construction

January 29, 2009

While just a teenager, I learned from my father, that in a trade, you need to do your job as efficiently as possible. For some jobs, people have already figured this out and we can learn from their experiences rather than reinventing the same process over again. My father was a bricklayer, and he taught me this trade, so I also know these lessons from first-hand experience. Economy of movement is the single most important success factor in any of the building trades. The trade has collectively learned these tricks and they teach it to new craftsmen through apprenticeship. The bottom line is you have to produce to stay hired or in business. Your competitive advantage comes from your discipline to do quality work as efficiently as possible.

The software business different in that technology is constantly changing out from under us. It’s much harder for us to recognize the emerging patterns that allow us to do work in the way that has worked best for others who came before us. The patterns movement is an analog to the apprentice program that tradesmen have used. The key point about patterns is they are developed and shared using the scientific method. This means observing what works, hypothesizing why, testing the hypothesis in your work as well as others, making refinements based on experimental feedback, and sharing the knowledge with others. This sharing can be both within a company and within an industry.

Unit tests are a practice used by programmers that dramatically increases their economy of movement (which we call velocity). These are shared within the development team but they are poor at communicating outside the team. That’s okay because they serve a purpose only within the team itself. The customer of a building tradesman really only cares about the end result and the price. This shows a clear separation between the tricks of the trade and what the customer needs to know. Clearly, there are standard work rules that have been learned and followed on the team. In both cases, many of the practices are communicated “via word of mouth”. The difference is that the software industry operates in many different contexts and some practices learned in one shop won’t apply in the next.

The key is to learn principles on which the practices can be derived for a given context. One the practices for a given shop or a given job are learned, the job-specific practices should be documented in a way that will be understandable to a new worker taking on the same task. Often managers are the bridge to learning and transferring these practices from one worker to the next. Collectively, as agile practitioners, we have ignored this problem (because it affects the next person and not us). Management should step in and not allow this to happen. The bottom line is not having job-specific learned-practices documented results in a significant amount of waste. Self-organizing teams can usually come up with the right (efficient) practices, but they’re unlikely to communicate what they have learned.

I’ve begun reading about the concept of “standard work” in Lean Manufacturing. The idea is to distill what prior operators have learned about how to perform the work for a specific station into something easy and quick to understand by new operators. (Think of the instructions for how to put together IKEA furniture.) Keep in mind that new things are often learned and that these instructions should be considered changeable to reflect this. A good measure of what constitutes need for improvement is when a change in the procedure will result in value. This could be a faster way to work, a way to check the quality and prevent defects or scrap, or even a safer, or less fatiguing way to do the work. This particular knowledge does not come from the manager, but from the workers themselves.

I’ve seen examples of “standard work” practices when I worked as a member of a release engineering team. We developed checklists for releases to make sure all team members performed tasks completely and repeatably. Many of the checklist tasks were automated but there was still a human performing a sequence of tasks. We did the checklists out of necessity because not following an established procedure resulted in variability in the work output. We had the discipline to solve such problems and share our method with the rest of the team. I’m hoping that you will think about the work you do and find ways to share knowledge with your coworkers. This usually results in greater job satisfaction as well as improving the bottom-line for your company. If you are a manager: do the jobs performed by your team. Use this as an opportunity to share learned knowledge among the team. Be appreciative of what you have learned and find ways to show the team how sharing this knowledge benefits everyone. Once the team has bought in, consider producing pictures, mind maps, or checklists so that everyone can easily remember the current best way known to accomplish each job.

Bob Clancy

Welcome to the AgileTester.Net blog!

January 16, 2009

Welcome to the AgileTester.Net blog!  On this blog we will discuss all things related to testing effectively on agile teams.  You will find useful information here whether you are a scrum master, software developer, product owner, system analyst, or software tester.  In a way, agile software testers need to bridge all of these disciplines.  To begin, you can learn a little more about me on my website and a lot about me in my LinkedIn profile.   Please explore these areas and stay tuned for my upcoming posts!

Oh yeah,  I’ll probably discuss some agile practices in the context of their underlying lean principles (provided people want that) too.

Bob Clancy