I was at Agile Fusion last week, an event intended to explore the ways testers could be integrated into XP, and though there was a lot of good dialogue, there was no resolution. I am not disappointed by this, as this issue is not something you simply "solve" in one week. But it has left me thinking as I believe skilled testers can greatly improve the agile development process.

During a tutorial I attended today about the Lean Development Toolkit, I found inspiration. Mary Poppendieck talked about concurrent engineering in the automotive industry and commented that software development could benefit by adopting the technique. In concurrent engineering, the product is developed with multiple, parallel activities aimed at developing different components of the finished product.

So, I have the following idea, though it is really half baked. Consider the beginning of an XP project (or any XP iteration for that matter). During the planning game, testers contribute by asking questions that help expose areas of risk and necessary consideration. Though the whole team should be doing this, skilled testers are particularly adept at this. (Lisa Crispin raised this idea during Agile Fusion.)

The rest of the planning game proceeds as normal. Once stories are established and tasks laid out, development begins with normal pairs of developers, with an occasional third member (a tester) who can move among pairs, sort of like a bee collecting pollen and cross pollinating. The tester, at this point is observing more than participating, but she is gathering information about the internals of the software, the habits and biases of the programmer, the architecture decisions, etc.

The tester only does this gathering for s short period of time, at which point the tester (or testers, though I have though about this much) break away from the development activities to focus on their activities. From what I understand of context driven testing, such testers will formulate theories about how to test specific systems, effectively developing strategies and plans for testing the system (though not huge documents of test plans and specifications, but rather ideas and strategies).

At the end of the iteration, the tester will discuss with the entire team his theories about how to test the system, the important risks and any concerns they have. This information is a vital part of the iterations retrospective and this feedback should be used for the next planning game. The developers hand off a working system to the testers and begin their work in the next iteration. The testers have a working system to test; both for their approaches of how to test the system and the system itself. They revise their plans, expose new risks and identify defects (or areas for improvement). The testers should still join some pairs to constantly learn about the system internals and the developers should integrate the contribution of the testers in their automated tests. This workflow continues for each iteration.

I would characterize this workflow as a weaving in and out of the tester with the pair programming activities. It allows the testers to collect information that helps them better formulate their test strategies, but gives both testers and developers the freedom to concentrate on the tasks that they are best suited to.

Brian Marick (and other in the context driven school), commented that one of the core principles of context driven testing is that testers would rather have working software to test than documents about how they would test the software. He also noted that context driven testing develops testing strategies appropriate to the system they are testing. I think that the workflow I outlined satisfies both these desires; testers get working software in each iteration that guides the refining of their strategies. The developers also get feedback, with each iteration, about what issues they need to think about and hopefully use this information to improve their automated tests and overall code.

There is another element that appeals to me in this idea. I think developers prefer to build something first, then reflect on it, and integrate their reflections into the software, proceeding in a very incremental and iterative fashion; developers are anxious to dive right in. Testers (from what I have observed), prefer to think about the system, consider it from many perspectives and generally develop a hypothesis before they actually start. I think both perspectives are appropriate for their task. A developer's job is to produce software, so active development directly supports the production of working software. A tester's job is to inspect software, rather than produce it. The tester wants to formulate a strategy first to avoid random "hacking" testing that is undisciplined and immature. There is conflict if you try to force the developer to spend too much energy and time before they get to write code and not allow the tester enough time and thought about how they would test a system.

So, I think the approach I am outlining allows both developer and testers to work together without getting in each other's way. The "weaving effect" is just enough collaboration to provide a benefit without trying to force one to emulate the other's job.

Another benefit is that it provides an iterative and flexible environment for testing. The testers are integral members of the process, and with each iteration they have a more functioning system that they can test and revise their approaches with. I would hope this increases quality and the efficiency of the software and team.

At this point I am starting to babble and it is getting late. I have lots more ideas in my head, such as pair debugging (something I have done with testers), but I want to get feedback. I have already discussed some of these ideas with others. There seems to be enough merit to continue the discussion, though I don't know how much.

Lean Development Toolkit

I went to Mary Poppendieck's tutorial on the Lean Development Toolkit. The following is a sampling of ideas that were most important to me:

An organization's ability to embrace change and deliver fast is a competitive advantage. I see this as a core motivation of agile development.

Software is a development activity, not a production activity. Production activities don't benefit from iterative activities, for example, where as development does.

A resource that isn't 100% utilized is not waste. This is a common misconception. For example, consider a piece of machinery. It may operate optimally at 80%; anything higher can cause burn out. You wouldn't want 100% server utilization. So, don't try to use human resources 100%.

Cost of Delay: On Time Commercialization: Explores a P&L statement that assesses the cost of delay in software. The model is an estimate and intended to serve as a guide for making trade-offs. It is formed with the help of a cost accountant and not intended to be an accurate.

The GE Workout: Don't tell people what to do, ask them. Change the culture: speed, simplicity and self confidence

