Planning Poker

Teams often ask “what if we estimate wrong”. To me this is reality for any estimation process. By definition we are “guessing” (hopefully educated) and therefore our estimates will be wrong. The idea is to be consistent rather than precisely wrong. This allows teams to better predict based upon similar constraints to earlier iteration how much they will be able to deliver in the next iteration. Rather than basing estimates on predictions of the future we are basing them on what we have done in the past.

The use of “estimate size; derive duration” method of estimation helps teams gain knowledge about how much they can deliver in a time-boxed iteration. One technique to generate the estimates of size is Planning Poker. Most teams start out attempting to get the estimate exactly “right”. I will not advocate that this is bad to do but I do think that teams would find Planning Poker and other exercises for estimating size more valuable if they focused on the communication that occurs. The real magic of Planning Poker is that cross-functional team members and team members with different perspectives are able to share their knowledge with each other and ultimately meld the points of view into an approach for implementing a user story. A focus on communication allows teams to capture important information, constraints, and decisions around a particular user story and better understand as a team what is involved in its delivery.

Sprint Planning Task Breakdown

When teams come together for the first time in organizations where they have been separated by functional role or even teams that haven’t worked together before, the act of breaking down user stories into tasks assists teams with communication. If the Product Backlog describes the “what” then the Sprint Backlog describes the “how”. Tasks are tools for capturing the “how” and makes it visible to the entire team. Instead of team members with different functional roles, team members describe how they will contribute to the potentially shippable product increment delivered by the end of the iteration. Instead of focusing on the perfect tasks and estimates on those tasks, I believe it is more valuable to have a shared understanding of how the team will deliver the user story. Tasks are just the tool to make visible that shared understanding and we should focus on the communication between team members and capturing the important details that enable successful delivery.

Now, tasks are not the only way to get a shared understanding, of course. I have been on teams where we would talk, draw a little picture on a post-it note, and then agree with as a team that was enough to plan with. This was with an extremely experienced Scrum team that worked together or around each other for a long time. When a new team comes together in an organization that has not created user stories before they have difficulty getting “right-sized” user stories for the team. Most of the time there seems to be some difficulty breaking them down items into small enough items for the team to deliver within 1/2 of a sprint’s length. As the team does task breakdown they are better able to capture details that help them work out how the whole team will contribute to the user story. This leads to recognition of user stories that are too big or even those that are ambiguous.

New teams using task breakdown in their Sprint Planning meetings should focus on how they communicate with each other and make sure that each member of the team is heard. This will lead to a better shared understanding of how they will work together and deliver successfully.

Focus on Team Communication

Here are some things that teams can do to help their communication in planning:

• Make sure all team members are heard so they will feel compelled to participate
• Always discuss reasons why you, as a team member, are not satisfied with the plan
• Don’t push your estimate or task breakdown suggestions on the entire team
• Cross-pollinate within your team across functional role boundaries to better understand other roles
• Use past experiences and story-telling to describe reasons for a particular position
• Use whiteboards and design techniques to visually portray ideas

Hopefully a focus on team communication will help make estimating and task breakdown a more valuable experience for your team. Please share things that your teams have done to help focus more on communication to increase shared understanding by leaving comments on this blog entry. I look forward to hearing from you.

For many years now, it has been a goal of mine to get feedback as early as possible when developing software. Past blog entries here and here have discussed how we can approach increased feedback. A tweet from Jason Gorman mentioned his list of tools that provide continuous feedback on his code and design: “Emma, Jester, XDepend, Checkstyle and Simian”. This inspired me to write a post on how I approach setting up project reporting and my IDE to provide increased feedback. This article will be the first part of a series on “Extreme Feedback from My Tools” and will focus on Maven 2 configuration and reporting.

Maven is my tool of choice for managing builds, versioning, deployment, and test execution. Although, it wouldn’t hurt my feelings if teams I worked on used Ant, make, or other scripting methods to manage these, but it tends to be more difficult overall. For those who are alright with using Maven, here is a look at different aspects of a typical POM file configuration I use:

