effective software development

Offing the off-site customer at the Oklahoma APLN

Wed, 4 Jun 2008 09:52:25 -0500

Yesterday's meeting of the Oklahoma APLN featured Jim Shore's Offing the Off-Site Customer exercise, facilitated by Tina Mangham. The workshop is a great way to get a gut feel for the difference in effectiveness between document-centric BDUF and direct collaboration with the customer (or knowledgeable customer proxy).

In a nutshell, people work in twos to carry out a mini-project using first a waterfallish approach and then a collaborative approach. The working duos consist of a customer and a developer. The customer receives a drawing that the developer cannot see. Based on the drawing, the customer has to write a "requirements document" that describes, using only words, how to reproduce the drawing. The customer hands off the document to the developer, who creates a drawing based on the written specification. In the second phase, the two work directly together without a written specification. The developer creates the drawing while the customer provides guidance. Then the results are compared and the group retrospects on their experiences.

I acted as the customer on my "project." In the first phase, I was able to write specifications for all the "must have" parts of the drawing, but didn't complete all the "nice to have" requirements within the allotted timebox. The requirements I wrote contained one error, and one of the other specifications was misunderstood by the developer. That is, the requirements document contains two of the classic types of defects one expects to find in software requirements: A mis-stated requirement and a misunderstood requirement. The specification was also incomplete, as it did not include all the "nice to have" items from the original drawing. No doubt these issues sound familiar. Our team's developer, working from the written specification, completed a portion of the requirements at a low level of quality within the five-minute timebox.

The second phase was far easier and faster, when we could just talk about what was required as it was being developed. Our team completed the five-minute "project" in three minutes will all requirements fully satisfied. Of course, this was completely unsurprising to the developers in the room. Unfortunately, the meeting didn't draw many people who work in the roles that sorely need to learn the lesson: Product Owners, Project Managers, Business Analysts, Requirements Analysts, and so forth. Tina and others involved in organizing the event made an effort to invite people in those roles from their own companies and from client companies, but the response was poor.

Jim's exercise is a powerful tool for illustrating the value of customer collaboration over contract negotiation. I strongly encourage you to run the workshop at your company or local user group, and to include people in the appropriate roles. If they can get this message, maybe they will become supporters of positive change in their organizations.

"Overcoming Resistance to Change" at XP2008

Mon, 2 Jun 2008 09:45:09 -0500

Lasse Koskela and I will present a half-day workshop on overcoming resistance to change next week at XP 2008. We both work as agile coaches, mentors, and trainers at consulting firms whose clients are attempting to adopt agile software development methods and to transform their organizations to enable and support that adoption. Lasse works for Reaktor Innovations in Finland and I work for Valtech Technologies in the US.

The workshop incorporates elements from previous workshops we've each developed independently and draws on material from Dale Emery (creator of the Resistance as a Resource Game), David Buchanan and David Boddy (authors of The Expertise of the Change Agent: Public Performance and Backstage Activity), and John Kotter and Leonard Schlesinger (authors of Choosing Strategies for Change), as well as from our respective direct experiences. This will be the first time we have combined our material into a single workshop.

The workshop exploits experiential learning techniques and includes several hands-on and interactive segments. One of the basic ideas is that any corporate IT organization may face resistance from any of three main constituencies: IT technical staff, IT management, and business (corporate) management. The sources of resistance vary depending on which consituencies are behind the proposed change and which feel threatened by it. We use Dale Emery's Resistance as a Resource Game to help participants gain an understanding of different points of view and priorities of people and groups in a large organization. From Buchanan and Boddy we learn about patterns of behavior that represent covert or passive-aggressive resistance in organizations and specific counter-strategies to deal with them. Kotter and Schlesinger offer a practical, six-level framework for overcoming resistance, emphasizing win-win alternatives except when the resistant party simply will not come around, and then resorting to progressively more forceful methods. The experiential segments provide participants with the opportunity to role-play and explore various behaviors of resistance and methods to overcome it.

As if this weren't reason enough to attend, June is considered to be the best time of year to visit Ireland. We hope to see you there!

Program notes - http://www.lero.ie/XP2008/tutorialOvercomingResistancetoChange.html

