Category Archives: agile techniques

Pair Programming Comments

Yves Hanoulle had some questions from class participants on his post about Pair Programming. I am not a very experienced pair programmer, but that didn’t stop me from providing some answers 🙂

* Can you PP over skype?

Yes — or other similar screensharing technologies (iChat) that allow you to switch control. @jbrains and I did pairing for a code retreat a couple of months ago. You can see the code and a video link here on github.

* Do we need somebody to ‘supervise’ the way you do PP ? (Esp in the beginning?)

Might not be a bad way to more quickly learn from someone else’s tips and techniques. But even better, just switch up the pairing so that you gain insights/ideas from other people with more experience.

* What if there’s no option possibility to use some OS/Computer

With no computer to program on, you would have to stretch the limits of the definition of pair programming I suppose. Pair Yapping About Programming — P-YAP?

* What to do if there is a conflict between the two, a discussion??

Try and sketch out the competing ideas in code. Unless the argument is about which beer is best… then you need to take it to the bar and do a double-blind taste test.

* It can’t work with any type of character, how do you manage?

Pairing should be optional.

* What if one uses AZERTY and another one QWERTY keyboard?

You could solve that with technology.

* Doesn’t it make it harder to plan a project or resources people (Yves re-framed resources to people)

I would suspect the team that pairs is not that much different than a team that doesn’t pair. Both teams are probably lousy at estimating <g>. Instead of stressing at how PP affects your team, just make an initial guess at your estimates and alter the guess after each iteration.

* Can someone do PP with 1 person and PP for something else with another person?

I don’t understand the question. If you mean simultaneously, no. If you mean one time someone does Pair Programming with person X, and later does Pair Painting with Person Y — sure, this is possible. But what does it have to do with anything?

* Can you get into “the zone” when you’re PP-ing?

Probably. You’ll just have to try it and see.

* Does Promiscuous Pairing kill the flow? (30′ interrupts)

Never tried it. Let the team try it and see what happens.

* Why not use PP all of the time?

Let the team try it and see what happens.

* PP = More talking = more annoying for other nearby teams?

It is more annoying for people that are bothered by such environments. I suppose some people prefer quiet.

* Do you plan who is going to do what or how do you choose whose turn it is?

Let the team decide.

* Can you do PP with > 2 people?

You can do whatever you like. Just observe if it is effective or not. I suspect you might find diminishing returns.

* How do you handle the “Don’t care”?

What does this have to do with PP? If you have done everything humanly possible to help someone become a productive member of the team and they are intent on being a-holes; and you have warned them of the consequences of being an a-hole to the team; then fire them so that the team morale is not broken by “one bad apple.”

Simple != Easy

In a nice, vintage post from the oh-so-wise Ron Jeffries,  as I saw this heading:

“It couldn’t be that easy!”

It led me to think, possibly a different way to say it…

“It couldn’t be that simple!”

Because I think what Ron is getting at — at least this is what I believe to be true — is that, many times, folks over-complicate things.

In addition, folks often confuse simple and easy: just because something is simple doesn’t mean it is easy.

Conversely, just because something is hard doesn’t mean it is complex. I think sometimes folks run into “hard” things to do, and decide that it has to be complex to justify the degree of “hard.”

Not so…

Keep it simple.

(Now, go look at the date of Ron’s post!)

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!

Getting Started w/ Best Practices & Design Principles

Praveen had a seemingly innocent question here and there were lots of good answers…

If we are following Agile Methodology (Scrum) & We are in Java/J2ee Domain,

What are the Best Practises & Design Principles need to be followed
while designing the applications.

