Extreme Programming, Simplifying Software

Pondjumpers Podcast Episode #9 is Out

The Pondjumpers podcast is about (agile) software development in open source communities.  It’s hosted by two self-confessed geeks on either side of the Atlantic: Greg Turnquist of SpringSource (the originator of Spring Python and currently on the TC Server team), and Russ Miles of Open Credo (consultants specializing in building open source communities).  Their first hour-long episode came out in June 14, 2009, and they publish a new one about every other month.  It’s available on iTunes or at http://pondjumpers.com, and you can follow them on Twitter at pondjumprs (http://twitter.com/pondjumprs).

Overcoming Delays – No Silver Bullet

Where past episodes have featured interviews with developers of various open source projects, this episode is devoted to a discussion between the two hosts.  One of their main themes this time around is overcoming delays in software development, from delays imposed by the technology to delays imposed by time zones separating distributed team members.  In particular, they discuss how companies looking to “lower the waterline,” increasingly realize that there is no silver bullet — that it’s always a matter of scrutinizing lots of little things.  Shaving a few minutes here and even a few seconds there all add up.  We’re talking about things like speeding up unit tests, speeding up the compile/run/debug cycle, and how long it takes to commit code to a branch and then merge it into the trunk.  These kinds of time savings make the difference between being able to consistently deploy new code to production in terms of days and weeks rather that weeks and months.

On a related subject, Turnquist and Miles stress the importance of automated continuous deployment (not just continuous integration) complete with “smoke tests.”  Another topic covered is the popularity of distributed version control and, specifically, the trials and tribulations of moving from Subversion to Git.

If Pondjumpers resonates with you, then keep an eye out for a new podcast series that Russ Miles is involved in producing for Open Credo.  It will feature screencasts and videos devoted to, as Miles boldly puts it, “software development in the real world.”  For this endeavor, Miles is aiming to focus on interviews with “honest, no-holds-barred doers.”

Scrum, Simplifying Business

State of Agile – Survey Results

VersionOne today released the results of their fifth annual “State of Agile Development” survey.  For those of us who have been in the trenches, these results are not surprising, but it’s sure nice to see our anecdotal evidence backed up by a survey that sampled over 4,500 respondents.

As you read the survey results, pay special attention to the question, “How Many Teams Adopted Agile?”  29% of those surveyed work for companies with 10 or mores agile teams, with another 17% reporting between 5 and 10 agile teams.  That’s huge — and it should put rest any lingering doubts about whether or not Agile has gone mainstream.

You can read the survey results online and/or download them as a PDF here: http://www.versionone.com/state_of_agile_development_survey/10/

Events, Simplifying Business, Simplifying Software

Simplicity Appreciation 101

1 Comment

If you happen to be near Raleigh, NC on December 7th, I’ll be speaking at the local Agile developer’s group while I’m out there on business.  The title of my speech is “Simplicity Appreciation 101,” and here’s the synopsis…

Update: Due to a scheduling conflict, I was not able to deliver this talk in Raliegh, but I did present it at the Fullerton Code Camp on January 29th. The slides are available for download on the Downloads page.

Complexity is insidious.  It creeps in and takes hold and doesn’t let go.  Time and again, we see major undertakings fail due to overwhelming complexity.  That’s why proponents of Agile methodologies all tout the virtues of simplicity.  “Do the simplest thing that works.”   “YAGNI.”  “KISS it!”

But what exactly is “simplicity?”  Can it be dissected and described?  In many ways, simplicity is ethereal and personal, gleaming only in the eye of the beholder.  But, yes, it can be broken down and viewed with an objective eye.  In this presentation, we’ll explore dozens of examples of simplicity from the realms of software development, business enterprises, and life, in general.  We’ll look at specific cases of simplifications as well as tools and techniques recommended for achieving simplicity.

Our starting point will be ten observations about simplicity by an MIT professor named John Maeda.  In his book, “The Laws of Simplicity,” he describes how simplicity relates to size, time, context, emotions, trust, and more.  These revelations alone provide a solid foundation for making better decisions to achieve simplicity, but, time permitting, we’ll also consider the nuanced wisdom of Albert Einstein, Mark Twain, Winston Churchill, and others.

For further information about this event, see the group’s MeetUp page: http://www.meetup.com/agileRTP/

Scrum, Simplifying Business, Simplifying Software

Prudent/Inadvertent Technical Debt

