Ruck … Ups and Downs in the Rangers Backyard

This post i part of the series of Ruck posts, which you can find using the Ruck tag:

Firstly, what is Ruck? Looking at Wikipedia here, we get the following definition: “a "loose" scrum (today officially called a ruck in rugby union)”. For the Rangers it is a derivation from the Scrum framework, adopted to support the Rangers ecosystem. At this stage Ruck is currently evaluated as part of the Lab Management Guide project and will shortly be used by the Build Customization Guide project team as well.

While the Rangers project take on a number of different ecosystems within the various feature area teams as shown in the following cartoon, we are investing in Ruck to bring the overall project ecosystem to one that resembles the first illustration … one of order, transparency and productivity.

loaned from book “Software Engineers on their way to Pluto”, showing typical feature area environments.

The “Ups” with the Rangers is important to mention before we get to the “Downs’. The family of Rangers are made up of experienced, knowledgeable, sharing and passionate technology geeks that have embraced the African concept of “Ubuntu”. Looking at Wiki again we find the following definition for Ubuntu here: "I am what I am because of who we all are." It is a great term that summarises the family of Rangers made up of members from the product group, user education, services, Microsoft Most Valuable Professionals (MVP) and other technology community leads. In essence, it is all about the team or as the Borg would have said, it’s all about the Collective.

Core challenges with Rangers projects identified to date

Some of the key challenges … the downs …

  1. Rangers are distributed across multiple time zones, literally around the globe.
  2. Ranger teams are made of up different experience and area of speciality resources.
  3. Ranger teams are made up of part-time resources, ranging from primarily few hours per month to full-time bandwidth.
  4. Ranger teams often work in isolation, resulting in duplication of effort.
  5. Ranger projects were often based on community polls and individual perceptions of importance and “killer features”.
  6. Ranger project status  was often maintained and managed in custom documents and workbooks, limiting re-use and increasing maintenance efforts.
  7. Ranger project status is often out of date or incomplete, making it difficult to create meaningful project management reports.

These challenges sound more like annoyances than challenges in an information technology world, where virtual teams and workspaces, conference calls, messaging, Skype and other concepts and technologies are promising an alternative to the old fashioned face-face communication. Trying to discuss a design, investigating an issue, doing a Scrum stand-up (how can we guarantee everyone is standing?) or doing a sprint planning with the team is something that comes fairly naturally when all team members are assembled around a whiteboard, are talking to and with each other and are able to observe body posture and facial reactions. Trying to do the same via a teleconference, with a virtual whiteboard, members scattered around the world(minor issue)  and time zones (most severe issue as some may be attending at 3AM in the morning in their time zone) is at least 50% less effective, thus taking twice as long to get to a similar, not same, result.

… not everyone may be in your time zone. Thinking and talking at 3AM can be challenging … try arranging a meeting for a team scattered over America, Africa, Asia and Australia 🙂

As we can only focus and remember seven (7) points, we will cover other challenges in future posts.

How Ruck attempts to address and circumvent some the challenges

Ruck is NOT the silver bullet (yet?!?) and is still based on very wet concrete foundations as we are reacting to challenges and suggestions by the team, constantly tweaking the process and the infrastructure. The objective, as mentioned before, is to create a case study and whitepaper for “Ruck” once we complete the Lab Management Guide project … which is somewhere in the first half of 2011.

The intention of these interim posts are to be transparent, to share our experience and to hopefully get more input from other teams that are battling with the same or similar challenges.

The challenges mentioned above in a nutshell to avoid scrolling:

  1. Distributed team, multiple time zones
  2. Different experience and area of speciality resources
  3. Part-time resources
  4. Work in isolation, duplication of effort
  5. Community polls and individual perceptions driving “killer features”
  6. Custom documents and workbooks used for project management
  7. Project status is often out of date or incomplete
Downs Ref. No How does Ruck address the challenge? Notes
1 The team is divided into feature areas, which are managed by feature area leads. The feature area leads and the core team (program manager, product owner, dev lead and Ruck master) collaborate using Ruck-of-Ruck sessions. We considered creating feature area teams based on regions, but due to the often low concentration of Rangers in specific regions on a specific project we resorted back to feature area teams that are focused on a set of features, but potentially dispersed around the globe … this area deserves a lot more investigation.
2 Each feature area is made up of a mix of experience, with the feature area lead guiding the feature area team and ensuring that information and experience sharing is part of the team ecosystem, requesting focused technology training where needed. Rangers are people who love to share and collaborate by nature. By involving a variety of expertise and experience we are achieving optimal information sharing and more importantly ensure that real-world –field-experience is included in the solutions.
3 The backlog and the associated tasks are estimated and managed in terms of normal hours. In essence a task is estimated with the assumption of full-time resource availability and focus, and then burnt down on a part-time basis. While estimating based on a normal and full-time environment delivers more accurate estimates, the part-time burn down is a challenge as tasks often span more than a sprint introducing some interesting sprint retro, review and planning side effects.
4 The team is encouraged to use the distribution lists to collaborate and ruck-of-ruck stand-up sessions bring all the leads together on a weekly basis. The ruck-of-ruck stand-ups are weekly to match the part-time resource constraint. With full-time resourcing projects we would expect the stand-ups to be on a more daily cycle.
5 A new initiative that has emerged out of the Ruck investigation is the analysis, identification and definition of teams and personas that are applicable to the specific project. The use of team and persona definitions allows the feature area teams to deliver focused solutions and guidance, which are aimed at real-world scenarios and users. More on this later in a separate thread.
6 The team is using Team Foundation Server (TFS) 2010 with the Scrum process template as the Application Lifecycle Management tool, SharePoint 2010 as the collaboration portal and tools such as for sprint planning. The use of custom documents, such as Excel workbooks, is feasible, however, the use tools such as TFS is a lot more productive and also supports collaboration, linking and re-use between Rangers projects.
7 The team is using weekly ruck-of-ruck stand-up meetings to consolidate and share the latest status, actively guiding the leads on the use of TFS. We are pursuing an empirical process of exploration, feedback and adaption, constantly guiding and supporting the feature area leads, adapting the framework and re-aligning as a team. The task of feature area leads is complex, as they are themselves part-time resources and balancing Rangers projects with other full-time projects.

Is it worth it?

Absolutely! Although we are still adapting the Ruck framework, reacting to challenges in the Rangers ecosystem and experimenting with tools to improve the transparency, the predictability and the productivity, we are seeing improvements in all these areas within the projects using Ruck.

Scrum patriots are probably shuddering with all the Scrum rules and guidelines we are breaking … then again we are using  a loose version of Scrum, namely Ruck, to introduce scrum-like processes in a very challenging ecosystem 🙂

Watch the space for more updates …

Comments (0)

Skip to main content