Blogs about Jazz

Blogs > Jazz Team Blog >

Making Agile Real

The theme of Agile 2009 this year was “Making Agile Real”, and the keynote given by Alistair Cockburn is available for your watching pleasure. Although Alistair is a great speaker, during his talk I was yearning for some hints on how to map his concepts into practices. While the eternal pragmatist in me was waiting for the concrete in his talk, at the 11:50 mark he mentions the Jazz project and Jazz.net as an interesting example of a product that is pushing “collaboration” to a new and interesting level. While collaboration and cooperation were common themes in the talk, I’m not sure it was clear enough how teams put these things in the center of their daily lives. Now some will say that more collaboration may be a bad thing, given that our inboxes overflow and we have to sometimes log off instant messaging to get work done. But as you’ll see later on, the collaboration we’ve instantiated in Rational Team Concert is more powerful since it’s a combination of  a pull model (eg, you can find out what is happening without asking) and making domain specific collaboration artifacts so that your team can have common virtual meeting places to coordinate high value activities.

Before jumping into details, the one quote that resonated with me the most was that “the speed of communication is 100% related to the speed of your project“. It’s at the core of all the tooling we’ve built in Team Concert, around how to remove the collaboration roadblocks in your projects and facilitate communication. It’s also a common theme in most of the examples I’ve outlined below.

Your Craft

Highly productive teams are composed of people who want to excel at their craft. When someone joins our team, I try to make it very clear that she will be working “with” a team and not alone on a feature and one of the best ways to perfect a craft is to be an apprentice. Even when you’ve been at your craft for years, there is always something new to learn. Here are some of the techniques that I recommend for those perfecting a craft and developing new skills on a new team while working with Team Concert:

  • Monkey see, Monkey do: Subscribe to an RSS feed for the events for a senior member of your team, follow their conversations, and look at their code changes. You can do this via the “Show Recent Events” action from the Team Concert client for the Eclipse IDE. Look at how they respond in work items or outline the progress of their work. How often, and clear are the interactions with others on your team and with others on different teams? When a feature or defect is fixed, what information is added to the associated work item and how do they inform others about breaking changes they are making? Then look at the actual code changes and look for how tests are written, what files have to be changed together, etc. You can learn a lot from following key people on your project. We build tools so that you can find out what is going on without having to ask. The following picture shows all the aggregated activity for Heather, you can see code changes, work item comments, and approvals without having to ask or poll the team.
  • ag2009-3
    Figure 1: Recent Events Feed for a User

  • Share your code early: Don’t work on a feature for a month without attaching the change sets to a work item or asking for someone to review your user interface. Attach a screenshot to the work item, give a demo, blog about it. Also, don’t get upset when someone asks for peer reviews, or just looks at the change sets that are attached to work items, they are extremely helpful. Using the combination of change sets, work items, and approvals and linking between all these things, you can really leverage your team and learn your craft with others. We’ve made it really easy to share code with others on your team so that peer reviewers can also run your code before it’s delivered to the team. Now if that wasn’t enough, we introduced “personal builds” which allow you to run builds on your code before you deliver so that you can get quick feedback on your changes and can iterate and gain confidence that you won’t break the build.Below you can see how from the work item you can track everything, change sets, approvals,  builds, and really get full visibility into what is going on.

  • Figure 2: Work Item “Quick Information” access to change sets and approvals

Cooperative Game of Invention and Communication

I couldn’t agree more with this practice, and much of what we built into Team Concert and the platform is to enable this cooperation.  Making the things that are important to enable collaborations “explicit” in the tool helps reinforce to the team that they matter. We took the main friction points between teams and that had  slowed us down in the past and created explicit artifacts in our process to enable these collaborations.

In our retrospectives we would often hear complaints about “that other team”. In order to avoid the blame game, and remove the friction between teams we added the “Track Build Item” and “Adoption Item”. These artifacts provide an explicit channel for cooperation on these two very important activities on our team. By making them explicit we’ve made it clear to the teams that succeeding and optimizing these two collaborative activities is a top priority.

ag2009-4

Figure 3: Our Collaboration Artifacts

It’s good to have the artifacts, but equally important is to make the information easily available to the team. We’ve learned that the more people know what is going on and that we can remove the roadblocks to communication, the more effective our actual communications can be. We use project dashboards, as shown below, to track important information.

alistair_cockburn_agile2009-dashboard