On the subject of Technical Debt, Martin Fowler identified a TechnicalDebtQuadrant in which technical debt is classified as either Deliberate or Inadvertent and either Prudent or Reckless.  He then makes the case that software projects can reasonably see all four combinations, including Prudent/Inadvertent — even though he can’t think of a real-word analogy that can be used to describe it to management.

How about this? Continue reading Prudent/Inadvertent Technical Debt →

Scrum, Simplifying Business, Tangents and Asides

Team Names – Gotta Have a Slogan

One early, easy win to be had when organizing a new Scrum team is to let the team members name their team.  It takes less than five minutes out of the first Scrum planning meeting, but gets team building and camaraderie off to a great start.

Encourage everyone to come prepared with at least one name suggestion each, along with a slogan for each name.  Winning names always seem to have a catchy slogan.

Continue reading Team Names – Gotta Have a Slogan →

Scrum

The Daily Standup – Sideways

Traditional wisdom says the way to run a daily standup meeting is to go around the room and ask 3 questions: “What did you do yesterday?”  “What do you plan to do today?”  “Do you have any impediments?”

I’ve found a few problems with this approach: First, there’s the deer-in-the-headlights effect.  The three questions are wide open and they call for a certain amount of creativity.  It’s sometimes hard to know what to say to a depth that will be meaningful to the other team members.  So, it’s common to watch someone stutter at first, figuring out what to say and where to begin.  The first person called upon will feel especially under the gun.

A second, related, issue is that by going around the room in order, the team members will anticipate when it’s their time to speak.  So, instead of paying attention to what the others are saying, they’ll tend to be thinking about what they are going to say when it’s their turn.  The big problem here is that, since everyone is given an equal amount of time, it’s too easy to compare one person’s report to the previous, and to the next.  So, everyone feels obligated to not only give a thorough report, but also figure out how to make sure it sounds like they are being personally productive.

The third problem is that this format tends to focus on the facilitator, as if he or she is the only one who cares about the information — collecting status reports — rather than focus on sharing knowledge.

Walking the Board

A better approach is known as “walking the board.”  Continue reading The Daily Standup – Sideways →

Extreme Programming, Simplifying Software

Taking the Stick

A front page story in this morning’s USA Today talked about airline safety and how improper simulator training for pilots often causes accidents.  Flight simulators, no matter how impressive the technology behind them, are not perfect representations of actual flight.  Yet, the airlines rely on them for the bulk of new pilot training.  So, under certain circumstances, pilots take the wrong actions because they react to how the simulator works, not to how the plane actually works.  This is proof that the old adage “practice makes perfect” isn’t quite right.  The saying ought to be: “practice make permanent.”  Practice the wrong things, and you just get good at doing the wrong things. Continue reading Taking the Stick →

Simplifying Business, Simplifying Life, Simplifying Software

This Simplification is a Lifesaver (literally)

Somebody at the American Heart Association figured out that, in most cases, CPR can be just as effective if only the heart-massage part is done, without the breathing part, and that hands-only CPR is WAY better than doing nothing. So, they’ve launched a campaign to spread the word, complete with how-to videos and smart-phone apps.  See http://handsonlycpr.org/.

This is a drastic simplification, and there’s a big lesson in this for us Agilsts. Continue reading This Simplification is a Lifesaver (literally) →

Extreme Programming, Scrum, Simplifying Business

Take 5 – A Tip for Running Retrospectives

Quite by accident, I discovered a bit of magic to running a 2-hour retrospective meeting. Halfway in, between the brainstorming part and the planning part, I needed to find a resource on my laptop that was eluding me (a file I had misplaced). So, I called for a 5-min break. I left the conference call phone bridge up and told the distributed team members to just set down their phones and come back in five.

What I discovered is that a few people hung out during the break and started to chat socially across the phone bridge — on the subject of marathons and bike races, in this case. I realized that it was a rare occasion for the distributed team to bond on something other than work. So, I let the conversation continue for a good 10 minutes after the break. I also realized that when we eventually got back into the task of turning our brainstorms into action items, it was with a clean slate and a slightly elevated outlook. I’m positive that the decisions we made during the second half of the meeting were better than they would have been had we gone straight from brainstorming to acting. For one thing, the break allowed everyone to unhook themselves from their particular brainstorm contributions and come back at the whole list with a wider view.

So, from now on, I’m going to find any excuse to take a break, and I’ll be sure to specifically prompt everyone to “chat amongst yourselves while I’m busy doing X.”

a blog by Craig L. Jones, Software Agilist