You cannot repeatedly deliver quality, in a timely manner, without discipline. (I include this because during an open space discussion last night someone tried to argue you don't need discipline to do XP well)

I don't think all development teams should always try to go faster. I think they should always try to improve, but this doesn't always imply speed. I am responding to an attitude I see prevalent in the agile, particularly XP, community, where speed is worshipped. It isn't that I think speed is bad, but too much of an emphasis on speed can limit your thinking. It may be easier to explain my concern with an analogy.

I frequently compare fitness and dieting to agile development, particularly transitions to agile development. If you have been lethargic for a long time, your goal may be to look like someone on a magazine cover, but this won't happen overnight. More importantly, you shouldn't try. Extreme dieting and massive exercise will place too much stress on your body. You shouldn't try to go too fast too soon.

In both the fitness and agile development scenarios, I think it is important to outline your expectations. Perhaps the development time cycle isn't as much a problem as the defect rate. Focus on techniques that improve code quality rather than speed to meet those expectations. Even if speed is a goal, your team's velocity is probably not going to improve ten fold after iteration 0. I think too many fledgling adopters of agile development underestimate the struggles they will encounter. (I think the basis for this, as with fitness, is that most people don't want to admit how bad shape they are in.) An experienced coach, for example, will address this, but I don't think the literature about agile processes addresses this well.

So far, I have only noted why it is okay to not to focus on, or expect, speed in early stages. What about mature agile teams? Returning to the fitness metaphor, many people discover that they are comfortable not looking like the magazine cover model. They realize the cost doesn't justify the benefit; they like eating Twinkies. Similarly, the agile team may have certain cultural, contextual and organizational factors that limit their speed. In certain circumstances, it is more important to maintain these constraints and accept the limits they impose so long as the organization adjusts their expectations to accommodate these limitations. Acceptance and contentment are necessary for happiness.

Mary Poppendieck talks about delivery speed and competitive advantage. The core idea is response time; this doesn't imply that increased programming velocity will result in better response time. It ignores all the other factors that go into shipping a software product. These factors, since ignored, are at a higher risk for being the bottleneck than programming speed.

I have seen many martial artists, who may not look fit and can't run very fast, but whose reaction times seem inhuman. They are flexible and responsive; they are agile in the truest sense. I think agile teams and organizations should learn from this example and look for all the ways that response time can be shortened.

I don't think speed is a bad thing. Its just important to think about how you define speed and what motivations and pressures drive your search for speed.

Yesterday, during an open space discussion about introducing agile development to an organization, questions were raised about what is the role of product managers and project managers in an agile process. Most agreed that this isn't addressed in the literature (at least to the group's knowledge of the higher profile writings) and it is one of the examples of why you need experienced help when beginning the transition to agile development. There are a lot of activities and roles present in real, working situations that are ignored in the literature.

Project managers are addressed somewhat in discussions of Scrum, for example. But I have read very little about the role of the product manager. Though many agile processes shy away from over specifying of roles (which I agree with), there is little guidance about the supporting activites these roles play. My concern, is that a naive or literal adoption of the processes outlined in the literature drops a lot of necessary work on the floor.

For example, a product manager typically collaborates with marketing to discuss schedules, the creation of marketing collateral, and launch plans. Many may argue these are outside the scope of development activities, that they are business activities, and not central to an agile process. What about product documentation? It isn't written by developers, but requires intimate knowledge of the product being developed. What about testing? There is a lot written about automated unit testsing and a little less about automated customer acceptance tests, but this is only part of the testing landscape, as I learned at Agile Fusion last week.

One idea I have that is half baked (as is this entry) is that if agile processes tried to address all the elements that necessary to ship a commercial product, for example, the result would resemble the Rational Unified Process. This would bring us back to where we are trying to get away from. I think the real value of all agile processes is a pragmatism that encourages flexibility and adjustments, rather than prescriptions and ceremony. Ken Schwaber, when talking about Scrum, highlights the feedback that is provided by Scrum (and other agile processes) to guide you to your destination. In an agile process, you know the goals (destination) but you don't know the road you will take to get there at the start. This is better than mapping out the entire journey in advance only to find a bridge along the way has been washed out.

So, I am left with the following desire or challenge. I would like to see some of these issues discussed or addressed, in the same fashion as processes such as programming has been addressed. I want guidelines, tools, mechanisms, heuristics, frameworks, techniques or advice related to issues like testing, product docunmentation, marketing, and all the other elements of software development that aren't directly related to programming, but necessary to ship product. In all the conferences and events I go to, these issues are frequently raised by those considering agile development. It seems like the literature ignrores or hides from these issues. When confronted, an agile advocate typically responds with some comment about "Well in real practice..." or "Oh yeah, you do..." which addresses the practical necessity of these issues. So, why is such a pragmatic philosophy hiding from such practical issues?

I have a lot of random ideas that spark my interest. Some of these are worth formulating and exploring; other are nothing more than a mental soundbite. I am trying to capture and record them, in the hope that I may either one day explore them or, in the process of writing about them, realize they aren't worth much attention.

I am at the first Agile Software Development Conference this week. I am excited because I am really interested in agile development and I will be presenting a paper on remote agile development, a topic of particular interest to me (more on this in a future posting).

I am hoping to record and reflect as I attend the conference, so I apologize if these postings are a bit rough.

Agile Contracts

I started the morning with Agile Contracts, a workshop held by Mary Poppendieck and Christine Moore.

Keynote

Jerry Weinberg gave the keynote. He talked about what it takes to be a good professional.

Open Space

• How to be champion agile processes for the non technician
• Can agile remote development work for legacy code?

Agile Contracts

I started the morning with Agile Contracts, a workshop held by Mary Poppendieck and Christine Moore. It was a good workshop and the following is a summary of what

Different goals for the Contract

• protect against possible opportunistic behavior of the other party
• promote mutual benefit from the project

This was best demonstrated by a prisoner dilemma simulation. (For those not familiar with the prisoner dilemma, it is a sample problem in game theory. Search the net for more info.) In our exercise, some groups defected, while others cooperated, then a repeat game resulted in all defections. The take away lesson is that the defections represent a risk mitigation strategy to protect you from the opportunistic behavior of the other party. A contract based on this principle can signify a bad start to a relationship, as both sides are anticipating the need for protection mechanisms against the other right from the onset; it stages an adversarial relationship. (A comment made several times was that if you find your team referring back to the contract, it is smell of dysfunction and potential problems.)

The alternative is to formulate a contract who mechanisms seek to promote mutual benefit. The complication, as I see made evident by the prisoner's dilemma, is that people tend to gravitate to the risk coverage strategy and anticipate lowest cost rather than maximum gain.

We then discussed various types of contracts, mechanisms for negotiating and related experiences. For more info please see the website.

Keynote

Jerry Weinberg gave the keynote. He talked about what it takes to be a good professional. He remarked that most people look at the "self" perspective, but ignore the "context" perspective and "others" perspective.

Context

Observation

Jerry remarked how it is hard to for managers to observe how people are being effective in an agile process and this can make them uncomfortable. He noted an anecdote where a manager expressed that in an agile environment, with elements like pair programming, the lack of code ownership makes it hard to know who to blame. Jerry's response was a seemingly rhetorical question: Which would you rather have, a process that works but you don't know who to give the credit to or one that doesn't work but you know who to blame? The manager responded that he would prefer the one that doesn't work, but he knew who to blame. (The manager, who had so many failed software experiences, expected more failure and therefore wanted accountability.)

Service

We generally don't get paid to develop software for ourselves, but rather software that someone else will use. We are providing a service.

Self

Work Habits

Reflect on your work habits.

Learning

Try to make sure you learn something new everyday. Always try to improve.

Self Care

Make sure to get rest and play.

Attitude

Are your fearless? Committed? What is your attitude toward your work?

Others

Communication

Obviously (hopefully), real important.

Credit

Share the credit.

Open Space

How to be champion agile processes for the non technician

There was a lot of ideas, but the discussion seemed to center on a couple of key points:

• it helps (is necessary) to have experienced members (coaches, consultants) in a transition to agile development.

Can agile remote development work for legacy code?

There was a lot of experience stories and discussion. A few of the basic ideas were:

• pure virtual development, where there has never been face to face interaction at some point, doesn't work
• multiple forms of remote development
  • core is co-located, few remote developers
  • multiple, distinct distributed teams that each are co-located
  • complete distributed development where all members are remote

The convener of the discussion described his current context, which has four separate offices (the result of mergers and acquisitions), with some coupling and dependencies between offices, lots of legacy code and distributed management: project management in one place, senior technical executives in another.

My opinion is that he has three separate problems, with possibly related solutions:

• how do we introduce agile development into this organization
• how do we deal with legacy code
• how do handle remote development

My opinion is that the real problems lie with the organization, whether or not its ready for agile development and the legacy code. These issues would be a problem if all the teams were located in the same building. This is part of a bigger idea that I tend to rant on: that a remote configuration can be implemented rather easily; the real problems are independent of the remote configuration and are related to the normal dysfunctions groups face. I will talk more about this in a later posting, as it is part of my experience report on Saturday that I am presenting.

So I have finally done it. I have started my very own blog. I have been intending to keep a journal for some time now. It was just one of those things that I hadn't got around to doing. Andy Tinkham convinced me it was about time, though it didn't take much convincing.

So why did I want to keep a journal anyway? There are a few reasons, though I mostly want to capture my musings, ramblings, and thoughts. I hope that the act of writing will force me to focus my thoughts and develop a coherent voice. I need to learn to be a little more stingy with words; I tend to be a bit verbose.

On the practical side, I am a software developer and coach who has a lot of ideas about development processes, team dynamics and the various technologies we use. I hope to capture and refine these thoughts. Also, I frequently make references to books, sites, and tools to others that I work with. I would like to provide a listing of for these references and reviews. I also work on a variety of open source projects (like NUnit) and would like to discuss them.

I also love to cook and watch movies. You will probably find a lot of ramblings about both.

Finally, if by some miracle someone else reads this, I hope to get feedback from people regarding my ideas and their related experiences.

What can you Expect to Find Here?

• thoughts on software development
• reviews of books, tools, technologies, movies and restaurants
• conference and workshop reflections
• open source projects
• article drafts
• recipes
• random thoughts