Category Archives: Agile

SOLID Design Principles at Launch Academy

I had an awesome day speaking to the students at Launch Academy in Boston.  I have a lot of respect for what Dan Pickett and Evan Charles are doing over there, and I hope it brings a lot of new, great developers into the community.

I had initially planned on doing a talk on the SOLID design principles, but as the group is just starting out learning good practices, I didn’t want to throw too much at them at once, so we focused on Single Responsibility Principle, Dependency Inversion Principle, and an Agile design practice called Incremental Design.

It was a ton of fun.  They are such an energetic and engaged group.  They had very good questions about technical debt, what constitutes a good test suite, and resources for further learning on TDD.

The talk is available below, although due to some technical difficulties at the talk I had to re-record it, so I didn’t get their questions or the wild applause at the end 😉

Thank you Launchers for hosting me, and I look forward to seeing more of you in the Boston developer community.

The example code used in the talk is available here

Here are the references from my talk

Bob Martin (Uncle Bob) on SOLID

Sandi Metz – SOLID Talk at GORUCO

Derick Bailey – Los Techies

James Shore – Art of Agile

And lastly, here are the slides


An Active Listening Retrospective

The team I am on holds a retrospective at the end of each week-long iteration.  I am a huge fan of retrospectives as they can help teams improve their processes and nip developing problems in the bud.

Our team has a lot of Agile experience and we typically trade off the facilitator role, so the retrospectives have a nice variety of styles and everyone gets a chance to improve their facilitating skills. Our retrospectives normally gravitate towards process improvements or specific technologies that we can improve as a group.  This week however, I wanted to experiment with a new format that I came up with influenced by some meditation and mindfulness practices that I have learned over the years.  One of the techniques I wanted to use in the retrospective was active-listening.

Some of the questions that were on my mind…

  • When we are pair-programming and our pair asks a question are we giving our full attention to what they are asking, or are we more focused on the problem that we are working on?
  • When someone raises an issue at the team standup, are we mentally preparing our rebuttal and not focusing on what is being said?

Laying the Groundwork

This style of retrospective needs to be held in a quiet place like a conference room, with enough room for team members to spread out in pairs without distracting one another.

At the start of the retrospective I reminded the team that we had all probably come from working on some challenging task, and our minds may still on those tasks to some extent.  To be fully present at the retrospective, I asked everyone to take a moment to clear their minds and focus on being present.  Next time I may try a short breathing exercise to help that process, but sometimes just reminding people to be present is enough for them to realize the distractions that may be going on for them and to put them aside.

The Mechanics

I asked everyone to take a few minutes, in silence, to think about what happened in the last retrospective.  What went well, what could have been improved, what pleased them, what frustrated or challenged them, whatever came to mind from the iteration.

I then asked people to pair up.  I chose names out of a hat because I wanted the pairs to be random and possibly have people pair up with someone that they might not normally seek out.  Also it eliminates the stress of “choosing” someone.  If there is an even number of people at the retrospective, the facilitator can participate, otherwise they focus solely on facilitating.

I then instructed the pairs to find some space away from the others, and for a few minutes (3 minutes in our case) one of the people would be the speaker and the other would be the listener.  I encouraged the listener to pay close attention to what the speaker was saying, and try not to form responses in their minds.  If the conversation lagged the listener could ask open-ended questions, but ideally they would focus only on listening to what the person was saying.

After the 3 minutes was up, I asked each of the listeners to tell the group what they heard from their speaker.  Everyone did a great job recalling what was said.  After each “listener” spoke I asked the “speaker” if the listener accurately relayed their conversation and if anything had been left out, which gave them a chance to fill in the gaps or clarify something that was said.

We then repeated the process changing speaker and listener roles.

After everyone had a chance at the “speaker” and “listener” roles.  I went around the room and asked each person if they heard anything that stood out in particular or that surprised them.  I made a conscious effort to allow each person to say what was on their mind, without getting a conversation started with the whole group.  If others chimed in I asked them to please wait until everyone had a chance to speak before we turned it into an open discussion.