Figure 4: The Team Concert Dashboard

Going back to making the important things explicit, let’s use an example scenario of how the Build Tracking item has helped us. When the build breaks on your team, what happens? For us, it always resulted in a flurry of e-mails, maybe a panic call, and everyone thinking that someone else was going to fix it. Instead of this random collaboration, we changed our process such that each build effort (eg, a weekly integration or milestone) has an associated tracking item. You can navigate from the build to the tracking item, or easily see the open tracking items from the dashboard. If you want to know what is going on, just look at the tracking item. The release engineering team owns the tracking item, but everyone is responsible for participating and giving approvals directly in the tracking item so that we can declare the build green without wasting time with meetings and e-mails. By combining rich tool support and making collaborations into first class artifacts, we’ve optimized our collaborative game.

Lean Processes

This is an area where we do encourage lean process in Jazz, but Team Concert doesn’t enforce a predefined process. I think the values of openness can be applied to different processes, either Agile or a more traditional waterfall process. We don’t tool ourselves into restricting one or the other in Team Concert. The key is to pick the strategy that works for your “game” and if the tools help make things transparent, the bottlenecks and inventory can be made a lot more visible to all. One of the problems teams have with adopting Agile practices or Team Concert is that they don’t know where to start and are sometime tricked into having to start from scratch.

When using Team Concert, pick a process that works for you and don’t be afraid of keeping some aspects of it “un-Agile”. One cool feature of Team Concert is that you can tweak your process at any time. Once you like your tweaks then you can create a template from your project and use it in other projects.  Our own process and practices have evolved over time and we are continuously reflecting on our own process. Our practices started with the eclipse way but since we started working on the Jazz projects, we have adopted several additional practices from the agile community. For example, our planning process has evolved to be more like Scrum. Not surprisingly as we started to use the Scrum planning practices ourselves, we have also improved the corresponding tooling support (see http://jazz.net/blog/index.php/2009/08/20/sprinting-towards-scrum/).

We have also found that our leanliness varies over time. As we have tuned our own processes, we have also found that our leanliness varies. In particular during and end game we use approvals to ensure a disciplined shut down. While approvals introduce a queue between roles, we have found that with the corresponding tool support we can make this very smooth.

Design as Knowledge Acquisition

As part of the design and knowledge acquisition practice, Alistair talked a lot about Trim the Tail. An iterative approach to not only setting up iterative development but also about how to align business and technical risks in a plan which allows you to have a smooth end-game and deliver on time or add new features. This is contrary to the usual option many projects have of only slipping. Scott Rich talked about our end-game in Team Concert 1.0, which is really what happens when your development team makes this happen in real life.

However, we’ve learned that it’s not always that easy, and in Team Concert 2.0 it was a lot less smooth. In retrospect, although having a single team follow a risk based, knowledge acquisition plan, we learned that their decisions affects other teams. See what happens in the figure below when a team decides to make a change that breaks others late in the game. The first two teams ship on time and have a smooth end game, while the other “downstream” teams suffer from a late breakage and slip. Often, the breakages can happen in non-risky code from the producers perspective but the actual “cost” is reflected in the ripples and not in the one isolated change. The picture below takes the planning timeline in Trim the Tail for one team and expands to several. It then shows how adoptions caused in core teams can affect the planning and probability of shipping on time for all other teams.

ag2009-5
Figure 5: Chain Reaction Breakages in Teams or Teams

When planning your iteration it’s critical to consider how to communicate and ensure you don’t derail other teams. We’ve used two main techniques to address this problem. The first is to create a first class artifact called an “Adoption” work item to track the collaboration and make breakages transparent to all the teams. These get created when a breakage will happen, hopefully before, and explain what will happen and when. Teams get notifications and can plan them into their iteration. Alternatively, you can stage the iterations such that upstream teams have a bit more time to stabilize based on the adoptions planned below them. We use both techniques to manage this cascading dependency slips.

Conclusion

Thanks to Alistair for an entertaining talk and it’s great to be able to attend these conferences virtually. I look forward to tooling a lot more of these practices in Team Concert and other Jazz products in the next releases. Keep an eye out for more “game” features in Team Concert… there is a lot of potential for new levels, bonus maps, and multiplayer planning! And don’t forget that Rational Team Concert is now FREE for 10 users.

Jean-Michel Lemieux
Rational Team Concert Lead