It all started with a problem with the way we were doing software development. Projects took years with “phases” such as Requirements, Design, Development and System Testing taking six months each. We used to create thud factors where our value was determined by how much the table shook as we laid down our documents that we laboured over for hours on end. There had to be a better way, and as it turns out, there was: Agile.
People often talk about how Agile has failed or not solved anything. But even if Agile had not come along the world of software development would have had to have changed. In a market when speed is important, in a market where delighting the customer has a direct impact on sales, we would have had no other choice then to look at solutions such as continuous deployment, automation and suped-up customer collaboration.
But Agile didn’t solve everything. Some teams found it incredibly draining to apply it to their environment. They described it as trying to fit a square peg into a round hole. They were teams that had large backlogs of work not a “project”, they were not date driven and sometimes they had specialisation. In essence they were operational or maintenance teams. So they sought other approaches that would suit their needs, methods that were more supple to their workflow but still had elements of agility. And they found Kanban.
There are still teams doing work who haven’t had their problems solved. These teams have a different problem again. They have a set date for an outcome to be delivered, high specialisation or domain specific knowledge and variable demand based upon the stage and breakdown of the work. This doesn’t normally happen in small organisations. This is a problem for large to massive enterprises. Neither textbook Agile nor textbook Kanban fit well in these teams. Primarily this is due to the fact that a stable velocity or lead time cannot be achieved – simply put, the team is too variable. The variability of the team changes based upon the story being delivered.
Let’s take a look at the work for such a team:
- Feature A
Story 1, Priority 8, RPSI (P – Fred Flintstone, S – Barney Rubble, Bam Bam, Ken, R – Bam Bam, I – The boss)
Story 2, Priority 6, RPSI (P – Fred Flintstone, S – Wilma Flintstone, Betty Rubble, R -, I – The boss)
Story 3, Priority 1, RPSI (P – Fred Flintstone, S – , R -, I – Betty Rubble) - Feature B
Story 4, Priority 2, RPSI (P – Barbie, S – Ken, R – Ken, I – Matel)
Story 5, Priority 3, RPSI (P – Barbie, S -, R – Ken, I – )
Story 6, Priority 5 (P – Ken, S – Fred Flintstone, Bam Bam, R – Bam Bam, I – )
Story 7, Priority 9 (P – Barbie, S -, R – Barbie, I -) - Feature C
Story 8, Priority 4, RPSI (P – Ken, S – Betty Rubble, R – Betty Rubble, I – Bedrock)
Story 9, Priority 7, RPSI (P – George Jetson, S – Barbie, Betty Rubble, R – The Thunderbirds, I – ) - etc etc
You will notice that there is an attribute attributed to each story that normally isn’t there for Agile work. This is a modified version of a RACI and RAPSI, which is a roles model for processes and activities and a role model for deliverables respectively. The example above predominantely uses the RAPSI model, but some work would benefit from the RACI more. A RAPSI normally stands for “Reviewers”, “Approvers”, “Providers”, “Supporters” and “Informed”. The provider is really the owner of the story, the person accountable. Supporters help the generation by answering questions and providing input. Informed receive the output but for information purposes; sometimes people believe this means they are the end consumers but that is not the intent. The “Approver” has been taken out as it isn’t the intent of an agile process to have heavy approvals – the assumption is reviewed is enough.
Some stories don’t have corresponding names against the roles. That is fine as long as consideration has gone into whether such a person(s) exists and why this story doesn’t require such roles.
It could be argued – when is a team no longer a team? But despite this the work needs to be done and the team does need to collaborate – not on a daily basis possibly, but on a story basis.
Trying to plan for this variability of when certain people are needed in the team could be potentially chaotic. If we tried to work in priority order and ensured that all of the cards were roughly the same size how could we potentially plan out resource needs in advance? The simplest solution is to give a weighting to the RPSI elements. As an example Providers would be ‘4’, Reviewers would be ‘1’, Supporters would be ‘2’ and Informed is ‘0’. Lets look at the resource usage for the first five cards in priority:
- Fred Flintstone 6
- Barney Rubble 0
- Wilma Flintstone 0
- Betty Rubble 3
- Barbie 8
- Ken 12
- Bam Bam 3
- The Thunderbirds 0
- The boss 0
- Matel 0
- Bedrock 0
So Ken is very heavily focussed at the start of the work, despite being the provider of only two cards. We are hardly using Betty, and not using Barney or Wilma at all. If the team takes the assumption that there is a maximum threshold for a person and that value is 12 for any person for a week then this week is full and no more should be pushed into the weekly plan. So what does this mean for the under-utilised team members? Surely they would go back to doing their other work until the project is ready to pull them?
What has this method done – it has taken into consideration the constraints of the team, the constraints of the story and created a framework to plan week by week without ever having to estimate. It considers the maximum limit of the team and the variability of how they may be involved in a day to day basis. What it doesn’t do too well is drive for efficiency and assumes that lighter or dead time is spent elsewhere.
This approach could be called “VSM” or Variable Systems Method, but someone else took that acronym. It is a different method for a different problem. The Variable Resource Method.
Disclaimer: This is not a method I have been using on software teams, but it is a method I have had to entertain for Agile in the Business. Your weakest link is your busiest resource.
Agile Forest 