AccuRev is going to Agile 2011! Stop by the AccuRev booth to say hello, enter to win our great give-away, or see the new AccuRev version 5.2 demoed.

Session hopping? Make sure you attend Damon Poole’s session, Scrum and Kanban, Like Chocolate and Peanut Butter on Wednesday, August 10th, at 3:30 PM in Imperial Ballroom A. You may wonder how Kanban can help with your real-world process problems. Damon will discuss Kanban from a Scrum perspective, show how the Lean practice of “One Piece Flow” is the key to both, and look at how to mix and match Scrum and Kanban to fine tune a process that fits your circumstances.  

AccuRev is sponsoring a brand new Agile event with Eliassen Group, Agile Journal and Rally Software- Incorporating Agile into Your Organization- a breakfast panel discussion that focuses on maximizing the ROI of Agile methodologies throughout your company.

We invite you to join us in answering the common questions:

‘What is Agile?,’ ‘How can you help Agile permeate through your organization?‘ and ‘Where is the ROI within Agile development?‘

Date & Time:
Tuesday, December 7th, 2010
7:30AM – 10:30AM

Location:
Boston Marriott Burlington Hotel
One Burlington Mall Road
Burlington, Massachusetts 01803 USA

Cost:
$50/person registration fee – each attendee will receive a $50 Amazon gift card at the event.

Agile Event Agenda

7:30 AM   Registration and Breakfast

8:00 AM   Panel Discussion- What is Agile?

8:15 AM   Panel Discussion- How can you help Agile permeate through your organization?

8:45 AM   Networking Break

9:15  AM   Panel Discussion- Where is the ROI?

10:00 AM  Q&A

10:30 AM  Closing and Rafflle

It’s going to be a great event, we hope to see you there!

This event is over. For more events visit: http://www.accurev.com/events.html

In the last few posts I have discussed some of, what I consider to be, the most valuable Agile methods for development.  The list is pretty long, so breaking the list up allows me to define each practice and include the individual benefit of each Agile method.  This post defines some hot terms right now- continuous integration, multistage continuous integration, and story points.  Enjoy!

Agile Method: Continuous Integration

How frequently have you merged your code with changes from the mainline, only to find that the result doesn’t build, or it builds but it doesn’t work? Monthly? Weekly? Daily? Hourly? Or worse, how often have you made changes that broke the build, requiring you to quickly correct the problem while getting flames from your team members?

A practice that has emerged to address the problems of integration is called Continuous Integration. The basic idea is that if integrating changes together and getting build and test results on a regular basis is a good idea, integrating and getting build and test results on every change is even better.

With Continuous Integration, all work from all teams is integrated into a single codeline as frequently as possible. Every check-in automatically triggers a build and usually a subsequent run of the test suite. This provides instant feedback about problems to all interested parties and helps to keep the code base free of build and test failures. It also reduces the integration headaches just prior to release.

Agile Method: Multi-stage Continuous Integration

Integration is tough enough when you are just integrating your work with the work of other folks in your small team, or the whole effort is being done by a small team, but when you are part of a large team there is also something called “Big-Bang” integration. That’s the integration of the work that multiple teams have been working on for long periods of time. In a typical project, this integration is done in a phase toward the end of the project. During integration, many problems are discovered for the first time which leads to delays and/or changes in scope.

The real question is, what is a good way to structure this integration so that it will scale smoothly as you add more people to the equation? A good starting place is to look around for a pattern to follow. What are some similar situations? I have found that everything your organization needs to do in order to produce the best possible development organization can be entirely derived from the patterns and practices at the individual level. This approach makes it much easier to understand and much more likely that it will be successfully followed.

As individuals we work in transient isolation to reduce the impact of work in progress on each other. Organizations isolate WIP by using only official versions of 3pty sources and by producing official releases for customers.

Multi-stage continuous integration (MSCI) scales CI to large distributed environments by isolating work in progress at the team level. Changes move from individual to team to mainline as fast as CI allows, but stop on failure. MSCI is particularly important in a distributed environment where fixes to problems exposed by CI can be delayed by a full day

Agile Method: Using Story Points For Estimation, Instead of Units of Time

In my experience, the best unit to use for estimates is story points. Two different people with two different skill sets or levels of ability in an area may take different amounts of time to perform a particular task. Estimating in hours mixes together the scope of the work that needs to be done with the speed at which a particular individual can do that work.

