We are into week two of the Lab Management Guide project, which is also the trial grounds for the Ruck (loose scrum) process. Ruck is based on the Agile Scrum framework, evaluating the main pillars of Scrum in the challenging Rangers environment. The challenges include:
The pillars for Ruck are the same as Scrum, with a few added pinches of features and challenges:
- Transparency … visibility is key, especially considering the immense challenges introduced by the distributed, virtual, part-time, different time zone and different culture Rangers. As with Scrum, Ruck needs a clear definition of “done”, to ensure that what is seen, is understood and believed :)
- Inspection … apart from diligence the infrastructure used by the Rangers allows patterns and red-flag scenarios to be detected early … it is much easier extinguishing and dealing with a fire early in its lifecycle, that when finally facing a raging forest fire.
- Adaption … constant adaption and alignment is essential, especially with “Ruck” where we are still finding our feet and experimenting on a daily basis. With so many unknowns and variables, it is important that the Rangers are open to change and adaption.
- Collaboration … being unable to walk to the team, have a chat over pizza or gather around a physical whiteboard is probably the most challenging aspect of the Rangers ecosystem. Thanks to the different time zones a common stand-up may be attended by Rangers in the morning, afternoon, evening and for some at the most ungodly hours of the morning. The use of collaboration technology is therefore key, as well as open communication.
The “Ruck” process diagram for the lab management Guide project looks practically identical to the Rangers Scrum process. In fact it is based on the same diagram, only using the “Ruck” terminology to highlight the fact that we are not using the standard Scrum framework. Get the latest quick reference poster here.
What does our “Ruck” environment look like “today”? Some initial thoughts …
The project piloting the Ruck environment has a distribution that looks similar to the map shown on the Rangers Index post. We have teams operating in most of the time zones, members from a vast variety of cultures and members who have a variety of part-time bandwidth committed to the project. The planning, the collaboration and the tracking is therefore a really challenging task.
Our infrastructure consists of a Team Foundation Server 2010 Team Project, based on the Scrum 1.0 process template. The team is split up into feature areas, with a feature area lead with the responsibility of the feature area and keeping in touch with the core team and especially the Ruck Master. While this team structure potentially allows us to address the variety of time-zones and cultures, we are using it to delegate some of the project management and tracking tasks to the feature leads and thereby allowing the core team to focus on tweaking, grooming and refining both the Ruck framework and the supporting infrastructure.
A rough Wiki is used to define some of the base guidelines:
- Use of Agile … we are not fixed on any specific methodology or framework, but are considering features from Agile, in particular the Scrum framework, as part of “Ruck”.
- Use of Tools … we use Application Lifecycle Management tools, such as Team Foundation Server 2010, and other collaboration tools such as SharePoint and LiveMeeting to assist the feature area teams in the challenging collaboration environment.
- Leads … each feature area is owned by a feature lead, who in turn is part of the core team consisting of feature area leads, program manager, subject matter experts and the Ruck Master.
- 1-2 Sentence area status email … status is based on ad-hoc stand-up meetings and regular brief and concise status emails. While more regular stand-up meetings are on the wish list, the dispersed nature of the team and especially the time-zones makes it sheer impossible.
- Iteration … our iterations are currently 4-weeks in duration. While this sounds like an excessive duration the part-time resource constraints makes shorter iterations (sprint) impractical.
- Avoid JIT task completion … a constant challenge is for the feature area leads and the core team to avoid the JIT task completion (oh, we have a deadline in a week’s time … let’s do an all-nighter) which often appears in part-time and distributed projects.
- Use of Virtual Meetings … again the dispersed nature of the team is forcing us to use the world of virtual meetings, using LiveMeeting and the Office Communicator, often recording meetings to allow those unable to attend to catch up. While we promote stand-up meetings, it is not feasible to validate that all team members around the world are actually standing up :) Another variation to Scrum, is that our stand-up meetings are typically time-capped at 30min, to counter the virtual nature and allow more collaboration ”then and there” as the stand-up meetings are ad-hoc, rather than regular.
The Wiki and the feedback from ongoing analysis will be consolidated in a whitepaper towards the end of the project, to ensure that we can share the framework and learning's transparently :)
Is it an empirical environment?
Yes, we are literally forced to evolve the environment and the Ruck framework to react to learning's in the highly distributed, virtual and part-time team ecosystem, which is probably counterproductive and considerable noise for the team in the short-term, but essential to create a Ruck framework that will be re-usable to produce transparent and predictable environments for the Rangers.
In other words, some team feature areas and members may appear like the following blue men at times, but are striving to turn into the vibrant orange chap :)
Next time …
… we will discuss the way we are dealing with stand-up, retrospective and sprint planning meetings as part of Ruck.