Category Archives: Extreme Programming (XP)

Introduction to Test Driven Development at Nashua Scrum Club

I had the opportunity to give a talk “Introduction to Test-Driven Development” at the Nashua Scrum Club this week.  It is a great group of folks, and if you are interested in learning more about Scrum and Agile practices you should check them out.  They are a diverse, engaging group of folks covering the full spectrum of roles in a Scrum organization.

The talk was targeted for all the roles on a Scrum team, and my goal was to give a small taste of what TDD can bring to a software project.  I have been using TDD for about 5-6 years, and I have definitely become “test infected”.  I can’t imagine developing production code any other way.

I wanted to stress the importance of working iteratively, and getting through the Red-Green-Refactor loop quickly, adding more and more functionality with each new test.  One of the areas new teams may struggle with TDD is to try and do too much in a single pass through the loop.  If you get bogged down and are in the loop for more than 15-30 minutes you may be biting off too much in this test and should look to a smaller incremental step.

Given the broad spectrum of roles that were at the meeting (Scrum Masters, coaches, QA/test, developers, managers, product owners) I also wanted to show how tests can be used to get the team to collaborate more.  I think tests can be a great mechanism for developers to collaborate with product owners to make sure the behavior is as intended.  There are also opportunities for QA/test to work with developers to understand what is tested at the unit and integration level.  Finally tests are a great mechanism for developers to share knowledge.  When I am looking at a code that I may not be as familiar with, I find the tests to be a great place to start to understand what functionality is provided.  In essence, the tests become an executable specification of the system.

We also spent some time talking about TDD and design, which I know has been something of a hot-button topic lately.  Does TDD guarantee a good design?  Is it a good design methodology?  In and of itself, I would say no.  But what I would say is that TDD encourages good design practices and to do it well, i.e. not have brittle tests, you need good design practices.  I had almost 20 years experience before starting TDD and felt I was a good object-oriented designer.  TDD helped me step up my game in terms of design and developing more modular, loosely-coupled code.  We touched on design practices like SOLID, YAGNI, DRY, separation of concerns, how design patterns like MVC allow better, more thorough testing.

Finally we talked about the challenges of adopting TDD.  Change is hard, and a switch to TDD can be a difficult and frustrating experience.  TDD requires strong design practices.  There is also the battle to fight about writing “all that test code”, to which I always like to ask “How much were you writing before”.  Jim Shore summed it up well when he said that you should expect 2-3 months to make the adjustment.

I had a great time at the Nashua Scrum Club, and want to thank everyone there for making it a fun (and hopefully informative) evening.  I look forward to a return visit soon.


Startup Lessons Learned Conference

Yesterday was the Startup Lessons Learned Conference in San Francisco.  Although I heard it was a beautiful day in SF, I enjoyed the conference from Cambridge, compliments of the Lean Startup Circle – Boston.  It was a great day, met a lot of interesting people in Cambridge, and heard a lot of interesting folks via the simulcast.

This was my first time at a meetup of the Lean Startup Circle in Boston and I really enjoyed it.  The group may gravitate a bit to the entrepreneurial side, but that is not unexpected.  Still I would like to see a broader spectrum of people and industries embracing the ideas of lean/agile, but it is a movement and that will take some time.  But thanks again to Matthew Mamet and John Prendergast for putting the event together.

Keynote – Eric Ries

Eric Ries kicked things off with the keynote.  The takeaway for me here was the definition of a startup:

A human institution creating a new product or service under conditions of extreme uncertainty.

It has nothing to do with the size of a company, what industry it is in, how it is funded, etc.  We need to develop practices that are geared towards managing and responding to that uncertainty.  He talked a lot about the Build, Measure, Learn loop (which Kent Beck later turned around to the Learn, Measure, Build loop), ways to fail fast, and knowing when it was time to pivot.  If you follow Eric’s blog there was not much new here, but he was setting the table for the presentations and case studies that would follow.

Build, Measure, Learn – Kent Beck

Kent Beck followed Eric Ries.  Kent was part of the Agile Manifesto and invented test-driven development and pair programming.  As a developer, TDD and pair programming are two of the most powerful tools/practices I have seen in all my years.  As I mentioned earlier, Kent talked about the Build, Measure, Learn loop, which makes sense from an engineering/development point of view, but by running the loop backwards, we are pulling the build (from Lean Manufacturing‘s concept of pull) from what we learn.

Kent also went through other aspects of the Agile Manifesto: people over processes, collaboration, accepting change.  He was preaching to the choir, so he didn’t go into too much depth.    He did go into some depth on knowing when to live with a simple solution to get a product out (he used the term “hackery”) and when you need to refactor.  As an example, he cited Amazon Dynamo.  At the scale they operate at now, this is an essential service, but if the had tried to start with that, they would have ended up in the scrap heap.  As a developer, I have seen many projects get behind by over-designing or over-engineering early on.  Getting out there early allows you to see if you have a viable product and as you learn more about usage/features you can refine your design and implementation.