On the other hand, story points are a relative measure of the scope of a user story. Story points separates out the “what” from the “who.” For instance, if you have one individual that is stronger with .Net than with Java, they will estimate a Java story as taking more hours than somebody that is stronger with Java. But they will probably both agree that something that is twice as easy to implement will take half as long to do.

To use story points, you need to create a relative scale of scope. A simple approach is to find a simple and straightforward story that you use to represent a single story point. Then think of stories that are 2, 3, 5, and 8 times larger in scope. You should have a couple of examples for each story point value to take into account that some stories have more test than coding, more documentation than test, etc.

Story points are primarily used for planning, not for implementation. Story points are used to help determine the contents of release by calculating a velocity.

Next up: Backlog, velocity, planning poker and burnup charts.

Who? Damon Poole, AccuRev Founder and CTO, Agile expert and popular speaker.

What? Presenting “True Agility Requires Us to Re-examine Our Beliefs” for Nashua Scrum Club.

Where?  45 High Street, Nashua, NH 03060

When? Thursday, September 9, 2010

Why should you attend? Damon says “Too many projects that “go Agile” are actually far from true Agility. They end up reverting to old habits or just change the labels on the activities that they are doing without changing what they actually do on a day to day basis. As a result, many so-called “Agile” projects get few if any of the benefits of Agile and some are even worse off than before! Why does this happen?”

This session will give you an opportunity to uncover and re-examine your mental model of software development by taking a look at the top ten Agile blind spots. This will allow you to discover the blind spots you or your organization may have so that you can work towards removing them and start experiencing the full benefits that true Agility offers.

Visit Nashua Scrum Club to register!

In the last post I defined two Agile software development best practices I believe provide value to a wide variety of development teams.   Here I define three more practices that I believe are also important when transitioning to Agile Software Development; collocation, unit testing, and refactoring.

Best Practice for Agile Software Development: Collocation

Collocation is simply having everybody on a cross functional team in close proximity to each other. This compounds the coordination benefit of cross functional teams. This is orthogonal to outsourcing. Whether you are outsourcing or not, collocation only refers to whether a particular cross functional team is sitting near each other.

Best Practice for Agile Software Development: Unit Testing

Unit tests are simply tests that exercise small amounts of isolated functionality. That is, if you have a function that adds two numbers, instead of depending on running a user function that eventually calls the function, exercise the function directly. This often requires the use of mock objects that pretend to be things that the function needs in order to test the function in isolation from other functions that it depends on.

The cost of unit tests is in writing the tests themselves and refactoring code as new functionality is introduced to keep the unit tests testing at the right level. The benefit is that you can easily test changes quickly to find simple problems before doing more thorough and slower testing. It also provides a good safety net for refactoring, gets developers more involved in testing, and usually improves the design of the software.

Best Practice for Agile Software Development: Refactoring

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. That makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code. Any change has the potential to reduce the maturity and stability of the product, especially if you don’t have adequate testing in place. That’s why refactoring is usually paired up with unit testing and together these are frequently combined with continuous integration.

Over the past ten years, a number of Agile software development process “guidelines,” or best practices, have formed and are now becoming widely adopted.  Terms used to describe these best practices are sometimes new to developers, so I defined the practices that I believe provide the most value to a wide variety of development teams in order to create a highly functional, unified software development process.  I have by no means compiled a full list, but over the next few posts I will introduce you to some ideas that you may find worthy of further investigation.

Agile Software Development Process: User Stories

Consider the following requirement and sub-requirements.

• 3 Simplified Purchasing

• 3.1 Customer Identification
  • 3.1.1 A web “cookie” shall be used to uniquely identify visitors
  • 3.1.2 Each customer shall be associated with a cookie
  • 3.1.3 Cookies shall be stored in an RDBMS
• 3.2 Sale presentation
  • 3.2.1 Each item for sale shall have a button marked “buy” next to the item
  • 3.2.2 Selecting the “buy” action shall trigger an order placement action
• 3.3 Fulfillment
  • 3.3.1 By default, all orders shall use the on-file default shipping information
  • 3.3.2 If available, all orders will use the customer’s default payment method
  • 3.3.3 It shall be possible for the customer  to cancel any order for up to 4 hours after they place that order.

This set of requirements is for something called “simplified purchasing.”  Take a moment or two to consider how you would sum it up in a single plain-English sentence.

The requirements called “simplified purchasing” describe the user’s desire for “one-click purchasing.” In terms of a user story this would be phrased as “As a user I want one-click purchasing.” User stories are a description of what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome.

