RULE II: START WHERE THE SYSTEM IS¹

Nate smiled and wistfully said: “Well, I’m the project manager and ScrumMaster. John will be the Product Owner. He works in our North East office. He should be able to represent the user community. He used to work in it. The tech lead and development team work in Europe.” Pausing he continued, “From what I’ve read, the Pundits suggest we’re doing almost everything wrong. But it’s the reality I’m forced to deal with.”

“So Nate, what do you know about the Agile Manifesto?” I asked. “Oh, the ‘We value Individuals and interactions over processes and tools’ stuff?” Nate replied. “Absolutely, but have you ever clicked on the twelve principals link? No? Let’s take a look at them and see what might apply and help you with your project.”

Like me, the clients I work with want to improve their effectiveness. When I visit clients I’m aware that with respect to their system, I’m both spatially and temporally blind.² I don’t know what has happened with the people and organization prior to my arrival (temporal blindness). The information I do gather usually represents at most a handful of viewpoints on what’s happening (spatial blindness).

Is a radical new start, a revolution the best way to achieve effectiveness? Or would changing just a little now, some more soon, evolving toward the final goal be a better approach? The best answer I have today is, “It all depends.” Nate works in a multinational conglomerate. Revolution will be stomped out faster than the speed of light. But evolution, starting where they are, inspecting and adapting has a chance to work.

We spent the next day and a half working through the twelve principles and how Nate could implement them in his project.

• We started reworking the software architecture list into user stories.
• We talked about Done, Done, Done. We reviewed the various types of testing and how/when to do them.
• Nate planned to have two week sprints. In addition to this, he’s now planning to have an automatic push to the test environment after every sprint.
• Potential system users will interaction with the code in the test environment and provide feedback to the product owner.
• We discussed metrics for the sprints and how he could use velocity to gauge project progress for the releases.
• How to conduct the five Scrum ceremonies.

In the end, the major hurdle remains the team’s distributed nature. Otherwise, Nate’s project embraces the agile principles.

As I was leaving Nate said, “Yes, I know it’s not ideal agile. But it’s where we are. In time, we hope to build on our successes and eventually change how IT projects get identified, defined and funded.”

The flame flickers and light shines.

What’s your experience? Revolution or evolution? Send me an email.

¹Herbert Shepard, Rules of Thumb for Change Agents, 1974 http://www.nickheap.co.uk/articles.asp?art_id=257

I was flipping through an old work note book and came across the following story.

I spent three days working with a client who had adopted Scrum for project management about six months earlier. On the fourth day I attended a Sprint planning two (user stories to task with time estimates) meeting. As we talked about stories and sizes, George asked the following question. “How do we deal with work that is too big to finish in a sprint?” In all my time coaching teams, I haven’t found a user story so large that it couldn’t be done in a sprint. If there is such a story, it usually an epic that can be further divided into smaller stories.

