Scrum/Agile Now Used To Manage Non-Tech Projects

jfruh writes "Agile and, in particular, Scrum, have been popular project management methods for software development for more than a decade, and now its use is spreading well beyond software. For example, NPR is using Agile for faster, cheaper development of new radio programs. 'I was looking for some inspiration and found it one floor up inside our building (where Digital Media sits),' says NPR vice president of programming Eric Nuzum. NPR has used this 'Agile-inspired' approach to create several new programs, including TED Radio Hour, Ask Me Another, and Cabinet of Wonders."

Comments

Re:Agile / Scrum method vs Brainstorming

[eulernet]

Agile/Scrum is not very good for brainstorming because it's focused on the process.
In fact, brainstorming creates a lot of ideas, but most of them are garbage.

I would recommend that you use the retrospective tool as follows:
  - first, use a timeboxed meeting (for example, 1 hour)
  - when the meeting starts, explain the goal of the meeting: to generate good ideas
  - then ask people to list the problems or the parts that could to be improved
  - then ask them to vote for the most urgent problems (give 3 points to each participant, and ask them to place their points where they want)
  - then take the most voted problem, and talk about it WITHOUT searching for a solution. The deeper the problem has been discussed, the better the problem is understood. If the problem is not clear, use the 5 whys.
  - NEVER search for solutions, since you'll fall in the "shitty instantaneous ideas" syndrome.
  - there is another syndrome, which is that people tend to defend their ideas even though they are bad. Most of good ideas are a mix of different ideas.
  - as long as you have time, continue taking the most voted problems

I call this process: the Reality Check.
It's necessary to detect what can be improved, and most of all to challenge the existing product/process.

Now, the tricky second part:
  - at the end of the meeting, ask people to propose solutions on a wiki page, or on a wall with post-its

Generally, finding good solutions requires to take a break, and cannot be found in a short amount of time (in my case, I find my best ideas after a good night sleep).
Ideas can be iteratively improved, so a wiki is the perfect way to do that.
Once a good idea has been found, reward all the participants, for example invite them for a lunch.
Some people like competition, so you may use a chart about the most creative guys, and reward them at the end of the year.

If you need more ideas, just contact me, and I'll provide you some other tricks, like ASIT methodology.

Re:What if...

[Instine]

I no longer consider any manager to be 'professional' if they get so dogmatic and process obsessed that they underline the word 'must' before asserting the need for a given practice or methodology. What you describe here is a soulless, creativity sapping mess of ass covering. It will not make better software, but simply reduce the attack surface of you in the boardroom/excecs' meetings (I've been dev, lead dev, Arch, Lead Arch of 30 devs, CTO and owner - if that makes any difference). It helps justify larger teams. It helps eat precious time. It helps track nonsense constructs, such as 'velocity' (please - as a physicist this term misuse makes me want to commit violence - what are the units of a scrum's velocity exactly?). It helps do many things, but not make better software more productively.