ACCUREV BLOG

Posts Tagged iteration

Agile and SCM: Avoiding Agile Merge Disaster

As you start to scale Agile, code and user stories have to be merged more often. Sometimes changes may flow from one organization to another. This means that you will need to take code from one team, merge, integrate, and test those changes. Each team needs to be able to work on their own schedule, and if multiple teams want to work on different sized iterations, they can. In addition, they can deliver changes as necessary and on a regular basis, independent of other teams.

The problem? With a traditional SCM system, you have to merge these code changes daily for them to be of any use. You also need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, people use a single baseline or “trunk” methodology for this configuration, where changes from each team are delivered to trunk and pulled from trunk as their iterations complete.

Working within an Agile context, your teams will have to deal with these branching and merging issues. But there are other problems that can happen when you do not use this methodology:

  1. Delivering 2 weeks worth of changes only causes isolation among teams
  2. It’s too hard to pick out each user story as it completes from our codebase
  3. Figuring out the dependencies of those user stories is complex
  4. Being able to identify what changes came from each branch becomes impossible

This “baseline pollution” is not scale-able. You can get around this by using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance and code reviews. A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Many traditional SCM tools do not easily support or surface a development hierarchy. An Agile SCM system supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.

Posted in: AccuRev, Agile, Tips and Tricks

Leave a Comment (0) →

Agile Teams Move Quickly… Make Sure Your User Stories Can Too!

It occurred to me recently how much emphasis is put on the need for an Agile Project Management tool as you begin to adopt and expand the use of Agile in your development environment.  While many, including myself, would argue that using post-it notes and physical story boards are the best ways to start and Agile pilot team (since I believe it instills good habits, like circling the team around a common goal) there is certainly a place for Agile Project Management as you begin to expand Agile within a larger organization.  Agile Project Management provides visibility across the development lifecycle and into teams spanning multiple time zones, allowing for a big picture view of the project.

User Stories are the Key

Driving development through the use of User Stories is often considered a determining characteristic of whether a shop is considered Agile or not.  And while I won’t go into the details here, it is important to have a ‘place’ to manage those user stories in a backlog.   It’s also important to be able to see and report which iteration the user story is assigned to, and the current status of a particular story.  Has it been scheduled for an iteration?  Have we started development on it?  Who’s working on it? Etc…

Understanding the state and status of user stories that are in development is crucial to accurately reporting the current state of an iteration as a whole.  If you are going to use burndown charts to know how many hours of work are left for an iteration, or a burnup chart to determine how many points are left to be accepted for an iteration, you are going to need accurate information.  Accurate data comes from updating user stories and tasks on a timely basis so you always have the freshest information.

How Accurate is Your Information?

One aspect of user stories that is often overlooked is the linkage between the user stories within an active iteration and the location of the actual code changes for those particular stories.  If you only have an accurate view of the stories from a development standpoint, but you have no idea where the code for that story is, then all of the information in your project management tool contains incomplete data.

Under more traditional development methodologies, the time to ‘check’ the linkage between closed issues and code that was changed in order to complete said closed issues happens on an infrequent basis.  Checking the linkage usually occurs toward the end of a long development cycle, when teams are getting close to a release point.  If we are executing on a 6 month release cycle, it probably won’t occur until 4 months in.

Identifying the status and locating the code for user stories happens weekly on an Agile team, regardless of the iteration length.  This requires you to have quick access to accurate information to track those stories from a development perspective.

Accurate Information… Quickly

In many traditional SCM systems, developers must manually indicate the linkage between the code and the story it is associated with as the code is checked in. At the end of the iteration, teams must determine what stories are fully completed and what stories are only partially done, and need to be retargeted to the next sprint.

Traceability and visibility into each story is necessary to see where code changes are located. The ability to easily associate code modifications with a user story will eliminate error prone manual linkage problems. In AccuRev, this information is stored in a Change Package, or a deep linkage between the user story that is related to project management and code. Change Packages can be tracked through the development cycle.  This gives developers visibility into the status of an individual user story without additional overhead, while providing traceability to Scrum Masters and Product Owners into the status of an iteration with increased accuracy.

