SCRUM

On Friday I attended a SCRUM course given by Ken Schwaber, who's brainchild is the SCRUM process (agile software development). A two day course crammed into one was a little hard to absorb, but nonetheless a great opportunity to pick the man's brains about his process.

OK, here are the basic tennets that I had mostly already grasped.

• SCRUM is and Iterative process (inspect and adapt) good at isolating teams from 'seagull management'. Each iteration is about 30 days and no one is allowed to come and feed more requirements or changes to existing ones within that window (known as a sprint). This is regulated by the 'Scrum Master'.
  
• The team meets every day at a given time and place to discuss three things. Each person reports i) What was achieved yesterday ii) what will be worked on today iii) what obstacles stand in the way of getting this done.
  
• Requirements fed to team on a basis of 'Best defined, riskiest and business critical first' meaning, those requirements which are known and whose solutions are clearly understood are prioritised before those less defined. Those features which are deemed to have the most risk and or business value (balance of business benefit and user benefit) are also prioritised higher than those which do not.
  
• Focus on Return on Investment.
  
• Minimal reporting
  

Things that I had very much clarified were:

• SCRUM basically has a premise that you can't just hand over a brief or spec, as this flys in the face of the iterative cycle where a multidisciplinary team cracks on with finding solutions to individual requirements rather than defining whole systems (yes, I was worried here... but I'll explain further, it's not that bad). Basically, Ken used the example of a flock of geese which use an empirical process to find what they need when migrating. Their requirements are that they need somewhere that's warm and has enough food and water for the winter. It doesn't matter where they go, so long as these fundamental requirements are met, the geese are happy.
  
• The other revelation was that SCRUM can be used on anything from planning a party to building software. The premise is a tight knit multidisciplinary team. Meaning we have design, production, tech, editorial all working together at the same time solving about the same set of requirements in a sprint as each other... and talking lots. So, this allayed my fears that SCRUM was all about clients talking to technicians and design is left out of the equasion.

So, here's the tricky part. Alan Cooper staunchly argues that you can't design a good system as a set of answers to requirements. You need to be able to specify an entire system and it's dependencies if you are to succeed in making a well-designed system. Now, I agree mostly with this but am willing to experiment with the rigidity of this assertion purely because it just is not economical having your techs sitting around answering your odd question as you spend months designing a system that you're reasonably sure, but not definately sure will work. Or, would I argue, is it a good way to build happy and thus productive teams.

There will always be a need to do some preliminary research up front when we're talking about user research and defining requirements where you can't involve all team members 100%. Just like as a user experience designer, I can't code lines of code when the time comes to that. So ultimately when we divide a project into Understand, Concept and Design phases, it defines time periods where different skillsets are 'at the fore'.

So whilst in the understand phase, the best thing to do is to employ techs to do research into technical thing. If we see the research as a requirement just like a feature would be we can start to see where a scrum methodology can be employed. The biggest hurdle is convincing programmers that they're not wasting time by being involved in such 'airy fairy nonsense' such as research.

It's always been in the conceptual development phase that things have become hairy or clouded for me. It just never seems right to try and define a system in a slight vaccume (after all, techs can answer our questions, but they too have to estimate the complexity of things from time to time) and the tech team gets (rightly) pissed off waiting for the design team to give them a spec. Here's a thought. What if we were to design in a series of cuts whereby we define a 'sketch' of the overall system first (based of course on the research we carried out in the understand phase), then start to refine it feature by feature once we had some idea what elements would affect other elements. Thereby actually working side by side with techs to constantly flex and change the implementation according to what was achievable or desirable.

So, probably, and I say probably because I haven't tried this yet, it would look something like this.

Basic prototyping has proven to be the most effective form of documentation for communicating functionality to a technical team. A basic interactive wireframe made using Macromedia Flash speaks 1000 times quicker than a UML use-case which arguably takes about as long to write once you've wireframed it and analysed all the permutations of an interaction element. I see this as the way forward, in combination with some UML elements such as flows for specifying the way a system works and how the interface impacts it.

There's so much more to write here... but it's late and my concentration is failing.

Posted by Ant at October 13, 2003 12:01 AM | TrackBack