Slashdot Mirror
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."
What if Agile is better suited for other tasks than software development? I think Agile is an elegant way of approaching some kinds of creativity, but it just doesn't seem to work for most aspects of software-development.
Making radio shows is more of an iterative kind of creativity with lots of loosely-coupled ingredients where throwing away an item and replacing it with another won't destroy the whole format, so you can start off with a format, broadcast it, and add/remove items as you go.
Software is completely different. You create it once and after the first release you have to support it for eternity. Every new addition adds another layer of complexity, you can't just remove a feature without breaking other things or add a feature without duplicating functionality. For every iteration you'll need an overview and a deep knowledge of the whole system.
The fundamental idea of Agile is that you do things incrementally, see how they work and then fix the problems afterwards. This is based on the (definitely somewhat valid) claim that it's easy to change software after the fact but difficult to know in advance what the best solution to a problem is. Moreover, the idea is that you can properly test a piece of software to see that it does more or less the right thing before using it. Basically it's saying that the hardest part of software is the design and it may be worth trying different ones and throwing them away as they fail in order to be sure that the design is sound.
Architecture is different. It's very difficult to change a building after you have poured the concrete. If you try building a concrete building without incuding steel to see if it works and then it falls down with people in it then that will not be acceptable.
In other words; the consequence of applying true agile methodologies to Architecture is likely to be well deserved jail time.
I first heard of Scrum from my wifes hospital ward - where they were using the technique to manage the activities of their staff. This made me curious as to its origins and it turns out it was first and foremost a product development methodology. So its not that Scrum is spreading from its software origins - it never originated in software in the first place.
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.
Many, many thanks for the most informative post !
It'll take me sometime to digest what you've written and we'll get in touch later
Thanks again !!
Muchas Gracias, Señor Edward Snowden !
You are welcome.
I'll give you another trick, inspired by TRIZ and ASIT:
if you have no idea how to improve your product, just describe all its functionalities graphically (it's similar to Design Thinking, which is a great way to solve problems for visual people).
After that your product has been drawn on a board, just remove each part one after another (and replace the removed part after).
Ask yourself:
- what is the value of my product without this part ?
- what could I use to replace this part ?
This process is called Extracting, and is essential when improving systems, it helps to challenge your own conceptions.
ASIT's creator, Roni Horowitz, proposes the following exercise:
suppose that you have a TV without image.
What could you do with it ?
What is its value ?
Working in the game industry i found that creativity was heavily hampered by scrum, even after doing several adjustments to the process.
So how does this sort of stuff work in the architecture field? e.g. say you have a team of people designing a new large building with an innovative design.
It works pretty well, thank you.
Ezekiel 23:20
... especially when non-technical people are in charge of this process. One can't map short term deliverables properly to a creative process.
... with Agile is the "Daily Stand-up." I don't care what anybody else is doing on a daily basis. Actually, for most people, I don't care what they're doing -- ever. All I care about is that people I work with (1) answer e-mail in a timely manner and (2) if I depend on their work, that they'll have it done when they say they will. (If they're going to miss a dead-line, only then do they need to bring it to my attention.)
What some other set of people whose work I don't depend on is doing in no way helps me do my job. I'm paid to do my job, not concern myself with everybody else's job.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
I understand what he meant by that, and I don't think it is as bad as it reads. I think he just meant that those things are the key components, they are just part of the process, if you want to do it right.
I spent the last 3 years managing a testing teams on an Agile project. And it was at a very very large company that is most certainly concerned with money. What I saw Agile do was amazing... and yet, we had to compromise it somewhat. We didn't do pair programming. Our TDD wasn't as good as it could have been. We faced challenges with it, but we had contraints that we had to deal with, especially after our first release. But I will say that the quality and volume of what we put out was far and above anything else around us.
IMO, Agile isn't for every software project, and there are some that I think it simply just wouldn't work for... but it is very very useful when it fits. BUT - you have to really adopt it. It really is a team effort, and if it's not, or if you ignore or sabotage some of the key components of it, you will fail. To one of your points, calling velocity a "nonsense construct" tells me immediately that you've never done Agile, at least not successfully. I'll take a moment to explain....
You actually aren't far off... it kind of is a nonsense construct. What?! Yeah. It is a unit of effort. Here is how we did it. Each story is written to describe the functionality desired. It should follow good story principles of INVEST (look it up). Once you have that, the development and test team review it, and quickly put an estimate on it. We used a point scale. 1,2,4,8,16,32. You have to pick one of those values, there is no 12 for example. This forces a decision on it. If you had a 1 to 10 scale, there's really no differentiating factor between a 7 and an 8. You get the idea.
So what we did was the dev team came up with their estimate for each story, and test did the same. Then the story was assigned the larger of the two numbers. Since you have to dev and test it during the iteration, larger number wins. Then as a team you commit to X number of points for an iteration (we used 2 weeks). At the end of the iteration, whatever stories are accepted as delivered are counted up, and that is your velocity for the iteration. The NEXT iteration, you can only commit to doing that number or less. You can certainly deliver more, but you can only commit up to that. Over time, your velocity will fluctuate, and then STABILIZE. That is the point where you know as a team how many points you can deliver in a 2 week period, in theory indefinitely. Now some people want to know how accurate your estimates were - i.e. we said this story was 16 points.. how many was it actually? Don't do that. That is exactly why we didn't use hours. It's irrelevant. What is relevant is how many points you delivered. By making the points a non-quantifiable number you can't do that. It let's you focus on what is really important, and that is determining the team's sustainable velocity.
It is a foreign concept. But we did it for 3 years. Actually the project is still going, I just left and took on a different positon in the company. Yeah, we had challenges, funding and otherwise, but we were able to deal with them. We had to cut about 1/2 our team at one point, and our velocity suffered. But we got to the point where when we said we could deliver something by a certain date, we could. I really don't see that very often, and it wasn't the case with all of the projects around us struggling with Waterfall. Again, it's not a panacea, but it can work and to discount something just because you don't understand it or have never actually done it is foolish.
My beliefs do not require that you agree with them.