Posts Tagged ‘agile team’

Something’s A-Twitter in My Backing Stream

June 22nd, 2010 by amonty

One of the cornerstones of any successful organization is communication. On Agile teams, we often meet to share information, update one another on progress, to reflect on that progress and discuss how the process can be improved. These interactions, be they stand-up or retrospective meetings, provide this information at regular intervals. But what if you need “real-time”  information sharing?

Consider the concept of “one piece flow”, often treated as the holy grail of engineering process purists. Lean/Kanban fan boys live to talk about this at conferences, and in the isle outside my cube. The idea is that a single “workpiece” at a time moves through the workflow. In the software development process, this is rarely limited to a single item, but instead is throttled by WIP limits to minimize the bottlenecks in the process. For example, the number of items worked on by developers is limited so that the count of items designated “ready for test” is kept at a manageable level. As a tester on an agile team, I’d like to know as soon as an item is moved from the “wip/development” phase to the “test/validation” phase.

Consider the following basic stream structure -

Simple Stream Structure

In an ideal model, testers would be notified as soon as an issue is promoted from the WIP stream to the Validation stream. This model assumes that the project is utilizing AccuRev change packages to track work items as issues. Having a distinct stream for validation purposes simplifies the job of the tester. All issues that exist in this stream have been unit tested by developers, passed basic regression tests, and are ready to be explored, validated, and promoted to the next stage in the workflow.

So, how can this level of communication be achieved? AccuRev triggers! The rest of this post will demonstrate how the server post-promote trigger could be used to provide updates using arguably the king of “What’s Happening?” – Twitter.

Why use Twitter in your Backing Stream?

Why not? Sure, you could use e-mail. But who wants more e-mail? Tweet it, and let them aggregate the information for you. Team members can follow the account, or not. Pointy-haired managers that dream of pie charts and love visibility can subscribe to an RSS feed, that you don’t have to manage. Lastly, if you’re an agilista, you’re already hip and trendy, (and let’s face it, you probably  already tweeted about the awesome presentation on Lean that you saw at the latest Agile conference).

The Server Post-Promote Trigger

I am not going to go into the gory details of the AccuRev trigger system. Here’s what you need to know.

  1. The trigger can be written in whatever language you like. In this example, I use Ruby.
  2. The trigger needs to be registered with the AccuRev server, and associated with the depot for your software project.

For this exercise, I wrote a quick script called tweet_post_promote.rb. The first step is to register this script with AccuRev.

>accurev mktrig -p SoftwareProject server-post-promote-trig ~/dev/ruby/tweet_post_promote.rb

Once registered, the trigger will now fire for all promotes in the SoftwareProject depot. Let’s take a look at the contents of the script.

#!/usr/bin/env ruby

require ‘rubygems’

require ‘crack’

require ‘twitter’

ACCUREV_DIR = “/sandbox/amonty/accurev/”

ACCUREV_STORAGE = “#{ACCUREV_DIR}storage/”

ACCUREV_SITE_SLICE = “#{ACCUREV_STORAGE}site_slice/”

USER = ‘ValidationBot’

PASS = ‘password’


def load_trigger_data(file)

xml = ”

File.open(“#{ACCUREV_SITE_SLICE}#{file}”) do |f|

xml = f.read

end

Crack::XML.parse(xml)

end


def twitter_get_auth(user, pass)

httpauth = Twitter::HTTPAuth.new(user, pass)

Twitter::Base.new(httpauth)

end


def main()

hash = load_trigger_data ARGV[1]

if hash["triggerInput"]["stream1"] == “Validation” then

changePackageIssue = hash["triggerInput"]["changePackages"]["changePackageID"]

update_string = “Issue #{changePackageIssue} just promoted to stream #{hash["triggerInput"]["stream1"]}”

twitter = twitter_get_auth(USER, PASS)

twitter.update update_string

end

end

main if __FILE__ == $0

This script is very simple. It makes use of the Ruby gems crack and Twitter. Essentially, the script takes the XML trigger file (provided as ARGV[1]) and loads it into a hash. Then the script checks to see if the stream being promoted to is our Validation stream. If so, it uses the twitter gem to update the status on our ValidationBot account.

Something's a-Twitter in my backing stream

A more useful example is to provide a link to the AccuRev Web UI Issue screen.

Something's a-Twitter in My Backing Stream

This way, anyone subscribing to the feed can click on the link and open the issue in the AccuRev Web UI.

Something's A-Twitter in My Backing Stream

This is a small example of how AccuRev triggers can be used to increase communication on your team. Testers can follow the ValidationBot account and be notified via their favorite Twitter client whenever an issue is promoted to the validation stream and they need to begin work on it. This could obviously be extended to include additional information (actual file changes, for example). That is, of course, if you can fit it into 140 characters. :)

For more information on AccuRev triggers, please see the Administrator’s Guide.

Visibility in an Agile Environment

May 13th, 2010 by clucca

Amazing fact: The lookout crews for the RMS Titanic were without binoculars. Due to a last minute change in personnel, the team member who was in charge of spyglasses, binoculars and other optical equipment was not on board the ship, and all of this equipment was unfortunately locked away, crew members unaware of the location.

We all know the rest of the story; by the time that the lookout crew saw the iceberg, the opportunity to change course already passed.  There was not enough time for the crew to respond to the problem and correct it. They had no visibility (literally).

Agile is about adaptation. It’s not about sticking to the plan; it’s about exposing and responding to change in your development cycle. But how can you respond to problems if you don’t know what they are?

Our last blog post was about “inspecting and adapting”, and I don’t want to get these 2 success factors confused. The real point that I’m trying to get across is that visibility in an Agile environment allows your teams the ability to inspect and adapt to impediments.

Why is Visibility in an Agile Environment Important?

Information in an Agile environment is viewed more often, and scrum teams  need to see this information on a daily basis in order to change course if necessary. Visibility in an Agile environment allows teams to use information in their stand-ups, sprint reviews, demos and retrospectives.j0336214 Visibility in an Agile Environment

Visibility also needs to happen on a large scale, and everyone needs to be involved. Just think, if we gave only one pair of binoculars to the entire look-out team on the Titanic, it would have been much less effective than if each team was equipped with the proper visibility gear. Everyone needs to be aware of the problem in order to change courses.

But here’s the real trick. Centralize this information, make it visible to everyone and all your tools.  If you do this, you can integrate with all of your processes. This guarantees the information in the tools is correct. For example, if you have an integration in your SCM tool to your project management tool, you can see what changes correlate to what iteration, guaranteed. You can also integrate your build, test and deploy tools to provide tractability on all levels of the stack. Centralization also provides a single place where everyone can see what’s happening. Scattering the information against multiple tools that aren’t “Agile aware” will only confuse the process.

So having a global visibility can help re-route a ship that’s traveling on a disastrous course. It can also help your development teams change course when they need to.

Wouldn’t it be beneficial to get your whole team some binoculars?