Workshop description, links to further information, and presentation slides - http://davenicolette.wikispaces.com/Overcoming+Resistance+to+Change

Agile maturity and metrics

Fri, 30 May 2008 23:01:00 -0500

I had an interesting conversation with Al Goerner, a colleague at Valtech, about tracking agile projects. In a presentation, Al recommended tracking separately (a) test coverage, (b) percentage of tests passing, and (c) tests failing that used to pass. I found this strange, since by definition an agile team must have full test coverage (although this may not be 100% LOC coverage literally, due to the way coverage tools work), 100% of tests must pass before the work is deemed "done," and any broken tests must be fixed before the work is deemed "done." I didn't see how the three measures could be separated in a meaningful way, so I asked him what he was trying to achieve.

Al pointed out that many of our engagements are with clients who are at a very early stage of agile adoption. In terms of the agile marathon, they are only now daring to dream of beginning to think about starting to consider the possibility of carefully attempting, in a limited way, some of the practices at maturity level A. Their development teams routinely label code as "done" when it isn't fully covered by tests, when some tests aren't passing, and when previously-passing tests are broken. Their management knows development projects tend to run over cost and time, but they don't know why. The additional metrics are meant to make the causes of cost overruns visible to management and the effects of suboptimal development practices visible to technical staff.

Considering that agile methods are still at an early stage of diffusion — about 12% of companies have experimented with something they label "agile," whatever that means, but on the whole we're stuck at the edge of the chasm — Al is quite right to say most organizations need to see these metrics. Once teams become more comfortable with and more skilled at agile development and they move closer to maturity level B, it should be feasible to reduce the number of categories of measures. When code coverage is normally acceptable and when it is routine for all tests to pass (both new and old tests) before code is deemed "done," then you will know you have achieved a level of maturity that makes some of the additional metrics superfluous. The sooner you can get there, the easier and more valuable your work will become. Until then, it's probably a good idea to make as many issues visible as you can.

Primate behavior and adoption of new practices

Thu, 29 May 2008 23:01:00 -0500

If my own experience is typical, then teams that learn effective software development methods from peer-level mentors tend to learn, apply, and benefit from the new methods more successfully than teams whose members take a training class or attempt to figure out the new methods on their own without any live, hands-on guidance. For instance, I first learned XP by working on real projects alongside mentors from a consulting firm that specialized in XP and whose personnel made up 50% of our company's development teams. It proved to be a highly effective way to adopt the new practices. In just a couple of years, we had built up an agile development group of some 60 people and felt confident in releasing the consultants.

Yet, there seems to be a widespread belief that an organization can successfully adopt an entirely different way of approaching software development just by sending a few of its technical staff to a training class. When the newly-minted change agents return to work, they find themselves in a cultural environment that is hostile to change, working with colleagues who have no interest in changing the way they work, and enjoying no real management support for introducing change. Unsurprisingly, they end up back where they started. Often, they label whatever new methods they were trying to introduce a "failure."

Liza Moscovice and Charles Snowdon of the University of Wisconsin at Madison published the results of a study in Animal Behavior, 2006 April; 71(4): 933–943, entitled The role of social context and individual experience in novel task acquisition in cottontop tamarins, Saguinus oedipus, in which they examined a process for dissemination of new foraging techniques through a group of tamarind monkeys. The parallels with learning effective software development techniques are striking.

The authors investigated how well the tamarinds learned the new skills "(1) individually, (2) while interacting with a naïve mate, and (3) while interacting with a mate trained as a knowledgeable demonstrator." Long story short, the only effective way to disseminate the new skill throughout the group was when individuals learned by foraging with a knowledgeable demonstrator who had been trained individually. The basic process was as follows:

Habituation
Individual learning

...followed by:

Interaction with a naive mate or
Interaction with a knowledgeable demonstrator

The parallels with adoption of a new way of building software are obvious:

Habituation is similar to reading about a new approach to software development and realizing that one's present way of working may be suboptimal.
Individual learning is similar to attending a training class.
Interaction with a naive mate is similar to trying to work out how to apply new techniques when no one on the team has used the new techniques before.
Interaction with a knowledgeable demonstrator is similar to pairing with a mentor.

