Agile in a Flash

Test Abstraction Smells

2011-11-30T12:17:00.072-06:00

In our article Test Abstraction: Eight Techniques to Improve Your Tests (published by PragPub), we whittled down a convoluted, messy test into a few concise and expressive test methods, using this set of smells as a guide. We improved the abstraction of this messy test by emphasizing its key parts and de-emphasizing its irrelevant details.

Stripped down, the "goodness" of a test is largely a matter of how quickly these questions can be answered:

What's the point of this test?
Why is the assertion expecting this particular answer?
Why did this test just fail?

That's a nice short-form summary, but it is descriptive rather than prescriptive. In the Pragmatic Bookshelf article, a real-world code example was used to painstakingly demonstrate the techniques used to improve the clarity of tests by increasing their level of abstraction. Here we provide the "cheat sheet" version:

Unnecessary test code. Eliminate test constructs that clutter the flow of your tests without imparting relevant meaning. Most of the time, "not null" assertions are extraneous. Similarly, eliminate try/catch blocks from your tests (in all but negative-case tests themselves).
Missing abstractions. Are you exposing several lines of implementation detail to express test set-up (or verification) that represents a single concept? Think in terms of reading a test: "Ok, it's adding a new student to the system. Fine. Then it's creating an empty list, and then adding A to that list, then B, and ..., and then that list is then used to compare against the expected grades for the student." The list construction is ugly exposed detail. Reconstruct the code so that your reader, in one glance, can digest a single line that says "ensure the student's expected grades are A, A, B, B, and C."
Irrelevant data. "Say, why does that test pass the value '2' to the SUT? It looks like they pass in a session object, too... does it require that or not?" Every piece of data shown in the test that bears no weight on its outcome is clutter that your reader must wade through and inspect. "Is that value of '2' the reason we get output of '42'?" Well, no, it's not. Take it out, hide it, make it more abstract! (For example, we'll at times use constant names like ARBITRARY_CHARGE_AMOUNT.)
Bloated construction. It may take a bit of setup to get your SUT in the state needed for the test to run, but if it's not relevant to core test understanding, move the clutter out. Excessive setup is a design smell, showing that the code being tested needs rework. Don't cope with the problem by leaving extensive setup in your test, but tackle the problem by reworking the code as soon as you have reasonable test coverage. Of course, the problem of untestable code is largely eliminated through the use of TDD.
Irrelevant details. Is every step of the test really needed? For example, suppose your operational system requires the presence of a global session object, pre-populated with a few things. You may find that you can't even execute your unit test without having it similarly populate the session object. For most tests, however, the details of populating the session object have nothing to do with the goal of the test. There are usually better ways to design the code unit, and if you can't change your design to use one of those ways, you should at least bury the irrelevant details.
Multiple assertions. A well-abstracted unit test represents one case: "If I do this stuff, I observe that behavior." Combining several cases muddies the abstraction--which setup/execution concepts are relevant to which resulting behaviors? Which assertion represents the goal of the test case? Most tests with multiple assertions are ripe for splitting into multiple tests. Where it makes sense to keep multiple assertions in a single test, can you at least abstract its multiple assertions into a single helper method?
Misleading organization. You can easily organize tests using AAA (Arrange-Act-Assert). Remember that once green, we re-read any given test (as a document of SUT behavior) only infrequently--either when the test unexpectedly fails or when changes need to be made. Being able to clearly separate the initial state (Arrange) from the activity being tested (Act) from the expected result (Assert) will speed the future reader (perhaps yourself in 5 months) on his way. When setup, actions, and assertions are mixed, the test will require more careful study. Spare your team members the chore of repeatedly deciphering your tests down the road--spend the time now to make them clear and obvious.
Implicit meaning. It's not all just getting rid of stuff; abstraction requires amplifying essential test elements. Imagine a test that says "apply a fine of 30 cents on a book checked out December 7 and returned December 31." Why those dates? Why that amount? If we challenged you to tell us the rules that govern the outcome of this test, you'd likely get them wrong. A meaningful test would need to describe, in one manner or another, these relevant concepts and elements:
- books are normally checked out for 21 days
- Christmas--a date in the 21-day span following December 7--is a grace day (i.e. no fines are assessed)
- The due date is thus December 29
- December 31 is two days past the due date
- Books are fined 20 cents for the first day late and 10 cents for each additional day.
- 30c = 20c + 10c
(Consider that each of these concepts could represent a separate unit test case, and that this detailed scenario represents more of an end-to-end test case.)
A unit test that requires you to dig through code to discern the reasons for its outcome is wasteful.

You could easily survive without our list of test abstraction smells--and figure out on your own what to do about your tests--as long as you keep one thought in your head: "My goal is to ensure that each unit test clearly expresses its intent, and nothing else, to the next person who must understand this system behavior."

The 4 Ts of Engaging Management

2011-11-22T09:24:00.002-06:00

Teams self-organize and self-direct, so much of the Taylorist views of what a manager can do seem to not apply at all. What is the working arrangement between an agile team and their manager?

Time (schedule) - As a steward of the schedule, a manager needs to know where the teams' effort stands--are they behind or ahead the expected schedule? Does the release need to be delayed or de-scoped? The manager is best positioned to communicate issues and evaluate the larger impact to the organization. When the schedule needs change, we find that your chance of success is greater the earlier the matter is communicated to management. While human nature may lead one to avoid delivering bad news, it is usually better to share problems with people who are in a position to help.
Talent (talent pool) - A manager may bring in additional talent in the form of trainers, consultants, staff augmentation contractors, or new employees. Sometimes having an eLearning course, a visiting expert, or a short-term consultant can make a huge long-term difference in the team's technical proficiency.
A manager may change hiring criteria to bring in the kinds of developers that will help the team to work in a more fluent and productive way.
Likewise, a manager can remove or reassign a team member who just isn't working for the current team. These kinds of issues require coordination with HR and possibly even legal representation, but are a good use of your manager's time. See also Robert Sutton's research on maintaining a productive workplace.
Target (direction, goals) - Agility (strictly defined) is the ability to change direction gracefully. Sometimes a change of technology or target audience can greatly improve a product's chance of being accepted in the market. Additionally, agile teams would rather face failures early when they're inexpensive (fail fast) than have hopeless projects run on until resources are exhausted. Any a significant change in direction, whether cost-saving or value-creating, will need to involve management.
Treasury (funding) - There are times that spending a few hundred or a few thousand dollars can make the difference between the team working fluidly versus struggling and slogging along. Is your biggest need for a distributed build product? A better build server? An alternative testing tool? A local version control server? More reliable intranet? A better library or framework? A minor hardware upgrade? An online training course?

When a problem can only be solved using one or more of the 4Ts, then it is clearly a management problem. Make use of your manager's sphere of influence to improve the team's chance of success.

Agile supports the empowered, competent team. The team should own their problems and push forward with solutions and data-based decision-making. On the other hand, a team can hardly be called "resourceful" when their management assets go unused. Remember that the manager is a member of the team, and often managers pride themselves on problem-solving.

For problems in the gray area where some solutions are purely technical, it may be wise to involve management in triage. You would be surprised how many times teams have struggled with a work-around only to find that a manager would have been happy to solve the problem outright through his contacts and resources.

In your next retrospective, consider adding solution category called "take it to management." See if it helps your velocity over time.

Management Theater

2011-10-12T22:42:00.000-05:00

Great managers can improve teams in meaningful ways: smoothing the workflow, selecting targets worth hitting, wisely managing budget and schedule, and working to align teams with organizational goals. We have fond memories of great managers, technical or otherwise, who led and mentored us, who helped us reach new plateaus of understanding and productivity.

We're not talking about those great managers today.

Instead, we'll discuss a particular form of management dysfunction often seen in development shops. Daniel Pink (in Drive) points out that programming shops are full of people who are motivated by the work and excited to make progress. Intrinsic motivation tends to be quite high, though exceptions exist (see Esther Derby's Stop Demotivating Me). Most shops face problems with procedure, organization, technological limits, overly ambitious schedules, and shortage of knowledge or practice. Less astute managers don't understand the problems in their teams, and misinterpret these as motivational issues. When the problem is technical, it does not help to attempt solving it through motivation.

You've probably been a witness to most of these. Just in case they're not obvious:

Begging: "Please, I just really need you to work harder to get this done. Just this one time."
Browbeating: "Stop your whining and get it done before I replace you with someone who gives a darn about their job!"
Cheerleading: "I have faith in you, you're the best! Go Team!"
Punative Reporting: "I want to see daily status reports! Twice daily!"
Publicity Stunts: "I want every last one of us in this meeting. We need a show of force!"

Such motivational tactics tend to be ineffective. To people struggling with difficult organizational and/or technical problems, emotional appeals seem to be a kind of buffoonery. Of course, if the team succeeds despite the management theater, it merely strengthens the causal connection in the manager's mind. By simply not failing, the team locks their manager into a pattern that ensures that all future crises will be met with emotional and ineffective responses.

We should not be asking how to make managers behave. We should be asking what a team can do to ensure that a manager can provide effective servant leadership. Management theater is not a manager's first choice of action, but rather a tactic of last resource. When a manager does not have sufficient information or timely opportunity to be effective, she must use whatever ethical means remain. Management theater is, therefore, primarily a process smell not of management but of the development team.

Worldwide shortage

2011-10-03T16:51:00.002-05:00

I'm told that there are shortages of AgileInAFlash, some channels having projected waits of as much as two months for replenishment.

You can still get AgileInAFlash physical decks at the Pragmatic Programmers site, and you can also pick up electronic copies there to tide you over. The electronic version is not as handy in mentoring settings, but is fine for reading or projecting.

Second Printing

2011-09-16T19:22:00.001-05:00

Thanks to the demand of our readers, Agile In A Flash is going to its second printing only 8 months after its initial release. Thanks to all of you!

Mobile Version

2011-06-10T07:23:00.002-05:00

Thanks to our hosts at blogger.com, we now have a mobile version, so accessing Agile In A Flash from your mobile device is finally easy and even pleasant.

Doctor Dan's Prescription

2011-05-29T21:07:00.002-05:00

Dr Dan's Prescription: An Agile Flashcard a Day keeps the Fail away...

This photo of card #33 was received via twitter from Daniel Thomas (@geekdan) in Brisbane, Australia, complete with the quote above.

I like how they have a low-tech "frame" for the cards, and a place of honor on the team whiteboard. I hope they get some help, humor, or inspiration from the deck.

Dan tweets a lot of interesting links. Give him a follow.

A Card-Enriched Workspace

2011-05-25T11:28:00.001-05:00

Friend of the blog Brian Kelly offers us a glimpse of his workspace. I notice that the books on organizational change are above the card on overcoming organizational obstinance, and that the rest are values and practices cards.

The new website-only card, Five Rules for Distributed Teams, is shown on the monitor. It was released coincidentally with Lisa Crispin and Nanda Lankalapalli's StickyMinds article on Tele-teams. I guess the distributed team meme is in the air.

Brian is the fellow who has been posting the excellent near-daily meditations on the 52 cards of the official Agile In A Flash deck released by Pragmatic Programmers in late January of this year.

We are very proud, indeed.

Rules for Distributed Teams

2011-05-24T15:14:00.001-05:00

As the Greatest Agile-In-A-Flash Card Wielding Coaches So Far^(tm), we're often asked for advice (or drawn into arguments) about how to make agile work with distributed teams. Sometimes it's for more humble reasons, though: We've both been remote members of a team, pair-programming with peers daily. We prescribe the following rules for distributed development:

Don't. Traditional organizations should avoid the extra strain, trouble, and expense of remote members without a significant reason. For example, building a better team using remote rockstars might provide some justification, but you might also be better off with a capable, local team that works well together. It's often out of your control, though, and in the hands of a really big boss, bean counter, or entrenched culture. You can make it work: Virtual organizations, startups, and the like find great success using virtual tools, pairing, and non-traditional communication pathways. Make sure you really mean it, because it's not a trouble-free add-on to the way your large organization does things now.
Don't treat remotes as if they were local. Treat your "satellite" developers as competent people with physical limitations. A remote is visually impaired, since he can only see through a web cam, and only when it is on. He cannot see the kanban board, the other side of the camera, and so on. Likewise, he only hears what is said into the microphone and not at all if simultaneous conversations occur. A remote cannot cross the room and talk to people, so interoffice chat (Skype, Jabber, etc) is essential. The local team has to make concessions, repeat conversations, and be the eyes and ears of the remote employees. Do not treat unequal things as equal--accept that there are compromises.
Don't treat locals as if they were remote. You certainly can install electronic kanban boards, online agile project management tools, instant messaging, cameras, email, and shared document management so that every local can sit alone in a cubicle or office and behave just like a remote employee. Rather than being empowered, you are all equally limited (see point #2). Never limit so that all are equal. Allow all to rise to greatness. The power of people working closely together in teams is significant (see first bullet above).
Latitude hurts, but longitude kills. Just being remote hurts (see first two bullets), but the complications can be overcome when employees share the same time zone and working hours. The further you move the team across time zones, the fewer common hours they have, and the longer any kind of communication takes to make a round-trip. Agile is predicated on short feedback loops, so 24-hour turn-around is out of the question. If you can't be a single team that works together, create separate agile teams.
Don't always be remote. Begin your engagement with a nice long on-site visit. A week is barely enough. Two weeks starts to make it work. Visiting for one week a quarter or even a week a month can keep a feeling of partnership alive. Dealing with difficulties is easy among people who know and respect each other. While constant telepresence (Skype, Twitter, IM, etc.) can minimize the problem of "out-of-sight, out of mind," studies show that distributed team success requires teams with strong interpersonal relationships, built best on face-to-face interaction. The bean counters may not be able to comprehend it, but the investment is well worth the return.

Tim: Would I remote again? In fact, I do most of my Industrial Logic work remote. We are in constant touch with each other and pair frequently. I converse with Joshua Kerievsky more in the course of a week than I have any other "boss" (he'll hate that I used that word!) in my employment history. We even work across time zones. We would work more fluently and frequently side-by-side, but we'd probably not get to work together if we all had to relocate. It is a compromise that has surprisingly good return on investment for us. We also have the advantage that we are all mature agilists; it would be very hard for first-timers. It's hard for me, as I have a tendency to "go dark" sometimes.

Jeff: I enjoyed a year of remote development with a now-defunct company one time zone to the east. Pairing saved it for me. The ability to program daily in (virtually) close quarters with another sharp someone on the team helped me keep an essential connection with them. On the flip side, however, I never felt like I was a true part of that team. I missed out on key conversations away from the camera, and I felt that debating things over the phone was intensely ineffective. You do what you must, but I'd prefer to not be remote again.

Card-Carrying Agile Team

2011-03-22T10:18:00.002-05:00

Top row: Chris Freeman, George Sparks, Sudheer Pinna, Scott Splavec, Sreehari Mogallapalli, Matt Poush.
Bottom row: Toran Billups, Ryan Bergman, Andrea de Freitas, and Benoy John
Photographer: Vadim Suvorov

Say hello to the team from Sum Total. Back before acquisition, the company was known as GeoLearning, and Tim was one of the coaches to help with their transition to Agile methods. Later, while working on Agile In A Flash, Jeff and Tim were both employed as remote pair-programming team members. The team has done some remarkable things in just the past three years.

Vadim (an excellent developer, brilliant guy, friend) reminds me that he is present in this photo as a reflection in the eyes of all the developers who are standing in front of the camera. If this were a TV detective show, you could zoom in and see him clearly.

Card-Carrying Scrum Master

2011-03-22T09:56:00.001-05:00

Dion Nicolaas (not pictured) displays the Agile in a Flash cards on his desk in the TomTom headquarters in Amsterdam, the Netherlands. Showing a different card each day, he has inspired some colleagues to order their own decks!

Daily Meditations

2011-03-18T22:05:00.000-05:00

On twitter, follow "buildndeploy" (Brian Kelly) for a daily meditation on Agile In A Flash. Well, mostly daily. He has a day job, and we certainly forgive a missed day. Brian is going through a card a day (when possible) and providing an 140char summary of his thoughts. Follow along by card number (use this index, or your own deck) and see what buildndeploy has to say.

Brian is using our hashtag #agileinaflash, so it is easy to catch up with his prior reflections.

Getting Better (guest blog post)

2011-03-18T21:58:00.000-05:00

Today we have a short article from our guest blogger Johnno Nolan, who caught our attention in twitter when he said:

Great 2 hear the team talking soft dev. We go through an Agile in a Flash card every am and critique. Can feel devs caring again

Johnno Nolan's story is still in progress, but I felt that tweet was inspirational enough that I invited him to provide a short blog post, and he kindly submitted the following story.

I've worked here before. We developed with chaos. I left. They persuaded me to come back. They said it would be different. "We can do things a different way. Your way" they said. The chaos would be mine to tame. I accepted and returned.

The cold reality set in. The team was demotivated, resigned to the current system. Worse, we'd tried to implement 'Getting Better' before (I don't like to use the term Agile) but we'd lack courage and when the main change driver had gone, adoption fell by the wayside. There was mistrust, ignorance of doing things that way and then the team was asked to pick back up where they left off. So there's a been an open dialogue of what's been wrong and we've been focusing on the basics to 'Get Better'.

And we are.

I can look back a couple of months and we were not talking, not thinking, just accepting of the norm. Now we're learning together. Sometimes we have bad days, but today was a good one.

Before our stand-ups meetings we talk about one Agile In A Flash card. They say story cards are a placeholder for a conversation and that's exactly how we use them. We don't always agree with the card but we talk about it and try and understand. The cards provide a focal point.

Today was really productive, we finished more than we expected. We passed stories back because we didn't think they were good enough. We talked about design. We returned to the cards and talked more about process. For the first time in months we cared and we're proud of what we are doing.

We're not becoming Agile in a Flash but we're Getting Better Steadily.

Jeff and I are receiving several stories every week about how Agile In A Flash is helping teams re-engage with fundamentals. We'll be entertaining other guest bloggers in the future, in addition to providing some fresh content every month.

Card-Carrying Network Weaver

2011-03-15T22:39:00.000-05:00

A welcome to Patrick Wilson-Welsh, seen enjoying his new deck of Agile In A Flash cards at the Agile And Beyond gathering in Dearborn, Michigan, where I dare say we had the most interesting table full of people in the entire room. Patrick really wanted these cards. Let us know how they're working out for you!

Card-carrying Agile Tester

2011-03-10T14:24:00.002-06:00

This is Lisa Crispin, brilliant Agile tester and author, trainer, and early adopter of Agile In A Flash. Here you see her sharing deep testing insights with Jo, Edgar and Chester.

No animals were harmed or insulted in the making of this blog post.

Agile On A Desk

2011-03-08T18:27:00.000-06:00

Dave Rooney, a card-carrying friend of Agile In A Flash, walked into a manager's office and what do you suppose he saw?

The astute observer will see all the cards are marked with either the compass rose ("The Plan" section) or else a waving pennant ("The Team" section). We intended those two sections to be especially interesting and useful for managers.

It does our hearts good to see Agile In A Flash in use. Your encouragement is always welcome here, in pictures, comments, tweets, purchases, or referrals!

Card-carrying Professional Scrum Developer Trainer

2011-03-08T15:30:00.001-06:00

This is Andreas Ebbert-Karroum who is busy in Germany, leading codecentrics Agile Software Factory. He looks very happy to have his Agile In A Flash deck.

Card-carrying Team Effectiveness Amplifier

2011-03-08T14:45:00.003-06:00

Say hello to George Dinwiddie. George is a well-known and well-respected software development coach and consultant, software blogger, and a Card-carrying Team Effectiveness Amplifier, and a friend of the Agile In A Flash effort (not to mention the authors).

Can you feel how the warmth of his personality radiates from this picture? Yeah, he's like that in person.

Restoring The Trust

2011-03-01T14:31:00.000-06:00

Make sure you see Uncle Bob Martin's video Restoring The Trust, about the agile balance. A certain deck of cards is prominently featured (thanks, Bob!) in the opening and closing moments.

There are a few other cards relating to balance, but clearly the Manifesto card is very close to Bob's heart, as he is one of the original authors and signers of the both Craftsman and Agile manifestos.

Card-carrying Seer of System Dynamics

2011-03-01T13:53:00.000-06:00

(in dramatic Black & White, no less!)

This is Esther Derby, a management consultant and Agilist who is helping companies to put a more human face on software development. We highly recommend her conference talks and blog. Here Esther has a brand-new deck of "Agile in a Flash" and a happy smile.

What's On Your Wall?

2011-02-24T18:11:00.000-06:00

Tim describes how the Agile In A Flash cards help make his workspace more informative.

Agile in a Flash Card Index

2011-02-23T09:36:00.002-06:00

In order to keep Agile in a Flash very low cost and actually make a buck or two, Tim and I were pressured to keep the number of cards to a very minimum. That's why you'll see no author bios, for example, and no index / table of contents. (Of course, if the book takes off and you buy bajillions of copies, we can likely justify an index.)

Without further ado, here's the index of cards (which also tells you, by omission, which blog entries here are not in this deck--if, uh, all goes well with sales, we'll be doing a second deck):

The Idea:

Why Agile?
The Agile Values, aka the Agile Manifesto
Principles Behind the Agile Manifesto
Role-Playing in Agile
Agile Success Factors
Courage
Redefining Discipline
Pillars of Software Craftmanship
Toyota Production System (TPS) Principles
The Right Process
Got Organizational Obstinance?
Got Individual Obstinance
Don't Get Too Deep in Technical Debt

The Plan:

Incremental Everything
Embrace Change
Reach Consensus on Story Priority
INVEST in Your Stories
Categorize Requirements with FURPS
Sail on the Three C's
Shrink XL Stories to Fit
Acceptable Acceptance Tests
Acceptance Test Design Principles
Story Estimation Fundamentals
A Winning Hand for Planning Poker
Iterate with Principle
Communication-SMITH with Information Radiators

The Team:

Shu-Ha-Ri
The Only Agile Tools You'll Ever Need
Successful Stand-up Meetings
ABCs of Pair Programming
Retrospectives
When Not Pairing
How to Be a Team Player
Collective Code Ownership
Coding Standards
Is Your Team Circling the Drain?
Pair Programming Smells
Stop the Bad Test Death Spiral
How to Stay Valuable

The Code:

Eight Crucial Practices of Agile Programmers
Build Superior Systems with Simple Design
The Seven Code Virtues
ReallyMeaningful Names
The TDD Cycle
FIRST Properties of Unit Tests
Triple A for Tight Tests
Prevent Code Rot Through Refactoring
Refactoring Inhibitors
Field Guide to Mocks
Break Unit Test Writer's Block
Test Double Troubles
TDD Process Smells

How to use the deck

2011-02-22T12:43:00.002-06:00

People have been asking how to best use the cards in their teams.

We've had several notes via twitter or email about teams reading and discussing them at retrospectives or standup, and even using them in lightning talks at conferences. We are happy to see them used in this way.

But people have been asking how normal, individual, non-coach team members can use the cards. Jeff provides our recipe for use of Agile in a Flash:

Pick a card that's relevant and read its front
Read the back
Re-read the front to help ingrain the short list
Consider tacking the card up, so that it's in your face, helping you ingrain the concepts
Seek and re-read related cards to get a more complete picture of the topic
Visit the corresponding post here on the blog site if you seek more detail on the topic and why we said some of the things we did
Visit the links located on many of the cards and at the blog site if needed

Don't forget to google the subject matter, because there is more written than we could fit in either the deck or the blog. Other opinions and recommendations are equally valid.

Please share and discuss the cards with your community, starting with the local software team and its neighbors but extending to conferences, user groups, or any other willing listeners. New insights can come from anywhere.

Javaranch Event

2011-02-21T20:58:00.000-06:00

The Big Moose Saloon welcomes writing team Ottinger and Langr to a special event:

This week, we're delighted to have Jeff Langr & Tim Ottinger helping to answer questions about the new book Agile in a Flash. See this page for a description of the book.

The promotion starts Tuesday, February 22th 2011 and will end on Friday, February 25th 2011.

We'll be selecting four random posters in this forum to win a free copy of the book provided by the publisher, Pragmatic.

Please see the Book Promotion page to ensure your best chances at winning!

Sit in, ask or answer some questions, see if you can't win your free Agile In A Flash deck. If you don't win one, don't worry. We still have a few left for sale.

Sighting Report

2011-02-20T19:49:00.000-06:00

From an undisclosed location in Des Moines, Iowa, comes this sighting report. It is likely a book store, judging by intact plastic wrap and "Alphabetical By Author" sticker on shelf. It also looks like they're down to their last copy. Snag it now, before their supply is totally exhausted!

Card-Carrying Mad Railer

2011-02-19T11:47:00.000-06:00

David van Leeuwen, Card-carrying Mad Railer, shows off the new deck of Agile In A Flash that he won in a drawing at the Madison, WI conference.

Lisa Crispin and Courage at Belgium Testing Days

2011-02-15T14:59:00.003-06:00

Our deck of cards makes a surprise appearance at Belgium Testing Days 2011 thanks to Lisa Crispin and her experience with the Courage card.

It is pleasing to see the cards having a supporting role in the lives of respected professionals, and to see them appear in a testing conference instead of a more predictable place like an Agile or programming conference. Markus Gärtner provides descriptions of several talks in this blog.

Card-Carrying agile author

2011-02-15T11:13:00.000-06:00

Jeff Langr, programmer geek and computer addict shows off his Agile in a Flash deck in front of a warm fire in Colorado Springs. Look, Ma, no shrink-wrap! Tim, have you opened yours yet???

Card-Carrying Embedded Software Engineer

2011-02-14T12:41:00.001-06:00

Card-carrying embedded-software engineer James Grenning, fellow-author, fellow-ex-ObjectMentor consultant, owner of Renaissance Software, great guy. Here James shows off his deck of cards at a Starbucks near Mundelein, IL. Doing embedded software, but don't know how to do it test-first? See James Grenning (and buy his book Test Driven Development for Embedded C to be released very soon).

Card-carrying Rocketeers

2011-02-14T12:36:00.000-06:00

Card-carrying Hash Rocket team members show off their deck of Agile In A Flash cards gifted to them at their office in Chicago. They are a really great, kind, competent group of people worthy of your business. Tim loves their open workspace and open hearts.

Card-carrying Django Developer

2011-02-14T12:34:00.000-06:00

Card-carrying Django developer, Cezar Jenkins, shows off the autographed deck he won at the Chicago Python users group meeting. His superior memory allowed him to edge out the other attendees and seize the prize!

Card-carrying Agile Author

2011-02-14T12:32:00.000-06:00

Card-carrying agile author and programmer, Tim Ottinger, smugly shows his plastic-wrapped Agile In A Flash deck at home. Tim is the originator of the Agile In A Flash concept, and co-author of the deck with Jeff Langr (without whom this project would have died on the vine). Feeling smug? You betcha.

Card-carrying software journeyman

2011-02-14T12:29:00.000-06:00

Card-carrying software journeyman, Corey Haines, shows off his deck and a broad smile at a Chicago Starbucks outlet.

Getting the Word Out

2011-02-14T12:07:00.001-06:00

By now, many of our readers (perhaps all) have recieved copies of the Agile In A Flash. The feedback we have received has been very positive and we are very encouraged. I understand that a few decks even traveled to the Agile Manifesto event in Salt Lake City.

Our goal is to get this tool into the hands of coaches, trainers, managers, product owners, and development teams all over the world. Since the book has only been out for less than one month, we don't have a lot of information about our sales, but we know from twitter that we are selling on several continents and that people are finding value in the books.

Our goal is to get the cards in the hands of the people who are really doing the work: your project team and its neighbors in the business where you work. If you are interested in helping promote the Agile In A Flash project:

Let your employers know that you are getting value from the deck, and maybe ask to outfit the whole team!
If you are a member of a user group or software interest group of any kind, talk to us about promotional give-aways. We might hook you up with discount coupons or maybe even a deck or two.
On Feb 22, Java Ranch is holding a promotional event for us. Join us!
A review at your favorite on-line book retailer will encourage others to try Agile In A Flash.
Keep us in your tweets and status updates.
Send us a "Card Carrying" picture. We'll post them here. Maybe someone will be inspired!
Send us your great promotional ideas. We're all ears.
This blog could use a Digg or Reddit or HackerNews vote.
Vote us up at CodeBix

Anniversary

2011-02-11T09:08:00.000-06:00

Agile In A Flash is published in the 10th anniversary year of the Agile Manifesto. It hit the shelf only weeks before the reunion gathering in Salt Lake City. We thank the original authors and signatories for providing us with a good foundation for our practice, and we look forward to whatever lies ahead.

Join the celebration by popping over to the Tenth Anniversary site. Read the articles, check out the photos, and join the dialog.

Two Agile Works that Work Great Together

2011-02-09T10:32:00.000-06:00

Have you seen The Agile Samurai yet? We're currently reading it, and really enjoying it. You may see some new Samurai-inspired cards on this site in coming weeks. Jonathan Rasmusson has had kind things to say about Agile In A Flash as well.

Pragmatic programmers have recognized the value of these two works together, and offer a special deal on the physical works tucked away in their latest podcast announcement:

Don’t forget our special discount on our latest agile-themed titles. Save 35% on the paperbacks if you purchase both Agile in a Flash and The Agile Samurai. Just put both paperback books in your cart, and the 35% discount will be automatically applied. While supplies last. Does not apply to prior purchases, or to ebooks; do not read while operating heavy machinery, pages may be slippery when wet.

The Big Four

2011-02-02T13:26:00.002-06:00

There are many concerns for software design and architecture, including functionality, scaling, performance, extensibility, backward compatibility, platform compatibility, future-proofing, the list goes on and on. However, for a system to continue to be workable (maintainable, readable, extensible, correctable) there are primarily these four large concerns.

Software developers have pondered the question of "design rot" as long as there has been software, and have realized that the internal structure of a software system is vitally important to its continued success, just as external factors are critical to user acceptance.

Object-oriented design has provided tools for managing continued workability, but many developers today have not received a well-grounded education in software structure. They are instead pushed to make software that lacks internal structure, but works and is appealing in concept or user interface.

We are presenting a series of articles via the Pragmatic Bookshelf magazine, which we hope will fill in the gaps:

Promo Video Contest

2011-01-31T11:58:00.002-06:00

Tim and I aren't videographers (although I do like his video, see the previous post in this blog). Nor are we in real, day-to-day teams right now (I'm doing on-customer-site consulting, tough to get permissions and such). So we're looking for someone to provide us with a cool video that shows your team's use of Agile in a Flash, and helps promote the book.

We're offering as a prize a ten-pack of cards ($110 at PragProg) for the video we choose as the best. In return, you'd grant us rights and permissions to use the video and whoevers' likenesses for promotional use.

Please email me (jeff at langrsoft.com) if you have any further questions about the contest.

Contest deadline: February 28, 2011

Legal stuff: This is all arbitrary, and Tim and I reserve all rights, including the right to not choose a video if none suits our promotional needs.

The Deal

2011-01-24T18:13:00.000-06:00

Agile In A Flash is not a replacement for coaching, training, consulting, and those wonderful books that my colleagues have written. Agile in a Flash is a great way to get started, and a great tool for coaches, trainers, and consultants to use in teaching Agile software development to their clients and colleagues.

This is our first released video about the cards. Stay tuned.

Released.

2011-01-20T15:46:00.001-06:00

It's here! After a few years of writing, a lot of editing, a bit of promotion, and a whole lot of work, Pragmatic Programmers has released Agile In A Flash.

To our knowledge there is not another product like this one anywhere in the world, on any topic. We've worked hard to make something useful and unique for our Agile community. We have spent a lot of time on format and form factor, phrasing, clarifying points when possible, and weeding out the cards that seemed less useful. As a result of our extreme culling and revisits, you will find powerful advice in a surprisingly small package.

Pragmatic Programmers helped us to make it affordable for teams and companies alike, and individual copies are not out of "impulse purchase" range. This was a departure from their normal publishing activities, but they believed in it and did a lot of legwork to make it possible. They've been supportive and amazing, and I hope you will reward them with your custom.

Thank you for your comments, reviews, tweets and retweets. Today the project is entirely "real" and we appreciate all our readers have done (and may continue to do) to make this crazy little idea work.

New PragProg article: Code Coupling

2011-01-07T14:48:00.000-06:00

Our latest in our series of "big ideas in software" is now available and appearing in the PragPub January 2011 issue. This is the second article out of four, each covering one of cohesion, coupling, abstraction, and volatility. In this article on coupling, we talk about the impacts of too many dependencies in your software, and what you can do to prevent it.

In addition to the HTML version, you also find PDF, epub, and mobi versions of the article here.

Agile in a Flash is slated for publication on January 20! You can advance-order now from Amazon; you'll also soon be able to order in bulk, at a discount, from PragProg directly (and this is the kind of thing for which you'll want a separate copy for everyone on your team).

Meanwhile, Tim and I are banging out the next article, on abstraction, in the series. If you have any advance thoughts on what you'd like to see covered, drop a comment here or send us a line.

Thanks for reading!

On its way!

2010-12-29T17:28:00.002-06:00

The current theory is that the decks will be available (and quite affordable) in mid-to-late January, probably pushing toward the "late" bit. I'm incredibly excited about it, and hope you will be too!

Shu Ha Ri

2010-11-04T14:19:00.000-05:00

The latest PragPub issue is out with our latest Agile in a Flash-related article, Sh Ha Ri: Learn, Detach, Transcend: Steps to Agile Mastery. Or go to the PragPub magazine page and choose a different format (PDF, epub, mobi, and HTML are available).

This article expands on some of the thoughts we presented in our original Agile in a Flash blog post on shu ha ri (complete with card facsimile). Shu ha ri is one of the cards we present in the soon-to-be-published PragProg deck.

Under Test

2010-11-03T22:54:00.003-05:00

Apologies to AIAF readers. The article sent in RSS was intended to appear at AgileOtter blog, not here.

This is the problem with having multiple Blogger accounts starting with A, and writing at night when you are less wary about checking site names when writing. Apologies to readers and to my coauthor for the slip-up.

Agile In A Flash - Whew!!

2010-10-15T19:30:00.000-05:00

We are off to the copy editor, and that means your Agile In A Flash cards are coming soon.

See the official Pragmatic Bookshelf page!

See the O'Reilly catalog entry!

See the Amazon catalog entry!

See the ongoing series of articles in PragProg Magazine!

See the happy authors!

Thanks to everyone for the support and reviews and ideas and permissions. It's fun to see a dream come true!

Now it's time to go replace my exclamation mark key. ;-)

New PragProg article--What Agile is Not

2010-10-06T15:11:00.003-05:00

Latest update: The Agile in a Flash project is nearing final draft, close to being sent to production! Once that happens (perhaps end of next week), it's 6-8 weeks away from shipping to you.