<build>
  <plugins>
    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
        <source>1.5</source>
        <target>1.5</target>
      </configuration>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>2.4.2</version>
      <configuration>
        <includes>
          <include>**/When*.java</include>
        </includes>
        <redirectTestOutputToFile>true</redirectTestOutputToFile>
        <trimStackTrace>false</trimStackTrace>
        <useSystemClassLoader>false</useSystemClassLoader>
      </configuration>
    </plugin>
  </plugins>
</build>

The above portion of the POM file are configurations for all Maven execution scenarios for this project. The first plugin, “maven-compiler-plugin”, sets the expected source code compliance and the JVM version that the compiled binary will target. The “maven-surefire-plugin” executes tests such as those developed with JUnit and TestNG. Because my approach is to take a more BDD-like naming convention and style for test cases, this POM is configured to execute unit tests that start with the word “When” in the test source code directory, by default this is “src/test/java”. Having the full stack trace from test execution issues is essential to effective debugging of the automated build and tests, therefore the configuration makes sure that they are not trimmed in the output file. Finally, some code that I have created in the recent past needed to find classes on the Maven classpath and through much debugging I found out that the system class loader was used by default with surefire so I now make sure to set it up to use the Maven class loader instead.

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-pmd-plugin</artifactId>
      <version>2.3</version>
      <configuration>
        <linkXref>true</linkXref>
        <targetJdk>1.5</targetJdk>
      </configuration>
    </plugin>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>cobertura-maven-plugin</artifactId>
      <version>2.4</version>
      <configuration>
        <formats>
          <format>html</format>
          <format>xml</format>
        </formats>
      </configuration>
    </plugin>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>jdepend-maven-plugin</artifactId>
    </plugin>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>dashboard-maven-plugin</artifactId>
    </plugin>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>findbugs-maven-plugin</artifactId>
      <version>2.2</version>
    </plugin>
</plugins>
</reporting>

Reports are effective at giving the team indicators of potential problems in their project artifacts early. Teams tend to find that trends are more valuable then specific targets in the generated reports. If the code coverage is going down we ask ourselves “why?”. If more defects are being detected by source code analysis tools then we can look at how we can change our approach to reduce the frequency of these issues. The 5 plugins used in this POM report on different perspectives of the software artifacts and can help to find problematic trends early.

• PMD is for source code analysis
  
• Cobertura is for code coverage
• JDepend is a package dependency analyzer
  
• FindBugs detects bugs in code
• The dashboard plugin shows the results of the reports in a single view

When the continuous integration server successfully executes the build and automated tests, the Maven reporting command is executed to generate these reports. This happens automatically and is shown on our video monitor “information radiator” in the team area.

<dependencies>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.7</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.8.0</version>
  </dependency>
</dependencies>

We make sure to update the POM to use JUnit 4 so that our team can use annotations and better names for the tests. Also, Mockito has become my favorite mock objects framework since it stays away from the “replay” confusion of other mock frameworks (or their old versions at least) and also has a BDDMockito class that enables our team to use the given/when/then construction for our tests.

Once your POM file is configured with these reporting plugins, you can generate the reports by executing the ’site’ life cycle in Maven:

mvn site

Part 2 of this series of articles will discuss configuration of an Eclipse IDE environment for Extreme Feedback.

Meet Carrie (pretend that is her real name).  The team she is part of is “sort of” collocated.  Most of them occupy a portion of a massive cube farm that makes collaboration a one or two person event at a time.  The Daily Stand-Up meeting is a sit-down and lasts about a half-hour.  On the other hand, they joke and laugh and have a good time for about 15 minutes before settling into the real purpose of the meeting.  I asked Carrie, “Does it help?”