Big question is an understatement… here’s what I would advise:

  • Understand the business domain
    • because, if you get that wrong, it doesn’t much matter how well-crafted and well-tested your code is
    • Design using Separation of Concerns as the granddaddy of all patterns to sear into your brain.
    • Be sure you use a layered approach to your architecture — if I catch you putting SQL in your javascript, I’ll come over there and stab you in the toe
    • Design in the Large to avoid excessive dependencies
    • Design in the small to adhere to all those good practices like SOLID
    • Consider looking into the Domain Neutral Component — within which a shockingly huge number of domains tend to fit.
  • Architect and build the application in a highly consistent manner — much like Rails enforces.
    • If you have a dozen domain items that need the same sort of treatment from persistence to UI, please don’t get creative and do persistence 5 different ways.
    • Pick one and stick with it for the sake of consistency!
    • I’d rather a consistent implementation that is mediocre, than one with 5 different approaches (one stellar, one horrid, and the rest mediocre). Why you might ask? Because it is easier to refactor when things are consistent 🙂
  • And, of course, apply an agile process…
    • Involve a customer/proxy to ensure you understand the requirements from the business perspective, do not rely on documents — but if you must, then you need to exaggerate the agile process and make it more granular. That is, to compensate for the likelihood that the written word is ambiguous, you need to show small steps of progress on a feature and get rapid feedback to ensure you are not mis-interpreting the requirements doc.
    • Build a vertical slice of your design to prove it out and to serve as a model for how you will work on your app
    • If you have stringent performance needs, prove them out early
    • Show working code early and often
    • Get yourselves set up on an automated build
    • Try to build out the features using something like BDD or TDD
  • General
    • Be patient with your learning
    • Be impatient to see results, don’t let any team member or task go dark for more than a couple of days
    • Create the lightest-weight process possible
    • Don’t do anything to excess without frequent feedback
    • Always foster a team attitude to question everything with boldness — including my advice

Hope that helps

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.

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!

Refactoring Cucumber Features

I was inspired by this post (You’re Cuking It Wrong) to re-look at some feature specs to see if I could improve them.

I went from here:

Feature: Season Management
Scenario: Create a Season
  Given an organization like "My YMCA"
  When I add a season like "Summer Basketball" for "My YMCA" from "1 May" to "31 August"
  Then I should see the "Summer Basketball" season for "My YMCA" in a list of the organization's seasons

Scenario: Add a Registration Setup
  Given the "Summer Basketball" season for "My YMCA"
  When I add a setup like "Summer Signup" open from "1 April" to "30 April"
  Then I should see "Summer Signup" under the "Summer Basketball" season

to here:

Scenario: Create a Season
  Given an organization like "My YMCA"
  When I add "My Season" season
  Then I should see the "My Season" season

Scenario: Add a Registration Setup
  Given the "My Season" season for "My YMCA"
  When I add a setup like "My Season Signup"
  Then I should be able to signup under "My Season"

This also led to improvements in the steps. For example, by getting rid of the unnecessary dates, I also removed some unintended “brittleness.” As an example, this:

When /^I add a season like "([^"]*)" for "([^"]*)" from "([^"]*)" to "([^"]*)"$/ do |season, org, from, to|
  visit organizations_path
  click_link org
  click_link "New Season"
  fill_in "Name" , :with => season
  fill_in "season_starts_at" , :with => from
  fill_in "season_ends_at" , :with => to
  click_button "Create"


When /^I add "([^"]*)" season$/ do |season|
  visit organizations_path
  click_link # Created in a prior scenario, no need to pass in
  from =      # Create more appropriate from/to values
  to = from + 120*24.hours
  click_link "New Season"
  fill_in "Name" , :with => season
  fill_in "season_starts_at" , :with => from
  fill_in "season_ends_at" , :with => to
  click_button "Create"

Subtle, maybe, but certainly more clear and less likely to need attention if/when the solution changes.

Scrum Dust Up

This post is in response to this:

Kripanidhi said the following on 10/25/10 9:34 AM:


It may have been a very interesting and useful idea to have included one more question in your survey:

“How many Certified Scrum …..Masters, Teachers, etc know how to code or have ever written a piece of software that was paid for ? ”

I could easily speculate that figure at less than 50%. Can guys who have never hacked in their lifetime, call themselves Agile ? and worse still teach others how to hack and Scrum ?

Food for Thought

I view Scrum more like a form of Project Management. Nothing more. Nothing less. But I might be mistaken. I am not certified. At least not in that way.

Anyway, given that as my starting point… I am not sure if teaching how to do a particular style of Project Management (e.g., CSM) requires knowing how to do the work that will result in the end goal. AFAIK, Scrum can be applied to many things beyond software. Even for software, does a good PM have to know how to do great graphic design, or be a brilliant UX person, or be the most awesome coder/hacker? Maybe folks drawn to CSM actually realize they can do more for the project than simply do mediocre coding.