A few common themes emerged from the individual observations, and after everyone had a chance to speak individually we discussed the common issues for a bit and came up with some actions to address them coming out of the meeting.  I wrapped up the meeting reminding everyone that we are often hyper-focused on the problems in front of us and may not give one another our full attention, but that we should be mindful of that and try our best to listen to one another.  I hope we can build on that as a team.

The Take-Away

One of the coolest things about the format, that I didn’t realize until it was happening, was that everyone got a voice through someone else telling their story about the iteration.  It is inevitable on any team that some people are more outspoken than others (I am no shrinking violet), but this way everyone got the floor.

I think it was also an opportunity to remind everyone that we each have our own perspectives and we should respect and try to understand each other, even when we may not agree.

Total time for the retrospective, with 6 participants, was 45 minutes.

Further Reading/Watching

If you are new to retrospectives, I highly recommend Esther Derby and Diane Larsen‘s book Agile Retrospectives – Making Good Teams Great.  It has great techniques for organizing and facilitating retrospectives so that they are most effective.  They also have formats that are designed to address specific issues that may be a concern for your team.

If you are interested in mindfulness, I recommend that you check out the Center for Mindfulness at the UMass Medical School or take a look at these videos with Jon Kabat-Zinn, founder of the Center for Mindfulness, speaking at Google.

Stone Soup Development

I consider myself lucky to work in an environment that not only follows, but embraces, Agile and XP practices.  We follow test-driven development.  We pair program almost all the time, and we switch pairs frequently, usually at least once per day.  The benefits of these practices hit home this week during our iteration retrospective when the question was posed “What were you proud of this week”.

There were some interesting problems with very creative solutions that happened during the iteration, but the thing I was most proud of was a simple little piece of code.

Around the middle of the iteration I worked on a “calculator” that made some determination based on a set of rules.  We’ve all written code like this 1000 times before, it was not an especially difficult task.  But it was the kind of thing that could get ugly pretty quickly, and yet still “work”.  It was the kind of algorithm that could have easily morphed into a nasty tangle of boolean logic.

Instead, my pair and I started out with a few simple cases and applied a few brute force implementations in the “Calculate” method.  We continuously refactored as more tests were added and the complexity grew, reducing duplication and breaking the problem up into more digestible chunks.  At some point, my original pair swapped out and someone else swapped in for an hour.  It was late Friday, we improved some of the naming, added a few more test cases and supporting logic, then called it a day.  Energized work in action.

Monday morning, a new person swapped in.  Normally I would have swapped out since I had been on it the longest, but there were a few scheduling conflicts and so I stayed on.  We finished the class, ending up with very expressive names, a “Calculate” method that read like plain English, and small methods that did one thing, and did them right.  Again, this problem wasn’t rocket science, but it was done right.

Everyone brought something to the problem and helped refine the design.  We discussed trade-offs, avoiding traps like “my idea” and “your idea”.  After discussing it at the retrospective, it reminded me of a story that I learned as a kid called Stone Soup.  We started with nothing, everyone threw a little something in the pot, and we came out in the end with a nice little piece of code.

I Hate Year End Lists

One of the things that drives me crazy about this time of year, is the never-ending set of lists for what happened in the last year, or resolutions for the new year.  Absolutely hate them.  So why am I writing one now, good question, I have no idea.  But if you hate lists and have stopped reading, oh well.  Anyway, here’s my lists of things to get done in 2012.

1. Set Up a GitHub Account – Really?!?!  It is the tail end of 2011 and I don’t have a GitHub account.  More and more it seems to matter less and less what is on your resume.  Show me what you’ve done.  Show me you can collaborate and play nice with others.