Agile Development Case Study – Farb Nivi

A real highlight for me was the Agile Development case study at Grockit, by Farb Nivi.  Farb went into a lot of great info about accepting change/chaos, how to write good user stories (make them narratives, not “to do” lists).  He talked about an Agile planning  tool they use called Pivotal Tracker that I need to take a look at.  His presentation also had a very cool feel to it and was done with a tool called Prezi.

The thing that really caught me about Farb’s presentation was the development culture and the way they have embraced pair programming.  The interview process at Grockit is simple.  Candidates come in and pair program with one of the development team.  I can’t think of a better way to get to know whether a candidate is someone I would want to work with and has sound software engineering skills. I have had a few posts on the value of pair programming and the challenges in getting more developers to adopt it, so having this question about a candidate answered up front is invaluable.

Grockit’s philosophy on languages is simple and straightforward too.  They don’t care what languages or tools you have used, if you have good skills and work well as part of a team you will be able to produce good code in whatever languages they are using.  That is an incredibly refreshing and enlightened attitude (although on their website they say you need to have programmed in Java and Ruby for at least a year.  Jeez, Farb which is it LOL).  Developers at Grockit spend 70-80% of their time pairing, with the reminder spent on spike’s or some other stand-alone tasks.

Getting to Plan B – Randy Komisar

After the break, Eric Ries sat down with Randy Komisar in a talk titled “Getting to Plan B“.  This was a great back and forth discussion between Eric and Randy.  Randy talked about answering the “Leap of Faith” questions.  These are the questions that you need to answer, that if you don’t know the answer to will kill your product.  They can be technical, marketing, whatever.

Randy also talked about the importance of a “dashboard”  to guide you and track your progress: are you measuring the right things to answer your leap of faith questions.  I found some interesting articles with the Sloan Review and Sramana Mitra that touch on a lot of what he talked about.  When the presentations go online I strongly recommend watching this presentation.

In Closing

There were several other good presentations, more than I can write about.  When the presentations go online I strongly recommend checking them out and finding the things that hit home for you.  And thanks again to the folks at the Lean Startup Circle – Boston for putting on the simulcast and giving a place for people to get together and exchange ideas.

Update: The videos from the Startup Lessons Learned conference are available on

Convincing Developers on the Value of Pair Programming

Something that often comes up when discussing the topic of pair programming is the notion of convincing management of its value. Am I paying twice as much to have two developers to work on a task instead of just one?

My experience with convincing management of the value of agile and XP methods has been if you deliver software on time and with few defects management will accept whatever practices get them those results.

The problem I often face and find much more challenging is how to convince other software developers of the value of pair programming. Getting comfortable with pair programming can be a challenge. The evolutionary nature of software development in an iterative, TDD environment means we don’t have all the answers up front. That can be an uncomfortable feeling. Nobody wants to look like they don’t have a clear vision of where the design is going or be uncertain about the best way to implement it. My advice is to get over it. The other person you are pairing with is in the same boat. When you switch seats and they are at the keyboard, they are going to be leaning on you to see the big picture and help guide the design.

Some people advocate code reviews and feel they can serve the same purpose as pairing. That is true in a sense, but one of the problems I have with code reviews is grasping the subtleties of the design and what trade-offs went into a particular design decision. With pairing you are intimately involved in the design, coding, and testing. You talked out the trade-offs as you went along. The tight feedback loop in pairing also reduces the likelihood of having to make a major refactoring that may come out of a code review. I am not opposed to code reviews, I just think pairing provides a better mechanism for good design and coding practices.

A lot of successful pair programming has to do with the two engineers developing a good working relationship and respecting one another. Talk through alternatives, try different implementations, write good tests, listen to one another, and learn from one another. My pair programming experiences have been some of the most gratifying development experiences in my career.

Project Retrospective

I held my first project retrospective this week. It was probably overdue, but there is no time like the present right?

I found Peter Steven’s blog and Boris Gloger’s paper on Heartbeat Retrospectives helpful in setting the format. I decided to cover the following topics in our retrospective

  • What did we do well?
  • What can we improve on?
  • Who has ownership of the things that can be improved?
  • What are the priorities?

We used sticky notes and a white board. You need to be succinct to state your point on a sticky note. Plus once they go up on the whiteboard they tend to lose ownership and they become the team’s ideas. There were only a few times when we had to ask who wrote something and that was only to clarify an idea. The group ownership of ideas keeps things flowing and prevents the meeting from being driven by one or two strong personalities.