User stories are different than requirements. When using requirements, it is likely that the developer implementing the requirement will be presented with an implementation task or a design document and be constrained to implementing as specified or as designed. A user story removes invisible constraints by focusing on the outcome desired by the user. The developer doing the work will see the user story, will be able to better understand what the user needs, and will be able to participate in or even own the specification and design of that story. User stories provide engineers more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

A user story does not necessarily replace requirements documents or other documents. A common scenario is that the user story is the unifying high-level description for the work that needs to be done to make sure that everybody involved has a common understanding of the work, from customer to developer to tester to doc writer and back to the customer.

Agile Software Development Process: Cross Functional Teams

A cross functional team is a small group of people (7 + or – 2) that works together towards a common purpose, where time is primarily spent as part of the team, and, as a team, has all of the skills needed in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, project manager, etc. The intended benefit is that you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects.

Next best practices I will explore? Collocation and Unit Testing.

As you have been seeing in the blog and on AccuRev’s Twitter feed, I spent last week at Agile 2010.  I thought it was a great show- I met a lot of interesting people, led three big Agile sessions, and even got to ride Epcot’s Test Track.  It was definitely a fun and eventful week in Orlando!

To thank you for your support this year, I promised to post my presentations in the AccuRev blog. The presentation from my first Agile 2010 session, Scrum and Kanban-Like Chocolate and Peanut Butter, has already been posted in case you missed it or were turned away.  (Agile 2010 volunteers ended up brining extra chairs into the event room but lots of people were turned away due to fire code restrictions.)

Here are the other two presentations I gave later on during the conference week, enjoy!

_____________________________________________________________________________________________________________

Damon’s Agile 2010 Retrospective

In an effort to drum up ideas for next year’s Agile conference, I started asking some of the people I met with, “Why do you come to conferences like this?” I received a variety of answers and created a little retrospective video, all with my iPhone 4 and iMovie.

AccuRev has been down in Orlando at Agile 2010 for almost a full week now, and if you haven’t stopped by the booth to say hello to us yet, I encourage you to do so!

Damon Poole, AccuRev CTO, wrapped up a series of three Agile sessions today, and was pleased with the outcome.

“I think the sessions went really well, people were excited for them, I was excited for them, but ultimately I hope everybody learned something valuable” said Damon.

His presentations were titled “Scrum and Kanban- Like Chocolate and Peanut Butter,” “Getting Managers and Agile Teams Out of Each Others Hair,” and “Managing Growth Pains on the Way to 40 Scrum Teams.” (See “Three Days with Damon Poole on Agile Development and its Components” for more info).

Damon’s first session at Agile 2010, “Scrum and Kanban- Like Chocolate and Peanut Butter,” attracted a large crowd, and unfortunately several people were turned away.  But as he promised, we are posting all of his presentations in the AccuRev blog.  You can download Damon’s presentation of  “Scrum and KanBan- Like Chocolate and Peanut Butter” here.  Enjoy!

Agile 2010 is fast approaching, and AccuRev is excited to sponsor and support the Agile community involved with this conference.  However, our excitement is partly due to the fact that Damon Poole, AccuRev’s CTO, was chosen as a featured speaker for not one, not two, but three sessions during the conference week.  I sat down with Damon to chat about his Agile 2010 plans, the ideas behind his session topics, and ultimately, the unrelated topic of my recent exposure to Star Wars.

Star Wars aside, Damon has some great talks about Agile development and components planned for Agile 2010.

Damon’s Discussions on Agile Development and its Various Components

Damon’s first Agile 2010 session will take place on Tuesday, August 10^th at 1:30 PM and is titled “Scrum and Kanban- Like Chocolate and Peanut Butter.”  Here Damon proves Scrum and Kanban are not in fact mutually exclusive, but play well together, much like chocolate and peanut butter.

KE: “So Damon, how did you come up with the chocolate and peanut butter concept?”

DAMON: “I have witnessed infighting within the Agile community, between Scrum advocates and Kanban advocates.  Agile is a way of thinking, and the community wins when there is a synergy between camps.  I want people to recognize that not only can Kanban and Scrum co-exist, they can actually be a very beneficial combination to development teams.”

KE: “Who might this session be best suited for?”

DAMON: “I would say this session is for folks that are already doing Scrum and are curious about Kanban.  I will address Kanban basics, how Kanban can help with real-world process problems, how to apply one-piece-flow to Scrum, and the value of work-in-progress limits applied to Scrum.”

KE: “Since it’s about chocolate and peanut butter, will there be Reese’s?”