Despite the obvious difference in native intelligence between the two species, there is reason to believe humans may be able to learn new software development methods through direct mentoring, even when training classes and ad hoc guesswork are ineffective.

The agile marathon

Wed, 28 May 2008 23:01:00 -0500

I hear so many different opinions about what is or isn't feasible for agile teams, which agile practices are or aren't practical, and which projects are or aren't "agile" that I sometimes wonder how we can ever communicate our ideas about agile development in an unambiguous way. Recently it occurred to me that the adoption of agile thinking in the industry is a bit like a marathon. At the start of the race, everyone is lined up in the same spot. Ninety minutes into it, the runners are spread out over the course. Some are farther along than others. Some are very, very far behind and there is virtually no chance they will ever complete the course, even at a walk, yet they feel as if they are just as much a part of the race as anyone else and they wouldn't appreciate being labeled as "not runners at all."

Agile adoption is like that, too. If we take the official start of the race as February, 2001 (when the Snowbird meeting took place and the buzzword "agile" was coined), we might say everyone in IT was lined up in the same spot. Seven years after the starting gun, we're spread out all along the course. Some have moved far along, some are still pretty close to the starting line, and most are somewhere between. The leaders are already critiquing the quality of the course and thinking about how to organize next year's race. Back toward the starting line, a few seem to be jogging around in a circle, having merely re-labeled their old work habits as "agile," yet they feel as if they are just as much a part of the race as anyone else and they wouldn't appreciate being labeled as "not runners at all."

As of mid-2008, different organizations and different teams are at different levels of maturity in the application of agile principles. Most of the IT industry hasn't embraced agile at all just yet. Of those who have embraced it, most are trying to master the art at the maturity level labeled A in the illustration. Some are ahead of that point, and are collapsing role-based siloes to reduce work-in-process inventories and hand-offs, shortening feedback loops, pulling tests forward, and removing still more overhead from their process such as task-level estimates in ideal time and iteration burn-downs. Thought leaders in the community are exploring ways to blend in good ideas from other sources, such as CMMI to achieve better scalability, predictability, and repeatability, while reducing waste even further through Lean principles. Looking ahead, some are considering how organizations need to restructure and how managers need to adjust their thinking in order to take better advantage of the potential benefits of agile and lean methods.

The wide range of opinions regarding feasibility and practicality of particular agile techniques may simply be a reflection of different individuals' experiences to date. Those who believe certain practices aren't feasible may have experienced difficulties when they attempted to introduce agile methods in organizations that weren't prepared for change; once burned, twice careful. Those who have had good results at maturity levels A and B are in a position to see, and therefore to try and knock down, the next level of impediments in the pursuit of excellence.

Circa 2002 the leading edge corresponded to maturity level A, the ideas listed under B would have been considered pie in the sky, and the concepts at maturity levels C and D weren't on the horizon at all. True to agile principles, empirical information from agile projects has informed continuous improvement in agile methods and enables us to push the envelope day by day and year by year. It's an exciting time to be involved in the IT industry!

Shapes in the fog

Tue, 27 May 2008 23:01:00 -0500

Most people who are interested in effective software delivery agree that short feedback loops are generally preferable to long ones. One of the most powerful combinations of development practices comprises test-driven development plus version control plus continuous integration. This combination enables very short feedback loops in the context of building well-tested code incrementally and with low risk of creating new problems. The practices depend on tools that make it possible to drive development through unit tests, to perform incremental refactoring easily, to synchronize changes made by more than one developer concurrently, and to run a build with all automated tests very quickly whenever changes are detected in the version control system. The tools, in turn, depend on the team to configure and use them appropriately and to isolate and fixture their tests in a way that allows the build to run fast and often.

With this in mind, I think it's clear that the automated build is one of the key elements in an effective software development process. To support continuous integration, we want a build process that runs tests at the unit, integration, and functional levels with appropriate isolation and completes quickly enough to provide feedback to developers before they proceed with the next bit of development work. If we take the current state of the art in software development technique to be test-first development with very short red-green-refactor loops, then we want a build that provides feedback about our latest check-in before we get into writing the next test case. For teams using agile development methods, that implies a build process that runs in five minutes or less, generally speaking. (There may also be a nightly build that covers non-functional requirements, collects data from static code analysis tools, and exercises all the external interfaces. That process need not run in under five minutes, of course.)