The answer to this one question convinced me this was the perfect thing to do.  Carrie responded, “Yes, this is the time where they get to bond and have fun together.  There are no similar interactions like this any other time. It really brings the team together!  Sprints go much better since this started.”  I thought, “What a great use of 15 minutes!”

I realized I had seen this before with an executive team using Scrum practices to run the company.  A Product Backlog and Sprint Task Board covered part of their beautiful view in the meeting room that adjoined the CEO’s office.  They were faithful with Sprint cadences, periodic retrospectives and velocity tracking.  They used some kanban practices to pull their stories through.  It was very focused and productive.

Yet, the daily meeting with all the CxO’s, and legal counsel took 30 minutes every day.  It always started out with good-humored needling, a touch of politics, local business happenings, and even a few pranks.   Most of it was extremely funny and no one was “safe.”  The standard meeting goals were always accomplished, and the group would head back to their offices.   It took me awhile to realize this meeting was a bonding activity more than an agile meeting.  They had adopted their “daily 15 minutes of fun.”

Sometimes we forget how much we work at a break-neck pace.   Sometimes we need to relax and have some fun.  Like continuous integration, where we bite off small chunks of “pain” instead of enduring excruciating integration phases, frequent bits of fun is a great way to do business.

For those of us lucky enough to be on collocated teams, we may not need extra fun.  For those of us that need a bit more fun at work, try something new.  I believe developing great software is both a creative and technically challenging endeavor. If doing it is not fun then something is wrong. We must figure out why it is not fun and do something about it.

During STIQ’s development, we created a Maven 2 plugin, imaginatively named maven-stiq-plugin. This plugin did only 1 thing: start up the STIQ server for your project without having to run Java from the command line. In the past couple of days, I have finally had enough time and desire to develop integration of exporting STIQ tests into Selenium RC compliant “selenese” so they can also be executed during your Maven integration-test cycle in the 2.2-SNAPSHOT version. So, lets get down to the “how”.

First, add the STIQ Maven 2 repository to your POM (pom.xml file for your project) as shown below: (NOTE: updated with correction on URL from original posting)

<repositories>
...
  <repository>
     <id>STIQ Sourceforge</id>
     <url>https://storytestiq.svn.sourceforge.net/svnroot/storytestiq/trunk/www/maven2/</url>
  </repository>
</repositories>

We, also, must put the STIQ Maven 2 repository into our plugin repositories within the POM because so that we can find the maven-stiq-plugin to execute during the integration-test cycles: (NOTE: updated with correction on URL from original posting)

<pluginRepositories>
...
  <pluginRepository>
     <id>STIQ Plugins Sourceforge</id>
     <url>https://storytestiq.svn.sourceforge.net/svnroot/storytestiq/trunk/www/maven2/</url>
  </pluginRepository>
</pluginRepositories>

Next, we will put in the maven-stiq-plugin configuration.

<plugin>
 <groupId>net.sourceforge.storytestiq</groupId>
 <artifactId>maven-stiq-plugin</artifactId>
 <version>2.2-SNAPSHOT</version>
 <executions>
   <execution>
   <id>export</id>
   <phase>pre-integration-test</phase>
   <goals>
     <goal>export</goal>
   </goals>
   <configuration>
     <pageRootPath>repository</pageRootPath>
     <suiteWikiPagePath>ProjectRoot.StoryTests</suiteWikiPagePath>
   </configuration>
 </execution>
 <execution>
   <id>exec</id>
   <phase>integration-test</phase>
   <goals>
     <goal>exec</goal>
   </goals>
   <configuration>
     <userExtensions>src/main/resources/user-extensions.js</userExtensions>
     <browserType>*firefox</browserType>
     <suiteFile>target/stiq/ProjectRoot.StoryTests.html</suiteFile>
   </configuration>
   </execution>
 </executions>
</plugin>

