Agile Won’t Be Killed

Agile is about the freedom to do the right thing.

UncleBob wrote this good piece on whether Scrum could Kill Agile.

To me, Agile is a mindset, a state of mind, a way to be. It is neither a (set of) coding practice(s), a concrete process, or a management technique.

Agile is not TDD, XP, FDD, Crystal, Scrum, Lean, Kanban, Six Sigma.

Agile is about being responsive to the current and future needs of the business within the current context, so that you can do the very best possible given your team and budget. Read these again:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The “we value the left-hand items over the right-hand items” is precisely loose because it all depends on the context and the business needs. Believe me, we argued mightily over small wording changes in that Snowbird meeting! It’s just that in general, our collective experiences had born out the truths that we were more effective and responsive to delivering valuable software when we emphasized the left-hand items. I was coming from the government background, and I was determined to demand we push for truth and honesty in software. No more stupid 70% done and no working software to show for it!

I submit that the Agile Manifesto tenets are irrefutable ideas and will stand the test of time.

The Non-agile Manifesto

Let’s try a little negative test (if you agree to these, I’ll poke you with a hot stick):

  • We will build software with processes and tools — that way we don’t need to worry about people issues and effective communication.
    • That way we can hire any individual regardless of skill, and forgo all verbal/personal interactions in favor of solely written words. Even better if those written words are automatically transformed into code. Maybe we can get non-coder tools! After all, people are merely fungible assets/resources, and software is factory-work — with processes and tools, and a horde of low-paid serfs, we can crank it out!
  • We would rather spend exorbitant sums of money producing comprehensive documentation than have tangible, working results early on.
    • We start with complete requirements specifications (often 400 pages), that follow our company standard template.
    • Even our Use Cases follow a mandatory 3-level deep path, with proper exception and alternate paths worked out.
    • We link the requirements items into detailed design documents — which include system design diagrams, interface specifications, and detailed object models.
    • If we don’t write it all down now, we’re likely to forget what we wanted. And if we don’t do it to the n-th degree, the developers might screw it up.
    • Writing it all down up front allows us to go on vacation while the process and tools “write” the code from the detailed specs/diagrams. Sweet.
    • In addition, we love to be rewarded by reaching meaningless intermediate deadlines that we place on our 1500-node Gantt chart.
    • When we combine all of the upfront work with a important deadlines, many of the senior managers can get promoted due to their great commitment to generating reams of cool-looking documents. By the time the sh!t hits the fan when folks realize the “ship it” deadline is missed, the senior managers are no longer involved.
    • Besides, if we actually built software instead of writing all sorts of documents thinking about building software, our little ruse would be exposed! (BTW: if the human race had done nothing more than documented the ideas about how best to go about procreating, we wouldn’t be here to waste software budgets. w00t!)
  • We prefer to write a tight Statement of Work & force a strict fixed-price contract rather than actually work towards a common goal with the client.
    • The agreement is based on the 400-page, fully-specified requirements document, and we pad the cost estimate with a 400% profit margin.
    • We then hire dozens of people to argue during the Change Control Review Board monthly meetings about re-writing code to deliver what you wanted versus what you asked for when you thought you knew what you wanted (and wrote it down in that 400-page doc).
    • Contract negotiation pissing matches are such great uses of our collective resources and always result in perfect software! We love our fine print 🙂
    • With a 400% padding, the projects are too big to fail.
    • Once we are in it for 1 or 2 million and 50% done and 2x schedule overrun, who would ever say “No” to a contract extension? Who better to get you to the goal line than the same folks who squandered away your treasure, pissed away the calendar, and delivered no working software yet?
    • We like to appear like we’re just about done… Asymptote? Never heard of one.
  • There’s nothing more appealing than following a 1500-node Gantt chart. To the letter and subletter. Change sucks.
    • Especially a Gantt chart that has been built with tender loving care to include resource allocations, inter-project dependencies, and partial resource allocation assignments for matrix-style organizations.
    • We love hiring a small army to ensure that we drive the entire team to meet every micro-task deadline even when they no longer make any sense.
    • The real fun is collecting the “actuals” data from the developers assigned to each task.
    • And nothing sweeter than seeing 90% of our tasks being started, and 75% of those being 67% completed, and 25% of them being 99% completed — the roll-up summary to management is such a compelling story.
    • Changing such a beautiful plan that took 4 man-years to develop, that incorporates all of the comprehensive non-code documents, and is an appendix in the contract, is no small feat!
    • Better to produce the software according to plan even if nobody wants it that way. That’s our motto, and we’re not going to change!

