Archive for October 29th, 2008

• Uncle Bob says…

  Date: 2008.10.29 | Category: Agile, Conferences, Test-Driven Development | Response: 0

  “Test-driven development [TDD] is dual-entry bookkeeping to prevent errors in your code.”

  I was lucky enough to see Uncle Bob give a presentation on TDD this week.  During his demonstration of the Bowling Game, I noticed he refrained from writing tests for the all the little helper methods he extracted during the course of the test-code-refactor cycle.  In the past, I had a tendency to take these private methods, make them public and write tests against them.  Something never felt right doing it, but it never hurts to have more tests, right?

  However, after watching Uncle Bob, I understand why you don’t need to do that: the original method that spawned all the little helper methods is already well-tested.  If there was a defect in the private helper method, the public method will inform you.  Intuitively, I knew that and was beginning to go there.  Uncle Bob just moved that process along faster, so thanks!

• XP c.2008

  Date: 2008.10.29 | Category: Conferences, Documentation, Extreme Programming, Pair Programming | Response: 0

  In Boston, I attended a session lead by Neal Ford from Thoughtworks.  He shared his company’s experience of applying XP in a variety of domains.  Thoughtworks almost exclusively uses XP on all their consulting engagements.  Here are some thoughts on three pieces of misinformation about the XP community.

  Pair Programming

  Pair programming continues to remain controversial, but removing it from XP cripples the process.  The main reason is because eliminating pair programming takes away one of the key feedback loops XP is built upon – review of code by a second pair of eyes as it is written.  Having developers pair program increases the concentration, focus and productivity of the team.  I know it is counter-intuitive, but pair programming is one of the main reasons why XP teams make such great improvements in productivity.  Everyone is focused either with the writing code or thinking about how to improve the design.  No one is off surfing the net, killing time on the phone or responding to email – they’re working and working hard!

  Kent Beck has clarified his position on pair programming in Extreme Programming Explained (2nd Edition) - not even Kent pair programs all the time! – and it remains very important to the process.  I feel pair programming is so tightly coupled to the identity of XP, that I would find it hard to believe a team is “really” doing XP (as if that really matters to anyone but us process nerds) if they are not pair programming.   IME, if a team says they are not doing pair programming and you dig into the details why, you normally find out they are not working in timeboxed iterations, not refactoring, don’t refactor and on-and-on.  The just took their ad hoc, undisciplined process and labeled it XP.

  Documentation

  Contrary to what people think they know about XP, good XP teams document their work.  They just tend to use light-weight documents for communicating to themselves, only preserve documents that are useful and avoid the “write-only” (think about it) documents often mandated by process police.  XP teams tend to use a wiki as a living document repository and their unit tests as a specification document built from code examples.   The wiki (probably one of the more revolutionary pieces of software ever created by XP’s “grandfather” and “midwife”, Ward Cunningham) is the place to hold user stories and the details surrounding the stories, preserve design discussions, design briefs and useful design diagrams and a place to maintain strategic and tactical decisions made.  I have seen Confluence be used very well when I worked at a large government contractor, but like anything else in XP, you need to be disciplined about maintaining it.

  Code Comments

  Code comments are a special form of documentation and are commonly thought of as a “best practice”.  Yes, we want to write comments about why we do something or capture the domain rules, but we do NOT want to write a comment telling me what the code does.  IME, if you need to write a comment in your code, then you have failed to express yourself clearly in your code.  Class, method and variable names all should be easy-to-understand and expressive.  When you read code, it should read like a blog entry, i.e. be coherent and comprehensible.  Document and comment your API, but writing JavaDoc style comments for code that will never been seen by the outside world only gets in the way of refactoring the code later.

