Blogs about Jazz

Blogs > Jazz Team Blog >

A Scrum Master’s experience report on using Feature Teams

I am currently the feature team lead and scrum master for the team working on the feature to improve gap handling in Jazz Source Code Management (SCM). We have been using the feature team model that was presented in the blog post Organizing our teams for Continuous Delivery and we thought it would be worthwhile to share some of our experiences working in a feature team.

The core team consist of five developers, where three are in Ottawa and two are in different locations in India. We have also had a temporary member responsible for creating our graphics. Our feature is made up of a server portion, a client core piece used by all clients, and specific integrations for our main clients: Eclipse IDE, Microsoft Visual Studio, Windows Shell and the Command-line Interface (CLI). We started working on the feature in late 2012 and are targeting to release the feature in late fall of 2013 as part of the next release of  Rational Team Concert (RTC).

Here are some of the tools and practices we have used to help us along the way.

Regular Scrums

We have daily scrums so that team members can keep up-to-date on everyone’s progress and ensure any blocking issues are dealt with. Due to the time difference between Ottawa and India, only two of those scrums are with the full team, while the other three are with the team members in Ottawa.

The status round during the scrums typically took 15 minutes or less but we schedule one hour for scrums to give us time to discuss any issues that were raised or to give a demo. Because our team is distributed, we made use of IBM SmartCloud Meetings to enable us to show demos and discuss various topics.

Team Wiki

Any discussions we have in the scrum are typically documented beforehand on our wiki to enable us to have a more productive meeting. Using a wiki also allows us to communicate ideas and implementation aspects both within the team and to other stakeholders. The types of information we have been collecting on our wiki are:

  • Design specifications
  • High level planning
  • Preliminary documentation
  • Test Plans

Some of this information will eventually make it into other forms, such as documentation, articles and test plans, but we find that starting to capture this information ahead of time on our team wiki allows us to discuss and evolve this information. For an example of our use of the wiki, visit our Change Set Patching feature team page.

Team Wiki

Issue Tracking and Planning

For our tracking and planning, we made use of a hierarchy of stories and tasks in RTC to break our feature work down into workable pieces. This is really part of the bread and butter of our day-to-day development of the feature. Here are some of the features  of the RTC work item support we rely on.

Here’s a simple query we use to show all our unresolved work items. This query can be used to create a feed to see daily work item activity.

Work Item Query

Plan Item Checklist

An important aspect of our feature planning is the feature checklist. Each plan item has a list of the items that need to be completed in order to ship the feature. There is a default checklist that is a part of every plan item and individual feature teams determine which of those items apply to their feature. The checklist includes items such as Done Criteria, Acceptance Tests, Implementation and many other general development related activities that need to be done before the feature can ship. Have a look at the 249763: [CCM] Merge Gaps : Provide initial workflow to mitigate merge gap exceptions plan item to see the entire checklist.

Plan Item Checklist

Coding

We rely heavily on RTC’s SCM and Build components. Because of the size of our feature, we have been working in a side stream which we kept up-to-date with our main stream (see Rational Team Concert source control makes continuous delivery easier for a look at the stream structure used by the SCM feature teams). Working in a side stream in RTC is not without it’s challenge but RTC makes it manageable.

Side Stream

Because we have been working in a side stream, we set up our own set of continuous builds running against our stream so we could still get the benefits from continuously running our automated tests. As one would expect from a new feature of this size, the continuous builds proved invaluable in detecting test breakages early.

One of the disadvantages of working in a side stream is that customers do not get a chance to preview the feature in a milestone. We really wanted to make the feature available for customers to try so we create a side stream of the entire RTC codebase and set up a build to create a beta build in order to allow customers the chance to provide us with feedback. Creating the stream and build in order to produce the beta was straight forward.

Run Team

As mentioned in Organizing our teams for Continuous Delivery and Role of the run team in our Continuous Delivery process, one of the aspects of our development process is the Run Team. Although the SCM Run team is separate from our feature team, they have been invaluable in handling the day-to-day work of maintaining Jazz SCM which has enabled the feature teams to focus on feature related work. Our feature team members have occasionally been pulled into customer issues or other discussions but the presence of the run team have made these manageable. I think it is safe to say that, for Jazz SCM at least, the feature team approach we have taken wouldn’t be viable without the run team.

Customer Interaction

While we have had several demos to customers and received useful feedback, the work on this feature benefits from the fact that it addresses an issue that we experience ourselves. In essence, this means we have access to a large customer base that includes our feature team members, the SCM Run Team, which has participated in some of our test passes, and the broader RTC and CLM team, along with our customers.

Challenges

I think it is worthwhile to mention some of the challenges we have encountered working in a distributed feature team.

One of the early challenges we encountered was having team members in different time zones. All of the team members are self directed so the issue was not in the day to day execution of the feature. Rather, it was in the area of design discussions. We found that many of the design discussions we have start spontaneously during the working day at someone’s desk. We found we would often have a good discussion and come to what we thought was the good solution only to meet with resistance when we presented it to the rest of the team. Once we recognized the issue however, we were able to deal with the issue by delaying the deeper design discussion until the entire team was present.

Another area we can improve in is breaking down these larger features into pieces that fit into the continuous delivery cycle. While RTC makes working in a side stream manageable, the ideal situation is to define deliverables that fit into the delivery windows. Our feature has been in the works for over 8 months already and has spanned 3 releases.

Another challenge has to do with the transition from an organization where teams focus on particular areas of responsibility to an organization that supports feature teams. Before we switch to a feature team based development model, we would have implemented the server and core pieces of a feature and then passed that off to the client teams to adopt. We switched to a feature team based approach in order to shorten the development time by working on these separate pieces concurrently. As I indicted above, our feature team is working on all these pieces together and I find that it has been a big improvement over how we used to do things. However, while we still have have some work to do in folding all the feature related work into the feature team. Our organization has separate teams that are responsible for graphic design, testing, documentation, and translation. We are still learning how to best incorporate these into the feature team model. For our graphic design and documentation work, we are assigning temporary members from those teams to work with us at the required time. This is not ideal but it a good starting point. We still need to work out how to effectively incorporate the other areas into our feature team model.

Conclusion

Having worked using both our old development process and our new feature teams based approach, I firmly believe that we need the feature team approach to make continuous delivery work. Having team members who are able to focus on the feature and are in regular communications has been instrumental in successfully completing our feature. The facilities provided by jazz.net and the RTC tooling have been crucial in enabling us to do our work. As we near the end of the release and the delivery of this feature, the feature checklist will become invaluable in ensuring that we have all the pieces in place.

We still have a way to go in fully reaching the potential of agile development through features teams, but we are on the right track.