Starting with “what went well” set the tone that the meeting is going to be positive and constructive. At other companies I have been at these type of meetings often turned into a finger pointing exercise and went downhill rapidly. Our team has a lot to be proud of, and it was great to reflect on the things we did well. And if it ain’t broke…..

The things we thought we did well broke down into 3 catgories: Team, Process, and Technology. I am not sure if that categorization was planned or an impromptu decision. Grouping them into categories didn’t really serve any purpose other than it allowed us to acknowledge each point as we decided where it belonged.

Like any project there are things that we can do better. We purposely did not put any limits on what people thought we could do better. Once we put everything up on the board we broke it down into two groups: Team and Organization. Team means we can do it within the framework of our own team structure. Organization meant we had to bring others (HR, management, etc) into the mix to help address the problem.

Once we had things broken down into 2 categories, it was time to prioritize the lists. There are a couple of different schemes you can use here. Seeing the same issue raised by multiple people may indicate something that is important. Ultimately we decided to do a simple voting scheme where everyone got one vote, and that seemed to work pretty well. Next time we may try giving everyone three votes, but that’s for next time. We have a small team, so there were only a few items in each category that got votes, but even that tells you something, and we were able to prioritize those items. The reality is you can’t fix everything, so you focus on what is most important.

Probably the most important part of a retrospective is that you take action on the high priority things to improve. I am anxious to seize the momentum and teamwork of the meeting. That is the challenge for me and the team in the very near future.

Weekend Reading

I went away for a relaxing weekend, far from cell phone reception and internet access. Given my recent post about not being able to turn it off at the end of the day, maybe it is slightly ironic that I packed two books: The Art of Agile Development and The Art of War.

The Art of War is one of those books I like to pick up from time to time. I am not a fan of comparing war to sports or work, there is no comparison. The book is a good read though for understanding strategy, how to utilize resources, and human interactions. Many of the concepts are applicable to daily life.

I found an interesting passage in The Art of War that could be applied to the concept of Energized Work.

In War,
Victory should be swift
If victory is slow,
Men tire, morale sags
Sieges exhaust strength;
Protracted campaigns
Strain the public treasury.

If men are tired,
Morale low,
Strength exhausted,
Treasure Spent;
Then the feudal lords
Will exploit the disarray
And attack.
This even the wisest
Will be powerless
To mend.

Energized Work and Personal Responsibility

Logically, I believe in the concepts behind what the XP community refers to as Energized Work. Software engineering is a complex activity and it requires you to be fully engaged and focused. That is hard to do if you are working long hours. The problem I have with it is that over 20+ years of working as a software engineer, I have conditioned myself to work to the limits.

I was talking with another developer about this recently and I said that it really takes buy-in from management to make Energized Work possible. He turned it around and put the burden back on me. His thinking was it only worked if I made the decision to follow the principles and it would never work if I waited for someone else to make it happen.

That meant I had to make the decision to leave work at a regular time. That I had to make the decision to spend time with my family instead of sneaking off to do work. This developer and I have worked together in the past and he knows my work habits pretty well. His analysis stopped me in my tracks.

Bad habits are hard to break. One of mine is not being able to turn it off at the end of the day. I have to put the blame for that squarely on me. I have no problem saying to another developer “Go home, you’ll get it in the morning”. I need to remember to apply that advice to myself from time to time.

Pair Programming Follow-Up

In my last post I described some of my early impressions on my first pair programming experience. Still no complaints, although a few additional observations.

I am surprised at the end of the day to find that I am a little mentally drained and I think that is a good thing. The effort that we are putting in is sustainable, but it is also very focused. There is little down time since at any given moment at least one of us is “on” and good progress is being made. Even when we are at a point where we are stuck the ideas are still flowing and we are both mentally engaged in the process.

Given the focus that we both have on the task, I find it beneficial to take breaks from time to time to check email, grab coffee, and even read a few blog posts. It would be a tough pace to maintain continuously and I think the occasional 5-minute break keeps both of us fresh.

We are doing a good job of share time at the keyboard, and I see a real difference in the approach I take depending on whether I am at the keyboard or not. When I am at the keyboard my focus is on the details of programming: variable names, style, and yes…just being able to type with someone looking over my shoulder. When I am not at the keyboard I seem to see the big picture better: are we repeating code, what is the complexity like, is this code easily testable.

I just started reading James Shore’s The Art of Agile Development and I hope to learn more about the mechanics of pair programming and tips/techniques to be more successful at it. Mike and I are pairing well together (I think), but I am also looking forward to pairing with someone else on our next iteration , getting a better understanding of how they work and how we can work together.