Wanting to be helpful I said, “Well, split the story into smaller stories.” Mentally allowing that I haven’t seen all the possible user stories in the world (and there /MIGHT/ be one story so large it couldn’t be finished in a sprint, I continued … “If that doesn’t work, pull the work into the sprint and burn down as much as possible. You don’t get velocity points, but if the backlog is properly ordered you’ll have work done for the start of the next sprint.” Hoping to point to some future perfect day where the team was burning down faster than anticipated I added, “It’s just like when the sprint burns down faster than estimated. You pick the next story from the Product Backlog and start work on it.”

George replied “We’d never do that. We get graded on how well we complete our stories. If we have unfinished work it counts against us.”

The Fundamental Software Development Process

The fundamental software development process looks like:

This system dynamics drawing² varies somewhat from the Diagram of Effects (aka Causal Loop Diagram) I often use by showing the stocks (levels) and flows (rates) associated with the development process. User stories flow into the Product Backlog. The team converts the user stories into Implemented Features at some rate (Velocity). By and large it’s how everyone develops software. Steps may have different names and take more time to complete (or not) but we take what user’s want and give them software that performs those actions.

An important aspect of the Fundamental Software Development Process involves recognizing it’s an open loop system and open loop systems are inherently stable. User stories come in as they will and become part of the Product Backlog. The team works at some natural development speed based on their abilities, the story complexity, and their intrinsic motivation. The Implemented Features accumulate and eventually the software gets released to the users. Based on the Product Backlog size (in story points) and the team’s velocity (in story points) it’s possible to calculate when the next releasable set of Implemented Features will be ready to go to the users.

But what if that date isn’t soon enough?

Add Some Feedback

The conversation with George happened my last day on site and I had meetings stacked the rest of the day. But on the flight home I started wondering, “Why would someone want to ‘grade’ the teams on how well they completed the stories?” One answer is to build confidence in team’s velocity value. Another possible explanation would be a behavioral assumption that the developers tend to avoid work and a way to make sure the developers don’t shirk is to compare the sprint results with the estimates made during the sprint planning.

Whatever the reason for “grading” the sprints, the action of “grading” has created a feedback loop in the system. Adding feedback means taking a system output and sending that output (or some portion there of) back into the system input. I wrote about feedback control loops in Multi-Use Model. Feedback loops provide the opportunity for control, aiming the system at some new target such as a new delivery date. Unfortunately feedback also provokes instability in the system. Unless great care is taken, the system becomes dysfunctional at best and destructive at worst. The Fundamental Development Process now looks like:

The “split” rectangle means management has a choice at this point. They can choose to “grade” sprint results or not. If the grading happens, the rest of the reinforcing loop happens. In a nutshell:

• Team members want to look good. I don’t know if “counts against us” includes performance evaluation, but it could.
• Since the team wants to look good, they’re not likely to take risks. Not taking risks could mean:
  1. Not bringing additional work if they finish early.
  2. Inflating story points for user stories during estimating sessions.
• Since the team won’t take risks, measured velocity won’t decrease (and indeed may increase) while actual velocity (the rate of delivering implemented features) may decrease. As Robert Austin notes:

Boomerang Measurement

I confess I’m doing a certain amount of mind reading now since I didn’t have a chance to talk with the person who decided grading the sprint results would be a “good thing”. But I can’t wrap my mind around the concept that they explicitly set out to slow the development process. But they did, we have another boomerang measurement.

Truth be told, I believe the person thought they were (are?) doing the best possible actions to help the developers be more efficient. I’m serious. You can’t make up stuff like this.

For more information on how management goes astray with measurements I recommend reading Measuring and Managing Performance in Organizations by Robert Austin and Slack, Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco.

Got an example of a boomerang measurement? Drop me a note.

¹I first heard this line from Jerry (Gerald M.) Weinberg
²http://en.wikipedia.org/wiki/System_dynamics
³Measuring and Managing Performance in Organizations Dorset House Publishing, ISBN 0-932633-36-6, page 38

I’m not going to say how long I’ve been around, but I have two copies of The Mythical Man-Month. I have the Anniversary Edition and the 1982 edition of the original 1975 book. I’m not sure why someone on Amazon is trying to sell the 1982 book for $ 129.95. The Anniversary edition contains four chapters not in the original edition including “No Silver Bullet”.

Brooks concludes “No Silver Bullet” with Promising Attacks on Conceptual Essence. His four major points are:

• Buy versus build.
• Requirements refinement and rapid prototyping.
• Incremental development – grow, not build software.
• Great designers.

Here’s what he as to say about these points.

Buy versus build

“The most radical possible solution for constructing software is not to construct it at all.” pg 197.

Requirements refinement and rapid prototyping

“… For the truth is, clients do not know what they want. They usually do not know what questions must be answered … Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteration between the client and designer as part of the system definition.” pg 199

Incremental development – grow, not build, software

“The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance and too complex to be built faultlessly, then we must take a radically different approach. … Some years ago Harlan Mills proposed that any software system should be grown by incremental development. … One always has, at ever stage in the process a working system. I find that teams can grow much more complex entities in four months than they can build“. pg 201

Great designers

“The central question of how to improve the software art centers, as it always has, on people. … Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge.” pg 202

Agilista or Not?

I find it interesting that Brooks originally published “No Silver Bullets” in 1986. That he nails the agile techniques of build only what you must, iterative and incremental design and delivery, and focus on people amazes me. In the next chapter “No Silver Bullet” Refired, he reviews many of the more serious comments and in the end concludes: “Net on Bullets – Position Unchanged.” pg 226

Such are the joys of 20/20 hindsight. So what do you think? Agilista? Forward thinker? I’m spending too much time reading meanings into what I’m re-reading? Drop me a note and let me know.

Reading Better People, Better Process may make it seem like I’m one of those touchy-feely “people over process” types. I confess I have a fondness for people but I’m also a big fan of process. Luckily, people and process don’t exist as either/or. People and process exist as both/and. Here’s a process that can both improve your other processes your people, and the process itself.

Another Multiuse Model

This model is another Multiuse Model. This process tells what to do in a retrospective. Retrospectives occur when we stop, think, and decide what to do next. We call a one person event “introspection”. A software development team may have a facilitator for their retrospective. Retrospective permutations abound. Here are the steps for a successful retrospective.

1. Set the stage – get focused
2. Gather data – create a picture of what happened
3. Generate insights – why? And what could be done differently?
4. Decide what to do – what one thing to do, and what is the first step?
5. Close – decide how to document and plan for follow-up.

You can learn more about this process by reading Agile Retrospectives. If you are a person who would like to go from good to great, and/or work in/with teams and/or organizations who you’d like to go from good to great, stop reading now and order the book. I’ll wait.

Back already? Wonderful.

So why do a retrospective? Retrospectives involve the Learning Loop. By continuously learning to improve our process, we can learn to improve ourselves. As we improve ourselves we can improve the retrospective process. A conscientious facilitator does a their own retrospective for every meeting they facilitate. George Dinwiddie and I facilitated a two day product owner release planning meeting. After each day we met to discuss what happened that day, what it might mean for the product owners (and us), what we could do to improve, and what changes we would make for the next meeting.

Hints and Suggestions – Three Possibilities

As a bright shiny new ScrumMaster, my retrospectives always included: “And what one thing would we like to work on to improve during the next sprint?” As I prepared for one retrospective, I thought, “Wow. All I ever do is ask what they’re doing wrong. What would happen if I asked about doing more of something they’re doing good?” Based on the what the Gather Data and Generate insight steps reveal I vary the question to focus on:

• Improve (change) something you’re currently doing. Based on their retrospective, one team decided they were making too many assumptions and needed to get the product owner’s input.
• Do more of something you’re doing well. One team noticed the developers were finishing the sprint in good shape while the testers struggled to complete the manual and automated tests. The team decided to have developers work with the testers earlier in the sprint to increase the teams over all velocity.
• Add something you’re not doing. I worked with one team that decided to schedule a meeting with the product owner mid-sprint to update the product owner with new information and verify the team had the spriint goal still in focus.

For the most variety ask the team to create possibilities for all three categories.

Only One Thing

Choose one change to work on. I’ve observed a some details over the years:

1. Teams generate many possible change items.
2. In a team of equals, some team members are more equal than others. This may be due to experience, longevity, or just plain loudness. I deal with this by giving each team member two votes and then call on team members for their votes making sure not to call on the “more equal” team member first. The item with the most votes gets proposed for the “do this” for the next sprint.
3. Any change can create instability. Too many changes at once will push the system to instability and dilute the change impetus pretty much ensuring nothing really gets changed.

Buy In

The team needs to buy into the decision. I recommend using the team’s norm for group decision. I’ve seen the “Fist of Five”, “Roman Thumbs”, head nodding, and probably a couple I’ve forgotten. The point is to get everyone to agree with the decision. If the whole team doesn’t commit to make the change happen, it probably won’t happen.

Follow-up

Pay attention to the change during the sprint. If I don’t see evidence the team is working on the agreed change, I ask a question at the end of the daily meeting about how the team is doing with the change. During the “gather data” portion of the next retrospective I include a question about how the team feels they did on their change idea. Failing to follow up on the topic teaches the team that constant improvement isn’t important. All you get from then on is grand ideas and lip service.

The Unaimed Arrow Never Misses

If you’re the facilitator, structure the retrospective as neutrally as possible. This is easier said than done if you also serve as the team’s ScrumMaster. It’s critical for the team decide what change they’re going to attempt. Structuring the retrospective or guiding the conversation to your predetermined result will result in less commitment if not out right rejection from the team.

What’s Next?

The basic cycle is do, inspect, adapt. Doing starts the cycle. So do something. Then inspect, adapt, and repeat as necessary.

If you don’t have Agile Retrospectives I’d suggest you start by reading the book.

I’ll be leading a session at this year’s AYE Conference involving Introspection. The conference still has 8 openings.

I came across some new words reading Joe Little’s blog entry Two Cheer’s for the Nokia Test. In the post Joe says: “Why do I like it? I think it is a simple way to set some sort of lower boundary on Agile (Scrum) and it tends to make two problems more visible: Cowboy Agile on one side and Agilefall (aka Wagile) on the other side. Cowboy Agile is where you are doing stuff you are making up on the fly (mainly not doing things you personally don’t want to do). Agilefall is where you are doing Waterfall (or mostly waterfall) and calling it Agile (or Scrum).” This started me thinking about some curious things I’ve noticed when looking at job descriptions for ScrumMasters.

I suggest you can determine if someone is doing Wagile or Agilefall based on language. If you find command and control agile in the description, I propose you’ll find an organization interested in Wagile/Agilefall. I offer the following examples.
From a job posting on Dice.com
Responsibilities

• Keeping the project on time, using Microsoft project.
• Setting team status meetings, track milestones, drive project.
• Being responsible for driving the team and managing them to hit the projects time lines.
• Leading scrum meetings
• There will be 4 – 6 people on a team

This was the first example I noticed. It’s probably not the first one ever, but the mental models exposed grabbed my attention.

• Projects being kept on time using Microsoft Project?
• Drive the project?
• Driving the team to hit project time lines? (Does there seem to be a lot of driving going on?)

I was so amazed by this mashup of agile and command/control I didn’t have the presence of mind to apply for the position.

Posted on the Scrum development email list

We are looking for a highly motivated Technical Project Manager eager to participate in the web2.0 world of user generated content, new media, hosted services and widgets. The successful candidate will be responsible for driving technical project management initiatives.

Responsibilities

• Be comfortable acting in a Scrum Master role to facilitate the development process and ensure timely delivery of work products across a variety of product teams.
• Identify and remove roadblocks for teams; shield teams from external interferences; work with the Product Owner(s) to maximize ROI; work with the Product and Development teams to ensure goals and backlog items are addressed.
• Help ensure that technical projects are delivered on time by managing the project schedule, mitigating risks as they arise and escalating issues as appropriate.
• Formulate and work to define technical scope and objectives of the project.
• Communicate project status to management and stakeholders.
• Work with development and product teams to define project schedule and iterative deliverables.
• Manage client expectations for projects to ensure ownership and success.
• Assist in the development of project budgets, capital expenditures, requirements or other cost estimates related to a project.
• Report to management, clients and others on the status of project deliverables and milestones.
• Responsible for combining successful software development process experience with agility, effective collaboration, facilitation, leadership and coaching skills.
• Responsible for advising and coaching the development team to form empowered teams.
• Manage project schedules in Microsoft Project and simple spreadsheets for backlogs.

Qualifications include:

• 3+ years Project Management experience
• Ability to work on multiple projects at once
• Proficient in Agile Development and strong experience with Scrum Methodology.
• Qualified candidates should have experience in all aspects of software development life cycles, with an emphasis on Agile methodologies.
• Scrum master certification a plus (Desired)
• Formal project management training and/or certification preferred.
• Fluency with Project Management Tools.
• Strong, attentive listening skills with ability to work in a fast-paced environment.
• Proficiency in Microsoft Project, Excel, PowerPoint, Visio and Word required.
• Self-motivated, flexible and ability to multi-task and handle concurrent projects.
• Ability to influence and collaborate with all levels of technical and product business partners.
• Excellent interpersonal and communication (verbal and written) skills.
• The successful applicant will be a creative problem solver, a self motivator, posses a can do and attitude, positive mentoring skills and accomplishments, and demonstrate career building self improvement behaviors.

I considered not including the entire post (I did remove the company information) but felt to be fair I should include it all. Some parts of this don’t sound too bad. For example:

• Responsible for advising and coaching the development team to form empowered teams. Sounds reasonably agile oriented.

But most of the responsibilities sound command and control not agile. And what’s up with all this driving? “The successful candidate will be responsible for driving technical project management initiatives.”

About this time I started to wonder if it was me. When I read the responsibilities, they make sense. These items need to be handled by someone somewhere at some time during the project. But the way the responsibilities are worded to me indicate a non-agile mind set in spite of:

• Responsible for advising and coaching the development team to form empowered teams.
• Proficient in Agile Development and strong experience with Scrum Methodology.

I’d like to say these two examples are unique in the recruiting business. Unfortunately they’re not. You can find similar descriptions on just about any job board that caters to software development. I was going to quit with these examples, but I felt driven to find an example of cowboy agile. Alas, I didn’t have to drive very far.

Also from the Scrum development email list

[Some company] is looking for a Certified Scrum Master-Project Manager for a 2 month plus contract position for a client in [a city]. This project starts almost immediately and has a go-live date of June 1 [sic] with a project completion date of June 30. This would be our client’s first time using Scrum so some training and mentoring of the team will be needed. At the end of the project, an evaluation of how Scrum could continue to be used as well as recommended in the next steps would be required.

There are about 10 people on the team. Other than training and mentoring, this person will be expected to be the project manager. They don’t need to be a subject matter expert, just someone experienced in the Scrum methodologies of running a project. The training could just be a formal one-day training session at the beginning of the project and then just kind of on-going during the project.

Here the rules have changed. There are no rules. Am I the only person who wonders why a company with a time critical project (it goes live the day after scheduled completion) wants to shift to a new development method? And a lullaby word keeps being repeated.

• just someone experienced in the Scrum methodologies
• just be a formal one-day training session
• just kind of on-going during the project

If you didn’t read Lullaby Language I recommend doing so now.

Crossed Goals

I decided to learn more. Maybe if I could talk with someone I could understand better what they were looking for, so I replied to one of the above. I received a nice email from the person which said they’d have to talk with the account manager and get back with me, which they did. The reply was no more illuminating than the original post. After a couple emails back and forth I gave up. It seemed the recruiting company needed a body to fill a slot regardless of how it would affect the client’s outcome.

Truth in thinking:

1. It’s hazardous to generalize from a single data point.
2. These are my perceptions. I could be wrong.
3. Just because something doesn’t work for me, doesn’t mean it won’t work for someone else.

So, it is me? Or do others of you see agile being accepted as main stream verbiage while the main stream continues to do business as always? Let me know.

¹Tools For Critical Thinking, page 5

I’ve been reading some interesting emails concerning names in an Scrum environment. Backlog in particular seems to generate energy.

Several valid points for change have been made. Backlog felt negative to one team, and they wanted to use a positive term. Another participant mentioned that “backlog” was difficult to translate into his language. Yet another argued that Agile is more about what you DO, than what you name what you’re doing. I think these points have validity.

So what’s the problem?

Take a step back and ask, “What is the purpose of language?” What did you come up with?

For me, the purpose of language is to get the thoughts out of your head into my head, and vice versa. This has several benefits:

1. We can learn from each other’s experiences.
2. We can share (and help create) knowledge.
3. We can co-create a co-reality.

What it Looks Like

We interact with the real world, and through the processes of abstracting (extracting sensory data) and abstraction (converting the sensory data in to words, thoughts, and feelings). Words (hopefully) represent some object in the real world. When we interact with another person, it looks like:

Communicaton Model

The explanation is contained in Getting to Language.

The Problem Arises

As Kelly Waters points out when you choose to use different words, translation trouble occurs. George Dinwiddie and I recently had a discussion about a Scrum Project. Since we share a common Scrum vocabulary, we discussed the project owner, product backlog and sprints with no explanations. We didn’t have to say “OK, by product owner, I mean the person who ….”.

What NOT to Do!

• I doubt I’d whip out the diagram. If pushed for why common words are important, I’d use the Satir Interaction Model
• I wouldn’t say they’re wrong. If we argue, the team will become more entreched. And I don’t believe the team is wrong.
• I would avoid discussions about “The One True Way”. Agile (and Scrum) are about providing working software and business value. I’d prefer to use the same words other teams use (especially if they mean the same), but that’s not the major goal.

So What to Do?

To resolve the “backlog” seems negative to the team issue and keep the same word for “backlog” (which is of course “backlog”), I’d try the following:

• Acknowledge the feeling that “backlog” seems negative. It’s how the team (or some portion of the team) feels.
• Explore with the team WHY they think “backlog” is something negative. Are all backlogs negative? Is it possible for some backlogs to be positive? Could it be that backlog is both positive and negative?
• Based on the exploration, I’d try to get an experiment approved where we used “backlog” for a set number of sprints, and then revisit the issue. This is the “Trial Run” Pattern from Fearless Change.

I suspect that after three sprints, the concern about “backlog” being negative will disappear being replaced by other concerns about delivering business value via working software.

At the bottom of the third rapid, there were three paddlers on the shore in various stages of “where’s my gear?” Everyone was safe, and with a little time, we found all the gear. The river widened, the rocks got further apart, and everyone made it to the take out.

As I thought about the experience, the parallels to software projects struck me.

• Some people had more skills than the others.
• We could see the start, but didn’t know all the problems we’d find along the way.
• Everyone on the team knew how to take care of themselves.
• When someone got in trouble, other people would help out.
• We moved as a group, although different people lead at different times.
• We all got to the finish.

In regard to “March 17, 2005 Blog Entry — Can Developers Test Software?” For me, your observations go back to the dynamic between verification and validation.

Verification

In my experience the developers have the verification mindset, “Does it do the job?” Most everyone who uses the software has the mindset, “Does it allow me to do my job?” And that is the essential difference. The job or requirements are dependent on what pair of glasses one wears. Developer, project manager, line manager, procurement official, program manager, and user all have different ideas about the software.

Validation

I hold the opinion that “doing the right job”, or validation, is much more important than “doing the job right”, or verification. Validation ultimately includes verification, but not the other way around. Unfortunately verification seems to be the tail that wags the dog, at least in government procurements and way too often in commercial procurements.

To me it seems that software craftsmen are not the only ones who do not look to the user. Jerry Weinberg in his QSM Vol 4, “Anticipating Change” quotes Witold Rybczynski:

“What did ‘getting it right’ mean in practice? To the classically trained architect it meant, first of all, pleasing the client or, in a broader sense, the user of the building (not always the same person). This unassuming, and to most persons obvious, requirement needs emphasizing in a period when architectural design has become a self-expressive pastime. The great Chef Carême said, ‘In matters of cookery there are not a number of principles, there is only one and that is to satisfy the person you are serving.’ If I were to quote his advice to my students, they would find it a hopelessly old-fashioned and intolerable imposition.”

Your comment, “A quick review of the most project dynamics indicates that everything can slip as far as delivery except the final ship date.” is only the beginning. I usually see final ship dates turn into the first of many unplanned ship dates, which begs the old question, “Why do we have time to do it over, but never the time to do it right the first time?”

Appreciations

I appreciate Charles for taking the time to read and respond!

It Only Makes Sense

After all, developers have always done some testing.

• Does the code compile?
• Does the project still build?
• Does the new code do what it should?

Great! What’s next on the list of things to do?

Agile methods promote test driven development. The testing plan gets written before the code does. Management is simply proposing the logical result. Fire the testers since the developers are now doing the testing! But does this really make sense?

You Mean There’s More To Testing?

Yes, Virginia, there’s more to testing. I’m a developer, not a tester. I know only a little bit about testing, but I DO know that testing methodologies move just about as fast as development methodologies do. It’s no longer just about white boxes and black boxes. Check out Quardev and Satisfice for some great ideas in testing. Developers are lucky if they have the resources (time and training) to stay current with new development concepts. What are the odds management will think to include resources for learning how to test?

The View From Over Here

Another point to consider: Developers and testers have different local and global view points. The goal of development is to create and prove software works. Testing tries to discover those conditions where the software doesn’t work. Two very different ways of looking at the software. Shannon Severance does both developing and testing, but never on the same project. Once you get a particular view point on a piece of software, it’s hard to switch to another viewpoint. The difference in view points leads to better software.

Slip Sliding Away

Given that developers like to develop, not test, how does having developers do testing impact testing time? A quick review of the most project dynamics indicates that everthing can slip as far as delivery except the final ship date. Software development requires discovering what features should be coded, figuring out how to code them, coding them, testing the code and delivering the software. Testing time gets compressed in most projects to the time left (if any) after the major development is completed and the scheduled delivery date. With developers doing the testing, time (if any) will naturally shift to development to squeeze in “one more feature.” After all, “I’ve been testing as I go along.”

A Tester, By Any Other Name

Any significant software project involves multiple development teams. Who tests the overall results? Designate a developer to handle this release’s integration testing? Doesn’t that make them a defacto tester? And an unhappy one at that. Developers don’t have the mindset, training, and knowledge to do a good testing job. Why force this on them? Good software needs multiple viewpoints (after all, pair programming is basically instantaneous code reviews). Why not get the view point of some one who wants to do the job?

Let’s Think About This Some More

Firing the testers and using developers to test is a Siren’s song. Do it long enough, and you’ll hear sirens again as the software crashes and burns on your former customers’ computers.