What if the build process does not complete in five minutes or less? I think it's obvious that waiting for feedback from the latest build will affect the team's ability to follow other good practices. One way to look at it is to think of the build as the first domino in a row of dominoes that are lined up to fall in sequence. The longer the delay in receiving feedback from the build, the more dominoes fall. That is, the worse the build process is, the more severe the negative impact to other agile development practices will be. To illustrate the concept, let me describe four real-world situations and step through the impact on delivery effectiveness caused by the build process in each case. First, let me set a baseline for comparison by describing the current state of the art in development, as I understand it.

Agile techniques have evolved considerably since the term was coined in 2001, and they continue to evolve today. In my opinion, current state of the art as of mid-2008 means (in part) that developers work in short TDD cycles in which they write a single test case, then the code to make the test case pass, and then consider the need for refactoring and carry out the refactoring if necessary. Then they check in and let the build run. If the build is clean, the developers proceed with the next test case, and so on all day long.

This approach enables each developer or pair to maintain a state of flow (or to be "in the zone," if we need to distinguish this use of the word "flow" from the Lean sense) for most of the time they spend in heads-down development activities. Working in a state of flow, their effectiveness is maximized. Interruptions to the state of flow reduce their effectiveness until they can regain that state again. That means any context switching they have to do during the day reduces their delivery effectiveness. In case it isn't patently obvious, let me say that project cost varies in inverse proportion to delivery effectiveness. Therefore, anything that reduces a team's delivery effectiveness directly increases project cost.

There is another cost to lengthly build processes, and it may not be quite as obvious as the impact on delivery effectiveness. The effects of a long build process can make it hard for people in the organization to perceive the cause of their problems or to see how to fix the problems. The metaphor of a fog bank comes to mind; depending on how dense the fog is, people may or may not be able to discern meaningful shapes in the fog. When the effects of a bad build process create so many problems that causes and effects are difficult to perceive, then people may not understand what is causing their problems or how to address them. I hope the following examples illustrate this aspect of the issue as well as the more obvious aspects.

Case 1. This is a fairly large-scale enterprise initiative that involves multiple teams coordinating their work in a scrum-of-scrums (or team-of-teams) arrangement. They apply the most common set of agile methods in use today: Scrum plus XP. All the teams use Scrum reasonably well, but not all are equally mature in the use of XP practices. The teams are working on the same large codebase and there is a comprehensive build that includes full-system tests of the entire product with all external interfaces active. To support continuous integration during the day, each team has its own build that includes unit, integration, and functional tests for the components they are developing. Some of these are properly isolated and others have external dependencies that affect the build. Most teams' builds complete in 40 to 70 minutes. The best case team build runs in 3 minutes.

How does a 40 to 70 minute build affect good practices? If you visualize yourself working on one of those teams, the first thing you will probably realize is that after checking in the code for a single test case you will have to wait an hour or more to get any feedback from the build. Will you sit there doing nothing until the build completes? Of course not! You will continue to build up code on your own workstation. By the time you see the results of the latest build, you will have gone ahead with considerable additional code. You might find that some of your tests are broken, or that your changes broke other tests. At that point, you lose flow and have to context-switch into a debugging activity. Once you've fixed the problems from earlier in the day, you may be ready to check in the large volume of new and changed code you've developed since the last build. Everyone else on your team has also been building up a lot of code between check-ins. That means you will have to spend some time merging the code and synchronizing with the repository. That's another context switch and another interruption to value-add flow. All these interruptions reduce your effectiveness as a developer.

With respect to visibility and awareness of the problem, this organization understands that the length of the build process has a negative impact on delivery effectiveness, they have a plan to address the problem, and they are gradually remediating the various team-level build processes. I mentioned one of the teams has achieved a build time of three minutes. Other teams are also working to reduce their build times. The problem is not so severe that its cause is difficult to see. There is a bit of fog, but the cause is still visible — at least, to those who choose to look at what is in front of them.