Waterfall Sucks

Waterfall — as practiced — will die under it’s own weight. Waterfall is a bad idea when applied broadly to all sorts of classes of software projects. Eventually people will wake up and realize that — for many situations — there are better ways to doing software than waterfall. (Waterfall done on one feature at a time is a fine practice 🙂

I remember seeing folks who worked for Big Consulting Firm go into an organization to do all of the Use Cases for 9 months straight. Their documents were then handed off to some other firm to do the analysis and design. And finally, yet another firm would do the implementation based on the sum total of documents. Since the written word left nothing to the imagination, these projects always delivered perfectly. Oh, wait. Standish Group says that really isn’t how things worked out. This might be an okay way to go about hardware or construction projects — since you can be more deterministic up front, and there are more common parameters that are “agreeable” to most folks in terms of real interface documents (like engineering or architectural drawings are pretty specific and not ambiguous). But to anyone that has any experience in software development, waterfall seems ludicrous from Day One! Who would ever think that you could hand off all features as they went through each of the major phases with no loss of understanding? Who would ever think it is good to wait FOREVER to see any tangible results? After all, we’re NOT bending metal or breaking ground. It’s freaking software! Sigh.

Waterfall seemed ludicrous to me my very first time. I was exposed to Mil-STD-2167 while doing DOD contracting in the 80s. I think I followed along like a good little well-behaved junior engineer my first time. Probably even my second. Then my brain kicked in and said — this is stupid for our situation. We’re doing software development for R&D projects, we’re not doing assembly line work for a brick factory. We can’t know everything up front, and it is risky to think you can! So I started to look for better ways, and began to not do wasteful practices, even though they were prescribed. I began to do the right thing for the customer — and they agreed to the <ahem> “waivers.” (I was applying the “Better to beg forgiveness, than ask permission” principle I learned from my good friend and mentor, USMC Colonel Rich “Magic” Dinkel, fighter pilot extraordinaire.)

I sound like I am bashing people that did Waterfall… I don’t want to be that harsh. People did what they thought was best at the time. I think many times we fall into a trap of wishful thinking. And even in the face of overwhelming observations to the contrary, we soldier on in hopes things will work out like we want. (Besides, it’s in the contract!) Rarely is hope ever a good strategy. Maybe never? So folks doing waterfall certainly had good intentions, and it was compartmentalized enough to reward intermediate victories and give an illusion of progress, but there’s no denying it’s just a bad idea.

Agile didn’t kill Waterfall per se. Sure, maybe it helped accelerate the community’s realization that there were better ways to do software than a giant, rigid, 4-stage assembly line.

Waterfall killed waterfall.

Scrum Won’t Kill Agile

I say let the Scrum Fun continue! Make tons of money! Waste as much budget as you can. Brag that you are doing Scrum and have hired 20 CSMs to whip your developers into shape!

The more people and HR departments that think there is some magic bullet, the more companies that might fail and lose business. This makes way for smarter, leaner, more entrepreneurial start-ups to eat their lunch. After all, I would wager that very few small organizations are falling for the Scrum Will Save The Day stupidity that is seemingly gripping some (large?) portion of our community.

Convenient Cover?

Here are a few phrases that come to mind regarding the Scrum dustup, and I’ll add a new one…

  • A friend once quipped that “Off-shoring is just a cheaper way to fail” — implying that if you can’t build software locally, you probably can’t build it 12 time zones away either. But at least the costs are lower.
  • No one was ever fired for hiring IBM
  • We are doing Scrum — all the rage in Management By Magazine circles!

In other words, it is often far easier to go with the flow, follow the herd, live by the plan, and say you did what you were told. It is much harder to buck the system and call out the ineffective and wasteful activities, and continuously try to improve. It’s hard to buck inertia!

Conclusion

Nothing will ever kill agile.

Bold, I know. However, I view it like the USA’s founding principles — immutable laws of freedom. Agile is about freedom to do the right thing.

How can you ever deny the correct way to do software is to do what’s best for the business?

How can you deny the Agile Manifesto tenets?!

Successful software will continue to be developed in an agile manner, regardless of the terms that might become popularized.

Plan & Estimate, Only if You Must

It must have been the morning to challenge planning efforts, as GeePawHill did here. I was answering a post that had gotten around to discussing budgeting and planning for interruptions to fix legacy apps while teams are building new stuff.

When all of the sudden, I blurted this out:

Kanban is simple, in theory. Simply do one feature or bug fix all the way to being released. AKA focus. But there is a lot of things that have to be working well, for example: the cost of testing has to be low so that it doesn’t cost a fortune in treasure or time to get in that new feature or bug fix. (Expensive testing often leads to bundling a bunch of stuff into a given release and widening the time window, and introducing parallel development techniques.)

And, regarding budgeting in to prepare for the unknown maintenance efforts… That’s but one way to handle things. Another way is simply let the people who care about getting things done participate in setting your priorities. If you were given 10 things to do in a month, and halfway through you get an 11th thing to do. You probably don’t need to budget for that unknown. You simply ask for help deciding which of the original 10 should get axed to make room for the new “emergency” item.

Like it or not, you are all in it together, it is a zero sum game. If you fix the resources, fix the schedule, the amount of work that gets done has to give when new work is injected. Deal with it in an honest manner.

Hard to describe in words… and had to know your exact context… but what you are facing is probably more of an organizational issue than anything else.

All we software folks do for a living is produce features and fix bugs to keep paying customers happy. Just keep trying to improve your team’s efficiencies and squeeze out wasteful practices.

When you are producing software as an internal organization, you can sometimes be brave and forgo lots of planning stuff. If you have the priorities set, and if you have a delivery schedule, and if you understand your costs of releasing, you can make a pretty simple and smooth process. I’ve done it many times in companies formerly steeped in waterfall fantasy land. Why waste all sorts of time making estimates if you don’t have to?

The answers to these questions can help you decide how much ceremony your processes need:

  • Does it matter if the team does 5 things in an iteration or does 10?
  • Does it matter if they estimated 10, but only wound up being able to do 5?
  • Or, if they bid 5 and found they could do more and gobbled up 10, is that a problem?
  • Is it more important to hit a date with at least some features?
  • Or, is it more important to produce specific features as fast as you can, even if you miss the date?
  • Does the team need to be accurate on their estimates? How accurate and why?

Many times, we fall into traps of wanting to manage software process as if it were a brick-making factory. Unless you live or die by doing software as a fixed-bid project, you can often really get simple and make software really fun in your organization by doing less ceremonial planning crap!

Ideas for a Distributed Team

In response to a posting on Agile Project Management…

I am starting up a ‘Distributed’ Agile Project and looking at tools to assist the distributed team communicate the status of work undertaken, stories, estimates and burn down/up charts as well as general collaboration (forums, document sharing etc).
There are tools such as Agile Wall, Mingle, Trac (with plugins etc).
I am ideally looking for an externally hosted solution (something that we will not be setting up in-house).
I have a core team of 15 people and with an additional 10 people that would want access. I am looking for any ideas or suggestions on online tools that you may have.
Thanks in Advance.
Regards
Neal

I’ve been doing this sort of thing since 2000, so it is very easy and very possible to be extremely effective as a distributed team.

Here is a very simple approach using Basecamp (and you can get an add-on for burndowns if you like that sort of thing). I’ve been doing this on a small project since March or so.

Then I set up other simple collaboration tools (looked like this on many projects, though you might have to march around that hodgepodge of a site to find more tool ideas):

  • Wiki: Project stuff that is not issues or code needs a home; a.k.a.,
    (you can use basecamp, though not as extensive as something like confluence)
  • Chat Room for being the virtual cubicle farm and water cooler. Skype or IRC works great. You can establish key words that call out for attention, like “@ALL I’m going to kick the TEST server.” You can even have textual scrums if voice is not always possible. For a while, we had a bot that recorded the chats and logged them to the wiki 🙂
  • Issues/Bugs: You need a place to store your lists of things to get done. Some call that an issue tracker; others, simply a To-Do list. I have used Jira for a l-o-n-g time for both features and bugs. I have also used Lighthouse — which is just fine too.

Atlassian Studio is worth a look. You can add in continuous integration and code reviews and what not.

My suggestion: start really small and humble with the tiniest process.

That really simple Basecamp process I blogged about? We actually got to PRODUCTION with much less ceremony. There were none of the “To be QAd” or “To Be Released” because we did it more in iteration chunks, so we knew the overall state of a given iteration (in dev, qa, or released).

The slightly greater ceremony of QA and Release buckets allowed me to answer the need from the stakeholders and other non-developers to know the state of the project at a glance. It’s easy to see what is in the backlog, or what is in progress, or waiting QA, etc. Now we’re doing Kanban. I crank issues and (rare 🙂 bugs through one at a time usually.

Anyway, have fun!

Response to “Three Things I Don’t Like in Agile Community”

Andy wrote some interesting observations in his “Three Things…” post:

1. Dogmatism
Agile is about adaptive, creative approach to complex work yet amazingly average agilists are the most dogmatic people I know.

Part of dogmatism is also treating agile […] as the all-encompassing solution to problems not only in software development, not only in IT, but everywhere. [This] is a far cry from healthy pragmatism that I think is at the core of all good management.

I see this is a common thread among those who have issues with Agile. Naturally, if someone is presenting a methodology at a conference, I can see where it might sound dogmatic. However, if an Agile Consultant is engaged with a team and preaches “Do it My Way or Else” in spite of vehement team opposition, well, that strikes me as non-agile.

For me, agile has always been more about the proper state of mind than dogma. We need to prefer to do those things that are best for the business/customer goals over doing things that are not as helpful at getting the project closer to “done.” Sure, there are practices associated with agile methods, but simply doing those practices don’t make someone agile per se.

No, what makes someone agile is a combination of what they are doing, how they are doing it, and all within the cultural and business context in which things are being done.

For example, you just can’t walk into an elderly long-term care facility and do yoga like you would with 20-30 year-olds. (Well, you could, but that would be stupid.) Similarly, you can’t simply ram your favorite XP tools and practices and Magic Scrumbans into a steeped-in-old-ways, very stodgy organization full of legacy software written in a 30 year-old, no-longer-supported language. Well, you could, but that would be stupid.

So, Andy, if you spot one of us “Agilistas” spouting off a dogma, smack us upside the head and say “Work with me, son!”

2. Sectarianism

Kanban, Scrum, XP – everyone follows their own method, and basically says others are useless or at least not as good. […] Again, this is in the face of core principles of agile.

Hmmmm. The only good method I ever practiced was the one I was doing at the time it was working right. While I can understand someone who is training in a strict methodology being sectarian, that is not the same as consulting. I attempt to be a generalizing specialist (as Scott Ambler likes to refer to it…) and use a blend of tools, practices, modalities, and therapies.

Andy, if you find yourself being preached to by a consultant (not a trainer) that is one-dimensional, take it for what it is worth. A single, focused, dimension — nothing more.

3. Domination by consultants Most if not all agilists that write, teach and coach do only this, and have not run a software project (or a business) hands on for quite a while.

Well, the lack of real-world experience should be obvious by perusing their background. While trainers can be good at getting across certain practices and methodologies, and while coaching dozens of teams provides valuable exposure, it does not substitute for actual production experience. I learned a great deal traipsing around dozens of companies to help train and consult to kick-start projects — lots of cross-pollination potential as well! Similarly, consultants with great experience at building real world systems and helping teams do that, may not be the best down-and-dirty, nitty-gritty trainer for a given technique.

It’s a trade-off. First off, don’t confuse training on a skill, with consulting to help achieve a business goal. I think you have to understand what the purpose of the consulting engagement is, and who was brought in for that task. If you just want to learn the mechanics and lingo of Scrum, it takes only two days — it’s that simple. But tell any Project Manager with real world software project experience, and they’ll tell you that you don’t know much after just a few days of training.

So, if you ran into an agilista trainer that has not been on a real world project to deliver production code in a long while — or ever, then you should not expect that sort of knowledge. It doesn’t mean they cannot provide you with valuable training.

However, I will also say that not much is new under the sun in software development in the past 30 years. I mean, seriously. The same core issues exist in trying to roll out a piece of software to production as did 30 years ago. Admittedly, I don’t recall having quite as much fun as I do now with delivering production code with Ruby, Rails, Cucumber, RSpec, github, Mongo, gems… The ecosystem makes it so much easier to “do the right thing” with BDD/TDD for example.

Andy, I can appreciate your observations about the “Agile Community” — like so many others I have read on the web. To that end, I suppose we need to re-double our efforts at re-stating that Agile is a State of Mind, not a set of dogmatic practices.

And, in the end, Andy, caveat emptor. The Agile mantra should be one of empowerment and individual freedom to please the customer in the best way possible. You are ultimately responsible for doing the right thing. Agile ideas, processes, tools, trainers and consultants are just that — and nothing more. We are not the answer, we just try to help. In the end, the team is the answer.

Responding to “What’s Next for Agile”

In this post, there are some scary assumptions. I wonder where they come from?

  • “But where does [the Manifesto] say that the customer gets what he wants?”
  • “Mary talked about the next inflection point in agile – getting back the customer focus.
  • “‘Agile’ until now was about the processes and tools that improve software development.”
  • “[We] now have to align with the business goals of the organization –  provide what the customers need.”

Everyone is entitled to their opinion. But this is sooooooooooooo far away from what Agile is all about, I find it shocking.

My primary response:

Well, if you aren’t building software for customers, then you can do what you want.

Even though the customer is mentioned explicitly in the very first principle, I submit it is obvious that you are to satisfy the customer to build valuable software. Always. We ain’t no stinkin’ charity for developers to play around with shiny new software trinkets. (At least not overtly <g>.)

Anyway, “satisfying the customer” is simply a “given” behind each one of us that met to author the Manifesto.

And, who ever suggested moving away from the customer (implied by the need to “get back”)? That is completely anti-agile.

Agile is also not “about the processes and tools” as the post suggests — if anything, Agile is about a state of mind to do the right thing in every circumstance.

How do these ideas get out there about Agile?

I’m confused.

Certification is a Good Thing

I read with pleasure “The Value of Certification” from Pawel Brodzinski, that emanated from a discussion about evaluating employees.

Pawel points out some obvious pros to certification, and one big con:

  • It’s objective measurement
  • It’s butt-simple (Pawel didn’t actually say this, that’s, ummm, me talkin’)
  • It’s, and I quote, “pretty much useless”

Then it dawned on me. College degrees are certificates, as are high school diplomas. So are participation trophies for the poor schlubs who didn’t win anything at tweeny league and are (defenselessly) surrounded by adults who mistakenly (IMHO) think such a trophy is meaningful to the kids (kind of like dogfood made to appeal to the purchaser). But that’s a digression…

In our software world, it is the Scrum Certification that bears the brunt of criticism — even though Pawel does not mention this particular style of paper valor. For those who pass an exam after two-days of grueling lectures, practical hands-on training (a.k.a., apprenticing) at the feet of master craftsmen, and in-depth co-op work experience at multiple cutting-edge development shops doing different projects… Oh, wait, that’s not quite fair as that really isn’t what’s going down in just two days. Crap. Scratch that tact.

Anyway, let’s just say many folks seem to be intent on hiring other folks based on Scrum certification (caveat emptor: I do not have said certification, so I am not speaking from direct experience — I’m too cheap to pay for it). I base this on my extensive analysis of randomingly seeing two hiring ads for Scrum Masters that were virtually identical in content — and buffoonery, I might add. For me, it was a big, bad smell for the organization. But, in large bureaucratic organizations (government or MyLargeCo), abdicating responsibility is honed to a fine art. Ergo, the HR departments did what they think was valid trawling for Scrumsters by evidently plagiarizing some sort of HR-i-pedia definition of the perfect Scrumster parameters. Good luck with that. These actions are a boon to your not-as-lazy-or-naive competition (oh, unless you are the Government, which has no competition, only an ever increasing appetite — I’ll not digress here, either).

So, maybe the Scrum Certificate is a bit like a Participation Trophy.

Yea, you were there. You participated. You didn’t actually compete/win or do anything meaningful in the real world to earn it, but there you have it. You should feel better about it. And it does mean that you at least did something (unlike me). Go forth and procreate little Scrumlins. (BTW: I’ve got nothing against Scrum, I think it is a great and simple approach to PM! It’s just hard to pass up the opportunity to poke fun at our own agile software world and make up little monikers as I go.)

So I can look at “certification” in at least two ways:

  1. Basing hiring or performance appraisal on a CSM certificate is pretty awesome for the individual on the receiving end. I bet they didn’t have to go into debt to get one (compared to a college degree)! (Although all of me wants to be judged on my real merits, not on some piece of paper — alas the chicken and the egg comes to mind for newbies.)
  2. If companies find a valuable correlation between a certificate (CSM or otherwise) and knowledge work, I would be surprised. In my experience, the last thing that I would qualify as a trait of software projects, is that they are “cookie-cutter” — that is, where one-size anything fits all (be it ideal Scrum process, database, language, etc.). However, sans external stupidity (like a bailout), companies will “learn” how to treat any software certificate — much as they have with college diplomas and belly buttons (i.e., everyone has one). The market will sort things out, eventually — in that I have faith.

So there you have it. Pawel says “Certification is Pretty Much Useless” — and I disagree. That very aspect of certification will serve a purpose to differentiate those that place undue trust in the paper from those that stick to good hiring practices and good employee relations. I predict the latter prevail.

ps: Pawel, I agree with you in spirit.

Agile Manifesto Simplified

JB Rainsberger took a stab at simplifying the Agile Manifesto.

Original (24 words):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I’ll see your 3 bullets (24 words), JB,

  • People working together over precise rules and pre-packaged solutions
  • Working software over promises
  • Doing what’s needed over doing what we said was needed

and raise (well, reduce) you:

  • People working together over dogma
  • Working software over promises
  • Doing what’s needed now

24 words to 13 words. Same context? You decide.

More to follow 🙂

Be an Agile Survey Monkey

Survey Schmurvey!

There’s seemingly quite a bit of a dust-up over assorted agile surveys:

  • Scott Ambler’s 2010 Scrum Certification Survey.
  • VersionOne’s “State of Agile” survey.

I did Scott’s simple survey last week. I did the VersionOne not-so-simple survey the other day.

After someone dissed Scott’s efforts and praised the VersionOne effort, I replied:

I could poke serious holes in the “State of Agile” survey. I mentioned a flaw or two back to VersionOne (i.e., I replied to the email with the link).

But I won’t. It isn’t worth my time.

Surveys are extremely hard to design. I submit that the VersionOne survey has a flawed model of development projects underlying the questions—not that it stopped me from supplying answers. And when you toss it out to self-selection, it gets even weirder to draw major conclusions. And to get subjective info on being more productive with agile, etc., is anything but accurate.

If people make decisions based solely on someone’s survey (or certification or education), it’s a free country.

Good luck with that.

I would never be so foolish.

Using Basecamp in an Agile Manner

Even the lowly “To-Do List” (as can be found in Basecamp) can be used to manage an agile, Kanban-style, lightweight Software Development process.

Software Development Life Cycle

In software development, we want to make our process as visible as possible to all participants and stakeholders. To that end, behold a simple process that uses a handful of Basecamp To-Do Lists as markers for how a feature or bug is working its way through this process.

At any point in time, you can look at the “To-Do” list page for a status on your favorite new feature, task, or bug. And, if you have a chunk of features piled up in an “Iteration 1” list, you can see the number of items being worked through to completion. (There are even third-party apps that allow you to do burndown charts if they appeal to you.)

Using Basecamp's To-Do List in a simple manner

Requirements/Bugs

The business has a desired priority for features as expressed by the order of items in the “staging” lists, and especially the On-Deck list (to borrow a baseball metaphor for “What’s next”). For major new features, the business and the developers will work out a rough Release Plan. But for simple enhancements and bugs, the business can simply add desired items to the lists.

Development

The Developer will pick a new task off of the top of the On-Deck list. There will usually be a conversation around the issue to ensure proper understanding (unless it is self-explanatory). Ideally, we get the business/testers helping to write User Acceptance Tests in the BDD form of Given… When… Then… The Developer moves this feature into the “In Progress” list. If desired/possible, the user could add a date estimate for the task.

The Developer will create tests, be they Cucumber, RSpec, or UnitTest, or all 3 types. If possible, the Testers can help write the up-front acceptance tests, so that they are intimate with the feature/bug. The Developer writes code until the tests pass.

Once the issue is complete, and the tests are passing (and you didn’t break any other tests), the Developer: commits the code, updates the TEST server, and does a smoke test to ensure things still work as expected. The Developer then moves the task to the “To Be QA’d” list, where the Testers will now verify the issue is indeed complete and correct on TEST. Close collaboration between Tester and Developer is warranted here, as the nature of the fix and any developer tests can be explained so that testing can be as effective as possible. Plus we want to maximize use of automated tests, and minimize any unnecessary manual tests (as they are time consuming and expensive) given the nature of the code changes.

Testing

If the QA passes, the Tester moves the task to the “To Be Released” list. Depending on the nature of the feature, the Business can also help to “test” and ensure things work as expected. If the test fails, then the task is moved back to the On-Deck list and the details added to the issue as comments (if simple) and image uploads (add image link to the comments), or to the issue tracker if it is more complex (even though it is technically not an issue against the released product).

Release

The Developer will schedule the move for “To Be Released” tasks to the PRODuction box. This may require coordination with the client’s IT team if they have internal controls. Following release, the application is smoke tested to be sure the basics are still functioning. If any problems arise, the server can be rolled back, or fixed ASAP, based on the nature of the error.

Once the items are released to PROD, you can indicate that they are “complete.” If the issues came from a list that you want to keep for posterity, simply drag the completed task to the original list (“Iteration 1” for example). Now you can see the items in that list that have been released (i.e., completed).

Summary

I’ve used Jira and much more elaborate SDLC schemes in the past. But a recent Rails project with just a few folks on the team, found us trying out Basecamp. By creating various lists, we can mimic the Kanban-style wall board that Greenhooper provides within Jira. Because the lists allow simple ordering to show priority, and you can drag-and-drop between lists, and you can track your time, I think we have a very lightweight, winning combination.

This process is equally at home doing one feature all the way through, or an entire iteration’s worth of features in a bigger chunk. (Basically dependent on the cost of testing and the appetite of the end-user for changes.)

SDLC process[/caption]