• It’s 2008,

  Date: 2008.10.29 | Category: Agile, Conferences, Transitions | Response: 0

  … and the time for guerrilla Agile is over.”

  Or so says Gil Borza from Industrial Logic at his talk at SD Best Practices titled “Secrets of High-Performance Agile Implementations”.  Gil’s position is Agile has proven itself in enough places and on enough projects that we should not hide the fact we are doing Agile anymore and just do it.  If you can’t do it, then change your organization.

  One of the interesting refrains I heard regarding Agile transitions was the need for executive-sponsored Agile transitions teams with charters, budgets and authority to remove organizational impediments.  It was clear from many of the consultants that organizations who are successful with Agile transitions are the companies who put real money behind these initiatives, run transitions as change management programs using traditional project management tools and invest real money into their staff in the form of training and reduced productivity as the organization learns new skills and behaviors.  Real goals and milestones on what the organization should look like in 6-12-18 months are established and people are held accountable for their progress.  Giving everyone a copy of Kent Beck’s Extreme Programming Explained or Ken Schwaber’s Agile Project Management with Scrum and saying, “OK, now you are trained.  Go do it.” ain’t gonna cut it.

  As for the practical side of things, rarely does a mismash of cherry-picked Agile practices work.  Eventually whatever you left out – pair programming, automated testing, lightweight documentation, cross-functional teams, stand-ups, etc. – will come back to haunt you later and kill your productivity.  It is very important in the early stages of the transition process to select teams and projects that are appropriate for the Agile approach.  When you are fixing bugs, there is just not that much to learn about how to be good at Agile.  If you think a team trashing around with legacy issues as there first Agile project will be a success, you are deluding yourself.    Once you have got over that big hump of learning, then you can extend Agile to parts of your organization that are tightly coupled to each other and perhaps tackle those nasty legacy bugbears using a SWAT team of your best technical and business folks.  Another thing to keep in mind, co-locate your teams\product communities as much as possible and don’t break up the communities.  Keep people together with the product.  A lot of time and money was spent investing in these growing and nurturing these communities (I like to think of them as corporate assets) and reallocating “the resources” when a project is done just pours all that money down the drain.

  If you are serious about an Agile transition, recognize that every part of the organization that touches software development will have some type of change.  An Agile transition is trying to incrementally change the habitat in which an Agile team resides and to do that you need executive sponsorship.  Oh, if you lose your sponsor, you’re done (until you can find a new one).  Finally, expect to wait about a year before you start realizing the high productivity levels promised by Agile processes.

• Mistake Museum

  Date: 2008.10.29 | Category: Agile, Conferences, Transitions | Response: 0

   

  Here are some common mistakes people make when trying to make their organization more Agile from Rick Brenner and Nancy Van Schooenderwoert.  My comments are in italics.

  • Underestimate the politics of the organization.  Avoid this trap at your peril.  As Ken Schwaber likes to say, “A dead sheepdog is no use to the team.”
  • Use an Agile process to run the Agile transition.  Use tried and true change management techniques from the project management world.
  • Allow the internal auditors to credential the Agile process.  Frequently internal auditors do not know what they are dealing with when confronted with an Agile project.  My experience is they often gum up the works to make their lives easier.  While these people are normally trouble, learn what they need.
    
  • Scale up rapidly after a few successful pilot projects.  I call this early institutionalization or freezing the transformation process in an immature state.  You would never eat a green strawberry, so why push an immature system to your entire company?  Learn why the pilots are successful and amplify those factors while diminishing the obstacles.
    
  • The early pilot projects are not run like projects; there are no goals, budget or customers.
  • The “wrong” project was selected for the Agile team; i.e. legacy systems, unavailable customers, ill-defined goals, etc.  Agile teams need to work iteratively in close collaboration with a customer who cares about the project and has the authority to make decisions.  Anything less causes “issues”.
  • Select team members who are actively hostile to Agile. Agile relies on the goodwill of the participants to try new things in order to succeed.Skepticism is good, but too much makes the whole thing a farce.
    
  • Treat people as interchangeable resources and swap in-and-out at will. Agile asks people to make commitments by encouraging them to take ownership of products.  How much ownership do you really have when you are on four different teams?