Posted in: AccuRev, Agile, AgileCycle, Best Practices, change packages, user stories

Leave a Comment (2) →

Agile and SCM: Helping You Get to “Done”

You spent the last 2 weeks working on 10 user stories for you sprint. Your team has completed 8 of the 10 user stories, and now it’s time to show a working demo for your sprint review. Sounds like a typical scenario right?

Here’s the problem, the 2 remaining user stories have partial work associated with them. That code is in your source control system, and in order to correctly demo or ship what was accomplished in your sprint, you’re going to have to do some work to create a “done” product. You will have to subtractively merge those changes, or put them on another branch, then re-test the application, redeploy.. check the changes again etc. There is still a lot of work to finished in getting this sprint to “done.”

One way to get around this is to associate user stories with code changes in your SCM tool.  AccuRev already creates a link between your user stories and code in the form of change packages. Creating that link between the user stories and your code is the first step. But using a powerful story-driven process out of this linkage is the key to “getting to done” in an Agile environment.

Your user story will move through different stages as you move through your process. One user story may have these states:

chart Agile and SCM: Helping You Get to DoneDEV- Currently in progress with dev team, or “coding”
QA- Coding finished, ready for QA to test
UAT- QA finished ready for user acceptance testing
PROD- Tested by QA and users, ready to ship

However, while  user stories move through this process, the code doesn’t follow. Traditional SCM systems are designed around single branches and a long and lengthy merge processes. Fast paced Agile environments expose those limitations as development teams struggle to ship code to customers at the end of iterations.

During that iteration, testers may want to test completed user stories, but need a stable configuration to do so. If you’re using a traditional waterfall branching and merging based SCM tool, you may end up with some user stories ready for QA, and some still in the DEV stage, creating a poor testing environment and broken builds. As a result, developers often delay committing code so changes can be implemented, tested, and passed to QA before they integrate.

During your retrospective of the previous iteration, you may decide that parts of your process need modification. For example, you may decide to add a code review process right before testing. Your SCM system has to be flexible to enable this new step without time consuming tasks, like re-writing scripts.

SCM and an Agile Process

The trick is to have an SCM system that can help you manage and enforce an Agile process. Code should be able to follow the same process user stories follow. If a user story is in QA, all of the code needed to test that issue should reside in a QA configuration. The same goes for DEV, UAT, PROD, or any other process that is part of your environment.

A stream structure is an easy way to  process change – streams can be added to adjust your process. In a few clicks, you can add a code review between a DEV, and QA step.

Agile and SCM: Avoiding Agile Merge Hell

As you start to scale Agile, code and user stories have to be merged more often. Sometimes changes my flow from one organization to another. This means that you will need to take code from one team, merge, integrate and test those changes with everyone. Each team needs to be able to work on their own schedule, this means that if multiple teams want to work on different sized iterations they can. In addition they can deliver changes as they need to on a regular basis, independent of the the other teams.

The problem here is that to do this in a traditional SCM system, you would have to merge these code changes daily for them to be of any use. You also still need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, the type of configuration people use for this is a single baseline or “trunk” methodology, where all changes from each team are delivered to trunk and pulled from trunk as their iterations are completed.

Working within an Agile context, your teams will have to deal with these branching and merging issues. But there are other problems that can happen when you use this methodology:

  1. Delivering 2 weeks worth of changes only causes isolation among teams.
  2. It’s too hard to pick out each user story as it completes from our codebase.
  3. Figuring out the dependencies of those user stories is complex.
  4. Being able to identify what changes came from each branch is impossible.

This “baseline pollution” is not scale-able. You can get around this by using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance, and code reviews.  A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change, as well as the system as a whole, reaches a higher level of maturity. While many traditional SCM tools do not easily support or surface a development hierarchy, AccuRev supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.

Posted in: AccuRev, Agile, Best Practices, change packages, user stories

Leave a Comment (2) →
Page 1 of 2 12