Now, to tell you a little bit about what is going on in the above configuration. The <groupId> and <artifactId> elements describe what plugin to grab from the plugin repository and use in the project. In the executions section, we define 2 separate execution elements. The first execution is called “export”. This execution will occur during the “pre-integration-test” cycle within the full Maven 2 build life cycle. The goal, similar to an Ant target, on our maven-stiq-plugin that you will be “export”, which is the goal that exports our StoryTestIQ acceptance tests as “selenese” to run within the Selenium RC server. The configurations shown above are <pageRootPath>, which is the directory located below your top-level project directory where the StoryTestIQ tests are located, and <suiteWikiPagePath>, which is a wiki page location for the top-level suite including all of the tests to export. If you don’t already have STIQ tests, please go to http://storytestiq.sf.net to find out how to get started.

The second execution element is called “exec”. This execution will run during the “integration-test” cycle in the Maven build life cycle and will execute the exported tests using Selenium RC server. The configurations for this goal are <userExtensions>, which is where any new selenese actions are defined specific to your project, <browserType>, which is the web browser to execute the tests within, and <suiteFile>, which is where the exported selenese tests were generated during the “export” goal execution. As a convention, the generated selenese file will be located under the “target/stiq” directory by default with the name of the file as <suiteWikiPagePath>.html.

Now you can run the usual ‘install’ command in your project’s top-level directory:

mvn install

This should compile and execute all of your unit tests then during the integration-test phase it will run the maven-stiq-plugin goals, “export” and “exec” in that order. During the maven-stiq-plugin “exec” goal execution, the web browser will open up in the background and you will see the STIQ tests run. After the tests have executed, the web browser will close and the Maven build life cycle will complete.

NOTE: If you are having trouble with “*firefox” as <browserType>, then you might be seeing a current bug with Selenium RC server version 1.1.1. An upcoming release version will include a fix and we will update the dependency once we see the update. For now, the fix is to go back to Firefox version 3.5.3 or switch to using a different browser as listed here on the Selenium RC documentation.

There is still much more to do with the plugin before getting to a release version of 2.2. Please comment on this blog post with any suggestions or issues that you have with the plugin and it’s configuration. If you are interested, do a search on StoryTestIQ within this blog to find out more about using StoryTestIQ or visit the main project page http://storytestiq.sf.net. Thank you.

• Technical debt: tends to focused on the code and reveals itself in duplication and code smells
• Quality debt: focuses on QA aspects of software development and shows up in growing bug databases and longer regression test runs
• Configuration Management debt: focuses on integration and release management aspects and becomes apparent with extreme branching and inability to recreate environments from scratch
• Design debt: focuses on design constructs of components within an application or enterprise infrastructure and is usually difficult to figure out until you are close to a deadline such handling production load
• Platform Experience debt: focuses on the people in the software creation process and usually involves extreme specialization and waiting on people to finish their part

Without further ado, here are the slides:

Also, here is the picture I use to discuss Managing Software Debt from high level in terms of maintaining and enhancing value of software assets:

Joe said, “Brent, as I watched this event unfold, I kept thinking about when I was a Honda motorcycle tester for their motocross program.  They were the worst bikes on the circuit until one day they changed everything.”

“Please go on!”  I replied, eager to hear a game-changing story.

So, Joe told his story:

I was quite young and had a job testing motorcycles for Honda.  Kawasaki and Suzuki were dominant and Honda had the worst motocross bikes.  One day, some engineers from Japan showed up along with a parts shipment.  They gathered all the test riders together and said, “We want you to FULLY TEST this equipment.  This means you should break it every day.  If it doesn’t break, you aren’t riding it hard enough.”  Each day, the debriefings were intense.

Three weeks later, the engineers came back with another shipment of newly designed parts.  These parts were designed and built and delivered based on the feedback from the last visit!  We went out to break them, knowing we had contributed to the parts design.

One evening the test riders went out for drinks.  The next day, they pulled us in and lined us up.  The leader said, “You are not riding the bikes hard enough.  You drank too much.  Go home and come back tomorrow.”