DAMON: “You bet.”

__________________________________________________________________________________________________________

The following afternoon, Wednesday, August 11^th at 1:30 PM Damon will present “Getting Managers and Agile Teams Out of Each Other’s Hair.”

KE: “This sounds like an interesting Agile pain point that lots of us can relate to.  How do you approach this topic?”

DAMON: “Well, one of the most talked about, but least understood components of Agile is the ‘self- organizing team.’ There is little research published on this concept and I spent a lot of time looking outside of software development for information and advice on self-managing teams.  I came up with new perspective on this concept by examining external roots of the practice.  What it is, what the benefits are, how it works.  I will share my advice on manager roles and responsibilities, aspects of self-organization enabled by multiple Agile development components, and challenges that teams face.  It should be a good session, I have given it before and it’s always well-received.”

_______________________________________________________________________________________________________________________________________________________________________________________________________

The third day with Damon is on Thursday, August 12^th at 9:00 AM. He will present “Managing Growth Pains on the Way to 40 Scrum Teams”

KE: “Forty Scrum teams is getting up there.  How would you recommend managing such large amounts of teams?”

DAMON: “You’re right, 40 Scrum teams is the sign of a large organization.  I have interacted with lots of large Agile shops that operate with many more than 40 Scrum teams, and noticed issues with Agile weren’t all that different from shops with smaller teams.  By recognizing trends and patterns sooner than later as the organization becomes deeper involved with Agile, teams can start following certain practices to eliminate issues.  When it comes to addressing issues, the sooner the better.

KE: “What best practices have you recommended to larger-sized Scrum teams in the past?”

DAMON: “Multi-stage Continuous Integration, small story size, collocation, cross-functional teams… a few more.  This is a good session even if your organization doesn’t have 40-something Scrum teams today.  It teaches you about growing pains and prepares you for future growth.

Well, Damon sure sounds like he has a busy week lined up at Agile 2010.  Make sure to check out his sessions- they are featured on the Agile 2010 schedule and under the “What’s Hot” tab in the Agile 2010 app for iphone and Droid, so don’t forget to add Damon’s sessions to your schedule via these apps!

Follow AccuRev on Twitter @accurev for Damon’s latest updates from Agile 2010!

One of the questions I hear a lot from Agile teams is “how can we have a stable build to test stories as they are completed?” Often, the only time the build is stable is towards the end of the iteration. That then squeezes the QA folks or sometimes even has them testing the previous iteration’s stories in the current iteration. Hmm. That sounds a bit like our old friend Waterfall.

Usually, when the question is asked, the team is creating and automating unit tests and doing continuous integration. That’s not the issue. (If you are not doing those things, stop everything and implement these three practices immediately!) But let’s assume for the moment that you are doing these three practices.

The problem is getting a build which consists of only stories that are considered “complete,” but still need a bit more work done on them, such as exploratory testing, load testing, usability testing, demo for customer feedback, etc. You might say, “but you can’t do that until the end of the iteration.” Ok, but then you are back to the problem of a compressed QA cycle and having development either sit on their hands or move on to the next iteration, neither of which represent Agile thinking.

There’s a simple solution to this problem, which you may have “thrown out with the bath water.” Branches! Or, in AccuRev parlance, streams (though I’ll stick with branches for simplicity). Each process stage gets its own branch. That doesn’t mean that you can’t write code and tests at the same time, only that code can’t advance to the next branch until it meets the criteria of that branch, such as “coding is done” and “all tests are written and passing.” I know, you cringe at the thought of branching and merging, but that’s probably because you are thinking of branches that contain long-lived changes. We’re not going to do that here.

The idea presented here is to advance changes through the set of branches as quickly as is practical. As changes get propagated to each branch, CI is done against that branch.  If it succeeds, it gets promoted to the next branch. If it does not succeed, then that developer (possibly with help from her teammates) fixes the branch. This is similar to how stopping the line works in a modern lean manufacturing facility.

In AccuRev, this process is greatly simplified. You can create a set of streams instead of branches, and streams can model your exact process. Promoting work from stream to stream is a simple drag and drop operation.

In the diagram above, there are streams for each of the stages from “wip” to “done.” Since each stage is a stream, you can run continuous integration at each stage. You can also do builds, for instance from the “tested” and “done” streams to do things like exploratory testing. By definition, a build from the “done” stream only contains changes which are built; integrated together; have unit and other tests written, automated and passing; and whatever other criteria you have for “done.”