2.  Learn Ruby – I don’t mean dabble in Ruby.  I don’t mean write “Hello World” in Ruby.  I don’t mean write C# style code with Ruby syntax.  I’ve done that and it hasn’t mattered much.  Learn to write Ruby style code in Ruby.  Why?  Because maybe it will make me a stronger developer across the board by introducing me to different ways to write code and solve problems.  I also think the Ruby community as a whole are strong proponents of software craftsmenship.  Or at least the ones I run into are, and that can only be a good thing.

3.  Write More Code – The last few years I have spent a lot of energy working with Agile practices, and especially trying to help the teams I am on be more productive and write better, well-tested code through practices like pairing and TDD.  I am very proud of the end results, but a side effect of that has been that I write less code on a day to day basis.  That may require being creative and looking for new opportunities to write code outside of my day job.  But I really miss the challenges of solving technical problems on a regular basis.

4.  Read More Code – Participating in the Global CodeRetreat was a great opportunity to work with a lot of developers, all with different experiences and skill levels.  Being an experienced developer is great, but there is so much to be learned from seeing how other people solve problems.  Instead of just downloading some open source tool that makes my life easier, peek under the covers, run the tests,  I don’t know…maybe even contribute to the project.  At the very least get some new ideas.

5. Get Out of My Comfort Zone – Over the years I have developed a set of skills and practices that work well for me and that I have been successful with.  I wouldn’t say it is easy, but it is a little safe.  I have experience with problem domains I work in, I am comfortable with the languages I use, and I have developed a set of practices that are well ingrained in me.  That’s all well and good, but there is a potential for a lot of growth to be found outside your comfort zone.

6. Buy a Mac – Windows and Microsoft have been good to me, and I have used Windows for work for the past 20 years or so.  I will probably still do my day job work on a Windows machine, but in the spirit of learning new languages and getting out of my comfort zone, maybe it is time to see how life is from the other side.  I could do all these things on a Windows box, but it’s time for a little change.  Plus I can hang out with the cool kids at developer events.

So I am seeing a theme here for 2012.  Hopefully I can make it all happen.

Have a safe and happy new year!

It’s Only….”Mostly Done”

A good measure of how mature your Agile process is to ask “what is your team’s understanding of done”.  Does being done mean all the tasks are complete, does it mean that the developers have implemented the feature to their satisfaction, has it been tested by QA, does it mean that it has been demoed for the product owner and she has accepted it.

Recently our team had a story that was “done” and we took credit for the points in our iteration.  But a few days after the iteration ended there were a few more check-ins against the story.  Nobody was trying to hide anything, it was brought up at the daily stand-up, but were we really done at the end of the iteration?  No.  It reminded me of a great line from the movie The Princess Bride where Miracle Max says

He’s only mostly dead.  There’s a big difference between mostly dead and all dead. Mostly dead is slightly alive. With all dead, well, with all dead there’s usually only one thing you can do…Go through his clothes and look for loose change.

Miracle Max - Early Agile Evangelist?

The Agile corollary to that is

There’s a big difference between mostly done and done-done, with done-done there’s only one thing you can do…Go through the backlog and look for new stories.

Being done-done requires that the team understands the story, that there is agreement to how it will be tested and verified.  The story should be demo-able and the product owner needs to be available to clarify questions that inevitable come up during implementation.  It also means that other parts of your software process are followed, e.g. code reviews, documentation, etc.

If your team doesn’t have a common understanding of what done means, you are in for some trouble.  There is a lot of pressure to be done, and nobody wants to take zero points for a story that had a lot of work put into it.  But a false sense of being done is worse.  You may end up building up a lot of technical debt and won’t have a sense of what your true velocity is.

Be honest and open about what your understanding of done is.  Talk about it with others on the team, address it at your retrospectives.  Everyone on the team needs to be in agreement, both in general terms and for individual stories.

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.

Agile and the Lean Startup