A few people went out again that night.  The next day, we got stopped again.  The leader pointed at several riders and said, “ You, you and you.  You cannot test these bikes hard enough.  You are fired.  Everyone else, go break those motorcycles.”

It was very intense.

Every three weeks, we would get new parts or even new motorcycles.  Each time we would have intense debriefing sessions.  We also knew we would have new parts in three weeks.

That year, Honda went from the worst to building the best motorcycles and started dominating the motocross circuit.

I always liked this story because of the lean manufacturing perspective and the Agile context where Joe told it.  The commitment to quick releases demonstrated game-changing results; even to field testers (Incremental releases). The ability to debrief effectively and analyze results with users of the product allowed them to identify and improve the product (Iterative development).  Fully tested means hard work.  Bridging the gap between engineers and users clearly demonstrated the value of co-location, even if for incremental periods of time.

To whom it may concern:

For many years we, Chris Sterling and Brent Barton, have worked for SolutionsIQ.  We both have had an amazing time working and establishing great relationships, strategic business capabilities, and successfully supporting SolutionsIQ clients.  We recently decided to follow a passion of ours: creating products. This means that as of October 16, 2009, we will no longer be employees of SolutionsIQ and will begin work under our new company, Sterling Barton.

It is important to let everyone know that this does not mean the end of our working relationship with SolutionsIQ.  We are working diligently to have a partner agreement that enables both of our companies to fulfill engagements together.  It is our expectation that this will be a strong relationship that continues well into the future. Our focus will be to fund our product development through consulting and this means our relationship with SolutionsIQ should be seen as complimentary.

Leaving SolutionsIQ is both exciting and difficult.  We have incredible friends at SolutionsIQ who also challenge us with their insightful perspectives.  SolutionsIQ has proven to be a joyful place to work combined with significant capabilities that go hand-in-hand with great people. This has not changed and we expect this to be continuing into the future and improving with time. We want the bonds we have created with the people at SolutionsIQ to extend past our employment with SolutionsIQ.

Brent, if you didn’t already know, started with SolutionsIQ six and one half years ago. He started the Agile Consulting part of the business four years ago and has shown himself to be a tremendous thought leader and respected individual in the Agile community.

For those not familiar with Chris, Chris started with SolutionsIQ four years ago as ScrumMaster and team member on projects. He joined Brent on Agile Consulting engagements soon after that part of the business started and has also become a thought leader in the Agile space.

With SolutionsIQ, we have both found the freedom and support needed to pursue new business opportunities and raise the presence of the company and ourselves within a larger community.  We are grateful for these opportunities and are happy with where we are today based on these and many other people’s efforts.

As we venture out and build a grass roots business, feel free to contact us.  We are having fun and would love to share more good times together with you.

Sincerely,

Chris Sterling and Brent Barton

sterlingbarton.com

If you are interested in contacting us, you can email us at brent at sterlingbarton dot com or chris at sterlingbarton dot com. If you are interested in hiring us  to support you in Agile adoption, management consulting, and technology consulting please send an email to info at sterlingbarton dot com. Thank you.

My first blog entry back is about the upcoming Pacific Northwest Software Quality Conference (PNSQC) that is happening from October 26-28 in Portland, OR. This conference was highly recommended to me by many people. This year I am fortunate enough to attend, have a paper published for the event, and presenting the paper for 45 minutes during the conference. Here are the details for my paper and presentation:

P-30 Managing Software Debt

Chris Sterling, SolutionsIQ

Many software developers will have to deal with legacy code at some point during their careers. Seemingly simple changes are turned into frustrating endeavors with code that is hard to read and unnecessarily complex. Test scripts and requirements are lacking, and at the same time are out of sync with the existing system. The build is cryptic, minimally sufficient, and difficult to successfully configure and execute. It is almost impossible to find the proper place to make a requested change without breaking unexpected portions of the application. The people who originally worked on the application are long gone.