Case 2. This is a relatively small (but not tiny) project involving a single team that is trying to use XP. Their build process is problematic. They can usually get a build to run to completion overnight, although it requires overtime for certain key individuals to nurse the process to completion. In a typical work week, the team will see the results of 3 or 4 builds. Best case, they will learn of errors after one day; typical case, after two days; worst case, after three days. The delay in receiving feedback from the build is longer than in Case 1, and the relative impact on other development practices is greater.

In this situation, there is no possibility of getting feedback from a build on the same day they check in code. This discourages them from checking in frequently. An additional impact beyond that of Case 1 is that the team cannot follow the generally-accepted agile practice of ensuring the build is clean before leaving at the end of the day. Lacking that particular discipline, it's all too easy for the team to let other good practices slide, as well. Development takes on the character of ad hoc work, almost in the nature of hacking. The main cause of all this is the build time.

In this case, the severity of the problem with the build process makes it harder for the team to understand what to do about it. They know their build process is problematic, but they do not know what to do to fix it. In discussing the situation with them, I learned that they were unaware of some basic ideas, such as multiple levels of test isolation, or using a different build process to support continuous integration during the day than they do for full-system testing overnight. They may try some of these ideas in the near future.

The fog bank is denser here than in Case 1, but people are able to discern meaningful shapes, even if only vaguely. They are able to see that their build process is a problem for them, but they are (or were) unaware of the possible correlation between build problems and other problems in their delivery effectivensss. They are (or were) also at a loss as to how to approach the problem.

Case 3. This situation is not unlike Case 2 qualitatively, but worse quantitatively. In this case it isn't practical to run a build even nightly. They may be able to get a build to run to completion once a week, with considerable manual intervention and often with some portions of the build script commented out.

The timeliness of feedback from the build is an obvious problem here, and they have the additional problem of reliability. Beyond the problems in Case 2, this team cannot depend on the feedback they receive from a build because portions of the build may have been disabled in order to force the process to complete. They can get some useful information from the build, but not really enough to support the disciplined application of robust agile methods.

The fog is denser here, as well. People on this team aren't too sure what is causing their problems. While they know their build process is suboptimal, they are experiencing so many secondary problems that they cannot stop fighting fires long enough to analyze what is happening. Under these conditions, they cannot apply TDD effectively. As a result, they generate a large number of defects and their codebase steadily accumulates technical debt. They spend so much time dealing with these tactical issues that they don't feel as if they have time to address the build process. Since the build process as such is not "development" and is not demonstrated to customers, they consider it a secondary matter.

The fog metaphor in this case is that people can make out some indistinct shapes in the fog, but they cannot recognize what the shapes represent or whether and how the shapes might relate to the problems they are experiencing. As a result, they continue to deal with tactical issues that are only effects, while failing to address the cause of the problems. They are so bogged down with tactical problems that they don't have the time to conduct a root cause analysis, so the problems recur.

Case 4. This is a group of engineers working in a heavy industrial plant who write and support software that monitors and controls portions of a steel production operation. The system includes components consisting of hardware with embedded software. The software is written in C++ and was never designed with any sort of rigorous software development process or good practice guidelines. Those responsible for the software are engineers — not "software engineers," but bona fide engineers. Like many engineers, these write software when their jobs require it, but they are not software development professionals as such, and the way they approach the task would strike a software professional as hacking.

To build the software and get all the components loaded and talking to each other requires several days of full-time effort by several people. The embedded code can't be compiled on the same platforms where it executes, so different components must be transferred to their respective hardware devices as part of the "build" process. Because of the difficulty and tedium of building the system, the group only attempts a build when a release date is approaching. They have to spend most of their time just building and deploying the system, so they have relatively little time for testing. Due to the tools they are using and the fact they never paid any attention to testing when the code was first developed, there is no automated test suite and manual testing is only possible when the entire system is configured and connected to all its external interfaces. As you can probably imagine, when they are trying to prepare for a release they discover numerous bugs and other surprises. Worse still, they have no way to revert to a previous, working version of the code. Once they begin building a new version, they are committed to it for better or worse.

The general situation is so messy that the group can't see anything but fog. As far as they can tell, the entire universe is a single, opaque fog bank. They see no shapes in the fog at all. Everything they try to do is deeply frustrating. They don't even realize they have problems with their build process; they just assume "life is pain" and maybe they should have chosen a different career path.