I was at a Windows Phone 7 Firestarter at Microsoft in Waltham and ran into The Hacker Chick.  We had just started a conversation about the Lean Startup and Agile when we were interrupted by someone who asked Abby “Excuse me, do you work for Microsoft?  Do you have any tape?”  I managed to bite my tongue and not say the obvious “It’s a hardware problem”.  Needless to say, the conversation got cut short while Abby ran off in search of tape.  I had no idea the life of a Developer Evangelist could be so demanding.  Who ever said Microsoft is not responsive to the needs of the marketplace?

So we never got to finish the discussion, but I have some thoughts about it.  There are certainly many similarities between Agile and the Lean Startup movement.  In fact, the use of Agile methodologies are one of the key components of a Lean Startup.  I see the Lean Startup as an evolution of Agile practices.

Both Lean and Agile involve the customer and welcome customer feedback.  Both are designed to get working products out into the customers hands as soon as possible to be able to incorporate customer feedback into next iterations of the product.  One way that I think Lean goes beyond Agile is that a key component of its practices is customer development.  Most of the Agile projects I have worked on already had a customer in place ,or at least a proxy for the customer in the form of an in-house product owner.  Customer development is critical in learning about the problem you are trying to solve with your start-up.   These slides describe how customer development combined with Agile practices can be used to address issues where neither the problem nor its solution are fully known.

Another concept that I think is key to the idea of the Lean Startup (or at least successful startups) is the pivot.  The idea behind a pivot is that there is a vision behind the product (there is a vision, right?).  As start-ups continue to develop the customer and get more feedback there will most likely come a time where what you are learning isn’t in line with that initial vision.  Start-ups that are unable or unwilling to deviate from that initial vision are most likely doomed for failure.  Companies that can incorporate that feedback and change the vision have a chance to succeed.   Eric Ries describes the pivot as

the idea that successful startups change directions but stay grounded in what they’ve learned. They keep one foot in the past and place one foot in a new possible future. Over time, this pivoting may lead them far afield from their original vision, but if you look carefully, you’ll be able to detect common threads that link each iteration.

Keeping one foot in the past is critical, otherwise you make drastic jumps from one vision to the next, and risk losing what you have already learned about the customer.  There are a lot of interesting examples of several successful pivots by companies like Flickr, Paypal, and YouTube.

To sum up, I think that Agile helps us build software right whereas the principles of the Lean Startup try to make sure that we are also building the right software.

P.S. To learn more about the Lean Startup, take a look at some of the presentations from this year’s Startup Lessons Learned Conference or see if you can find a local Lean Startup meetup in your areas.

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

Why TDD?

“When do you write your tests?”

This is a question that I have been putting to developers lately and the answers I get back sometimes surprise me. I still hear a lot of people say they are writing their tests after the majority of the code is written. These are people who, by and large, agree in the value of unit testing.  Unfortunately by deferring testing to after the code is written I think they are missing out on an opportunity to make significant improvements in how they write software.

Remember, it is test driven development.  The tests play an important role in driving the interface definition, underlying design, and structure of the code.

TDD Helps Define the Interface

What is your code going to look like to clients?  What methods are going to be provided, what are the arguments, what are the failure modes and behaviors? These are all questions that will shake out of a test driven development process.

When I am doing TDD, I typically go through a series of test, code, and refactor cycles that take the component under test through a progression of increasing functionality/behavior.

  1. Simply create the component under test
  2. Implement a simple, sunny-day operation
  3. Add some error conditions
  4. Layer in some more functionality
  5. And so on…

As I go along this progression, my understanding of the behavior of the component and its interface is evolving.  And since I am driving the interface definition from my tests, I am thinking about how the interface looks from the outside.  That is an important distinction.  Without that view from the outside it is easy to put a lot of effort into the internals of the design, without having a good understanding of how it is going to get used.  When I am writing the tests I have to put a lot of thought into how a component is configured and called, as well as how it will respond to error cases.

