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.