Meanwhile, our latest PragPub article (available in multiple formats--see the PragPub magazine index--is out. It's called "What Agile is Not" and talks about some of our experiences with agile. Looking at the article, though, I wonder about the lead-off sentence for our conclusion paragraph:

"The advice from Kent Beck and Ron Jeffries for successful adoption of Agile Software Development has always been to start with the values. "

But is that true? I believe there have been some recent statements to the contrary on one of the mailing lists. My apologies to Ron/Kent--that's how I've always looked at things, so perhaps I'd projected my misinterpretation on their teachings. Feedback please?

Article at Prag Prog, More to Come!

2010-09-01T12:24:00.000-05:00

This is a news update, not another card, but our latest article is up at Pragmatic Programmers.

We've gone a few weeks without a new card here, but it's because we've been working on the final versions of our cards to be published by Pragmatic Publishers "Real Soon Now." You will find a lot of familiar content, but even more polished and even more condensed. You'll get to enjoy physical cards, suitable for sticking and sharing with your whole team or company. Even better yet, they'll have been edited by actual professional editors.

We're not going to quit the blog, but we are going to be available in more forms than ever before. PragProg will release AgileInAFlash as physical cards and as ebooks. Imagine how cool "Courage" or "ABCs of Pair Programming" will look on your hot little iPad or Android phone! You'll have virtual Tim & Jeff everywhere you want to take us. This blog continues to be a place to write your comments, or to see cards never before released into the wild.

When you get your deck(s), take a picture of yourself using the cards and send it to us. We'll be thrilled and honored to see how you use your AgileInAFlash in your daily work!

Blessings.
Tim

Basic Agile Flow

2010-08-04T06:00:00.001-05:00

Tim Ottinger and Jeff Langr

There are many ways to conduct an agile project. Some work with huge backlogs, some with spur-of-the moment requirements, some have continual release, some have non-time-boxed continual flow. We recommend starting with the structure shown on this Agile in a Flash card.

Following this plan, the customer team puts together a prioritized list (feature backlog) of desired features for the upcoming product release. The release is broken into iterations, and the team and customer agree on what will be delivered at the start of each iteration (no sooner). The iteration is of fixed length, something that allows the team to begin gathering consistent data, which in turn they feed back into their estimates and subsequently a larger plan. Upon incrementing and iterating the software a few times, the software reaches a state that it may be released to the customer. Does the system implement the agreed-upon features (did it pass all of its acceptance tests)? Yes: Release to production!

The flow outlined above is a reasonable starting point for a team transitioning to agile. It represents a kind of "Shu" in the Shu-Ha-Ri cycle, where one follows a certain technique or style for a while to build up their ability to perform it. In fact, both of us started with this basic pattern and found that it worked just fine.

As you move to more "Ha" stage, you might experiment with reducing the size of stories so that more of them are done and "in the can" before the end of the iteration. You might work on making the software releasable at every iteration boundary. You might shorten your iteration period so you can gather data more often, provide smaller increments to certification, and get feedback from users more quickly. You might pick fewer stories per iteration. You may experiment with self-organizing to get work done. It is a waste to spend a lot of time detailing features which may be done in the remote future or not at all, so you may reduce the entire feature backlog to perhaps a handful of stories. You may learn (as Deming recommends) to use more effective quality practices and eliminate a "certification" stage, as indeed many software shops are doing (research topic: continual release).

Once you are into the Ha and the Ri stages, using agile principles and values should lead you to more informal yet more effective approaches. Here's an "agile flow" card for the more seasoned agile team:

In a bit more detail:
- The customer describes a small subset of needs orally, to the team.
- Through negotiation with the customer, the team commits to completing code that satisfies some, most, or all those needs in a given period.
- The team agrees on a working set of rules that define how they will deliver quality code, under good, sustainable working conditions, in the specified period. (Hint: The team might use retrospectives to help derive and tweak the rules.)

- Repeat. This magic word allows the introduction of things like projects containing releases, and releases containing iterations. Or not.

Acceptance Test Design Principles

2010-07-27T08:18:00.000-05:00

Jeff Langr and Tim Ottinger

Acceptance tests (ATs) are as enduring and important an artifact as your code. The proper design of each will minimize maintenance efforts. You'll recognize some familiar concepts--Kent Beck's rules for simple design and some classic OO principles apply well to the design of acceptance tests.

Abstract. A test is readable as a document describing system behavior. Uncle Bob's definition for abstraction applies equally well to tests: Amplify your test's essential elements, and bury its irrelevant details and clutter. Anyone, including non-DBA and non-programming staff, should be able to follow the steps taken in the test, and understand why it passes. Extracting duplicate behavior to a common place--the AT analog of programming's extract method--is the main workhorse that allows you to increase abstraction at the same time you remove duplication.

Bona fide. To ensure continual customer trust, a test must always truly exercise a system as close to production as possible. Passing acceptance tests tell the customer that what they asked for is complete and working. But once the customer has doubt as to what your tests exercise, you have severely damaged your ability to continue using them as contracts for completion.

Cohesive. A test expresses one goal accomplished by interacting with the system. Don't prematurely optimize by combining multiple scenarios into a single test. Keep single-goal tests simple by splitting common content into separate fixtures. Yes, this will mean your acceptance test suite runs more slowly, but it's far more important to avoid compromising clean test design. (It's also why your unit test suites should be as fast as possible.)

Decoupled. Each test stands on its own, not depending upon or being impacted by results of other tests. A failure caused by problems in another test can be difficult to decipher.

Expressive. A test is highly readable as documentation, not requiring research to understand. Name it according to the goal it achieves. As with unit tests, refactor each test to improve the ability of a third party to understand its intent. You should always eliminate magic numbers, replacing them with constants as appropriate. Improve visual accessibility by formatting your test using Arrange-Act-Assert (AAA). You should also make it clear what context is being set up in the test; one way is to incorporate additional assertions that act as preconditions.

Free of duplication. Eliminate duplication across tests (and even within the same test) before it eliminates you! Duplication increases risk and cost, particularly when changes to frequently-copied behavior ripple through dozens or more tests. Duplication also reduces the use of abstraction, making tests more dense and difficult to follow.

Green. Once a story is complete, its associated ATs must always pass. A failing AT should trigger a stop-the-line mentality. Don't allow your test suite to fall into disarray by allowing failures to be ignored!

Agile Success Factors

2010-07-21T06:17:00.003-05:00

Jeff Langr and Tim Ottinger
Font: Brown Bag Lunch

Pop quiz, hotshot.

Q. "You're not agile if you don't ... "
A. Select one more of the following:

	a.	Have daily stand-up meetings
	b.	Pair program
	c.	Do TDD
	d.	Employ a metaphor
	e.	Have a ScrumMaster
	f.	Run iteration planning meetings
	g.	Use index cards

The answer is H, none of the above. Practices are just that--specific techniques a team might or might not employ to aid them in being agile--whatever agile means. Here's our definition: Agility means you are able to frequently and continually deliver high-quality software that meets the customer's needs.

The agile manifesto lays out four core values ("working software over comprehensive documentation," e.g.) and a dozen or so principles. But what factors truly make an agile team successful?

Freedom to change. Incremental change, one of the other success factors, can only occur if your teamis able to change how they work without outside interference. Meddling and micromanaging, never mind the intentions, usually divert the team from what should be everyone's goal of shipping quality software. Get the right people in place in your organization to support the team's rightful decisions, and to not try to change them. We'll be blunt: Conversely, this may mean removing the wrong people from the chain of influence.

Energized team. The successful agile team just gets it. They want to work this way. We can walk into a room and generally see whether or not a team will succeed. A good team is highly transparent and visibly enjoying what they're doing. They've built a true team spirit, and no one talks about "my code" or "my stories." They collaborate without being told; they hold their own stand-ups without a project manager having to crack the whip. They always act to protect the product and its integrity--they don't discard quality controls even when under intense pressure to deliver. They also look for ways to make life better for everyone--"How can I rework this test so that the next developer will understand my intent?" They'll step in and help anyone as needed to deliver quality product, even if it's "not their job."

While we like to think a good, energized team is all it should take, lack of freedom to change will demoralize even the best teams, to the point where your guys who "get it" choose to move on to something less oppressive.

Commo (line of communication) to customer. A product is an intricately detailed ship that must be well understood and constantly steered. The best teams we've seen have been steered by a strong, enthusiastic single-person, dedicated customer who truly understands what needs to be built. This customer has the time to ensure that everyone else can learn from them what needs to be built. While the strong customer can have a supporting cast, a large, committee-style product management team simply doesn't work. (It's always unfathomable to us that most companies are willing to staff development teams with no end of apathetic dregs, but are unwilling to pay well for strong people who know what product to build.)

Collaboration. So many teams want to be agile but can't get past cube mentality. Sometimes we think stand-ups were designed solely to compensate for cube walls, to make people feel better because they got together for a few minutes in the morning. Collaboration isn't just meetings. It's working together, and more importantly, figuring how to change workflow so that you have to work together. Due to the heavy intricacy of hundreds of thousands of lines of code interacting together as a single unit, software projects cannot be individual efforts ("you do your code, I'll do mine"). We must learn how to collaborate in the code. Really--collaborate. Work together. We mean it. Those who treat coding as an individual activity don't get it.

Attention to quality. The code is your product, and, unlike most other products, one you will continually build on and shape to meet continual new customer demand. If you fail to pay attention to quality, you will eventually slow down in your ability to meet demand, sometimes to the point of stagnation. The team must ensure that the code is clean enough to accommodate new incremental customer needs. Attention to quality is never a separate task on a plan; it must be embodied in everything you do to build your product, including coding, design, documentation, testing, automation, tracking, communication, and so on. Quality must be incrementally and continually addressed.

Incrementalism Most of the practices you employ in agile have something to do with ever-smaller steps. Instead of a massive requirements document, you allow the customer to provide features just in time, in small chunks described on little index cards. Instead of a comprehensive up-front design document, you learn how to design on a task-by-task and test-by-test basis. And so on. You must learn to think incrementally.

You must also look to correct course continually and incrementally. For every few lines of code added or changed, take time to ensure the design is as good as you can get it. (Which you can only do if you have enough controls in place to allow frequent code improvement. Best way we know how to get there: TDD.) Not only do you need to correct course in the product, you need to always correct course in your team. You should always be introspecting about your team, probing for ways it's not performing optimally, and working to correct these problems. Retrospectives are a good start.

A successful agile project is not a bunch of hare-like sprints to the finish line. It is a cool-headed, tortoise-like, slow 'n' steady approach of small, well-reasoned steps. Each step is an opportunity to look up and see where it got you--closer to the finish line or further away? It's easy to correct a single misstep. In contrast, a single mad sprint in the wrong direction can take you pretty far off course from the finish line.

Automation. There are numerous ways to waste people's time on a software development effort--running automatable regression tests manually, for example, or suffering a build process that unnecessarily requires multiple manual steps or manual verification. Agile cannot work unless you automate as many menial, tedious, and error-prone tasks as possible. There's simply not enough time across a two-week period to get any real work done if you have to slow down for numerous manual gating processes.

Information Radiators

2010-07-13T06:05:00.006-05:00

Tim Ottinger and Jeff Langr
Font: Brown Bag Lunch

In keeping with the agile value of Communication, agile teams often place large charts and graphs in their workspaces to radiate important information such as defect rates, rate of completion, and measures of code goodness (CRC, bugs, test counts). Much is made of Informative Workspaces or Big Visible Charts (BVCs).

You'll find numerous graph types in the agile literature. Some types, such as burn-up, burn-down, and cumulative flow are commonly used to graph progress against a goal such as an epic story. Defects and velocity are also useful things to track, but don't limit yourself. Let your team determine--and let these information radiator principles guide--what you track and publicize.

Simple
A chart or graph should not require minutes or hours of study. Ensure it is brief and concise. Anything dense or complicated will fail to communicate. Also, don't use highly derivative, biased, weighted information. Simple facts speak more profoundly than clever algorithms.
Stark
BVCs don't exist to convince the public of your team's excellence. Nor should you mask errors or problems with them. The purpose of the graphs is to display progress and expose problems. Don't subvert the honesty of the graphs, otherwise your team will stop trusting them, and therefore stop using them to improve their work.
Current
Any information that is not kept current is quickly ignored. You may want to have the CI build graphs based on automatically-generated stats. Information more than a few days old is too stale to have evocative powers.
Transient
Radiators that only expose problems shouldn't be up there long, otherwise it's clear that you aren't solving your problems. Choose a BVC to highlight a current challenge for which you can demonstrably show improvement over the next several days or iterations. Once it's clear the team has gotten the message, and things are back on track, take down the BVC.
Influential
A good information radiator influences the team's daily work. It may also influence managers, customers, developers, or other stakeholders. Ideally it will empower the whole team to make better decisions, otherwise it is not worth preparing and presenting.
Highly visible
An effective information radiator needs to not only have information on it, but must transfer it to team members, stakeholders, and passers-by.
Minimal in number
Having too many graphs or charts will cause all of the charts to lose evocative power. Also, exposing too many problems on the wall at one time can demoralize any team, so choose either the most important, timely, or fixable problem to highlight, and defer the rest. Sometimes less truly is more.

Development Iteration

2010-07-01T07:30:00.004-05:00

Jeff Langr and Tim Ottinger
Font: Brown Bag Lunch

These half-dozen items provide the core set of principles around the iteration workflow for delivering stories to an eager customer. (Most of the principles would also apply to a kanban environment, with a bit of tweaking.)

Team commits to stories they can complete. Each iteration begins with a short planning session. The primary goal of this session is to ensure that the development team (hereafter "the team" in this blog post) and customer are in sync on what the team will deliver by iteration end. The customer and team jointly produce acceptance criteria that act as the contract for completion. The team commits to only the set of stories they can confidently deliver by iteration end. The workload is thus fixed for the duration of the iteration, although the customer can negotiate a change to the workload with the team. Hopefully this occurs only rarely, and hopefully the team has the sense to insist on work being taken off the iteration's plate.

Team works stories from prioritized card wall. The customer is responsible for managing the flow of work. Their job is to ensure that available stories are presented in priority order. Available developers grab the card with highest priority and move it into an "in progress" bucket. The card wall, whether real or virtual, is visible to everyone involved in the project.

Team minimizes stories in process. Applying non-collaborative approaches to agile asks for the same, lame results you got from waterfall. A typical anti-pattern we've seen (we'll call it "Indivigile"): Every story is close to a full iteration in size, and each developer grabs their "own" story to work on. So much for any of the significant benefits that you might have gained from collaboration (primarily better solutions, increased mindshare, and thus minimized risk). Worse, you dramatically increase the probability that stories will not be delivered by iteration end. A better approach: Team members work on the smallest sensible number of stories at one time, maximizing collaboration and ensuring that each story is truly done before moving on to the next.
Following this approach, you should see almost half of the committed stories 100% complete by midway through the iteration. Overall, the number of stories fully complete by iteration end should increase. Also, many activities that would have otherwise been blocked until iteration end can start earlier (additional testing, clarification/correction, documentation, etc.).

Team collaborates daily. A daily stand-up meeting is a good start for getting the team on the same page, but never sufficient. If the stories-in-process are few, the team must find ways to collaborate frequently throughout each day, to avoid wasting additional time.

Customer accepts only completed stories. Stories must pass all programmer and acceptance tests before the customer looks at the the software. The customer needs to play hard-ball at this point: Any story shy of 100% passing gets the team zero credit: Incomplete work provides no business value. The lesson for the team to learn (and apply in subsequent iterations) is to not over-commit.

Team reflects on iteration and commits to improvements. Agile is built around frequent incremental delivery, in order to maximize feedback, which in turn provides opportunities to improve. Iterations are not only opportunity points to improve the product, but also for the team to reflect on what the team needs to change, whether to improve quality, throughput (which improving quality will do), team morale, or any other execution concerns that the team recognizes. See our Retrospectives card for guidance on this critical agile practice.

Everything else that happens with respect to iteration execution is "implementation details," and thus up to your team to determine. We don't care if you use software tools or physical card walls. We don't care if your team is distributed, whether you run a formal stand-up meeting, whether you use velocity, planning poker, load factors, yesterday's weather, Scrum Master whip cracking, or any other specific practices for planning and organization. All is generally good as long as you adhere to the above principles for flowing work.

Why Agile?

2010-06-23T06:00:00.007-05:00

Source: Tim Ottinger, Jeff Langr
Font: Erwin

We've talked about what agile development is, how to do it, and why people object to it, but the big question that remains is "Why Go Agile At All?" If you or your employer are considering a conversion to agile, you should know what to expect from the change.

Agile is a work system, not just a style of writing code or a set of tracking tools. It is a very disciplined and orderly way to work, and it is also a lot of fun. It is intense, requiring a high degree of personal involvement (which is why Agile teams cap their work weeks at roughly 40 hours).

Improve Customer Involvement
Increase Quality
Simplify Releases
Increase Operational Awareness
Drive Down Risk
Agile teams work in tiny increments of functionality, not huge end-all features. This allows them to have working software ready early on. They do not necessarily produce software faster than non-agile shops, but it is in a usable state earlier. This means that the software can be used while it is being developed. It might even pay for itself.
Reconnect With Geek Joy

The most common reason does not appear on the list above, "What we were doing was not working." That is a reason to change from what you were doing, but not necessarily a reason to change to anything in particular. If you are considering a change, consider whether you want the qualities listed here enough to give Scrum and/or XP a shot.

The Only Agile Tools You'll Ever Need

2010-06-16T06:00:00.042-05:00

Source: Tim Ottinger and Jeff Langr
Font: BrownBagLunch

Perhaps you were expecting a list of software products?

Agile's raison_d'être stems from backlash against "heavyweight" methodologies that insisted upon voluminous documentation, never-ending and never-useful meetings, and vendor-lovin' high end tools. Yet in 2010, there are at least three major high-price, high-profile agile project management tools and dozens of lower-end ones.

We contend that using one of these expensive software tools says, "you don't get it, and maybe shouldn't bother, because agile may not work well for you." No doubt this will perturb those of you who have found some value in agile management tools, so let's step back and talk through the issues.

Agile is primarily about team communication and collaboration. It is predicated on continual face-to-face interaction. Every step in the opposite direction decreases the chance of success. Kent Beck had it right: The best opportunity for success, still, is having all project members sit in a single room and work as a team, instead letting a bunch of self-interested individuals retreat to the isolated comfort of their cube.

There is no room in agile development for "avoidance technology." If you can't find a way to meet its demand for close-contact, continuous communication, then you are not ready. If you don't want your programmers sitting together, talking through problems, writing code socially, then try something else. Attempting to bolt avoidance technology onto agile methods is like castrating a stud horse.

Once you diminish teamwork, you have to compromise other agile principles. If we're not in the same room, we need more meetings to talk to one another. We need to write more things down and produce more centrally-stored documentation. We need to have more contractually-oriented agreements between people who really work on the same team, because we can't trust one another, because we're can't see each other face-to-face every day. The agile practices topple like dominoes.

There is always questionable rationale about why things must be that way. "Every project has to be split evenly between low-cost [read: offshore] labor and high-cost [local] labor." That's not a definition of project success, just a broad-brush attempt at cost control. Having some remote team members should never force all team members to work as if they were remote.

Perhaps the executives could use their hard-won corporate smarts to organize the teams differently. "Half our projects must be low-cost" should appease the bean-counters, and could just work. Here come the excuses: "But we don't have business experts who can act as customers in Bangalore." Really, that's a problem you can't solve? Having two truly agile teams producing quality code should be better than having two teams pretending to be, and failing at, agile.

If you want to succeed at agile, find a way to put each team in its own room. Give them the tools we list on the card, and they'll rarely ask for more. We guarantee they won't ask for a high-end agile tool, because they don't need one and don't want to be bothered with one. Executives of various stripes might ask for one, but all they really want is a simple way to view and present status across significant numbers of projects. You don't need a high-end, specialized, complex tool to do that, and you definitely don't need to waste the time of everyone across every agile team to do that (hint: see Tracker and Coordinator on Agile Roles card. This is what you pay project managers to do).

Agile Roles

2010-06-08T20:18:00.005-05:00

Some of you might be surprised that there are no farm animals on this card. We'll talk about that later.

You'll also note that each role definition is preceded with the word "helps." Everyone on an agile team can act as any role at any given time, helping the team toward its ultimate goal of producing quality product.

In agile, roles are just that, roles. We don't look to protect our role from being usurped. While we are most comfortable playing in our primary role, we have no qualms about stepping into other roles as needed or appropriate. A tester might act as a tracker to gather useful team metrics; a programmer might assist the customer and testers in defining acceptance criteria for a story; a manager might help execute any remaining manual acceptance tests; and so on.

Extreme Programming (XP) originally designated two roles, programmer and customer (for whom XP described little--it is extreme programming after all). Each camp had specific rights, to protect each camp's interests against likely infringements by the other. A bit divisive? Indeed. You will be hard-pressed to find much remaining literature that mentions "XP Rights."

Within the programmer camp, XP eschewed specialists and hierarchies, fostering instead experts and team collaboration. But things other than programming and steering as a customer still needed to be done. Various adjunct needs, such as coaching and tracking, emerged. Who would do these things? These part-time needs were fulfilled by XP team members (customers or programmers) shifting in and out of secondary roles.

Proponents of Scrum (which predates XP a bit) were never so trusting in a teams' ability to self-manage, so they introduced the Scrum master, whose job is to keep the team on track. As for XP, the reality of human behavior brought its lofty goals down a peg, more so as Agile took off. Organizational interests and self-preservation took over. The concept of a self-organizing, title-ignoring team threatened HR, project managers, managers, and others who had vested interests in promoting and maintaining specific titles. In an attempt to keep us from falling back into isolationist and divisive behavior, Kent Beck began referring to the collection of all team members as "the whole team," instead of discussing specific roles.

Today, the agile organization doesn't usually look terribly different than the pre-agile organization, except within some programming teams. You'll still hear long-standing, specific names for specific customer roles, such as "business analyst," "product manager," "UI design specialist," "subject matter expert (SME)," and "stakeholder." But on the programming side of the fence, a team working within an open workspace and pairing usually has lost any real concern over titles and artificial divisions such as "front end programmer vs. back-end programmer." Since these roles are temporary, it is futile and undesirable to to tie hierarchical positions or increased benefits to them.

It is best for us to concentrate more on putting out quality product, and least on relative positions. We understand that it may not be realistic in your organization to shed your title, but you should still consider the ego-less organization a general direction to move toward. Sometimes simply thinking that there are no titles can help you find an answer to your problems.

Astute readers will note that "manager," "project manager," and "Scrum Master" do not appear on this list. We have instead substituted "team coordinator," someone who buffers the day-to-day development team from outside interference and distraction. A team coordinator can communicate scheduling issues, handle incoming requests, and smooth interpersonal problems. Within Scrum, this team coordinator also takes on the responsibility of enforcing the rules, something that a team is certainly capable of doing on their own. We suggest that the best Scrum Masters plan their own obsolescence: Their primary job should be to help us mature to the point where the team no longer needs a Scrum Master.

The lack of official leaders and managers in agile is off-putting to some. We've noted that most software teams do not suffer from a shortage of management, but a drastic overage as different departments try to exert control over the isolated "programmers" and "testers." In an agile team we come together as a team, and the work has us busy enough that little traditional management is necessary.

As far as the chicken and pig roles that some of you might have expected to see on this card: Everyone we've met on a well-functioning agile team has been unsurprisingly human. We don't believe people who might have something important to say should be stifled. If someone says inappropriate things at inappropriate times, we muster the courage to ask them to take it elsewhere. "Chicken" was deliberately chosen as a derisive moniker, the spirit of which has no place on a real team. (We quote Jeff Sutherland here, because his original blog post has been archived and may soon rightfully be buried entirely: "People who are not committed to the project and are not accountable for deliverables at the meeting do not get to talk. They are excess overhead for the meeting. ... Whatever we call them it should have a negative connotation because they tend to sap productivity. They are really suckers or parasites that live off the work of others. Sorry to be political [sic] incorrect but others should come up with a euphemism that conveys the right balance between being "nice" and communicating clearly that eavesdroppers must minimize their impact on the productivity of the team." Perhaps the goal is laudable, but the sentiment is so wrong as to be repulsive.)

Test Double Troubles

2010-05-26T21:45:00.002-05:00

Inhibited Refactoring. Mock-based tests must have special knowledge of a class' interactions with its collaborators. We gladly accept this special role of tests, as it allows us to test otherwise impenetrable code. By testing interactions, however, we create dependencies on design structure. Refactoring changes the structure of code, which breaks naïve structure-dependent tests. Tests that extensively use test doubles can exhibit structure-sensitive breakages which dissuade programmers from refactoring. Fear of refactoring is death to system evolution.
A proper unit test should have a clear intent, signaled by the name, and should read as though it is explaining the code. To a certain extent, though, the test will rephrase or paraphrase the system under test. If the system under test is not structure-shy, then the mock-enabled tests will also not be structure-shy. In general, the tests should be as simple as you want the code to be.
A test with extensive mock setup signals a class with many dependencies or too little encapsulation. A class designed with the Law Of Demeter in mind will be structure-shy, making it more cleanly and easily tested with partial mocks.
Tool complexity. Third party mock libraries like Rhino Mocks and Mockito are getting better at allowing you to write expressive tests, but they all introduce complexity. You must first learn a tool's extensive API and unique view of mock usage, which can include subtle nuances around things like partial mocks and void methods. Some tools even support multiple styles of mocking, each with its own special syntax. You must also learn how to read often-idiomatic code required to implement these various nuanced mock recipes.
Refactor tests to eliminate redundant test double detail^*. Good tests require high levels of abstraction, emphasizing readability and de-emphasizing mock implementation details. Extract the idiomatic, tool-dependent code to small, declaratively-named helper methods.
Passing tests that indicate nothing. A naive mock-based test may tell you that function X is called twice, and function Y is called once, but it does not tell you if you have a good design or even if you will get a good result. A heavily-mocked test suite may not behave in the same way that the underlying code will behave in production. It may have assumptions about handling of nulls or exceptions that are not coherent with production code. Worse yet, a test generated via 'tracer bullet' method may exercise a class or method but provide no useful information or evidence of correctness.
A proper unit test is more than function counting. To combat unrealistic mock scenarios, examine the code as-written to determine weaknesses that can be simulated and explained in further tests. Avoid writing tests that are mere exercises of code, and have no clear intent.
Testing mocks rather than the SUT. In a maze of test doubles, stubs, mocks, and partial mocks, one can become lost in the entanglement between tests and production code. A feature may appear covered by tests, all passing, but fails in production. Deeper exploration reveals that someone unwittingly replaced the method being tested with a stub. This always happens in subtle and indirect ways, and always results in face-palming.
It is important to be careful when mock setup has been extracted from test methods. One may not be aware that the method under test has been replaced by a mock in some shared setup method. Avoid using stubs that are distanced from the direct class target of a test.
Low readability. Tests can require significant amounts of detailed setup ("record") and verification ("expect"). Such clutter makes it hard to tell which expectations are simulation-enabling and which are the crucial assertions of the test.
The primary goal of test doubles is to emulate collaborators in as simple a fashion as possible. Well-designed test doubles have virtually no logic, and well-designed classes only directly interact with a few collaborators. When interactions are many and span many classes it is because the system under test is too structure-sensitive. Refactoring the system under test to be structure-shy will help reduce the number of collaborators that demand mocking, which in turn will simplify its test. Extracting methods which interact with other classes or APIs will allow effective use of partial-mocking.
Ambitious mock implementations. Fakes--objects that completely emulate all aspects of a collaborator--require implementing redundant behavior, which sometimes requires involved logic. The problem with real logic, as opposed to simple stubbed methods, is that it's easy to screw up. Recently both of us have been working with code that uses a massive faking scheme, and both of us have wasted considerable time in implementing, deciphering, and debugging the fakes.
If you have many tests that require variant test double behaviors for a single collaborator, absolutely resist the temptation to combine these into a "mock mother." One mock, one behavior. Combining behaviors into a single test double class will quickly lead you down the divergent path of maintaining mocks for a living. Keep your test doubles simple and discrete!
Vendor dependency. You'd think we would have learned our lesson years ago. We created Java systems that rampantly interacted with JDBC (an almost direct mapping to SQL statements). Most of us moved to APIs that provided higher levels of abstraction, such as JDO, entity beans, and Hibernate. That transition was painful, mostly because of the highly-redundant, highly vendor-dependent code that we allowed to seep into hundreds of classes and thousands of methods.
Mock tools are no different. Some of you chose RMock several years ago, and some of you probably feel that you're stuck with it due to its pervasive use in your system's tests. Too bad. Mockito is a great tool, but we imagine a better one will come along when Java finally sports closures (Java 8? 9? ...). We want to transition to this new tool without so much pain.
The recommendation is, once again, devise small, cohesive methods that encapsulate mock tool details.

* We wanted to abbreviate the phrase "Test Double Detail," but we think TDD might mean something else.

Mock Terminology

2010-04-30T23:19:00.000-05:00

By Jeff Langr and Tim Ottinger
Font: BrownBagLunch

Well, the title of this post is just wrong. The generic term for "things we use in testing to emulate production behavior" is test double, not mock. The casual programmer may bandy about the term mock when they mean test double, but it is technically incorrect and may lead to misinterpretation. We've never seen it make much of a difference to the end result of a programming conversation, but there are distinct definitions for the various implementations and uses of test doubles.

The term mock object stems from a 1999 paper by Tim Mackinnon, Steve Freeman, and Philip Craig, "Endo Testing: Unit Testing With Mock Objects." The authors' simple definition: "a substitute implementation to emulate or instrument other domain code." Mocks, or whatever you might call them in 2010, still serve the same purpose.

Use of mock objects in TDD circles grew dramatically over the next several years. Debate grew dramatically, too. The community debated about (a) whether or not to use them at all, (b) in what situations they were most appropriate, and (c) whether or not to use one of the mock tools that were starting to proliferate and pro-create.

In 2006, Gerard Meszaros published the book XUnit Patterns, which enshrined a handful of nuanced terms for the various kinds of test doubles. These terms had been shopped around in various agile forums for some time leading up to publication of the XUnit Patterns book. Today the taxonomy is commonly accepted by programmers and mock frameworks alike (oops, but "mock frameworks" itself is a misnomer, as these frameworks usually support all sorts of test doubles, not just mocks).

Test Double is the generic term, the phylum for all our species of testing dopplegangers.
Stub - An object that returns a specific, fixed value to the system under test (SUT). Stubs are usually constrained to a small subset of methods defined on a collaborating class. "When someone calls the price method, return the value 9.99."
Fake - An object that completely emulates its production equivalent. The classic example of a fake is a lightweight, in-memory "database" object that allows for simple, fast emulation of a relational database interface.
Mock - An object that self-verifies. A mock asserts that information sent to it is as expected. A test that uses a mock defines and verifies this expectation.
Partial mock - An object that contains a mixture of production method implementations and mock method implementations. Partial mocks are generally used when you need to emulate non-existent behavior (i.e. abstract methods) or troublesome behavior defined on the same class you are testing, something that might indicate questionable design.
Spy - An object that simply captures messages sent to it, so that the test can later verify that the SUT interacted correctly with its collaborator.

These terminological differences may on occasion be useful but are not worth arguing with any real passion. We suggest learning the differences as a means of avoiding time wasted with arguments, using a formulation along the lines of "I'm sorry. Of course I meant spy, not mock. Now, look on line 47..."

So, where do we stand on the debate? (a) Yes, use test doubles (b) when you must, (c) and use a tool if it makes things easier or clearer. Next time, we'll talk about more important things, such as what pitfalls to avoid when working with test doubles.

Organizational Objections To Agile Process

2010-04-30T16:30:00.000-05:00

By Jeff Langr and Tim Ottinger
Font is Andrew Script

It is no surprise that organizations struggle when attempting to transition to agile methods. As with any new venture that threatens the status quo, the list of objections is long and varied. In developing this card we collected over a hundred typical sentiments and grouped them into about a dozen categories--too many for a single card. In keeping with our personal vows of brevity, we present here the first card: Objections borne out of organizational and cultural circumstances. We will present reasons that stem from individual belief systems and biases separately.

In order to help transitional consultants and rank-and-file people who are struggling, we provide commentary and counter-arguments.

"It Can't Work Here" There is a common assumption that Agile methods require a special set of initial conditions. Most companies believe that their own situation is unique, their software uniquely complex, their market position too tenuous, or their management system too inflexible. Given such specialized initial conditions, how could a general-purpose method based on simplicity possibly work?
Agile is not so much a set of a constraints and rules as it is a framework in which a team can continually discover its own limitations and then derive better approaches. There are few necessary initial conditions beyond an agreement to work together in an incremental and iterative way.
"They Won't Let Us" is a special condition of "It Can't Work Here." Agile methods may be deemed feasible and even advantageous among the technical crowd, but may seem counter to the organizational culture and/or management habit. For instance, there may be a competitive personnel evaluation system for staff which frustrates attempts at collaboration. The management might have a strong command-and-control model which prevents self-organization. Perhaps the organization is built upon the concept of a strong lead programmer directing a squad of "code monkeys." Maybe schedule pressures are so great that there is no slack to spend on organizational learning. It may be that the team cannot modify the layout of the office due to union issues or concern for decor.
Agile methods are advantageous to development and product management since they provide more data about the team's real progress, allow better focus on important features, and require very limited limited overhead to practice. While some aspects of Agile practice are clearly focused on management practices and product management strategies, an increasingly capable team can usually cope with difficult organizational practices in the short term and can win over leaders in the long run.
"Guilt By Association" refers to the situation where Agile methods have not been tried, but at first blush seem to resemble other methods or practices that have fallen from favor. Sometimes Agile is associated with uncontrolled "cowboy coding." Other times Agile is perceived as a trick by management to force programmers to work harder. It may be confused with ceremony-heavy consulting-driven methodology. The poor image is often tarnished further by tool vendors hoping to cash in on the latest buzz with tools that are rarely necessary, of limited helpfulness, hard to learn, tedious to use, or even detrimental to collaboration and communication. An Agile conversion project may follow on the heels of other failed "flavor of the month" methodology attempts.
Agile is a low-ceremony, disciplined way of working built on concepts and ideas that have been successfully applied in the software industry for many decades, and longer in other industries that still embrace these principles today. It is a simple, incremental approach to team software development that requires little tooling beyond a place to sit, a whiteboard, a good supply of index cards, and a few rolls of tape. It would be a shame if an unfair prejudice caused us to miss out on an opportunity to build a truly great team.
"Means/Ends Juxtaposition" is a variation on "cargo cult" mentality. A typical non-agile company will have layers of policy and management practices built on strict phase separation, copious up-front documentation, individual accountability, rigidly-defined hierarchical roles, and/or tail-end quality control processes. Artifacts produced by these practices become the primary output of teams, and enforcing mandated behaviors becomes the primary concern of managers, even though neither contribute meaningfully to quality software development.
An organization attempting to transition to agile may fall into the same trap by rigidly applying so-called agile practices. Numerous teams claim (capital-A) "Agility" because they hold interminable feckless retrospectives, prescribe stand-up meetings that provide only vertical status, or prolong interminable pair "marriages." Stand-ups, retrospectives, and pairing are extremely valuable tools, but only if you are able to align them with agile values and principles.
To succeed at agile, we must first understand that it is a continual journey of team discovery, and not a rigid set of practices. We must have some sense of where we want agile to take us, and that the journey will reveal unforeseen challenges and opportunities. Agile development is about growth rather than conformity.
"Inferiority Complex" The team that ships quality software on a consistent and frequent basis exhibits a high level of confidence. A team that lives with frequent failure and inability to estimate quality of product will exhibit a low level of confidence. An observer may attribute the confidence and ability of the team as an initial condition and not as an eventual outcome of the process, surmising that confident superstars are a necessary initial condition of agile success.
The Pareto distribution suggests that most teams simply don't have enough star developers to conquer this mistaken understanding of agile. Real concerns over minimizing entropy in a rapidly changing system engender pure fright: "How can we possibly introduce new features without pre-conceiving the entire design? Our code is horrible to start with, and we've tried to write some unit tests, and it's just too hard." A large number of teams ultimately feel they lack the skill to produce anything of value in a short iteration.
Agile software development is about teamwork, not about superstars. For example, pair programming helps make TDD less difficult (for everyone, superstars and supernovices alike); TDD in turn provides us with the means to safely refactor code; refactoring sustains quality design in an extremely dynamic environment. Likewise, introspection and teamwork allow for continual improvement. Agile is a means to raise the competence of a team and lower the difficulty of working with a code base.
"Superiority Complex" is when an organization feels that they have a pretty good handle on things. They have a process that has allowed them to deliver successfully in the past, and regard any change in practice as a step down. Practices like TDD and pair programming are regarded as training wheels for junior programmers, and wholly inappropriate for serious software professionals. They may believe that they have a special gift for up-front design that makes incremental design wasteful and unnecessary. The organization believes they have transcended the need for Agile practices.
There will always be those who think that the world has nothing left to teach them. If the organization is perfect, there are no flaws to uncover, no waste to reduce, and no improvements for agile to bring. Since agile methods are about doing, measuring, and reflecting on the work, we often find that Superiority Complex is based mostly in wishful thinking and a lack of measurement.
If, on the other hand, a company has found the techniques that leave Agile in the dust, we would love to learn about and adopt this superior method at work. Agile methods are perhaps not the best methods possible, only the best ones we know as of this writing.
"Rejection of Insufficient Miracle" is the tendency to refuse to use a practice which leaves any current problems unsolved. "It's all or nothing, baby!" A team that cannot automate all testing sees little point in automating tests at all. Incremental development does not guarantee that a certain date will be met with all features in place, so there is no reason to iterate. The team must collaborate with other groups which do not work in an Agile way--what is the sense in only part of the company being agile? If we can't guarantee everyone will refactor the code, why should anyone spend the time cleaning up the design? By refusing incremental improvements, the organization rejects the very soul of the Agile way of working.
Samuel Johnson once said, "Nothing will ever be attempted if all possible objections must first be overcome." All software projects, even one that might be hypothesized to be free of technical error, are prone to failure from myriad reasons. All products, teams, and organizations are "insufficient miracles," leaving many of life's problems unsolved. Seeing that we have all gotten out of bed and come to the office, the question is whether we want to try a process that maximizes learning and quality (without guarantees), or an equally guarantee-free process that does not.

We fully recognize that there are teams that will not want to use Agile methods, and we suspect that there are organizations unwilling to modify their practices to accommodate a new style. We suspect that any method will not be successful in such organizations and that abandonment may be a reasonable strategy. As they say, "Change your company, or change your company."

In time, we may discover ways of fulfilling the promises of Agile with other methods. Agile is not the only possible way to improve an organization, even though we have found it to be one exceptional way to improve software-developing companies.

If, on the other hand, an organization is not interested in the kinds of benefits Agile methods promise (teamwork, growth, quality, productivity) we recommend that they become our competitors.

Branch Per Feature

2010-04-30T16:23:00.000-05:00

Font: Mechanical pencil for body, Erwin for heading
Sources: Tim Ottinger, George Dinwiddie (via mail list), Jeff Langr

Branch-per-feature is a common SCM strategy in which a branch is created on a central server for each feature that is under development. As a feature is completed, the branch is integrated back into the main development code line.

In some organizations, releases are composed by merging selected, completed features together. This seems quite rational, and can be made to work with enough effort applied in bursts. Every merge creates a unique, new configuration in the system that must be tested for side effects. If the merge has unintended consequences, then one or more features must be modified or the release re-composed without it. As a result, releases become major events in the life of the company with huge testing parties and great schedule risk. These times are frequently called "hell week" or "hell month" depending on the release periodicity.

In addition, the more two lines of code diverge, the harder it is to reconcile their changes. When work is integrated several times a day, it tends to be a fairly trivial effort. When it is integrated only a few times per month, it is rather harder. A few times a year, and it is surprisingly difficult. Likewise, if many branches are held for a long time, each branch will not only diverge from the main codeline but from other branches as well. This effect can make it rather difficult to estimate the effort of integrating branches, which contributes to the nervousness around hell week.

Agile teams integrate continually with great ease and success. Why, then, do some organizations hail branch-per-feature? Teams that use branch-per-feature as regular practice are often compelled to do so because they don't know which tasks/stories will actually be completed by the end of the sprint. It seems easier to hedge bets with version control systems than to tackle the organizational/political problems that frustrate planning and execution of sprints.

Too much WIP (work-in-process) means that too many tasks are undertaken at once. Branch-per-feature helps the team deal with the fact that work is not being finished predictably or reliably within the iterations. Many tasks are reported complete on the last days of the iteration, yet some of those are rejected. Branch-per-feature allows management to decompose and recompose the release at the tail-end as they find out what is actually completed.
In an agile team, as many as half of the features are done by the midpoint of the iteration and are being tested frequently. Very few changes are actually at risk of being left incomplete. In the best teams, missing an iteration boundary is a rare event, so branched features are unnecessary.
Features are too large if they cannot be completed in a small part of a single iteration. Otherwise the uncertainty prompts the team to fork the code base. The forked code base is more difficult to integrate as it diverges from the original code line. Fear of difficult integrations actually encourages the team to hold isolated branches longer.
Agile teams instead look to ensure features are small enough to completed within a few days. Small features completed in a day or two rarely require complex merging. Any overlap of effort can be easily coordinated with other team members during stand-ups or ad hoc conversations across the team table, further minimizing the chance that a merge will be necessary.
Structure is poor if changes routinely span many files in many libraries or assemblies (something Martin Fowler refers to as "shotgun surgery"). When a feature's implementation is scattered all over the code base, it is harder to accurately make changes and harder to predict when work will be truly done. This uncertainty drives the team to isolate rather than integrate.
Agile teams are highly cognizant of the value of simple, SOLID design. They understand that systems exhibiting true cohesion and minimal duplication dramatically lower the need for shotgun surgery.
If there is no way to turn off incomplete features then the team will fear customers stumbling into incomplete sections of code and causing damage to data or additional customer support burden. This force drives developers to develop code in isolation from the main codeline, which of course increases the cost of integration.
Agile teams view changes to the system holistically, breaking down each new feature as a series of incremental changes to the mainline. They understand that while this requires some level of overhead, it means that merge hell is minimized, and that it demands a better system design. For larger changes, they look to solutions such as branch by abstraction as helping provide both benefits.

Top Ten Reasons We Love Agile Certification

2010-04-01T09:48:00.007-05:00

Source: Tim Ottinger and Jeff Langr
Font: Narkisim

The Seven Code Virtues

2010-03-10T18:36:00.003-06:00

Authors: Tim Ottinger and Jeff Langr
Font: Burst My Bubble

Programming pundits often decry the dismal state of code in the world. We hear speakers demand professionalism or a more craftsmanlike value system, rigorous certification, etc. In response to these very demands we find contradiction of these very concepts. The argument is frequently made that whether code is "good" or "bad" is subjective and situational. We beg to differ.

To promote a shared set of programming values, we propose these seven virtues of code:

Working, as opposed to incomplete
A program that works is simply superior to one that doesn't work. We contend that a working program now is of higher value than one that might work some day. To this end, incremental and iterative methods (such as agile methods) push us to complete small features as soon as possible, with improvements and expansions to follow.
We ensure code is working by writing tests before and after writing code as we consider more success and failure modes. We can tell code is working by running the tests and by using the software.
Unique, as opposed to duplicated
The worst thing we can do to working code is to duplicate it. Copies and near-copies scattered willy-nilly across the code base makes code difficult to maintain. We struggle to eliminate duplication each time we refactor in our red, green, refactor cycle.
A dirty software industry secret: Many "stepback" or "regression" errors are not really re-broken code, but are instead examples of fixes to duplicated code.
We can tell that code is duplicated visually (common paragraph structures) or by the use of duplicate detecting tools like Simian.
Simple, as opposed to complex
Simplicity here refers to the number of entities, operations, and relationships present in any particular routine/function, and not to the readability of that module (which we call "clarity").
The best way to increase simplicity is to use simpler structures and algorithms. Reducing complexity in this way often translates to improved runtimes, smaller code size, and easier optimization.
We can also improve simplicity of one routine by extracting methods so that a series of manipulations becomes a single step as far as all of its callers are concerned. By moving the extracted methods to the appropriate classes, we also further develop the type system. After extraction, the code still takes all of the same steps, but those steps are evident in far fewer places in the code. The extracted methods are also simpler because they are unencumbered by their original context, a fact which aids us in finding yet simpler algorithms and structures.
Such simplifying code migration is at the heart of object-oriented design.
Clear, as opposed to puzzling
The meaning and intent of code must be obvious to the reader. Code misunderstandings generate errors. Confusion over code creates delays.
While high-level languages make it easy to see what code is doing, there is still an art to producing code which communicates its goal and intent. The consensus of multiple readers is nonetheless a reasonably consistent measure of clarity. Therefore, the most reliable way to make code clear is to have multiple colleagues reading it.
When one sees an improvement in readability from merely renaming variables, classes, or functions it is because one has improved clarity without changing any of the other virtues of the code. Clarity is further amplified by other virtues such as simplicity and brevity.
Easy, as opposed to difficult
Adding and modifying code should not be an arduous process. Ease is largely a matter of how much code must be typed in how many places, and how much configuration must change. In a particularly ugly code base, the easiest way to get code working is to implement a hack in an inappropriate place. In a truly clean and simple code base, putting a correct design into place is often as easy as a hack. Uncle Bob Martin has stated that design has degraded when the doing "the right thing" is significantly harder than making "an ugly hack."
Developed, as opposed to primitive
A primitive system is not necessarily simpler (fewer parts), nor easier (less thinking and typing), nor more clear than a developed system. Primitive code tends to be characterized by Duplication, Feature Envy, and Primitive Obsession code smells. These make a primitive solution more complex, more difficult, and less clear than one built with a well-developed type system.
In an object-oriented system, the developed type system of an application provides well-thought-out classes whose methods make continued development easy.
A system is well-developed when functionality appears to be just where one might expect it. String methods on strings, account methods on accounts, and button activations and the like merely make calls on "business objects."
Brief, as opposed to chatty
It is valuable for code to be as brief as possible without sacrificing other virtues. This is part of the reason that language tools like LINQ and list comprehensions and closures have become so popular of late. All programmers, including the one who writes it, benefit from writing and reading less code (as long as this smaller amount of code is otherwise clean).
Code that is long and chatty is much more likely to contain hidden errors. An overly cryptic method is likely to be misunderstood. Either one is hard to take in at a glance and understand.
Playing "programming golf" is actually a meaningful activity. If one can make the solution to a problem smaller without sacrificing clarity (or indeed may improve clarity by reducing the solution to a smaller form), then one is reaching a more brief form. The distance from an ideally brief, clear form is unwanted verbosity (chattiness).

Personal Objections To Agile Process

2010-03-08T23:38:00.006-06:00

By Tim Ottinger and Jeff Langr
Font is Kristen ITC

We have already discussed organizational objections to adopting Agile work methods. Here we discuss the personal objections.Agile development has never claimed to be an easy fit for all organizations.

We understand most of the reasons that agile transitions can be quite difficult for organizations. Likewise, individuals may be emotionally invested in certain structures and practives so that converting to an agile workstyle is perceived as threatening and undesirable. We again spent time collecting and categorizing a great many complaints, finally boiling (most) of them down to fit on our 7 +/- 2 bullet point format. We find the categorizations given here to be helpful, and hope that they will be useful to the coaches, managers, and developers who visit the Agile in a Flash blog.

Personal Bubble/Social Dysfunction The software development industry's long history of attracting anti-social sorts aside, there are some legitimate reasons that people retreat into a personal bubble. Some team members may have bad history together, ranging from the awkward (ill-fated past romance) to unpleasant (adversely opinionated pair) to intolerable (abusive partner). Some suffer from issues such as a simple timidity, fear of exposure for doing non-work tasks at the office, or a tendency toward introversion. There are iron-clad issues such as actual mental or emotional disabilities. Cultural issues can make understanding each other in a team more difficult.
The personal bubble is a tough issue to overcome, but we don't work in tight teams because it is comfortable. We work in this manner because of the advantages it can bestow:
- improved code quality
- ongoing opportunities to learn new techniques
- wider exposure to the code base
- a trustworthy, open communication channel with the customer
- process improvement based on experiential data
- a team aligned on common goals
Lone Ranger Teamwork is the Agile Way, but some individuals prefer immediate gratification with immediate recognition. The fictitious Lone Ranger would ride into town, solve a mystery, rescue the innocent, restore the peace, and disappear, leaving behind a single silver bullet as a signature. This romantic vision is appealing to many programmers. Everyone dreams about being the hero.
The downside is that a team is functional to the degree that it does not need to be rescued. The Lone Ranger may have been the hero of the day, but he did not share the knowledge and techniques that led to his success. The Lone Ranger does little to help the rescued learn how to solve similar problems in the future.
A better role model is the Karate Kid's mentor, Mr. Miagi, who not only rescues Ralph Macchio's character, but also teaches him to fend for himself. Skilled practitioners who can teach others are superior assets to the team and the organization. Agile teams provide superior mentoring, which leads to teams developing the art of making good decisions.
Old Dog "Habit is habit," said Mark Twain, "and not to be flung out of the window by any man, but coaxed downstairs a step at a time." This is especially true for those productive habits which have served us in the past. Sometimes people don't want to learn any new technologies or methods, and even those who are excited about new skills will revert to old habits under pressure.
Agile presents significant challenges to the old dog. Practices like TDD require developers to think about solving problems in a different, even inverted manner. Agile planning can invert the flow of how everyone thinks about their work--people once at the tail end of the cycle must think about how their role changes as they look to provide value earlier and more incrementally.
It may help to realize that agile is not only a change to how the code is written, but a way to ensure that the individuals in the team can develop personally and as a team. It is a way to optimize the meaningfulness of the work that is done. It is a means to gain respect for a developer's contribution. It is likely to increase the perceived value of the Old Dog's work, rather than merely inconvenience him.
Zero Sum Game It is especially hard to engender cooperative behaviors when the development team (or its leaders) are competing against each other for position, respect, compensation, or autonomy. If the team thinks in terms of a zero-sum game, then they feel that they can only win if their teammates lose. In organizations with a history or risk of layoffs, developers will scramble to avoid being at the top of the pay hierarchy or at the bottom of the performance stack, knowing that those ends tend to be chopped first. In organizations that reward individual effort, one feels the need to be the last to leave and the first to arrive to beat out his so-called "colleagues."
Agile promotes a different system. There is more than enough work to go around, and more than enough improvement possible for us all. There is plenty of credit to share. The Mr. Miagi sharing-and-mentoring model comes into play, and we can grow through our contributions to our teammates and our project. We can all have more success, and it lessens none of us.
Inferiority Complex The individual may fear he is less capable than his teammates, and may seek to hide his inabilities by working alone. He may be concerned about slowing down his teammates, or dreading daily humiliation at the hands of his teammates. Looking at the famous "rock star" agile developers, the insecure developer may fear that he could never measure up. The most senior persons on a team often fear displaying their few deficiencies in a pairing session.
The nice thing about a functional agile team is that you eventually will get over that sore ego hurdle. Things like switching pairs frequently to avoid silo pairing, collaborating in an open workspace, and delivering working software every few weeks all create true transparency.
A motivating fact is that pair programming is a path to personal improvement. Pairing with star programmers tends to make one into a star programmer. In relatively short time, any interested individual can become surprisingly competent. It is mostly a matter of seeing how it is really done, asking questions, and getting some guided practice.
Superiority Complex An individual who feels she has a pretty good handle on things may also believe that it is beneath her dignity to be "forced" to work with "mediocre" teammates. She may feel that she is the only one capable of working in agile, or that she is far above the use of common methods. Sometimes she even feels that she's already learned everything worth knowing about software development. To her, teamwork requires her to drag along incompetent partners, a practice that will slow her down and provide no personal upside.
As agile coaches, we react most strongly to the intransigent, overly cocky developer--but we need to remember that a projected superiority complex can actually be a mask for inferiority complex.Pairing can let the overconfident member fail more visibly, which can allow coworkers to help correct her shortcomings.
Some rightfully confident developers find that they also enjoy coaching and developing their coworkers. Bluster fades when developers realize that they are not competing against each other, but against errors and code faults. Finally, a developer with top chops in a pre-agile organization will usually emerge as a leader in an agile organization as well.
Rejection of Insufficient Miracle The individual experiences problems in the development team that are not addressed by agile methods. She realizes that it will not make all the teammates act like best friends, and won't make customer pressures or payscale changes any better. It may not make them happier in their workspace. Since the new system does not solve their individual issues, they have no reason to use it at all. It is not miracle enough for them.
The agile focus is on unencumbered and incremental development of the product, the team, the customer relationship, and the organization. Agile is more of a system in which to identify and address problems than it is a method or methodology.
One might choose to wait for an absolute solution to all problems, but in the meantime it might be good to invest in daily incremental improvements. Agile--in our view, the currently best bet for most software projects--will eventually fall out of favor for a better approach. We don't know what will supplant it, but we can confidently bet that the new methods won't involve eliminating incremental growth. Good things come to those who wait, but only if they work hard while waiting.

B.E.S.T. leadership

2010-02-01T21:37:00.001-06:00

source: Tim Ottinger & Jeff Langr
font: Brown Bag Lunch

Do agile teams require leaders? Neither the agile manifesto nor its principles speak about leaders. Instead, the principles emphasize teams, and the penultimate principle says that the "best architectures, requirements, and designs emerge from self-organizing teams." A self-organizing team would seem to obviate the need for a leader, at least in the classic organization's notion of being "singular and fixed."

But all teams, agile or not, need leadership. "Self organizing" is tough, and it's often far more effective for someone to guide a team along at times, through its various challenges. This leadership comes from someone who at the moment has the experience, the clarity to help drive the best plan, and the people skills to make it happen. Such leaders can be external to the core team (such as the ever-present line manager), but a successful agile team accommodates more dynamic leadership. Leaders arise from within as needed. The team learns how to support individuals in this role, however temporary it might be.

A successful agile team embraces incrementalism for all activities required as part of software development: planning, requirements gathering, analysis, testing, design, coding, review, and delivery. Leadership is but one more team activity that is best executed on an incremental and continual basis. At times an agile team member may fulfill the role of leader for perhaps a couple minutes.

Effective leadership requires four values that agile team members should also hold dear:

Benevolence: The team must trust that their leader won't throw them individually or collectively under a bus, that the team's achievements will not be used against them, and that their faults will not be grist for public humiliation. A benevolent leader is not a pushover, but even in confrontation, his interest is in improving the team and its members.
Effectiveness: If one cannot get things done, one cannot lead others. A recent study shows that the greatest motivator for "working people" is the ability to make progress. An effective leader will help make it possible for the team to make real progress every day. Within a team, the person who knows how to get started often emerges as a leader; this leader must also know how to keep moving forward when others would be blocked.
Strength: A leader does not lose her head in a crisis. A leader's infrequent NO carries weight. She does not beat up on her inferiors in order to look tough. If necessary, a strong, benevolent leader will remove some people for the good of the rest of the team. She provides feedback appropriately, instead of sweeping things under the rug or embarrassing team members with needless public confrontation. (Remember the old adage, "praise in public, punish in private.") Respect is best earned, not extorted.
Temporariness^*: A good leader does not install himself as a fixture in the company or team by building reliance on his personality and special knowledge. Knowing that success may lead him to new places, he is always helping others understand what it will take to replace his leadership. His actions when he is present will allow the team to continue successfully when he is absent.

When we find these four traits active in one person, we are looking at potentially legendary leaders. As followers, we need to support and encourage our best leaders and take pride in their work. As managers, we need to give them additional respect, autonomy, and possibly compensation. As clients, we should listen more carefully to such leaders and heed their warnings and advice. As team members, we should cultivate these four qualities in ourselves so that we may lead when we are called upon.

* "Temporariness" is a real word. We looked it up.

Refactoring Inhibitors

2010-01-25T12:14:00.003-06:00

source: Jeff Langr & Tim Ottinger
font: Daniel Black

Refactoring is perhaps the most significant part of sustaining a system in an agile environment. Entropy in a system is reality: Code degrades unless you make strong efforts to stave off the degradation. You need good controls (tests) that provide rapid feedback in order to effectively keep a system clean. If the system attains a state where its design is poor, maintenance costs can become an order of magnitude larger. This can happen more rapidly than you think.

Agile can exacerbate poor practice. You don't do a lot of up-front design, and you constantly add new features that were not pre-conceived in an original comprehensive design. Repeatedly forcing features into a design will result in a disaster unless you have a means of righting the design over time. That's what refactoring is about.

With the need to avoid degradation, it's important to recognize anything that might prevent a team from refactoring as much as they must. This card provides some inhibitors to refactoring that you should watch for.

Insufficient tests. Experienced developers know when they do the wrong thing, something that degrades the quality of the code. Yet much of the time, they don't follow up and fix the problems they just created. Why not? Too much fear over shipping a defect. "It ain't broke, don't fix it." They don't want to do the right thing, because that would require mucking with code that's already working--code that's not even "their" code.

The right thing is to retain a high-quality design through continual incremental refactoring, which requires the confidence to change the code. That confidence derives from very high levels of unit test coverage, which you can obtain through TDD. You won't get the confidence from test-after development (TAD), which at best nets around 70% (and often the complex areas are in that 30% of uncovered code). TDD enables confident refactoring.
Long-lived branches. The right thing is to ensure the system has the best possible design through continual refactoring. But developers working on a branch want to avoid "merge hell," and will plead for minimal refactoring as long as the branch exists. Branches should be short-lived.
Implementation-specific tests. "Changing the design of existing code" should not create the need for a lot of test rework, particularly if you are changing details not publicized through the class interface. The need to mock generally exposes information to a client (the test) that could otherwise remain private. The use of mocks should be isolated and abstracted. Make sure you're refactoring your tests! Minimize test-to-target encapsulation violations created by mocks.
Crushing technical debt. If you've not refactored enough, you'll soon be faced with a daunting challenge--code rampantly duplicated throughout the system, long (or short!) inscrutable methods, and so on. Once a problem gets bad enough, we tend to look at it as a lost cause and throw our hands up into the air, not knowing where to even begin. Don't let technical debt build up--refactor incrementally, with every passing test!
No know-how. Understanding how to properly transform code is one educational hurdle. Knowing if it's a good move or not requires continual learning about design. Developers without significant background in design will be reluctant to refactor much, as they're not sure what to do. Learn as much as you can about design, but start by mastering the concept of Simple Design.
Premature performance infatuation. The goal of refactoring is better design, which to most means more cohesive and decoupled. That means a good number of small classes and small methods. A simple refactoring, like extracting a method solely to improve cohesion and thus understanding of code, can frighten some programmers. "You're degrading performance with an unnecessary method call." Such concerns are almost always unfounded, due to things like HotSpot and compile-time optimization. A true performance expert, working on a system with some of the highest transactions in the world, backed me up on this one. Make it run, make it right, make it fast. -Kent Beck (and make it fast only if you measure first and after)
Management metric mandates. Management governance (wow, do I hate that word) by metrics can have nasty, insidious effects. Examples:
1. "You must increase coverage by x percent each iteration." Actual result: Developers tackled each story with a hacked-together written integration test, not a unit test, that blew through as much code as possible. Developers then hastily created new tests by copy-paste-vary. No time left to refactor--they just need to hit their coverage numbers! Later, changes to the system would break many tests at once. Since the tests were barely comprehensible, developers began turning them off.
2. "We need to reduce defect density." Defect density = defects / KLOC. Well, anything based on lines of code is useful only as far as you can throw it, and you can't throw code (the bits fall everywhere). You can improve defect density by reducing defects. Or, you can increase the amount of code. Most programmers aren't as evil to deliberately create more code than necessary. But if you say to your pair, "hey, we should factor away the duplication between these two methods that are 500 lines each," there will be either a conscious or subconscious decision to resist, since it worsens the metric.
Programmers will do whatever it takes to meet bogus mandates on metric goals. Use metrics to help uncover problem areas, not dictate absolute goals.

From a technical perspective, few things will kill an agile effort more certainly than insufficient refactoring.

Weinberg's (First Three) Laws of Consulting

2009-09-23T17:25:00.004-05:00

Font: AndrewScript 1.6
Source: Gerald M. Weinberg, The Secrets of Consulting

I re-read Gerald Weinberg's book The Secrets of Consulting (Dorset House, 1985) once every year or two. The first time I read it, about a dozen years ago, half of it seemed obvious while the other half seemed counter-intuitive. But I discovered that I too often ignored its obvious advice (i.e. "common sense"), and that its counter-intuitive advice is spot on.

Weinberg spills so many secrets ("give away your best ideas" being one of them) that it seems unfortunate to mention only the first three (and their corollaries), but getting past these is key to understanding the rest. And yes, I highly recommend getting a copy of the book so that you can discover the rest of the secrets, even if you don't consider yourself a consultant. Substitute "problem solver" or "agile coach" for "consultant," and most of the book will apply equally well (except perhaps the parts about marketing and pricing).

I actually lost a potential new client because of my inattention to the first law, or more specifically to its corollary. After having a phone conversation about the client's interest in transitioning to XP (this was about 5 years ago, when people still uttered the term XP), I met with the leadership team at their offices. On the phone, the person looking to bring me in talked about some of the serious challenges they had. But when I arrived, I heard little about these serious problems, only some vague notions that they wanted to improve how they did things.

Never mind, I was too wrapped up in my grandiose scheme to solve all problems for them using XP. I mentioned the challenges I had heard about on the phone, and indicated that I'd be able to help them fix it all. "What makes you think we have such serious problems?" Oops!

What Weinberg points out is that it's very difficult for us to admit it when we have serious problems. I didn't get the gig, because were I to have waltzed in and solved many large problems, it would have been far too embarrassing for the people in that room. Since then, I've promised as much improvement as their pride is willing to admit--per Jerry, 10%. (Of course, there's nothing that says you can't deliver more, as long as you are cautious about who gets the credit--see rule #3). Just last week, I found the rule to be dearly applicable in my personal life.

As far as the second law is concerned, we all tend to follow comfortable patterns, and this is often the cause of the problem: Once you're in a rut, it can be hard to get out. "We've always done things this way, that's just the way it has to be." The trick for a consultant is to help someone get out of a rut--which requires a change in direction--without themselves starting to fall into the same rut. You don't want to stay in one place too long as a consultant.

Some people have found Weinberg's "secrets of consulting" to be nothing short of greedy and cynical. They suggest the third law is all about taking as much money as possible from the client on an hourly basis. But Weinberg points out that this notion of not getting paid by the solution hearkens back to the first law: A solution expensive enough to require a consultant requires a problem too big to admit. Is it cynical to work in a manner that meshes realistically with normal human behavior? I don't think so.

I hadn't looked at The Secrets of Consulting in about two years. That's evidence of the rut I was tracking in. I've recently been shoved out of my rut, and I am thankful that someone reminded me (with the utmost subtlety) to revisit the book. I'm looking forward to re-amplifying my impact!

Stopping the Bad Test Death Spiral

2009-09-09T23:34:00.003-05:00

Fonts: Daniel, Daniel Black
Source (SCUMmy Cycle): Ben Rady, Rod Coffin of Improving Works from their Agile2009 presentation.
Source (Remedies): Tim Ottinger & Jeff Langr

The "SCUMmy Cycle" is all-too-common. A team with legacy (untested) code tries TDD hoping they will be able to continue making improvements. First efforts result in integration tests, perhaps because the code is tightly coupled and not cohesive. The team intends to someday replace them with proper unit tests. A team lacking essential understanding of the qualities of a good unit test will write integration tests unwittingly.

Months or years later the tests are abandoned, with a significant investment in their construction and maintenance having gone to waste. How does this happen?

Here's how the cycle generally plays out:

Only integration tests are written. One common cause: business logic is intertwined with UI or database code, perhaps as a reflection of examples found in framework and library tutorials.
More tests are added, until running them is slow/painful. Fifty to 100ms to interact with a database doesn't seem bad. But multiply that by a few hundred or thousand tests, and a even small test suite execution takes several minutes.
Tests are run less often because developers can't afford to run them. Developers will resist running ten-minute test suites more than a few times a day. Less-frequently-run tests are much harder to resolve when they fail. Large tests tend to be fragile and fail intermittently. They have runtime dependencies on external elements that are not controlled by the tests, and perhaps dependencies on side-effects other tests.
Tests are disabled because they are unreliable, obsolete from lack of maintenance, or simply too slow to tolerate.
Bugs become commonplace just as they were before the team started doing automated testing. Disabling too many tests lowers coverage and the remaining tests become ineffective.
Value of automated testing is questioned--"we're no better off than before!" And yet the team still wastes time writing and (sometimes) running tests.
Team quits testing in disgust, or managers mandate a stop to testing. The experiment is deemed an expensive failure. Teams are now free to return to the good old days of rapid coding and expensive manual testing. As W. Edwards Deming said, "Let's make toast the American way: I'll burn, and you scrape."

A sad progression, and it's real. Both of us (Tim and Jeff) have experiences confirming Rod and Ben's SCUMmy Test Progression. At each step along the progression it becomes harder to salvage the testing effort. Plenty of teams have started rough, but have recovered before reaching the bottom of the progression.

One possible lesson: it's cheaper to have no tests than to have bad tests. A better lesson: life is too short to settle for crummy tests.

The flip side of this card lists some therapeutic strategies for each downward step:

Only integration tests are written -> Learn unit testing. This also ties in with a better understanding of (and adherence to) the SRP and LoD. Consider hiring a short term coach to teach healthy habits in the team, or invest in better reading materials and the time to absorb the material. Attend a training session.
Overall suite time slows -> Break into "slow/fast" suites. Establish a time limit for the fast suite, and strive to keep the fast suite large and fast. Thousands of unit tests can easily run in under 10 seconds. Consider a tool like Infinitest to help keep tests running fast (but note that everything works better in a system that exhibits low coupling).
Tests are run less often -> Report test timeouts as build failures. The measures you institute will be arbitrary, but the key focus is on continually monitoring the health of your test suite. If the suite slows dramatically, developers will soon skimp on testing.
Tests are disabled -> Monitor coverage. New functionality should have coverage in the mid-to-high-90% range, and the rest of the system should exhibit stable or increasing coverage. System changes resulting in reductions in coverage should be rejected. Integration tests provide broad coverage, but you should either replace these with unit tests or elevate them to acceptance tests. You should otherwise delete disabled tests.
Bugs become commonplace -> Always write tests to "cover" a bug. These tests should always be written first, a la TDD. A defect is evidence of inadequate test coverage. Make sure you always track defects and understand the root cause of each and every one! Insist that these tests be fast tests.
Value of automated testing is questioned -> Commit to TDD, Acceptance Testing, Refactoring. Committing to TDD means learning how to do it properly--it is of low or negative value otherwise! Also note that many "regressions" are rooted in code duplication. Refactoring to eliminate duplication is critical for quality improvement. It is reasonable that a quality crisis causes a reduction in new features production.
Team quits testing in disgust -> Don't wait until it's too late! If a team's gotten to this point of admitting defeat, it's often too late--management won't normally tolerate a second attempt at what they think is the same thing.

In the adoption of unit testing, a few training sessions and a little time with a good coach can make all the difference in the world.

If you must self-coach, then ensure that team members don't view TDD as simply "management forcing programmers to test their code." Ensure that programmers understand the significant design and documentation benefits that TDD can deliver. Ensure they understand the scalability advantages of fast automated tests over manual testing.

A team that understands TDD and strives to attain the benefits it offers will avoid the Bad Test Death Spiral.

Test SCUM

2009-08-25T21:08:00.004-05:00

Font is "Pen of Truth"

Source is Ben Rady and Rod Coffin of Improving Works, given in an agile presentation at Agile2009.

In sharp contrast to the FIRST principles of good unit tests, Rady and Coffin give us these properties of completely bad (scummy) unit tests.

Slow: We discussed now important speed is in unit tests. I find that when tests are more than 40 seconds, people have to decide to run them, rather than feeling free to run them immediately after every small step. Rady's Infinitest runs tests automatically and analyzes the tests to selectively exclude those which have no (discernable) transitive dependency on the system under test, just to eek out some extra speed. While it is preferable to run all the tests all the time, in many circumstances culling the unrelated tests will give back some speed.
Tests are generally slow because thy provide insufficient insulation from the environment. They tend to spend a lot of time waiting on clocks, file systems, databases, web services, or the like. Slow tests are best rewritten with isolation from the environment.
How fast is fast? I find that I can tolerate a usefully large battery of tests if each of them takes about .002 seconds. I can tolerate any number that starts with a dot and two zeroes. I might be able to tolerate a very few with only one zero immediately after the dot. More than that is "slow". It doesn't take many multi-second tests before developers feel reluctance to run them.
Confusing: We have emphasized that good tests isolate errors and their causes. A confusing test is one that fails to isolate a specific error. This may be because it has too many things going on, or because it is simply unreadable. It is preferable that the combination of the test class name, the test method name, and the assertion gives all the information a developer needs in order to correct a misstep. In a confusing test, those three items are not enough an the entire body of the test may not shed light on the failure mode. Confusing tests are best rewritten as smaller, more clear tests.
Unreliable: Tests should be repeatable: they should always fail the same way, or always pass for the same reasons. Tests that run only in isolation or on certain days or times of day are not reliable tests. One of the best ways to judge reliability is to run tests repeatedly. Note that overspecification often causes tests to fail in unexpected and non-useful ways.
Missing: The tests that you don't run provide you no benefit, and quite a bit of harm. Tests help you to design your production code, and also help you to tell if you are making decisions that break the system in unexpected ways. Not having the tests means that you just don't know. Maybe your design is iffy in ways you hadn't noticed. Maybe you've broken other code with your last line of code. Maybe the behavior you hand-verified last hour is no longer occurring as you expected it to. The tests you did not write are the ones that are really holding back your productivity.

While we could list other unwanted qualities of tests, these seem to describe the most painful sins.

12 Principles for Agile Software Development

2009-08-20T20:48:00.003-05:00

Font (once again): MechanicalPencil

The canonical source for these principles is the agile manifesto website.

These are the basic agile principles, abbreviated to fit onto a 3x5 card without requiring the reader to hold a magnifying glass. They are "sound bites" and not the whole story. Each of these principles can (or has) launched myriad blogs/articles, and indeed many of the other Agile in a Flash cards touch on these principles. We could easily build a distinct card for each, though that would inflate the size of our eventual card deck quite a lot.

It has long been Tim's perspective that Agile is about having a short reach so we are allowing that point of view to color our summary of agile principles.

Satisfy the customer through early and continuous delivery--We shorten the distance between requirements gathering and customer feedback. The period is shorter because we plan less change at a time, and in return we get more opportunities to steer the software in a direction the customer appreciates. Notice that the principle actually says "continuous delivery", not just "quarterly" or "bimonthly." Early and continuous delivery is not about working faster, only about working sooner.
Welcome changing requirements, even late in development--We shorten the distance between conceiving and implementing an important change. We don't have to wait for a redesign of the whole system, or for the next system to be built. This is not to say that no features will be delayed; feature requests are frequently reordered or even dropped. The agile difference is that such changes take effect sooner.
Deliver working software frequently--We shorten the distance between the system-as-designed and the system-as-built. Both will evolve as we learn more about the system as it should be built. We also shorten the distance between planning and delivery, giving more opportunity to improve the efficiency and effectiveness of our work.
Business people and developers work together daily--We shorten the physical distance between a question and its answer. Moving the customer to a different building, area, room, or even to a cubicle just around the corner dramatically reduces the number of questions we ask the customer. With collocation, the business and technology sides learn to better understand each other and to make more mutually-beneficial decisions.
Build projects around motivated individuals--We shorten the distance between intent and action. The goal is to build an agile team of skilled professionals who care about all the business concerns including schedule and content, and who will work in a highly-engaged and result-oriented way. Such individuals need no babysitting and very little direction. Such a team will refused to be blocked, and will produce their best work at all times. Management does not have to spend time on motivational issues or "cat herding" so common to less-motivated teams.
Convey information via face-to-face conversation--We shorten the time between a question and its answer. Agile teams work in bullpens because it makes it much easier to ask questions and offer suggestions. Things that should be communicated get communicated, not forgotten, diluted, or otherwise insufficiently communicated. While there are many attempts to go agile without co-locating team members, we are not aware of any which have the kind of success which is typical in co-located teams.
Working software is the primary measure of progress--We shorten the distance between thinking we're done and knowing we're done. The team should be judged by the product it produces, not by the rate of typing or number of degrees, or hours worked per month, or how quickly the members walk from the parking lot, or how quietly they work from their individual cubicles. A good team frequently produces quality software the customer wants. All other measures are subordinate or irrelevant.
Maintain a constant pace indefinitely--We shorten the distance between productive bursts. This doesn't mean that management sets a large minimum hour limit for developers to endure months or years at a time. Excessive overtime cannot continue indefinitely without severely impacting quality. Instead, we choose a pace that allows us to go home tired and satisfied in the evening, and then return fresh and ready to rock in the morning. For normal people with families and bodily needs, that pace will not be 90 hours a week, and it probably won't even be 50 hours a week. We are never impossibly far from our life-sustaining relationships and activities.
Give continuous attention to technical excellence--We shorten the distance between implementation and ideal. An agile developer is never more than a few minutes away from the last time all the tests passed. Collaborating classes are not at the opposite ends of long chains of contains/references/inherits relationships (e.g. "train wrecks"). Developers need not wait to clean up redundant or confusing code. If working code is the measure of agility, then excellent code must be defined as code that accepts changes gracefully. An agile team takes steps to ensure that code gets better with each iteration.
Simplify: maximize the amount of work not done--We shorten the distance between comprehension and completion. We eschew things that don't matter. If we're less encumbered by unhelpful tasks and unwanted features, we've shortened the reach to useful work. We also attempt to simplify code (reducing the amount of reverse-engineering other programmers must do). Agile programmers tend to follow the rules of simple design.
Teams self-organize--We shorten the distance between need and action. We don't wait around to be told who does what. We do what needs to be done, not waiting for direction or supervision. We attack problems with fervor, mitigating risks and clearing obstacles.
Teams retrospect and tune their behaviors--We shorten the distance between introspection and adaptation. Improvement is never far away. Each iteration, we explicitly find ways to improve process simplicity, code quality, technical excellence, and predictability of results. We analyze problems and obstacles, and look for root causes and their solutions. We actively plan to use better techniques, tools, and process flows. We act on the plan in the subsequent iteration, without delay.

These principles are fairly simple in concept, but are profoundly deep in practice. If you are transitioning to an Agile work style or are looking for ways to improve your current Agile practice, we suggest you begin again with the principles espoused here.

Essential Unit Test Cards

2009-07-28T10:03:00.007-05:00

What are the essential unit test cards? Some of you have asked for these to be assembled into one place, so here we are:

With this deck of cards, you have enough information to understand how to go about TDD, how to work around some problems, and why you should bother. Throw in the wikipedia article and its links (, a nice xUnit framework for your language, and you should be able to competently carry out TDD on your current project. If not, let us know what TDD cards you really need, but don't have.

Plan-Do-Check-Act

2009-07-24T09:44:00.005-05:00

Font: Daniel Black

Thanks to Igor Czechowski for suggesting this card.

At the core of agile is short cycles of Plan-Do-Check-Act (PDCA). These steps are also what it means to be scientific in approach, at least per the definition of science that says you are following the scientific method: hypothesize, experiment, evaluate. Those who say agile isn't disciplined have not made this connection.

Plan-Do-Check-Act is echoed in agile practices, particularly TDD. The Plan step is about "making the expected output the focus," per Wikipedia. Writing a test that first fails captures your plan. After observing test failure, Do means you write enough code to make the test pass, and Check tells you to verify the actual results against the expected output. If there are differences you must Act to determine their cause and correct your implementation (or sometimes your expectations). In any case, you must also Act by observing the changes to the environment--the rest of the system--and "determine where to apply changes that will include improvement," which can mean some doing some incremental refactoring.

The iterative-incremental development core of agile also follows the cycle:

Plan - iteration planning/definition of acceptance tests

Do - day-to-day iteration execution

Check - verification of results using acceptance tests

Act - retrospectives and subsequent planning

As with many of the best modern ideas for quality control, PDCA in part comes from Dr. W. Edwards Deming. While Deming credited Walter Shewhart for the original concept of PDCA, Deming gets credit for popularizing the cycle.

Naming Fail or Comment Fail?

2009-07-22T12:34:00.002-05:00

Names changed to protect the innocent:


        /// Adds Sessions which fit in specified date-time range
        private void ReadSessions() {

Abbreviations

2009-07-20T08:21:00.005-05:00

Font is Mechanical Pencil

Source: Vadim Suvorov, Tim Ottinger

When can we use abbreviations as names in our source code? Can we ever use abbreviations as variable names? Vadim and I explored this issue, and Vadim in his orderly way of thinking enumerated these these principles. I'm sure that not everyone will find these to his liking, but I think these principles are well-reasoned and sufficient. I think these nest nicely into my naming rules in general, though my preference is to avoid any kind of encodings.

Shared, not Personal: the abbreviation should not be something the author has invented, and which other programmers will not recognize on sight.

Consistently Used: the abbreviation is not punned, so that it means one thing in one context and another thing entirely in a different context. Note that a very short abbreviation has a greater likelihood of collision (fn = function or filename or ...?).

Must Be Justified: If the programmer is to use abbreviations, then he should have clear reasons why the abbreviation is required. If, for instance, the abbreviation helps the reader see the unique part of the name without being distracted by context warts (prefix ofr suffix). My addition here is in the case of parallel names Persistant.User v. Domain.User if only one name is present, then no prefix is justifiable. My partner in this enterprise may not agree (likely with well-considered reason).

Special Latitude Given for Domains: in solution domains, some abbreviations are common and it is beneficial for the programmers to know them. If I worked with military jet software and didn't know IFF, or in education and didn't understand ILT, or if I worked in accounting and didn't grasp AP or AR then I would be less effective when communicating with the Business/Customer.

To the extent that your team deems to use abbreviations, we recommend these criteria for your consideration. Clean naming is one of the most important factors in writing understandable code, and has no negative effect upon compilation or runtime speed, and so is very precious to me. Yet, in the appropriate context, I am open to sacrificing the "no encodings of any kind" rule to appropriate use of well-reasoned abbreviations, with the caveats given above.

Planning Poker (R)

2009-07-16T10:05:00.006-05:00

Source: Wikipedia
Font: AndrewScript 1.6

Planning poker, trademarked by Mike Cohn, is a modernizing of a 50+-year-old estimating process known as Wideband Delphi. Estimating is not far from the dark arts, and attempts to make the process serious and exacting are ill advised. James Grenning devised planning poker as a quick and entertaining way to come to consensus on estimating stories in agile. I've found it can help dramatically minimize the tedium of estimating through a large stack of stories.

A typical point scale might be 1, 2, 3, 5, 8, 13. Resist larger scales--toss the higher-value cards. You might replace them with one card that says "too big."

You might want to include a few additional cards: 0, ? ("I don't have clue"), and infinity. The value of adding a 0 card is debatable (nothing is free, and even if development is "free," testing a story is never free), but you may find some usefulness in having it: Sometimes, completing one story automatically includes another. Or, a story might simply represent a milepost achieved.

The wikipedia site provides good detail on the steps involved, but I highly suggest you make your own rules and stick to them. The section on anchoring is particularly useful: part of the reason James devised planning poker was to counteract the heavy influence on estimates coming from one individual. Make sure that when people divulge their card selection, they aren't watching and waiting on certain other individuals to show theirs first!

Before starting the meeting, figure out how long you'd like to spend estimating. If your backlog of stories looks pretty good, and there's a good understanding of the project by most people in the room (obviously not always the case), you might find that 5 minutes per story works well. Appoint a facilitator who can keep time and help keep the estimating session on track.

If the product you're building is less well-known to the participants, this process will take considerably longer, maybe 10-15 minutes per story. Do the planning poker estimates, regardless, and plan on doing them again during a quicker second meeting. If you feel like you are bogging down on a story, and understanding of it is not "critical path," set it aside, and plan to come back to it after other stories are visited.

For a backlog of not-well-understood stories, you will probably want a couple sessions. Some stories will need to be set aside to split or researched offline. Some stories will need to be revisited by the customer. One of the best things to do is give people time to go off and think about things (and having at least one night between sessions is always a good idea).

Still, you want to avoid investing too much time in estimation. The more time you invest, the higher the expectation that the numbers coming out of it are anywhere near perfect. Estimates are guesses!

Instead, the estimation meeting is best seen as a way to ensure that we have good, appropriately sized stories that are fairly well understood by everyone involved. The consensus mechanism in planning poker will quickly let you know if this is not the case. Getting confidence from a good ballpark project plan is almost a bonus!

Principles of Package Cohesion

2009-07-01T21:25:00.008-05:00

Post: Tim & Jeff
Source: Uncle Bob
Font: Segoe Print

Coupling and cohesion are the two most important principles guiding the quality of an object-oriented class design. Most programmers learned about these principles in their first week of exposure to OO. The rise of TDD has helped reinforce the value of low coupling and high cohesion (although many programmers still unconsciously and even consciously resist truly small, cohesive classes and methods).

Uncle Bob teaches us that these core OO principles apply equally to packages. The Agile in a Flash card for Principles of Package Coupling covers the dependency side of the dynamic duo--how do you structure packages so as to improve the coupling relationships between them? This card covers the other side--how should you compose a package? What is the definition of "cohesive," as it applies to packages?

The Reuse-Release Equivalence Principle (REP) - The REP tells us that classes should be packaged together because they are used together. This seems obvious, but many package structures are instead based around ideas like "functional areas," "architectural layers," or "originating team." The result? Users are inconvenienced, for example, by having to recite a litany of import lines at the top of each file. REP tells us to consider the destination instead of the source or even the structure of the code itself. It urges us to group things together for user convenience.
An entire system shoehorned into a single package/library would comply with this principle. But if the rate of change in the library was not extremely low, it would suffer from the problems addressed by the remaining principles.
The Common-Reuse Principle (CRP) - This almost seems like a restatement of the REP, but the emphasis here is on limiting the impact to consumers. Imagine an API package with two sets of reusable class clusters. A programmer might choose to consume only one reusable component, but changes to the other component necessitate redistribution of the entire package. An unwanted release unnecessarily burdens the consuming programmer, who must re-integrate and re-test the entire library in order to stay current. Where the REP leads us to conglomerate, the CRP leads us to split packages apart. This tension between the principles leads us to find the level of granularity that provides greatest convenience (least negative impact) to users.
In spirit, the CRP is a package-level restatement of the Interface Segregation Principle, which says to keep interfaces small and focused for similar reasons.
The Common-Closure Principle (CCP) - The CCP is an application of the Open-Closed Principle at the next level up. This principle suggests that you should group your classes around the impact of change. A change should optimally impact only one package; as many other packages as possible should be closed to that change. This varies from the other two principles as it recommends grouping classes around the way the code is maintained, rather than the way it is used. Modules with a high rate of change might need to be grouped by closure rather than by use. Highly stable packages might be better conglomerated (REP).

The principles of package cohesion are not absolute. Sometimes a packaging may satisfy all three principles at once, but often the principles represent competing principles. The development team will have to make trade-offs in order to find a balance that works. In general, smaller (and even smaller) packages provide the best chance for adherence to the CCP and CRP principles, although the REP says there is a limit to how small you will want to go.

Following these principles will require occasional re-packaging, which is upsetting to many users. However, correcting less-than-optimal packaging is a single deep cut that can halt the "death of a thousand paper cuts" caused when changes ripple across packages, or when users of a package have to deal with frequent irrelevant updates.

TDD Antipatterns

2009-06-19T17:05:00.005-05:00

(font is brianne's hand)

James Carr enlisted a group of fellow travelers to define a list of TDD Antipatterns, errors in judgement common in TDD practice. He provided an initial list for us to base our work on, and did a very fine job of filtering out the duplicates and near-duplicates, providing catchy names, and writing up the result. Note that his list is longer than ours since we have a terseness constraint. Read the full list.

I wish I had thought of it first.

The Liar is a test that runs, but does not test what it claims to test. It could be named after a class, but actually be testing another. The test might be called ShouldNotThrowExceptionsForPositiveValues, but actually use the natural numbers less than 5. Liars give a false sense of security.
Excessive Setup is common when the architecture is badly coupled and mocking is not well-used. This is often evidence of insufficient pre-factoring. A little dependency injection and a little interface use can go a long way. This is also common when programmers give in to the urge to test software "in context." One hopes that when they get to the assert they'll remember what scenario they were testing.
The Giant is a single test that tests more than a single scenario. It may have excessive setup, but then follow with a large number of manipulations and assertions. It may test entire subsystems. Adding a new assertion requires a programmer to reverse-engineer his way through the Giant to find an assertion insertion point, and requries the programmer to exercise care to not leave side-effects that will cause the last half of the Giant to fail. Giants are ticklish and hard to understand.
The Mockery is a real piece of work. A pair/team/programmer has actually replaced the system under test with a test double. The test proves only that the mocks worked as expected.
Generous Leftovers are left behind by tests that dont clean up after themselves and cause later tests to fail when run in the suite but not when run in isolation. The leftovers are typicall in static memory, on disk, in a database (for shame!) or some other persistent store. When leftovers are found, it's often puzzling whose they are, and what they are.
Local Hero is a test that runs well, and tests a system well, but only passes on the author's machine or network. Being environmentally-sensitive, such tests fail for peers and CI systems. Typical failures involve hardcoded paths, locally-installed libraries, and OS-specific assumptions.
The Loudmouth is a test that produces copious output. It is like the boor at the party who thinks every trivial event in his live is worthy of an epic tale. At one time, the loudmouth's story may have been worth hearing, but now it's just idle chatter that gets in the way of a real conversation with more interesting guests/tests.
The Secret Catcher is a test that seems to do nothing at all, but is secretly (implicitly) depending on any errors to produce exceptions. The fact that the code executed without exception is expected to evidence that the code works. These tests can eventually be reverse-engineered by every programmer on the team. Failure of the test always results in code spelunking, an unpopular passtime.
The Hidden Dependency is a test that secretly requires setup that is not present in the test itself. Perhaps it requires a certain data setup script, or a change in a configuration file, or another test to have already run with generous leftovers. Hidden Dependency tests are a special kind of evil.
The Stranger is a perfectly good test in a perfectly wrong place. It is not a liar, it's just not testing the same system (SUT) that the other tests are testing. Strangers don't cause problem except when you're looking for tests for class X and it's hiding among the tests for class Y.
Success Against All Odds is a test that will always pass, no matter what. Due to a series of missteps, the test won't fail even if the code is wrong. Often these turn into complicated indirect versions of "assert true == true" or "false == false". These can be a variation on Mockery or The Liar. It is likely that a test with Success Against All Odds was written as a green test, without ever having seen the "red" part of the Red->Green->Refactor loop.
The Slow Poke is a test that takes too long to run. If you have 15000 tests, and you want them to run in less than 45 seconds, you have a budget of 0.003 seconds per test. A five-second test will cause some irritation. A few 10-second tests will make people think twice about running the tests at all. A test that takes a minute is unlikely to ever be run by a programmer. Imagine what hell awaits the author of some of the three-to-ten minute monstrosities that exist in the wild! In a TDD shop, slow pokes cannot be tolerated. Note that many slow pokes are also Giants with Excessive Setup. Be warned.

Tim recommends that readers follow the link to the original article, which covers more territory than the index card can allow.

What is missing?

2009-06-19T15:57:00.002-05:00

We have dozens more cards we can write and post, so were not running short on ideas even though we can be short on time to get them all written up. Still, I wonder, if you could pick the next card for me, what would you want it to be about? Is there an area we've not addressed at all? Topics of interest to you that might be interesting to others? Guest authors we should contact? I'm all ears.

Pairing Workstation Configuration

2009-06-19T14:26:00.004-05:00

(font is SD Marker still)

Teams beginning to use pair-programming often struggle because of poor workstation configuration as they attempt to use their individual programming space. There is more to it than merely adding a second chair. Take a moment to review Pair Programming Smells and recall that there are physical limitations as well as psychological limitations to overcome.

Chairs sit comfortably side-by-side so developers can have equal access. If either person is physically limited from grabbing the keyboard and mouse, then the setup is wrong. Pair programming is about sharing the editing of code together. It is necessary that both have equal access. Beware corners: if you have a monitor in desk/cubicle corner, then necessarily one person has better access than the other and pairing breaks down.

Add an extra monitor (or two!), preferably a nice, thin LCD or plasma screen. An extra monitor can be placed where the pair members can both see it equally well. A thin screen doesn't need a desk corner. Also, all of the annoying popups (mail, chat, etc) can be placed on the monitor where the code is not displayed, where it can be ignored. Finally, it is useful to run a countdown timer on one screen while programming on the other, to enable pomodoro-like techniques. Pairing is best done in time boxes with regular breaks.

Get some USB keyboard(s) for pairing. You should have a comfortable keyboard with a long cord. If one of you requires/prefers an ergonomic keyboard, then carrying around their favorite keyboard is a reasonable concession.

One mouse per keyboard is best. This is again about equal access for editing.

Get docking stations for notebook computers because shoving the computer back and forth is a pain, and because docking stations can give you extra USB ports and VGA ports. There really is not a lot of cost involved, and it really helps keep the pairing "fair".

Pens, scrap paper, and index cards should be in reach. You might be surprised how often you need to take a note now and come back as soon as the code is passing all the tests again. With two people, there are more ideas to choose from, and each learns tricks from the other. Writing things down allows each partner to process it when he is not pairing.

IDE/editor of choice with shared configuration is a contentious bit. We need to use the same tools if we are to have equal access for editing. In some teams, the emacs/vim/eclipse/scite wars will erupt, but it is better if the team chooses and all members learn to get by in the chosen environment. If they won't decide which editor to use, how are they going to make group decisions about design and architecture? It is better to learn use an "inferior" editor than to have to wrestle the editing environment from each other several times a session. When it comes to coding standards and standard editors, it is a good practice to "be a sport" and choose to make the team work better even if it will cost you a little in the short term.

Pair programming is not a utopian practice. Some people don't enjoy it at first, and some never warm up to it. Regardless, it makes the code better. If your team wants to make the code better through pair-programming, then it is important that their attempts are not hobbled by a poor workstation configuration. For a little bit of money, a leader can make a big difference in the way a company puts out software.

SMART goals

2009-06-10T21:49:00.008-05:00

Font: Sterofidelic

The best lists never die. The SMART mnemonic has been around for at least half a century, per Wikipedia. SMART is similar to INVEST, evaluating criteria for goals and objectives instead of for stories.

SMART has generated many different word expansions over the years. Sometimes M is meaningful, manageable, or even motivational(!). Our Agile in a Flash card uses the supposedly preferred words. But as a result of this inconsistency, I struggled yesterday to recall the best choice for the letter R. "Realistic?" No, that's too close in meaning to attainable. A quick search revealed relevant (duh!). I supplanted my mild self-annoyance (at my inability to remember the better choice) with elation at the prospect for a new, relevant agile card!

In the context of agile, I've found SMART goals to be useful when discussing action items to come out of retrospectives. True, there's no reason these couldn't be treated just like INVEST stories. But I've found that selling something half-a-century-tried-and-true can be a little easier with some crowds.

Here are my thoughts about the relevance of the SMART criteria with respect to retrospectives.

Specific - Vague promises of improvement usually don't generate results. Think of the 5 W's: who, what, when, where, and why. Instead of "we'll try to get stories done earlier in the iteration," how about "the developers will deliver at least one story every two to three days to QA, who will complete testing of them within a day of delivery, so that we can ensure stories are 'done done' by iteration end." (And don't forget that "try" is a word you want to banish.)

Measurable - Attainment of our specific example goal might be validated by answering some questions: What was the average number of stories completed within two to three days? How many stories did not complete in this time? You can think of iterations as fixed time periods in which to run experiments; you can express a hypothesis that validates or disproves the value of each experiment by capturing relevant data.

Attainable - It's important that a team can check off completed goals, to reinforce the sense of achievement. Obviously goals that your team can complete in an iteration best meet this criterion, but you don't want to have only short-term goals. There's nothing wrong with long-term goals; just make sure there's a way to measure incremental progress.

Relevant - Too many trivial goals can give a bloated sense of achievement. Shortening daily stand-up meetings by limiting them to five minutes might seem beneficial, but does it really change anything? What's the real problem? Don't hesitate to attempt dramatic changes, and don't hesitate to think outside the box that pseudo-agile dogmatists might otherwise paint you in.

Time bound - Like stories, many teams tend to have a problem with letting things creep past iteration boundaries. "We just need a little more time." Set up the experiment, define completion and success criteria, and grade the experiment: it was either completed or abandoned, and the hypothesis either held true or was disproved.

Get SMART today!

Team Smells for Coaches

2009-06-08T18:45:00.006-05:00

Every agile coach will have a number of factors they monitor constantly. Many are barely aware of the "smells" they are looking for, but will have a constant awareness of issues that indicate that a transition is not progressing well. We provide a short list of common smells that indicate your agile project is not going as well as you hoped:

Heaping piles of unfinished work will appear when assigned work is not being finished as quickly as new work is being assigned. This is generally a problem when the velocity is not being respected. The Theory of Constraints tells us that we have to subordinate the business to the bottleneck, a simple idea which is very hard to sell. Work may pile up in development or QA, especially if it is also piled up in sales.
Individual work assignments are typical in non-agile shops, but agile developers team up and pair on production code. Managers may demand that individuals are assigned work prior to starting an iteration so that they may track the productivity of individuals. This is a disincentive for agile teams, because pairing with a colleague risks the work one is personally assigned. By pitting team members against each other in the fight for individual rankings, work assignments can destroy true productivity.
Back-channeling is occurring if certain interests outside the development team (Customer or outsider) go directly to programmers and give them individual work assignments. This prevents the programmer from applying his abilities to the completion of the iteration. It also damages true productivity as others are required to pick up the slack, and the targeted programmer is forced to task-switch unpredictably. Back-channeled communications are a complex flow with political complications that prevent a team from doing their best work. It is better to work with a simpler, transparent management and communication structure. Note that sometimes back-channeling is an attempt by a leader whose work has been de-prioritized to get it pushed through anyway in defiance of the management structure.
Blame-avoidance behaviors cause programmers to fear refactoring, redesign, and any important practice outside of a narrow job description. In fearful organizations, blame-avoidance prevents both productivity-wasting activities and productivity-enhancing activities. Fear is a reason to stay wrong, or at least to be right only in familiar ways.
The urge to matrix-manage the team is a result of a lack of trust in the team by outside forces. When pressure is on any team, the certain leaders may seek to control other teams. When managers from outside a team try to manage the team by force or fiat instead of through normal channels (planning, prioritizing, etc) then it is clear that there are unaddressed problems in the management chain. These problems need to be resolved before they break down the team.
Cargo-cult ceremonies are ceremonies carried out for the sake of the ceremony, rather than performed for good effect. Examples are planning ceremonies where estimates are not accepted and stories are not scoped to the iteration, scheduled retrospectives where no problems are really solved, iteration boundaries where work is carried over to the next iteration with full credit for "completion", etc. These are signs that the team is "seeming" agile, rather than "becoming" agile. It shows a lack of real change in values.
Test negligence is a particularly nasty sign of an team's lack of agility. It shows that work is not being done by testing, and any pairing that is occurring does not support the agile practice. Agile teams depend on copious automated tests to accelerate their production. If tests are not being written, or not being run, then the team is not going to expand its capacity to produce. It is common that this happens in conjunction with back-channeling and/or work piling up. Skipping testing is a time honored way to seem to cut corners while actually making the software harder and harder to modify.
Guarded speech is a sign that the real values and the spoken values of the team are not the same. It may be that the team is trying to be agile, but certain leaders or managers are not willing to hear it or else that the management is bought into Agile development and the developers are not buying it. It may be that there is some barrier to productivity that is being held in place by political or personal power of some leaders. Barriers to transparency tend to be political. It may be necessary to change the team's political situation so that they may work openly.

Acceptance Tests

2009-06-08T13:26:00.011-05:00

Font: Complete In Him

The word "acceptance" implies that we have a high level of confidence that we can ship quality product. The goal for acceptance tests is to provide self-verifying, self-documenting executing examples of how the system is intended to be used. In a rough sense, they are use cases taken to the next level.

Define “done done” for stories. The acceptance tests for a story provide a contract for completion. As programmers, we know we are truly done when the code passes all of the acceptance tests. As consumers of the system, we know we can accept it when all of its tests pass. Progress in an iteration is often best tracked by the number of acceptance tests passing.

Are automated. Our Automating Tasks card provides detailed recommendations on when and when not to automate. Most importantly, this directive doesn't preclude the existence of tests that aren't automated!

Document all uses of the system. Think about the tests as examples that demonstrate valid uses of the system. This mindset will help you develop tests that can be read and understood by people wanting to understand the system. Such documentation never becomes stale (although it requires good effort to design the tests to be so expressive).

Don't just cover "happy paths." Stories usually require a family of tests to comprehensively cover alternate cases and exceptional situations. Inevitably, you will ship a defect that an automated test would have prevented. This previously "missed" acceptance test now becomes part of the complete test suite.

Do not replace exploratory tests. We will always want some manual testing above and beyond the tests that define acceptance criteria for a new story. Exploratory testing highlights the more creative aspects of how a user might choose to interact with a new feature. It also helps teach testers how to improve their test design skills. Don't forget to knee test!

Run in a near-production environment. How many nickels have you earned for hearing the phrase "It worked fine on my machine!?" Acceptance tests must execute in an environment that emulates production as closely as possible. This means they hit a real database and external API calls, as much as possible. By definition, then, acceptance tests are slow.

Still, minute to minute, I might want my suite of acceptance tests to run as fast as possible, as part of a continuous integration build. As a developer, I want rapid feedback, to provide high short-term confidence that I can move on. I know we'll still run the full suite in a proper environment overnight; having this fallback allows me to look at tactics such as using an in-memory database.

Are defined by the customer. Hopefully we know who the customer is. Agile acceptance tests are an expression of customer need (aka requirements). While all parties can contribute to statements of requirements, it's important that a "single customer voice" defines their interests as an unambiguous set of tests. (This also means that it's perfectly ok for a programmer to help with testing--they just can't be the one defining the tests.)

I'm often asked, "what about regression tests?" Most people define regression tests as "tests that make sure we didn't break something already in the system." My answer is that they imagine we had built this entire system in an agile, acceptance-test-driven fashion, i.e. where we ship only code that passes pre-defined acceptance tests. In this world, regression testing can thus happen every iteration--we simply run the entire suite of automated tests for all stories delivered to date.

Four Options for Agile Projects

2009-05-28T10:40:00.001-05:00

Source: Extreme Programming Explained, chapter 3, The Economics of Software Development.

Kent Beck, et al, say that XP makes a lot of sense if you examine the options that it gives management. These options are less open to managers whose teams follow a more traditional, specification-heavy method, but become feasible with early and continual feedback.

With XP, there is regular measurement of progress in running, tested features. Because running, tested, demo-ed features is a concrete and meaningful kind of completion, the data can be used as the basis for making decisions.

This from www.dmst.aueb.gr:

The theoretical basis for XP is an options-based pricing model of software development. As software is developed in an environment where technological, business, and human risk abounds, investing for the future through careful architectural design, elaborate code structures that will support all possible future requirements, and producing matching documentation can be a waste of effort. Changing requirements or technology may render parts of the system obsolete; design and coding energy expended in those parts will have been wasted. Kent Beck's insight lies in discounting elaborate design for future needs in favor of today's simplicity. Big and important design decisions are deferred until a particular feature is needed. Most important features are developed first, rapidly providing the customer with the functionality required and minimizing the risk of total project failure. As code evolves it can always be refactored in response to new needs. Surprisingly, Beck takes for granted that current technology state-of-the-art and programmer skills will not stand in the way of these continuous design changes.

The options an XP customer or development organization is granted through early, accurate management:

Option to abandon the software project. If the team is not gaining traction, or the functionality provided by the software is not a useful as expected, the project can be canceled. The ability to "fail fast" is a benefit of XP.
This has the additional advantage of allowing XP advocates to refer to canceled projects as "agile successes". :-)
Option to switch direction. Because the software is ready for use so early, there is an opportunity for the business to decide that they don't really want the system they specified. Agile teams can change direction because they don't have a lot of investment in the system "as specified", only in the system "as built".
Option to defer before investing. Since building is done incrementally and interatively, the business can choose not to produce features that may not have the same potential as others. Does the social networking bit have to be done before e-commerce? Should the e-commerce bit happen before we have full catalog capability? Being able to defer means that we can have the pieces we want most now. Of course, we can defer indefinitely (AKA: abandon) some features for further savings.
Option to grow to take advantage of a market that is taking off. This includes building scalability into the application as needed. It clearly also can mean growing the app in the direction of its uptake, such as adding social networking features or commerce features if those are drawing people to the application or SAAS.

Programmer Practices for Agility

2009-05-02T14:33:00.000-05:00

font: Another
source: Beck, Kent. Extreme Programming Explained, 2e.

This card lists programmer practices, both team and individual (or pair!), that can help us meet some of the rather daunting challenges of agile: How do we continually deliver increments of quality software that meet the changing and evolving needs of our customer, at a reasonable cost?

Continuous integration (CI) - Agile promotes continual forward progress. We expect programmers to frequently update the system with code changes, so that we can verify that the complete, integrated system is still working.

Test driven development (TDD) - TDD tells us to break down programming into technical tasks, each specified by tests that document small pieces of behavior. TDD provides us with feedback that we've built code that does what the tests specify. Most importantly, TDD supports the practice of design improvement.

Design improvement - With each change, programmers must reflect upon the code's new state, and correct any design deficiencies. Continual holistic attention to the system's design helps keep development costs from rising dramatically.

Coding standard - Navigating a code base without standards is like riding on a rough road: At the end of the day, the constant battle against all the little bumps, nuisances, and noise simply wears you down. A team that can't establish workable standards is a weak team. In addition to including naming and formatting, coding standards should include things like handling of build system warnings, build output standards (e.g. no stdout/stderr or stack dumps!), build timing standards, and test standards.

Collective code ownership - Uncle Bob's prime directive for agile development is "never be blocked." Class ownership standards create unnecessary blocking issues. We should all be comfortable with anyone touching any area of the code--as long as they're following all of these other programmer practices!

Simple design - Keeping the design as simple as possible allows for easier incorporation of new changes. Introducing unnecessary abstractions or complexities increases the cost of development. You ain't gonna need it! (YAGNI) More specifically, the practice of simple design is best described by Kent Beck's four rules.

System metaphor - A global understanding of the system and its concepts is essential for an agile team. We all need to build a common, ubiquitous language that helps us communicate with each other, and that includes non-programmers. The system metaphor is a system of names for its primary entities (classes) and how they relate.

Pair programming - How in the world will your team ensure that other developers are adhering to the common practices if no one reviews what is done? How will we ensure that we keep on track, and developer on time, if developers are left to suffer their own insecurities in their cubes? How can we shift from finding bugs to preventing them? Try it. If you have a real team, you'll like it.

The placement of practices on the card is not random. CI, the foundational practice for any agile programming effort, appears at the bottom. The left side represents more "community" practices--the things we practice more at a team level (technically, all of these elements are practiced as a team). The right side emphasizes design-oriented practices (similarly, however, all of the other practices have an impact on the design and vice versa). And pair programming is the best way to ensure we adhere to all of the practices.

Hmm, this card looks suspiciously like the technical practices of XP. How about that!

Priority Mechanisms

2009-04-24T08:18:00.000-05:00

Font is Marker SD

Setting priority for tasks is essential to agile/lean software development. Agile teams strictly limit the number of tasks in flight in order to have greater efficiency and effectiveness. The improved focus means code is completed sooner (not faster) and that product may be delivered to production more often. This focus is frustrated if we have too many "#1 priority" items and "emergency" items thrown in on top. Controlling the flow makes teamwork possible, and actually speeds the process.

We sometimes refer to the system that filters tasks into priority order as the magic funnel. All tasks and features are metaphorically dumped into the top of the big funnel. Ideally, the first (or next) item that falls out of the bottom of the funnel is the absolute most important thing we could possibly be doing. It has won the prize. It is the task we should be working on.

Setting priority is unsurprisingly one of the hardest things a customer can do. Do you pick the story that satisfies the most "important" customer (where "important" varies daily, almost hourly, and by which person you ask), or the greatest number of customers? Do you pick tasks that you think will bring the greatest number of new customers, or please the existing customers? Do you streamline processing or go with aesthetics? What makes one story more valuable than another?

Since the problem is large, and depends on local standards, there are many ways of prioritizing stories. The method shouldn't be something a team should agonize about for weeks. The most important point is that the product owners are able to reach a consensus, and that the features they pick are truly important. Tactics can vary, provided the strategy is good.

Here are some schemes and techniques that might help build a working "magic funnel":

A simple priority triage system (one short sentence) was reported by Mary Poppendieck inLean Software Development as one of the simplest things that could possibly work. The rule doesn't have to be subtle or obscure. A maintenance team might adopt a three-part rule, where production crises came first, followed by bugs on the release-in-testing, followed by everything else. Features that affect all customers may come first, followed by those that primarily affect million-dollar customers, followed by those that affect half-million dollar customer, followed by whatever. It is possible that product stakeholders already have a rule of thumb that suffices 80% of the time. The other 20% of the time is settled through escalation.
Determine "The Constraint" as in Goldratt's writings The Goal and Critical Chain. If you can define the one thing that inhibits you from being successful, then you can prioritize all outstanding bugs and backlog items in such a way that those that remove the primary obstacle become top priorities. Goldratt was speaking of process steps and production, but why not apply it to features that sell or flaws that inhibit? It may be that scalability of your web application is more important right now than enhanced functionality. It may be that a difficult feature is the primary reason you are losing sales or even customers. It may be that one issue prevents you from expanding, growing, producing. Critical Chain shows us that we need to solve this one big problem. And then the one after it.
Covey's Quadrants from First Things First will have us divide work into quadrants, so that #1 are those things that are both important (to the future of the company or product) and urgent, #2 are those that are important but not urgent, #3 are those that are urgent but important, and the unimportant non-urgent work is simply eliminated from the backlog. These items are taken in quadrant order, so that important, non-urgent tasks are done before urgent, non-important tasks are considered. Covey, et al, were talking about personal importance and daily tasks, but why not apply it forward to planning other work that has potential value and obvious levels of urgency?
Value-First is the rather like the Covey and Goal approaches, where the work that provides the greatest value (frequently represented in customer satisfaction or decreased support) goes first. This sounds easy, but of course the problem is defining "value" and dealing with "value to whom?"
Risk-First would tell us to start on those things that need the most research and testing sooner. High-risk items have unpredictable schedules, and may not pan out at all. Such stories would be prioritized earlier because they cannot reliably be produced on a schedule. Alternatively, some will choose to use risk-last planning, so that the so-called "low hanging fruit" may be completed before moving on to less predictable work. Some organizations may want to plan a mix (70/30 or 80/20) of low-risk to high-risk features.
Greatest Good to the Greatest Number works like the other "value first" kinds of schemes, but adds voting to the scenario. Each customer, role, or market segment that would benefit from a change has essentially voted for it. Among items of the same importance/urgency quadrant, those with the greatest number of votes would go first. Changes with fewer stakeholders would be done later. This is a customer-focused version of "Bargain for Success."
Fixed-length action queue would work by using a short list of only a few bug fixes or marketable features. This list would be overseen by executives, and to push an item from "backlog" to "action queue" requires high-level approval. Items in "action queue" can be retracted only by executive order, since stopping a feature-in-progress represents a financial decision to throw away development dollars. The customer works to push items into the fixed queue as other things fall out. Most customers could have a list of two or three items that might be next if approved. This tight focus helps the Customer not lose focus on immediate delivery. It is a lot like the Biblical "Law of the Medes and Persians", famous for being unrevokable.
“Only One Thing” is a little game best used when the priority rule is more intuitive than explicit. The stakeholders are given a hypothetical situation that only one feature can be reliably developed in the next iteration/month/quarter, and are tasked with picking which one feature it would be. Once they have piced the solitary feature, they are asked why it is important to them. This game can be played with "only three" or "only five" for a larger sample size. Most organizations, having argued through the exercise, will have a Simple Triage System they can use for future priority meetings..
Bargain for success is another game-like system. Each product stakeholder is given a number of votes/dollars/tokens/chips to spend. They are allowed to buy into features in order to bring their priority up in the queue. Stakeholders can make deals with each other ("I'll give 7 tokens to your feature Y this time if you'll give 7 to my feature Z next month"). The game-like nature of the exercise may cause some to see personal "winning" as the goal, rather than the greatest good for the company, but it will drive consensus nonetheless. Ultimately, the stakeholders have decided either way.

Some of these techniques (Bargain for Success, Only One Thing, Fixed-Length Queue) may qualify this card as a "Power Card". They are not guaranteed to result in happy handshakes and back-patting among all stake holders. Some may even resent their work being treated as a game (though in my experience they usually prefer to work in a game-like system with some rules and a fair degree of bargaining authority).

The ultimate power card (not included) is "CEO/Owner Demands". Most development organizations will pitch in and do all they can to get the feature completed well and soon. As long as the demands are within reason it should not be a problem. Most executives should understand the realities of development hours and sustainable pace, and are pretty hard-working guys themselves. The CEO DEMANDS power card is rightfully used sparingly and in cases most deserving of it.

Overplayed, all power cards will result in demotivation, loss of quality, slowed pace, and/or attrition. Coaches, managers, stakeholders, and product owners should move cautiously.

Principles of Package Coupling

2009-04-22T07:24:00.000-05:00

Principles: Robert C. Martin

Post: Tim Ottinger and Jeff Langr

These three principles, devised by Uncle Bob, describe how to structure relationships between packages (arbitrary collections of classes). A related (forthcoming) card, Principles of Package Design, talks about the forces that bear on how to optimally group classes.

There arise occasional shouts of "But that was in C++!" Yet we find that these principles can apply also to dynamic languages, where abstraction works rather differently than in interface-declaring languages.

Acyclic-Dependencies Principle (ADP) - You stay late to finish up some work, but come in the next morning only to find that your code is broken--someone else stayed later and checked in changes that make your code very unhappy. Fixing your code breaks a third developer's code, and his fixes break yours again. This "morning-after syndrome" can be an unending nightmare of changes breaking other code, which in turn must be changed, which in turn...

Cycles begin to make all packages dependent upon all other packages in the system. They dramatically increase build times to the point of pain (something one of us lives with daily on the C++ project he's working).

Some languages, like C#, have facilities to prevent circular dependencies among packages. But even modern, dynamic languages like Python can suffer in surprising ways from round-trip dependencies.

Dependency cycles among modules are a very serious problem, slowing development and wrecking deadlines. Note that mutual dependencies among classes are usually a problem if the classes are split across modules/packages/assemblies.

Stable-Dependencies Principle (SDP) is based on the understanding that code has volatility, and that changes ripple through a system along dependency lines. From the point-of-view of volatility, dependency is transitive.

If the majority of the system's classes are dependent upon a volatile bit of code, then we can expect a high frequency of system breakage and rippling changes. If, instead, a system depends on nonvolatile code, then breakage should not ripple through the system very often at all.

Some modules should change frequently, and should be volatile. Other modules are essential core abstractions and should not change very often.

Therefore the package dependency graph should flow from instable packages (packages that are easy to change) to stable or "responsible" packages (packages that are hard to change). In a sense, this is the dependency inversion principle applied to packages: You should depend only upon things that are unlikely to change.
Stable-Abstractions Principle (SAP) - Per Uncle Bob, this principle sets up a relationship between stability and abstraction. A stable package should be as abstract as possible, thus ensuring that its "stability does not prevent it from being extended." In contrast, an instable (not responsible) package should contain lots of concrete classes whose details can be easily changed.

This further reflects the Stable Dependencies principle, with the added observation that the reason for interfaces is to give safe, stable dependencies to clients of an abstraction. This drives us to the understanding that we should depend on the parts of the system built specifically to provide freedom from volatile bits (implementations).

In dynamic languages, SAP is a harder metric to automate. Clearly the principle still applies. There will be classes whose purpose is to provide a stable interface and other classes that provide easily-changeable behaviors. The only problem is that not having declared interfaces makes it harder to automate the process of assessing abstractness.

A "benefit" of working in C++ is that poor package coupling choices are all the more noticeable. Build times of several hours are not uncommon, yet these wasteful cycles can be quickly brought down with a bit of appropriate package reorganization. Without dramatically increasing build times, developers in languages like Java might not notice as quickly the cause of their morning-after sicknesses.

So how do we figure out where the problems are and what to do about them? The flip side of the card provides metrics that you can use as the basis for graphing the relationships between packages. Such a graph can point out nonsensical packages, such as maximally abstract packages that no other packages depend upon, or maximally concrete packages that all other packages depend upon. Uncle Bob's stability article provides some detail on how to put this graph together (but there are also tools that can help!).

Software Craftsmanship Ethics

2009-04-21T11:00:00.010-05:00

Source: Doug Bradbury, Dave Hoover, Robert Martin, cast of dozens

This is the outgrowth of a conversation among Doug Bradbury and a number of Craftsman Manifesto signers. The goal of the collaboration was to come up with a statement of the Ethics of Software Craftmanship. In the course of the conversation, one of our participants suggested the pillars shown here (the brainchild of Jason Gorman).

The long form is quite beautiful, and presented here in entirety as an explanation of the four points above:

We consider it our responsibility to gain the trust of the businesses we serve; therefore, we take our customer's problems as seriously as they do and stake our reputation on the quality of the work we produc.
We consider it our responsibility to write code that is defect-free, proven, readable, understandable and malleable; therefore, we follow our chosen practices meticulously even under pressure and practice our techniques regularly.
We consider it our responsibility to hone our craft in pursuit of mastery; therefore, we continuously explore new technologies and read and study the work of other craftsmen.
We consider it our responsibility to perpetuate the craft of Software; therefore, we enlist apprentices to learn it and actively engage other craftsmen in dialogue and practice.

FURPS+

2009-04-16T16:42:00.007-05:00

Source: http://en.wikipedia.org/wiki/Furps

Nowhere does it say that you must dispense with all prior knowledge in order to be agile. The FURPS+ card is a good example of a tool I've found useful in non-agile years long past, and still useful in the context of an agile project.

In agile, we don't refer to requirements; instead we talk about stories. Stories are really reminders for customer needs (requirements, in the general sense). We will refine these needs into product through continual discussion. We demonstrate confidence in our ability to ship software product by executing tests that represent acceptance criteria for each story.

Deriving a list of stories to represent a deliverable product is something that must happen in order to plan a release cycle. This backlog of stories must of course include all the customer's functional needs, as well as their non-functional needs. Non-functional? Many "real" customers don't think about such things.

The FURPS+ acronym, devised by Robert Grady of HP, provides a bit more meat around what we mean by non-functional stories, and also provides a good way to categorize such needs. The breakdown here suggests some representative questions around potential needs.

Functionality - What the customer wants! Note that this includes security-related needs.

Usability - How effective is the product from the standpoint of the person who must use it? Is it aesthetically acceptable? Is the documentation accurate and complete?

Reliability - What is the maximum acceptable system downtime? Are failures predictable? Can we demonstrate the accuracy of results? How is the system recovered?

Performance - How fast must it be? What's the maximum response time? What's the throughput? What's the memory consumption?

Supportability - Is it testable, extensible, serviceable, installable, and configurable? Can it be monitored?

The + reminds us of a few additional needs that a customer could have:

Design constraints - Do things like I/O devices or DBMS constrain how the software must be built?

Implementation requirements - Do the programmers need to adhere to standards? Is the use of TDD required? Is statistically sound testing in the context of Cleanroom required?

Interface requirements - What downstream feeds must be created? What other systems must this one interface with? How frequent are feeds produced?

Physical requirements - What hardware must the system be deployable on? Must we be able to deploy to a machine no larger than 12" square, to be stationed in the Iraqi desert?

Just remember, in agile, stories are negotiable (but end product is usually not)!

Value Of Index Cards

2009-04-08T17:18:00.005-05:00

Typographical search continues. Font is Marker SD.

Source: Langr, Jeff and Ottinger, Tim

Index cards are an important part of the agile experience. We use them as tokens for user stories, for task breakdowns (sometimes), for backlog generation, for estimation, for reminders, etc. Here at Agile In A Flash, we use them as cheat sheets and motivational posters. There is a surprising amount of value to having an agile card posted in your workspace. Print one of ours out, and try it for a month.

Index cards are great. Why?

They are Low-tech and High-touch. You can put your hands on them, hand them to other people, stick them on the wall, tape them together, sort them on the desktop, etc. Having a tactile device such as an index card can make various workspace rituals possible (like moving a card from "in progress" to "done").
They can be dynamically reorganized to order them by point cost, or functional area, or assigned teams, or originators. They can have connections one did not intend originally. This puts them a step above most software programs -- they are routinely re-purposed on the fly.
They can hold schema-free markup. For instance, the security or documentation team can write notes on them. Developers and product owners can mark them up with issues or orderings. They can have priorities added to them. They might have none of the above, only a two-word name. They can have pictures, and notes with arrows. If you have a card and a marker, your only constraints are space and penmanship.
They are reminders for much bigger ideas. Being small, they can hold very little content. Yet they can have vast evocative powers. Take the agile flash cards on this site for instance. Once you know a principle or practice, a card bearing as little as three words can help you do your job better.
They are extremely portable, being small physical items. You don't have to copy them to a USB drive or mail them to your teammates. You can use them on the bus, train, or hiking trail. They don't mind being without web access and are immune to OS and browser incompatibilities. Whereever you are, they are the same.
They are inexpensive and replaceable. Of course, you never want to be without your Agile In A Flash (tm) cards but most other cards can be lost without any real cost. If they are important, they can be easily reproduced. If not, maybe you didn't really need them. I think every day we can tear up a story card or two is a good day. They are not heirlooms to be maintained for the life of a project, and that makes them even better.

Shu-Ha-Ri

2009-04-08T07:00:00.001-05:00

Images from Wikimedia

Font: j.d.

References: Takamura, Yukiyoshi: Teaching and Shu-Ha-Ri

Cleanup & edits: thanks Tim!

Kata are patterns of movements practiced by martial arts students; the moves act as the basis for actual application, i.e. fighting or self-defense. The notion of executing kata is analogous to a musical student practicing scales or finger exercises. Note that many professional musicians still practice scales, and professional martial artists still use kata.

Learning music, martial arts, the game of go, new software development techniques, or anything that requires extensive practice to master, can be broken into three levels, or stages, known as shu-ha-ri. These three words are (according to Ward's wiki) roughly translated as "hold", "break", and "leave."

shu - In first learnings, a student strictly follows the instructor, replicating each move as precisely as possible. Per the late Takamura, "the student must first resign himself and his ego to a seemingly random series of repetitious exercises." Kata at this level (known as shoden) are specifically designed to get students to focus on basic movements. Some shoden are even designed to create "physical discomfort," in order to reinforce the student's need to master focus. Ultimately, the goal of shu is to ingrain basic moves in the student, so that they do not think twice when it comes time to apply them. Wax on, wax off. Or, "Red, green, refactor."

ha - At this secondary level, the instructor begins to grant the student some leeway to experiment and diverge from strict application (but not to the point where the kata no longer resemble the originals). The goal is to open the students' minds to begin to recognize the true usefulness of the thing being mastered. The ha level is where we expect to start seeing light bulbs click on in peoples' heads. After practicing strict TDD for a while, students start to see some of the power of being able to move their code bits around. They learn when they can not test something because it "could not possibly break." Letting students diverge also allows them to note the value in things like consistent test naming, taking smaller steps, or exploring more sophisticated forms like BDD.

ri - At the ri level, the student no longer views the rules as constrictions, but instead as having been the stepping stones to learning and freedom. In fact, the student no longer thinks about rules. He or she has ingrained a set of techniques that can be applied at a moment's notice, but has also learned to specialize that knowledge with additional experience-based elements. In some cases, this level may find the master abandoning Red-Green-Refactor to even greater success, for short periods of time. Don't try this before you're a master!

Rules were meant to be broken, but only after you've followed them for a while, to the point of intimate or intrinsic understanding of how they benefit you. Eventually, the essence of the rule has been internalized and the rule (as a rule) has been obviated. At that point, you are able to operate as if the rule were common sense. You are then free to deal with the repercussions of not following the rules.

CRISP

2009-04-03T15:15:00.006-05:00

Brad Appleton provided this as a reader submission. Thanks Brad!

Mike Clark gave a 2004 presentation on Pragmatic Project Automation that included a description of what he called the "CRISP" criteria for build. There is a similar description in the 2007 presentation “All Builds are Good”, and a more detailed description in this 2007 CT-SPIN presentation on project automation:

Complete:
• Build from scratch and independently without human intervention.

Repeatable:
• Must be able to create exactly the same build at a later time.
• Store build scripts in source control.

Informative:
• "Detector of unexpected changes".
• Provide information on why a build failed.

Scheduled:
• Let the builds run automatically.

Portable:
• Build should be runnable from any system (same platform), not just that of the developer.
• For cross-platform software, it should build on all platforms.

Why Put Big Ideas on Little Cards?

2009-04-02T09:25:00.002-05:00

"... certainly it is excellent discipline for an author to feel that he must say all he has to say in the fewest possible words, or his reader is sure to skip them; and in the plainest possible words, or his reader will certainly misunderstand them..."

John Ruskin

Metaphor

2009-04-01T21:09:00.008-05:00

The font for this agile flash card is Lavos Handy

Of the XP practices, the practice of Metaphor seems to be the most widely argued and misunderstood. Simply put, it is a shared understanding of how the system should work. It serves as the oversimplification that "everyone knows" and against which changes can be discussed intelligently.

It may literally be a metaphor, such as a description of a hive of bees or an assembly line or blackboard, but it may also be a more literal description of the basic entities of the system and their interactions (ie not metaphorical at all). The shared understanding is the thing.

The metaphor is:

A shared theory of system operation from which additional features may be discussed intelligently. If the system is like a spider's web, then we can talk about strands being moved and the spider waiting. If it is like an assembly line, we can talk about stations near the end of the line and the constant feed of parts. If it is like an accounting system, we can talk about double-entry accounting. The importance of the metaphor is partly that it provides a back story for further development.
A model of the system's primary entities and flows can be sufficient shared understanding if the solution is relatively straightforward and can be easily-enough digested. In this way, the business domain of a sufficiently transparent system may be its metaphor(!).
A shared system of names is provided by the metaphor. In a beehive system, workers and drones and queens may serve as class names or database tables. In a petri net, it may be tokens and places. I personally suggest a more straightforward naming style, but a metaphor can certainly be a rich source of meaningful names.
May be an actual metaphor or story that is well-known to the development team. If the system can be well-understood by comparison to a nest of termites or a storm system or trash collection then (as far as it goes) the metaphor can be at the core of all implementation decisions and requirements discussions.
May be replaced or rejected when the system, through evolution of an implementation, ceases to have a compelling resemblance to the orginal metaphor. Remember this when choosing names. The metaphor may still have paid for itself by simplifying earlier requirement and design discussions, and a new metaphor may have at least as much descriptive power. There is no requirement that one cling to an inappropriate metaphor.

The point of the metaphor is that it is supposed to make it easier to think about and discuss the implementation of a system relative to its requirements. Having a metaphor can certainly aid in development of new features, especially in the early days of a software project.

Rules for Commenting

2009-04-01T19:41:00.011-05:00

Font is Lavos Handy

Have you ever noticed that almost every popular code highlighting scheme places comments in low-contrast grey-blue-on-white or dark-blue-on-black? Commenting has long been considered an important part of programming, yet in practice comments are written to be ignored. I think it is because they are typically added to satisfy bureaucratic requirements rather than to supplement the source code with information.

I used to be a huge supporter of comments. I loved to see glorious, rich, voluminous comments in all the code I read. I loved to write them. I thought that for a program to be 60% comments was a pretty good start. But as my teams began to write cleaner code, they sometimes would brag that the code was so clean that it almost didn't need comments. Now I want all of my code to go beyond almost.

I also have come to value vertical space in a file. I want it to be filled with working code instead of boilerplate and fluff. I hate scrolling through noise to find the code.

A few simple points to consider, and we can all have code that is more clear and gloriously free from noise and distraction.

Comments provide information that is not expressible in code. Comments are meta-commentary. Anything that we can express in the code, we are duty-bound to express as code. Comments must never repeat the code, or the version control system. They are never substitutes for expressive code. Comments may express things like copyright, sources of algorithms, and reasons one algorithm or data structure is chosen over a more obvious alternative.
Comments are to be deleted when they are obviated. Any comment that provides information available in the code must be deleted. We don't need comments to tell us that x++ increments X. Any comment that does not provide value is to be deleted immediately. This applies to passages of code that are commented out. If the system runs fine without them, we don't need those lines.
We should always strive to obviate comments. When we see a comment, we should take it as a challenge. If we can make the code express the content of the comment through refactorings (renames, extracting variables/methods/classes, inlining methods/variables, etc) then we should do so post-haste. If we can do it, then the code itself becomes smaller and simpler. And then the obviated comments can be deleted.

Inevitably someone will read this card as giving them license to stop writing comments, but that is a gross misunderstanding. If one takes a big steaming mound of poor code and removes the comments, it becomes an even more unmaintainable steaming pile of crummy code. There is a system and a balance that needs to be understood here.

This card doesn't tell us not to write comments, but rather to avoid writing code that needs them. Do I write comments? Yes, when I absolutely have to. But now I know when I have to.

ABCs of Story Estimation

2009-03-31T07:18:00.002-05:00

Estimation, predicting the future, is an art at best. Backing estimation techniques with extensive mathematics and statistics may make upper management happy--it's always great if you can provide supporting data for something and distill it to a single number! (42, of course.) But such diligence only serves to bestow way too much legitimacy on a bunch of HAGs (remember WAGs and SWAGs? Well, the "H" is for "Hairy").

Agile teams use dozens of various techniques for deriving story estimates. As my doctor once told me, so many "solutions" means that none of them is very good.

Predicting the future with estimates is immediately setting ourselves up for failure. When we estimate, we are always wrong. Always. It's just a matter of degree. But that's ok--we can get better over time, and the business always finds value in estimates. Repetition and increasing familiarity with things can dramatically improve the amount of error.

Best advice: Start simply! These five guidelines should help get you on your way.

All contributors estimate - not just a representative developer or team lead, and most certainly not anyone from the customer team simply asking for the story (how bizarre!). Those who do the work get to have some say in how large the story is. It doesn't make sense any other way.

Break story down into tasks to verify scope - This exercise can help verify whether or not this is the right story, and often brings out discussions around things that will impact the estimate. Sometimes a quick task breakdown gets the team to concede that this is a much larger story than thought.

Come to Consensus using planning poker - James Grenning's wideband delphi-based technique is a fun, engaging, and expeditious way of deriving a lot of estimates from a good-sized team. Show the cards, and if all are in agreement, or close to it, pick the size and move on. If there's disagreement, debate for a few minutes, try again. If there's still disagreement, come back later and move on to the next story for now.

Decrease estimation granularity as story size increases - It's silly to think that we can estimate anything precisely. As the story gets larger, beyond a couple days, even a day variance on an estimate is too fine. "Is this 6 days or 7 days?" Gee, let's do it and find out. The Fibonacci sequence is a classic choice for agile teams. A story that the team thinks is a 6 is most certainly not going to be done in 5 days, so it gets bumped up to 8.

Estimate using relative sizes, not calendar days - There will be no end of debate on this, but sizes do not degrade over time, and they do not vary depending on developer capability and availability. Calendar days do. Mike Cohn's book Agile Estimating and Planning provides many good additional insights on the differences between the two.

TDD Process Smells

2009-03-31T06:30:00.001-05:00

This list of "process smells" focuses on execution of the practice of test-driven development (TDD)--not on what the individual tests look like. There are no doubt dozens of similar smells; following the rule of 7 (+/- 2), I've chosen the smells I see most frequently.

Using code coverage as a goal. If you practice test-driven development, you should be getting close to 100% coverage on new code without even looking at a coverage tool. Existing code, that's another story. How do we shape up a system with low coverage? Insisting solely on a coverage number can lead to a worse situation: Coverage comes up quickly by virtue of lots of poorly-factored tests; changes to the system break lots of tests simultaneously; some tests remain broken, destroying most of the real value in having an automated test suite.
No green bar in the last ~10 minutes. One of the more common mis-interpretations of TDD is around test size. The goal is to take the shortest step that will generate actionable feedback. Average cycle times of ten minutes or more suggest that you're not learning what it takes to incrementally grow a solution. If you do hit ten minutes, learn to stop, revert to the last green bar, and start over, taking smaller steps.
Not failing first. Observing negative feedback affirms that any assumptions you've made are correct. One of the best ways to waste time is skip getting red bars with each TDD cycle. I've encountered numerous cases where developers ran tests under a continual green bar, yet meanwhile their code was absolutely broken. Sometimes it's as dumb as running tests against the wrong thing in Eclipse.
Not spending comparable amounts of time on refactoring step. If you spend five minutes on writing production code, you should spend several minutes refactoring. Even if your changes are "perfect," take the opportunity to look at the periphery and clean up a couple other things.
Skipping something too easy (or too hard) to test. "That's just a simple getter, never mind." Or, "that's an extremely difficult algorithm, I have no idea how to test it, I'll just give up." Simple things often mask problems; maybe that's not just a "simple getter" but a flawed attempt at lazy initialization. And difficult code is often where most of the problems really are; what value is there in only testing the things that are easy to test? Changes are most costly in complex areas; we look for tests to clamp down on the system and help keep its maintenance costs reasonable.
Organizing tests around methods, not behavior. This is a rampant problem with developers first practicing TDD. They'll write a single testForSomeMethod, provide a bit of context, and assert something. Later they'll add to that same test code that represents calling someMethod with different data. Of course a comment will explain the new circumstance. This introduces risk of unintentional dependencies between the cases; it also makes things harder to understand and maintain.
Not writing the tests first! By definition, that's not TDD, yet novice practitioners easily revert to the old habit of writing production code without a failing test. So what if they do? Take a look at Why TAD Sucks for some reasons why you want to write tests first.

Card, Conversation, Confirmation

2009-03-30T10:26:00.007-05:00

Source: Ron Jeffries, Essential XP: Card, Confirmation, Conversation

Too often, the story card is the thing that agile teams elevate. Some teams insist on strict verbiage for what gets written on the card, or on writing the stories very neatly (sometimes even printing them), or on strictly arranging cards on a peg board and adding rules about who can touch the cards and move them. Some teams even go as far as to spend hundreds of thousands of dollars on a tool to track the cards.

But they're only cards! The card is perhaps one of the least important things in agile software development. Wow, that seems like an odd statement for me to make--this whole Agile in a Flash project is about the power of index cards. I carry cards with me at all times. I often depend on their power and flexibility to help expedite various meetings (planning, estimating, brainstorming, etc.). The cards are a very useful tool, but they aren't what's important. The cards ain't the thing!

Card - Index cards are little physical things on which you can jot only a few things. A card does not capture all details about what should be built. It is instead a reminder, a promise for subsequent communication that must take place. Ron refers to the card as a "token," a word choice that I like a lot: The card isn't the thing--it's a placeholder for the real thing.

Conversation - So what is the real thing? Collaborating to build and deliver software that meets the customer's needs! To succeed, we must converse continually. We must continue to negotiate supporting specifics for a story until all parties are in agreement and the software is delivered.

Confirmation - The specifics of what we're building must ultimately be clear to the customer and the team who will deliver. The customer captures this criteria in acceptance tests, designed to exercise the system in enough ways to demonstrate that the feature really works. When this set of acceptance tests for a given card all pass, it confirms to the customer that the story is truly done--the software does what they asked.

I think you could run a very successful agile project without using a single index card. But that's not what I'm recommending. The key thing is to understand what the cards represent.

Arrange-Act-Assert

2009-03-25T14:50:00.006-05:00

Source: William C. Wake

In a unit test, three things typically need to happen: you must first create a context, then execute the thing that you're trying to verify, and finally verify that what was executed actually behaved as expected. So if, for example, I need to verify that the system properly applies a fine to a library patron for returning a delinquent book, I:

arrange the context by creating a new patron object and setting its fine balance to $0

act by executing the applyFine method with an argument of $0.10

assert that the patron's balance is $0.10, thus verifying that the fine was applied correctly to the patron

The most direct result of thinking about tests in this manner is its impact on the code's visual layout:


@Test public void applyFine() {
 Patron patron = new Patron();
 patron.setBalance(0);
 
 patron.applyFine(10);
 
 assertEquals(10, patron.fineBalance());
}

Note the blank lines separating the three act, arrange, and assert sections in the test applyFine. I've even seen some test code with guiding comments to make the section names explicit:


// arrange
...
// act
...
// assert
...

Honestly, it's idiomatic--once this organization is explained, the intent is obvious, and thus it's only a waste of time and space to include such low-value comments.

Emphasizing AAA (Arrange-Act-Assert) played a significant factor in the evolution of the Rhino Mocks framework for NUnit. Ayende Rahien introduced a new interface for Rhino Mocks 3.5, one that dispenses with the need to call a "verify mock" method after assertions are complete. This allows for cleaner, AAA-compliant tests. In contrast, older "classic" syntax for record-replay mock tools generates "mock clutter" across the test--record, replay, and verify calls are littered through the test.

Note that the form can vary. If you're verifying a static function, there may be no need to Arrange anything. And you may also want to introduce preconditions that verify things are in an appropriate state before the Act step--you could end up with Arrange-Assert-Act-Assert, or even Assert-Arrange-Act-Assert. And it's also possible for Act and Assert to be combined effectively in a single line of code. I don't believe there's value in being dogmatic about the organizational form, but there is value in striving to ensure that the intent of the test is clear. Keeping sections clear and visually separate from each other helps!

Arrange-Act-Assert is a simple concept, and probably only adds marginal value. But it costs nothing to practice, and it gets us that much closer to being a community willing to agree on some standards. What I also like about memorable acronyms like AAA is that they provide a consistent way to communicate simple ideas, which often don't have concise and consistent names.

Stay

2009-03-23T17:43:00.004-05:00

I was reading an article by Cherie Berklee at Payscale on the topic of surviving layoffs (having not survived one not too long ago) and was inspired by some of the points. I recommend the article to those who have been laid off, and those who hope never to be.

Stay Positive is an inspiring bit of advice which no doubt has origins in antiquity, but which was all the more powerful in Berklee's article. I have not always followed this advice, and even had disregarded it for some time in my career and was the worse for it. Staying positive (not fecklessly hopeful or naive) when things are difficult is not just good behavior. It is leadership.
Stay Engaged. Though I don't have a reference, I seem to remember Robert Martin talking about professionals, and Craftsmen in particular, being more highly engaged (attentive, focused) than your average code monkey. It is sometimes a struggle to stay engaged, which is why we have things like the Pomodoro technique and pair programming to keep us focused.
Stay Professional should be the motto of the Craftsman movement (if I may call it a movement). Always do your best work, and always look for ways to raise the bar on "best".

We should be mindful of these points well before our companies start to have financial trouble. These are things that make us better employees and better people in general. I've since hand-written these three points on a sticky-backed index card stuck to the lower edge of my second monitor. It is there to always remind me of simple ways to be more effective and thereby more valuable.

Ten Principles for Agile Testers

2009-03-20T09:09:00.005-05:00

Source: Crispin, Lisa, and Gregory, Janet. Agile Testing: A Practical Guide for Testers and Agile Teams, Addison-Wesley, 2009.

Lisa Crispin and Janet Gregory wrote the recently-published Addison-Wesley book Agile Testing, a thick tome that fills a much-needed gap in agile literature. Prior, detailed guidance for testing in an agile environment was sparse. With Agile Testing and a couple other fairly recent books (2007's Test Driven: TDD and Acceptance TDD for Java Developers by Lasse Koskela and Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing by Gojko Adzic, 2009), we now have a good foundation for comprehensive agile testing knowledge.

The ten principles that the authors published should sound familiar. Four of these principles directly cover XP's four values of feedback, communication, courage, and simplicity; these and the remainder are also largely echoed in the agile manifesto and its supporting principles. So what's relevant about how these ten principles apply to agile testing?

Provide continuous feedback - The agile tester is central to providing the team with feedback: Acceptance criteria is the most concrete way to measure positive progress on an agile project. Tests also help identify issues and capture decisions on appropriate future direction.

Deliver value to the customer - The insistence on acceptance tests is a "reality check" on scope creep. Acceptance tests help us all understand what it means to realize a customer's needs.

Enable face-to-face communication - Testers can often be the ones on a team responsible for bridging the communication gap between customers (BAs, product owners, etc.) and programmers. A tester can be the one who physically brings these people together, as well as the one who drives derivation of a common language between the two parties.

Have courage - One of the larger challenges of agile is in sustaining a fast-paced iterative environment, where every two weeks we need to ship quality software. This challenge demands significant courage. Yet the irony is that we also need to understand that iterations afford us opportunities to learn how to fail and adapt--something that can require an even heavier dose of courage!

Keep it simple - Agile testers can help push back against an insistence on overly-elaborate features. Testers can also help the customer understand how to incrementally deliver value. They must learn an appropriate balance of iterative testing-- just enough to provide the right confidence in delivering software.

Practice continuous improvement - A key element of using iterations is to allow for learning to take place. Testers should be part of retrospectives (and if you're not consistently adapting based on the results of retrospectives, you're not agile enough.) Testers should also treat their career as a profession by continually learning more about testing practices, tools, and the system itself.

Respond to change - Agile testing is dramatically different in that there are few true "cutoff points"--things keep changing and thus must be continually re-tested. This requires automation! The agile tester learns to cope with the customer changing his or her mind from iteration to iteration, and correspondingly learns how to incrementally flesh out necessary testing specifications.

Self-organize - In a true agile team, everyone has the capability to act as a tester. Agile teams know how to shift focus as needed; from time to time, for example, it may be prudent for programmers to turn their attention toward helping verify a "done" but not "done done" feature.

Focus on people - Testers are often at the bottom of the totem pole in a non-agile software development team. Work is thrown at them, their available slice of time is continually squished, and programmers often look upon them as lessers. In an agile team, every shares the responsibility for ensuring that we are building quality product. Agile testers are key in bringing their testing expertise to the team.

Enjoy - The ability to help drive the process and be a true, equal contributor to a team can be extremely gratifying for an agile tester.

The use of acceptance tests to drive agile development is perhaps one of the most critical needs for a team that wants to sustain success. With that in mind, it's amazing that it's taken over ten years since the explosion of XP for us to begin to fully document just what agile testing is.

Make It Work, Make It Right, Make It Fast

2009-03-17T21:16:00.002-05:00

Today is our first ever reader contribution from Brian DiCroce

Our font today is called "j.d." See bottom of post for details.

Content Source: Kent Beck at C2.com wiki

When working on a feature, let yourself be driven by this little principle to actually get things done right.

Make It Work
Program with your mind focused on the feature's basic behavior. Just make the feature work. Ensure that all the test(s) pass for that feature.

Make It Right
Now that you have your feature working (all tests passing), focus on refactoring the code. Tests will provide the necessary feedback. Clear up structural and aesthetic issues, remove duplication, rename variables, etc.

Make It Fast
Once the the tests are passing and the code is clean, you can focus on tweaking its performance. Use a profiler of course. Once again, you can feel confident in your changes because the tests will ensure that functionality is not broken.

I abide to this principle whenever I'm developing a feature. It help to shift my focus toward specific development efforts when working on a single feature. The initial effort is toward getting a feature working for quick feedback from users (or potential users). Improvements can be made after the fact, making the code faster and smaller.

This principle is easily applied in conjunction with TDD. The test-first approach helps me drive the design or API of the feature, while the pre-existing tests ensure that the rest of the system continues to function correctly. Refactoring can be applied naturally and at will as the new tests provide a safety net for the code. With the functionality assured, performance improvements may be added with confidence.

If your quick-running, hand-optimized system does not do what it is suppose to do, it is not worth investing time and resources in making it any faster. After making sure that the feature works correctly, you can focus on the performance of the feature. Once again, the tests act as a sidekick in that they will continuously provide you feedback whether changes broke the system.

About the font:
"j.d." is a windows/macintosh truetype and postscript type 1 font, handcrafted in the Emerald City by Steven J. Lundeen, Emerald City Fontwerks, Seattle, Washington, USA.
Generously released as freeware, and copyrighted ©2001.

Legacy Code Change Algorithm

2009-03-16T10:01:00.006-05:00

Source: Feathers, Michael. Working Effectively With Legacy Code, Prentice Hall PTR, 2005.

A simply-written technique is not always easily written. The best reference for this technique is Michael's book, of course. Second best is the paper available through Object Mentor's web page (Michael's published papers).

To identify change points is either very easy or very hard. Find the place where you want to make the next change in order to get a new feature added or to eliminate a bug.

The point of change may be nested too deeply inside other methods or into a long if/then/else case, or buried in classes referenced by other classes. Michael suggests that this effort is proportional to the the sickness of the code.

When you know where the code needs to be changed, you need to find test points . Michael calls them "inflection points." The inflection point is in the call tree where any change below it will either be evident or insignificant. The test point is often not the change point.

Break dependencies that make it difficult or impossible to start writing tests to get some coverage of the current behavior at the test point(s). It is normal, in a legacy code base, to do some "pre-factoring" to make testing possible. This is tricky territory, since you don't yet have test to protect you as you work. Expect to spend time running and manually validating basic functionality. You are of course better off if there are some tests that cover the test point.

Write tests to cover existing behavior at the test point. Remember your tests will need to comply with the F.I.R.S.T. principles.

Make changes and refactor the change point in the normal test-first manner, enjoying the test coverage you've built.