After each of these steps, I am also checking in my code. There are several reasons for this. The obvious one is I am building up a revision history and keeping the scope of my changes small. That way if I paint myself into a corner or start to detect a code smell I can revert back to a known good state. I am also getting my tests to run in the automated build. That answers the question of whether there is an unknown dependency on a library or configuration that exists on my development system but not on the build server. It may also point to an expensive test setup or teardown condition that causes the automated tests to take a long time to execute.  Finding that out early makes diagnosing and fixing it a lot easier.

TDD Encourages Good Design

You can have good design without TDD, and you can write lousy code using TDD, but I find one of the strengths in TDD is that it encourages good design and good design practices.

The iterative nature of TDD,  sometimes referred to as red-green-refactor (or test-code-refactor), encourages continuous design.  One of the knocks I hear about Agile and TDD by people who really don’t understand it is that there is no design cycle.  In reality you are constantly thinking about and improving the design, just in incremental steps and in response to adding more functionality (via new tests).  As you continue to add in more functionality, opportunities to refactor for modularity, re-use, decomposition, and performance will present themselves naturally.  And since you have a test suite already in place you can refactor and get an indication that the component is still behaving as expected.

Another benefit to TDD is that it encourages loose coupling of components.  When you are unit testing, you want to keep the amount of code that you are testing to a minimum.  If the code under test has dependencies on other components,how do you restrict your testing efforts to the code under test and not all the pieces of code that it talks to?  How do you decide what dependencies should be covered in the test suite and which ones should be treated more abstractly.  There aren’t any hard and fast rules here.  I have seen code that has so many injected dependencies that it is hard to figure out what exactly it does, and I have seen code that included so many other classes that it is nearly impossible to have good tests that don’t break when an underlying component changes.  But by following an iterative, test driven strategy, you are forced to confront these issues early, before you have invested too much effort into what might be an unwieldy design.

You may argue that you can get these types of benefits with tests developed after the code is written, and that may be true, but at that point making changes to the design is more difficult.

TDD Enables Testability

That may seem obvious, but by writing tests starting on day 1, you are forced to deal with how to put in hooks for testing right away and how to determine that your component is behaving as expected.

I recently had to refactor some code that had practically useless unit tests.  The reason that the tests were of little value was because there was no easy way to see the interaction with the dependencies or evaluate the “success” of an operation.  Essentially these tests boiled down to “call this method and verify that no exceptions are thrown”.  That is a an unacceptable success criteria for a “finished” piece of software.

Two big issues for me with unit tests are dependencies and infrastructure.  How can I run my tests so my code is not dependent on too many other components, such that the tests become unwieldy or brittle.  I am a big fan of mocking and dependency injection.  For C# I use nmock2 for mocking.  At some point I need to finally try out an IoC framework (Scott Hanselman has a good list of them for .NET  here) for dependency injection, but to this point providing overloaded constructors and manually injecting dependencies has not been too painful.

The infrastructure issue is another thing you want to get a handle on.  How dependent are your tests on things like the file system, do they need a database, are there any special configuration files?  Do they run quickly or require a costly setup/teardown?  These may be indicative of problems in your test design and may cause problems.  Remember that your tests can be refactored too if you detect a code smell.

The Five Whys

I have recently been pointed to a great blog called Startup Lessons Learned. There are some great posts on product development, Agile practices, hiring practices and tips, and TDD, some of which have made me rethink how I go about my day and the practices I employ. I highly recommend giving it a look.

There were a couple of posts on a practice called the Five Whys, which comes out of Taiichi Ohno’s book Toyota Production System. The first post is about the Five Whys and what they are meant to accomplish, and the second is on how to actually run a Five Why’s analysis meeting.

I am very eager to start applying this technique. I am fortunate enough to be working on a really great team that has the maturity to avoid turning the five whys into a blame game. I am sure it will take some practice, but I am interested to see what comes out of it. If anyone has used this technique and has advice or stories to share I would like to hear them.

I’ll let you know how it goes.