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."
Is understanding the difference between an estimate, and vision on a problem.
Science advances one funeral at a time- Max Planck
I am adapting some principles from the Agile / Scrum method in managing my business
However, I find that in our monthly brainstorming sessions - the traditional brainstorming way still generates more leads than the Agile / Scrum method
Anyone have any experience to share ?
Muchas Gracias, Señor Edward Snowden !
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.
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.
FWIW, OpenAgile was designed for non-software agile use including management, sales, marketing, operations, etc. and there are some very interesting uses out there. I'm on the board of directors for the OpenAgile Center for Learning so I'm a bit biased, but I strongly recommend this approach to any organization or team that wishes to improve effectiveness. I think it's very exciting that Agile is spreading beyond software, but there are also many challenges. In particular, Scrum is really best for new product development and many practices are not applicable outside that environment.
Helping with organizational effectiveness is our job.
...more Cult of Management techniques being inflicted on the world.
worldmobilenet.com -- World Prepaid Wireless Internet plans
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.
I do not use it as a management tool, rather, I use it more as a "patchwork" tool to facilitate easing of the workflow
Muchas Gracias, Señor Edward Snowden !
I've worked on an award winning video game that used agile. Also a turkey that did.
It's not a magic bullet. Simply a technique.
Working in the game industry i found that creativity was heavily hampered by scrum, even after doing several adjustments to the process.
Agile methods like Scrum and Kanban didn't even start in the software development field. They've been used in manufacturing for longer.
... especially when non-technical people are in charge of this process. One can't map short term deliverables properly to a creative process.
My hunch is that at least some of the GP's post was computer generated nonsense and subsequently edited. There is certainly some superficially convincing computer generated nonsense out there, and plausibly some of this post this could have come from a similar algorithm using a more vitriolic set of training text - just seems to have that kinda feel.
Also, curiously, the style reminds me a little of the text of OT III.
What's old is new again, just with a different name. We were using what is now being referenced as Agile and Scrum techniques in the creative world (1990s architecture and art curriculum) long before the CS geeks discovered them and renamed them to try and make them new and exciting. We just called it "the way you get things done when designing for someone else." I have been applying those problem solving techniques in everything I do for years, since deciding architect was not the career for me after getting the degree. The practices are sound and when managed well help to keep projects on track and yet flexible to last minute changes (have you ever worked with a home designer?). I just wish they would ditch the names as with any process that involves best practices and continuous change a label for one set of practices quickly becomes outdated. Why not just call them development best practices with a version or date (kind of like BOCA codes and graphic standards in architecture) and trade in new ones as they arise? That way you're not stuck with a silly name and trying to explain why the old techniques aren't Agile (or Scrum) and the new ones are. Or just Agile 2.0, or something. But then some governing body would have to be formed and approve it. Then the back biting and infighting begins over what is best ... Maybe this is why I am going back to the creative world?
Very well thought out and informative. Thank you!
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
To me agile is just the latest buzzword. When I started my career then years ago it was "extreme programming". My first team claimed to be using it despite no pair programming or other practices I would associate with it.
To me "agile" is the way that many in house systems have been developed for years. It is only recently that the word agile has been applied to them (lets face it, almost everyone claims to be using agile these days).
My current work is to develop and maintain the in house database system used my a high throughput sequencing centre. We don't officially use agile, but looking at the agile manifesto http://agilemanifesto.org/principles.html, the way we work conforms to most of the principles laid out here. Regular frequent meetings, getting the software into the hands of users as soon as possible, frequent feedback, adapting to changing requirements. I haven't changed the manner in which I work over the years, but now I seem to be doing "agile" (more or less).
Bro, the agile movement (or buzzword) is almost as old as the XP movement (or buzzword.) "Extreme Programming Explained" was published in 1999 while the first Agile Manifesto draft was written in 2001, attempting to encompass similar methodologies of the vert late 80's and early-to-mid 90's. Back in 95, people were already (and rather empirically) were implementing lightweight methods moving away from rigid variations of iterative/spiral models (or waterfall if you were unlucky.)
Not sure how you can say Agile is the latest buzzword if you started your career at the dawn of XP.
Also, whether they are buzzwords or actual methodologies, that depend on the practitioner. I've seen people saying they are agile because they have no process or even source control. "Who cares about that, code and deploy directly on production. We are Agile!!!" At the other side of the spectrum, you have fundamentalist Agile-libans for whom they need to do every single religious step of Agile or XP regardless of the circumstances, like forcing people into pair programming irrespective of work culture.
In both cases, Agile (and XP) are just buzzwords, one for justifying shitty work, and the other to subordinate work objectives to mindless following of magical mantra.
Real software engineers do trade-offs, choices, pick stuff that work, and drop those that are not applicable. I've never seen effective Agilistas/XP practitioners that use every single thing in their manifestos just because.
Good software engineers will make things work be it with XP or Waterfall. Bad software engineers will fail regardless of methodologies.
The idea that you can mitigate the effects of changes to requirements by re-prioritizing features to meet a fixed deadline is a MYTH. I would claim it an epic lie.
You see, most companies have these people in a field called "Sales" and "Customers". People in "Sales" speak with "Customers". "Customers" ask for features, "Sales" promises those features, the product is often sold before the product is released and a release date gets fixed in the future. Code monkeys then have to add the features to the product, under stress and often under duress.
There is no concept of re-prioritization. "Sales" already promised N number of features in the product, the "Customer" already paid for (or will pay for) N number of features, so to pull out features to meet a deadline is simply unheard of in the cultures of "Sales" and "Customers".
The only projects I have seen succeed in an Agile environment are projects that the company does not care about. Side projects, pet projects, research projects, whatever. The only reasons why these projects can work in Agile is because they are 100% in the culture of developers. "Sales" often don't know these projects exists and so have no vested interest in trying to push them to "Customers", therefore there are no promises for features and therefore changes to requirements are rare.
The reality is that the moment a company ("Sales") knows about and cares about a product, its doomed.
Agile is a lie used to give project managers a false sense of purpose. A good project manager, regardless of whatever scheduling tool they use, will keep a project on course. Agile was invented for bad project managers and bad development teams to try and reduce the time spent on the eventual release of bad software.
Companies need to invest more in hiring good people rather then adopting bad project management processes.
I haven't thought of anything clever to put here, but then again most of you haven't either.
... 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 hate that expression with a passion.
What it means is that instead of a team of highly focused and specialized developers that are all skilled in specific areas of the project, you end up with jacks-of-all-trades that are mediocre in all areas.
"Transferring" knowledge, doing it properly, constitutes a significant amount of overhead simply to have another developer take over a task and do it poorly.
If you have already invested time and energy to investigate and work on a specific problem or feature in a product, why on earth should you hand it over to another developer during the next sprint? The only reason given is that if one developer becomes ill, or sick, goes on vacation, leaves the company, or dies, then the knowledge is contained by the team and so the project can continue on unencumbered by your demise. I mean, what a cold hearted process to assume you mean nothing to the company that your absence will not affect the outcome of a quality product? How is that motivational?
It should not take long for a good developer to ramp up in any given area of a product and I would claim it takes less time for a developer to become "specialized" in an area of a product, and results in better code, then the time wasted trying to spread and maintain the knowledge across the team during development on the off chance that someone might die unexpectedly.
I am not saying all developers should work in a fortress of solitude, never exposing their work until they are complete. Periodic updates (NOT DAILY) can go a long way to ensure that developers keep on track AND other developers are aware of what is going on and even become interested in other areas of the product, but in general the concept of Transfer of Knowledge is bullshit.
I hate daily stand ups because the reality is that most people really don't care what other developers are doing. Often these stand ups run long and get mired in details between specific people and all I keep thinking is that its taking time away from me completing my tasks, so its not a motivational tool, and what knowledge I am gaining will not help me in any way if I should need to take over an area of development. And believe me, I have taken over from other people in different areas of the code, and never found it detrimental to not be intimately aware of that area right away.
There is a quantity of overhead associated with Agile, and where I worked using it, it was upwards to 30 -40% of my time was invested in process NOT development.
So maybe Agile is better for non-software related projects that have generally less requirement for focus and skill in specific areas of a project, but for software Transfer of Knowledge is another myth and lie about Agile that needs to be squashed as a software development process.
I haven't thought of anything clever to put here, but then again most of you haven't either.
After working at several companies that use Agile/Scrum, my experience has been that Agile is a great way to stuff a company's ranks with non-contributors.
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.
Agile/Scrum is nothing new in other industries. I work in the engineering consulting business. We often have teams of 100+ engineers from multiple disciplines working on one project. When my programmer buddies explained what scrum was, it was very similar to the methods we use to run projects.