Now, would knowledge of the “how” help a manager be a better manager? Probably. But isn’t a truly good Project Manager (Scrum or otherwise) cognizant of the need to trust (but verify) their folks to do the right things? Sure, sometimes it is helpful to question an estimate, or critique a design approach, or help shape the product roadmap, or ask probing questions… But does that require intimate knowledge solely on the part of the CSM? Or does it require a good team effort? To turn the argument on its head: is taking the best coder out of the loop to be the CSM a good idea?

Despite my personal preference for (and being) generalizing specialists, I do not think it is a fair pass/fail “litmus” test to say a CSM has to be a hacker/coder/doer of everything.

Personally, I don’t think we have to challenge the CSM individual’s hacking skills. After all, do hackers inherently make better managers? Rather, we should challenge the terminology that bestows the ludicrous moniker of “Master” after a few days of classroom training. Of course, as a counterpoint, the concepts behind Scrum are simple enough to be mastered in a couple of days — that’s the beauty of a simple technique. But the skill of being a Project Manager can take a lifetime to master, Scrum or otherwise, IMHO.

I think what is worse is the blind-faith that someone who has been certified as a CSM is qualified to run an agile project. Or the illusion that everything else we do can suck, but as long as we have Scrum, we’ll succeed.

The beauty of a free market: this CSM brouhaha will sort itself out. Companies will learn one way or the other that there is no magic bullet to hiring (despite the world’s stupidest job postings for CSM folks), nor is there a silver bullet to getting projects completed successfully.

Using Basecamp in an Agile Manner

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


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.


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.


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).


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).


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]

Tale of the Demanding Consultant

So, I just heard that a consultant canceled a gig at a company because — get this — the company did not move off of a big VCS system prior to his Scrum (etc.) engagement. (In the words of one friend, it sounds a bit like a temper tantrum or elitism.)

In my opinion, any consultant worth their salt would simply deal with it… the choice of VCS is *not* an issue. Neither is the choice of “Use Cases” or “User Stories.”

If you think these sorts of things are a big deal,

  1. go directly to jail,
  2. do not pass go,
  3. do not collect $200.


Consider this a “Bad Smell” should you face such a pre-engagement demand!

Agile Bashing?

On a few different lists, on twitter, and elsewhere, there seems to be some disillusionment with “Agile.”

Here is a great article that outlines the rancor.

Much like pre-Snowbird, in my last few engagements over the past 4 years (just by way of recent examples), I always pushed solving the underlying business problem and providing solutions, as that was what the folks I was talking to needed. It just so happens that I use a lightweight, agile approach. It just so happened that the client was cool with that (and even if they weren’t, I would find a way to do it anyway <g>).

In other words, I did not come in selling agile and accidentally found a project. I was selling being able to help their team solve a business problem and deploy a solution.

One engagement (i was leading the team for about 2 years) was with a company devoid of much effective s/w processes (inefficient waterfall and palpable business/IT schism). Now they have an effective (distributed) agile process, they have a lightweight set of tools, and a good relationship between the business and IT. As agile as I would like? No. But on a scale of 0 to 10, I am very happy that they are probably a 6-7, and even happier that they continue to try and improve. After all, they are in charge of what practices they chose to adopt within their own constraints. I simply shared with them how I have had success doing projects. Some things I suggested we adopt were rejected. Some of those bit the team later — which was a better lesson than had I forced it down their throats.

However, many other times, I think, people/orgs are seeking to just become *more agile.* Or they want their people to be certified in this or that. For some reason, they probably think this will help them succeed. And maybe it will. For me, it is a bit nebulous. I always like to tie all education/training with actual doing so that the lessons would sink in and so that people had a reason to succeed.

Unfortunately, these orgs seeking “more agile” may not necessarily tie the agile transformation to any sort of project success. Rather, they just want to learn better techniques in the hope that it will foster improvement to their bottom line. Sometimes it is just throwing a bone to the folks to try and take their mind off of the truly waterfall world in which they operate.

At times, the agile hype is almost like “If I wear these jeans, I will be buff and have great-looking people surrounding me.” As Madison avenue has brainwashed most of us, that technique is very effective.

Frankly, this is a normal process of a good idea being turned into a movement being turned into a fad being turned into a money-making opportunity resulting in disillusionment and spotty success.

Warts and all, I’ll happily take the rewards that having agile “out there” has provided “humanity” — even if it is abused at times.

The smart and skeptical will prevail and the easily duped will be duped. The beauty of a free market 🙂

Caveat Emptor!