As I attended the Inoneweekend I tried to understand what software development style would work for such extreme software development. The closest I could find was Scrum Scrum can best be described by a joke about a pig and a chicken.
A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.”
So the pigs are committed to building software regularly and frequently, while everyone else is a chicken: interested in the project but really irrelevant because if it fails they’re not a pig, which is they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.
Pigs
Product Owner – represents the voice of the customer.
ScrumMaster – whose primary job is to remove impediments to the ability of the team to deliver the sprint goal?
Scrum Team – has the responsibility to deliver the product.
Chickens
Users – for whom the software will be used.
Stakeholders – people that will enable the project, but are not directly involved in the process.
Managers – who will set up the environment for the product development organization?
Because there were so many unknowns to start even SCRUM may not be enough.
The KEY concept of SCRUM, which is basically giving the PIGS work and leaving them alone to get the work done, had to be maintained. However, you had to setup a system to FEED the PIGS. There had to be three sides.
1. The business side determines what work to do. They create the requirements, define process flows, etc.
2. The architecture side determines how the work could be done. They have to make sure that everything is in place so the PIGS can produce work.
3. The PIGS doing the work and need to be left alone to do the work.
In a 72-hour event like Inoneweekend the business side and architecture side had to both work together to FEED the PIGS. If the two did not communicate effectively then it was likely that the PIGS would pay the price. For example if the Fact model own by the business side did not match the data model owned by the architecture side, the business may want information like a customer’s age stored but the database may not have age setup on the database. Such issues will only slow down the SCRUM team.
What makes it interesting is that things are moving so fast that one can’t really say here is a unit of work for the PIGS to do that they will complete in a two-week time frame. What is really happening is a scramble to put together a logical unit of work that can be performed by the PIGS while making sure the tools are in place for the PIGS to do the unit of work. To add to the insanity you have to create groups of PIGS each working on producing a different unit of work. This is only possible by properly defining tasks.
A key to defining the tasks is to define the interdependence between any two-project tasks with respect to problem solving based on the probability that efforts to perform one of the tasks to specification will require related problem solving in the other tasks.
The greater the interdependence of tasks the PIGS are working on the greater the chances are the PIG teams will be getting in each others way or the product produce by a group of PIGS will have to be reworked. This is really an old concept.
In 1973 Herbert Simon made an argument with respect to “decision making”
Tasks as follows:
“The division of labor is quite as important in organizing decision making
as in organizing production, but what is being divided is different in
the two cases. From the information-processing point of view, division of
labor means factoring the total system of decisions that need to be made into
relatively independent subsystems, each one of which can be designed with
only minimal concern for its interactions with the others. The division is
necessary because the processors that are available to organizations,
whether humans or computers, are very limited in their processing capacity
in comparison with the magnitude of the decision problems that
organizations face. The number of alternatives that can be considered, the
intricacy of the chains of consequences that can be traced — all these are
severely restricted by the limited capacities of the available processors.”
The greater the communication and coordination required among problem-solvers the greater the complexity and amount of time that will have to be devoted to problem solving. The key in a 72-hour project is to properly partition the tasks as to reduce the total amount of communication and coordination required to a minimum. Interdependencies have to be identified and eliminated when possible.
A good work on this was written by Eric von Hippel, Task Partitioning:An Innovation Process Variable (Published in Research Policy (1990) 19, 407-418.)
So even if all of this works properly you still need a PIG herder. With several PIG teams working at the same time there needs to be a PIG herder who’s job is to work with the SCUMmasters to handle any communication and coordination issues. The herder has to make sure the PIG teams are moving in the right direction and not fighting each other. If the Herder and Scrummasters are doing their jobs then the teams of PIGS can concentrate on delivering product.
What make the job more interesting is that for every task that can impact other tasks based on dependencies there is a risk of the impact happening that can be assigned a value of probability. This probability is based on the rate or likelihood of change, the complexity of the task, and the level of unknowns or assumptions related to the task. With these variables taken into account the potential impact to the PIGS deliverables can be determined with some degree of confidence and risk management plans can be created to deal with them. With only 72 hours available much of this is going to seat of the pants flying with a lot of assumptions being made. Anything that can be done to properly organize the tasks is going to be of benefit.