Scrum/Agile Now Used To Manage Non-Tech Projects 136
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."
Re:What if... (Score:2, Interesting)
I teach and coach teams on how to adopt Agile for their work. I have a computer science degree and worked as a software developer and architect for several years... using Agile methods. I no longer do lots of hands on work, but I mention all this to help you understand that what I am saying is based on experience, not theory.
Scrum is one Agile method. It is good for creating high-performance product development teams. Unfortunately, it cannot succeed without some additional things: you _must_ also use the Agile Engineering practices from Extreme Programming: refactoring, test driven development, pair programming, continuous integration, user stories, architectural spikes, agile modelling, and acceptance test driven development. These are the practices that directly address your concerns about the problem with changing an existing software system.
Probably the most important, and the least understood is refactoring. Refactoring is defined, in agile methods, as changing the design of the system without changing its function. There are different types of refactoring: UI refactoring (e.g. radio buttons to drop-down selection list), code refactoring (e.g. pulling a method from a subclass into its parent class) and database refactoring (e.g. splitting a table into two or more tables along columns). Refactoring can be done on its own, but it is much better to do it with the other practices, particularly TDD and Pair Programming. Refactoring is essential for maintaining internal quality of a system in the face of constant change (which normally results in ever-increasing amounts of cruft and technical debt).
In my practice with software teams, I no longer think of developers as professional if they fail to use these practices. They are hackers in the most pejorative sense of the word. Think of a surgeon. If a surgeon fails to wash her hands before operating, she is failing as a professional. These agile engineering practices are like surgeons washing their hands.
Re:Agile / Scrum method vs Brainstorming (Score:5, Interesting)
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... (Score:3, Interesting)
pair programming
Oh no, are we still harping on about this? I though it had died 10 years ago.
Paired programming: one compenent programmer carries the lazy one. Why should I have to explain every line of code because he is too lazy or thick to read it himself?
In the end the competent guys went off and coded the app on their own in a quarter of the time.
Actually, I also recommend this to most organizations: if you have 100 people working on a system, you can probably find the top 10, get them to work together and let the other 90 surf the web... and you will get a better product faster.
Still, most organizations don't have this luxury (for whatever reason, good or bad) and so they need a system and tools to help with the problem of poor performers. A good agile environment forces (yes forces) efficient cross training. If you are a top individual contributor, maybe you resent this. That, in my opinion, is also unprofessional.
Re:What if... (Score:5, Interesting)