I think there is a correlation between the quality of the build process and the effectiveness of the software development operation as a whole. As one problem leads to another, the overall situation becomes increasingly confusing and it becomes harder to discern specifics through all the background noise of constant problems. In Case 1, the issues are clear enough that people can see which ones are causes and which are effects. When they attempt corrective action, they can see the results and make a judgment about what to do next. In Case 2, people are able to see somewhat less clearly. They know their build process is causing problems, but they aren't sure what to do about it. The situation in Case 3 is generally messier and as a result it's harder for people to see what is causing their problems. They are bogged down with fire-fighting. Even if they attempted to improve their build process, the results of the change might not be clear because the group would still be drowning in problems. With a situation as messy as that of Case 4, people just give up.

Another potential problem has to do with auditability requirements. Case 4 is not a US company and is not subject to Sarbanes-Oxley, but I suspect there are many companies in the US that are in the same situation. What would they say to an auditor who wanted to see their standard processes and evidence that they follow those processes? Of the four examples, only Case 1 would be in a position to pass an audit. Their build process automatically generates and archives the relevant reports.

Because the build process is usually seen as a secondary or minor aspect of software development and support, and because it is not usually visible to business stakeholders or managers, there is a tendency to take it for granted. When I observe what appears to be a strong correlation between build process quality and delivery effectiveness, it makes me think the build process deserves to be treated as a first class citizen. Indeed, one of the reasons the people in Case 1 are in better shape than the others is that they have a dedicated build team. The many costs of a poor build process are not immediately obvious, and because of the domino effect each individual cost may not appear significant when considered in isolation. For these reasons, people may underestimate the value of applying resources and time to streamlining and improving their build process.

Questioning everything

Mon, 26 May 2008 23:01:00 -0500

As we shorten feedback loops (iteration length, etc.), is there a point at which feedback is essentially continuous?
When feedback is continuous, then what is the meaning of "an iteration?"
In an iterationless process, how might we do planning?
In an iterationless process, does story/task estimation add value?
In an iterationless process, how and when does a team reflect on its effectiveness for purposes of continuous improvement?
Is a "bug fix" qualitatively different than any other piece of work?
Which approach offers more effective and better managed delivery of business value: (a) Every bug report is an emergency that must halt other work unconditionally in an unplanned and unpredictable manner and without reference to business goals, coordination of work streams for product deployment, or market realities; or (b) Product owners have the opportunity to prioritize bug fixes along with the other work they have requested?
Is there a substantive difference between "development" and "support," or does the lifetime of an application constitute a continuum of incremental delivery in which proportionally less time is spent in building new features as the application matures?
If the lifetime of an application constitutes a continuum of incremental delivery, then what is the meaning of "delivery date" or "deadline" or "project completion date?"
If the lifetime of an application constitutes a continuum of incremental delivery, and a valuable increment of the solution is deployed to production in each iteration, then how can a project be deemed "late?"
If the lifetime of an application constitutes a continuum of incremental delivery, then what is the business value of disbanding the original development team and handing the application to a different team for "production support?" Is this approach muda?
If an organization manages its business and technical development needs as a value stream, then what is the meaning of "a project?"
What is the business value of running discrete "projects?" Is this approach muda?
If there is no need for discrete projects, then when should teams be formed and disbanded?
If teams are long-lived and dedicated to business themes rather than formed and disbanded on a per-project basis, then what is the unit of labor for purposes of performance assessment and employee rewards: The individual or the team?
If the unit of labor is the team rather than the individual, how can individuals manage their own career growth?
If organizational cultural values and work methods are explicitly team-centric, how can the "lone wolf" personality type contribute to the organization?
How do conventional notions of organizational structure, professional roles, career paths, employee compensation and incentives, and program management constrain positive change?
An organizational structure may be seen as a container designed to fit (and facilitate) a set of values, assumptions, principles, and processes. Can we effect radical improvements in software delivery effectiveness while remaining inside a container intended for a very different (and undesirable) set of values, assumptions, principles, and processes? Is it professionally responsible to attempt such improvements without also attempting to re-shape the container (the organization)?
If a team is dedicated to a shared enterprise asset (data warehouse, ETL package, business rules engine, ESB, integration platform, network infrastructure, etc.), should the team members be directly employed by the central IT department or by one of the organization's business units?
If a team is dedicated to a set of applications that supports a particular business theme, should the team members be directly employed by the central IT department or by the business unit the team supports? Is the "service" model muda?
If a team dedicated to a particular business theme does not have a consistent stream of work to keep them busy, is it more cost-effective to ramp up a new team for each initiative connected with the theme or to keep the dedicated team on board to carry out lower priority activities in between major initiatives?