How did the software get like this? It is almost certain the people who developed this application did not intend to create such a mess. This paper presentation will highlight ways teams can work with stakeholders to manage software debt over the delivery life cycle of the product.

I hope that I am able to see others at this event. If you are interested in attending and would like to get a $50 off the normal conference attendance fee, enter the promotion code “FOA – Chris Sterling” when registering. You can register at the PNSQC web site (http://www.pnsqc.org/2009-conference/registration-information). See you there!

I have worked with many individuals, teams, and organizations in the use of Scrum. During that time, I have found that 2 parts of Scrum continually overlooked in implementation. Since Scrum is already a minimal framework, just enough to keep a team out of chaos, when a piece of Scrum is left out problems are bound to occur. The 2 most common parts that I see left out are:

• Product Vision
• Potentially Shippable Product Increment

Product Vision

There are times that I work with a project team and ask what they are going to be developing. If the answer involves a list of requirements and the team has difficulty in describing how what they develop will deliver value then I know there is a missing product vision. This happens more often than you might think. If you want to check if your project team has a common understanding of the vision, do the following with the entire team:

Each person on the team please write down what the software we are delivering will do for its users in 1 paragraph. After we have all written a paragraph, each person on the team shares their understanding with the rest of the team.

If while going around to each team member there is another person on the team who disagrees with the part or all of someone else’s understanding, then your team might not have a product vision. At the very least, the product vision has not been communicated well to the entire project team.

A simple way to generate a product vision is to use the elevator statement template from Geoffrey Moore’s book “Crossing the Chasm”. Here is how it goes:

FOR (customer) WHO (statement of need) THE (product name) IS A (type of product) THAT (has this compelling reason to buy/use). UNLIKE (competitive products) OUR PRODUCT (is differentiated in these ways).

Filling out this elevator statement template with the information in parenthesis with the entire product team will help them get a common understanding of the product’s vision. If the product does not have a coherent vision or through the filling out of this template the value of the product seems to be missing, then this could also show that the project team should not be working on the product. If that is the case then the team could start working on something that will provide more value.

Potentially Shippable Product Increment

Many teams decide not to create potentially shippable software at the end of some sprints. It is difficult for the project team to work in a manner that would produce a potentially shippable product increment. This could be because:

• Roles on the team are too specialized
• Lack of motivation to work together
• Product Backlog items that can be completed by only one person on team
• Doing “Scrumerfall” or “FrAgile” (meaning design/code/test phases within a sprint cycle)
• etc..

Create a Definition of Done with the whole project team is a first step to working towards potentially shippable software each sprint. The Definition of Done involves all team members agreeing upon what they are able to deliver to product consistent internal quality in the software each sprint. The team will include members with backgrounds in programming, testing, analysis, design, and other disciplines within the software development field. The discussion that occurs in developing the Definition of Done will enlighten each member of the team and provide a way for them to keep on top of their internal quality as feature are being delivered iteratively.

In Summary

I hope that people read this and are able to identify whether they are doing these 2 essential parts of Scrum effectively. If a team does not know where they are headed, day-to-day decisions with an iterative and incremental approach such as Scrum will evolve into a messy implementation with no coherent focus for the users of the software. Getting a product vision and communicating it effective throughout the project team and even to stakeholders can help provide guidance along the way. If the team is unable to deliver a potentially shippable product increment after each sprint then the product will always have leftover work to do in order to get a release out to the users. This work will be to stabilize and pull functionality together in a coherent manner which is usually unpredictable leading to decreased quality and missed dates on delivery. Working on a Definition of Done as a first step towards understanding what is meant by potentially shippable product increment each sprint will begin the process of getting to software that is of releasable quality from the technology even though the Product Owner wants to go another sprint or more before actually releasing it to the users. Also, looking at the Extreme Programming (XP) technical practices to help create software in an incremental manner can help put the Definition of Done into action more effectively in some circumstances. Happy Scrum-ing!