"The Agile Edge" event, May 22

Fri, 16 May 2008 14:33:40 -0500

Valtech and VersionOne are hosting a one-day event called The Agile Edge at the Hilton McLean hotel in Tyson's Corner, Virginia, on Thursday, 22 May 2008. There will be three tracks: Agile Organization, Agile Engineering, and Agile Management.

Valtech's new Chief Process Scientist, David Anderson, will give the keynote. As we all know, any agile consultancy worth its salt must have a Scottish chief scientist. Valtech has now achieved that crucial milestone.

The estimable Mike Cottmeyer of VersionOne will handle the Agile Management track single-handedly, while Valtech's Mike Abney, Al Goerner, Nathan Slippen, Tim Walker, and your humble narrator will facilitate the sessions on the other tracks. This is mostly hands-on stuff, and not just talking heads and slide shows. It should be both fun and informative. Come and join us!

Point and counterpoint on TDD

Thu, 15 May 2008 08:18:56 -0500

An earlier post garnered some thoughtful responses from readers, mostly on the topic of TDD. Since these posts tend to scroll away fairly quickly, I wanted to point out that there are a few comments on that one that might be of interest.

If you're interested in the subject of TDD generally, you might find the following discussion lists valuable:

You might also find the following books useful:

Test Driven: TDD and Acceptance TDD for Java Developers, Lasse Koskela
Test-Driven Development in Microsoft .NET, James Newkirk and Alexei Vorontsov

There are several other books available on the subject of TDD, but they have very mixed reviews. If you're unfamiliar with TDD, you might find most of the other books a bit confusing.

There's also a sort of aggregator or focal point for TDD at testdriven.com where you can find references to articles and links to additional online resources.

Chicken silencer

Wed, 14 May 2008 09:40:13 -0500

A few months ago, we started a discussion group based on the book, The Art of Agile Development by James Shore and Shane Warden. Almost from the first meeting, the topic of discussion broadened into agile practices in general and how some of our own projects were doing. It has been a very interesting and constructive experience, and probably will continue indefinitely, book or no book. The discussion group is a great way for ScrumMasters and other practitioners to share ideas, experiences, issues, and suggested solutions. Recently we tried a somewhat radical idea and had ScrumMasters facilitate the retrospectives of teams other than their own, without having much knowledge of what the other teams were doing or what their issues were. Now we're considering having team members cross-pollinate other teams by sitting in and pairing with them for a day or so at a time.

One participant told a story this week about his team's retrospective that I found noteworthy. It seems one of our managers attended the retrospective as a chicken. At one point, a team member said something that piqued the manager's interest, and he engaged in a lengthy discussion with that team member, right in the middle of the retrospective (which was timeboxed). He was allowed to go on with this without interruption. I asked the discussion group what they thought the ScrumMaster should have done in that situation. Bear in mind that this particular chicken is the direct manager of this particular ScrumMaster.

A participant suggested that the ScrumMaster might carefully, delicately take the manager aside after the retrospective and gently, diplomatically suggest that perhaps he might, just maybe, let the team get on with its business and to try and remember that usually, sometimes, you know, if it's all right with you, "chickens" maybe ought not to speak too much during the retrospective, since according to theory, only the "pigs" are allowed to speak. Several heads nodded in agreement.

I nodded, as well, and then asked the group if anyone had another suggestion, since some of the participants have been through a CSM course and they might have received some slightly different advice about this sort of situation. No one offered an alternative.

So I did.

"Chickens don't talk!"

If the ScrumMaster was afraid to say this to his own manager, it raises a question about whether we have a culture of trust in our organization, doesn't it? The Right Thing is always the Right Thing. It doesn't change based on who is or is not in the room at the moment.