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."
The greatest wisdom of agile (Score:2)
Architecture (Score:3)
e.g. say you have a team of people designing a new large building with an innovative design.
Re:Architecture (Score:4, Insightful)
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.
Re: (Score:2)
I think it can work if we only apply it to the process of designing the building i.e. getting constant feedback from the customer, instead of going out once and writing a full specification based on that. But maybe architects already do that.
Re: (Score:1)
But neither of those are architecture. Pouring concrete is building. Whether or not you use steel is structural engineering. Architecture is about the design of a building. What it looks like, how it's laid out.
Re: (Score:2)
At least here in Sweden, an Architect has to know at least some fundamentals of materials/structural engineering etc to be certified as an architect, it's not just about artistry.
Re: (Score:2)
Re: (Score:3)
Agile can work very well in architecture - it simply has to be private, small-scale architecture, on the scale of a house or on a neighborhood layout level. Check out the work of Christopher Alexander (who invented the concept of the pattern language, from which software patterns were derived). His early work emphasized organic growth of architecture over large-scale planning, use of local materials, and energy-efficient designs.
Re: (Score:2)
It'd probably work fine for the design phase, where you can make progressive changes, but obviously not for the whole project. If you use it for design, and then pass it over to engineering to ensure it's actually a structurally sound solution, say, at the end of each sprint, then you could probably benefit. Just make sure that you end the Agile portion of the project and check one last time that it's structurally sound before you pass it off to the builders.
Re: (Score:1)
Re:Architecture (Score:5, Funny)
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 [cactuschristian.org], thank you.
Re:Architecture ... Actually ... (Score:2)
Re: (Score:2)
What if... (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Re: (Score:3)
Re: (Score:2)
Responding to change is one of the major tenets of agile development. That flexibility comes in part from good design and thorough automated testing, as well as close collaboration with the customer and users.
Ideally in agile development, each iteration will create a new build of the software. If your development doesn't stop, maintenance is just a continuing set of iterations past whatever build you call "version 1.0".
Re: (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 t
Re: (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 contribut
Re: (Score:2)
It isn't just about propping up weaker programmers with stronger ones, though. Pair programming can serve to combat information consolidation, better insulating a team against the loss of individuals. It can also aid in training new team members, helping junior hires to grow as developers or simply getting a newly-hired senior developer up to speed.
Re: (Score:3)
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.
So the top individual contributors are tasked with two separate jobs: programming and training. I trust they get paid a lot more for this? Otherwise, they have every reason to "resent" this: They're being asked to carry everyone else, to do double duty, and getting nothing in return.
Re: (Score:1)
Actually, top individual contributors are tasked with two separate part-time jobs. So, no, they don't get paid a lot more for this. I suppose if they were working 80 hour weeks and truly doing two jobs then it might make sense to pay them more, but most Agile methods (including Scrum) include the important rule that everyone needs to work at a sustainable pace. Additionally, they aren't getting "nothing" in return: what they get is a team that quickly learns how to avoid dumb-ass errors so that the senio
Re:What if... (Score:5, Insightful)
Actually, top individual contributors are tasked with two separate part-time jobs. So, no, they don't get paid a lot more for this.
For some people, being tasked with two separate jobs is more stressful than being able to focus on one specific task. This is true even if the total hours are the same (and I'm rather skeptical that this is actually the case in practice).
Furthermore, the skills needed to be a good programmer are different from the skills needed to be a good trainer. Many of the best programmers aren't exactly very social types.
What you're doing is driving away and/or burning out your best programmers by making them do a job they probably don't want to do, aren't very good at, and essentially punishes them for their talent.
Re: (Score:2)
Re:What if... (Score:5, Interesting)
Re: (Score:1)
Since this seems to be addressed to me, but is arguing about something I didn't say, I'm not sure how to reply... can you clarify please where I unconditionally asserted "the need for a given practice or methodology"? Or perhaps alternatively, can you point out how what I have described "is a soulless, creativity sapping mess of ass covering."?
Re: (Score:2)
I can help here. You wrote:
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.
That's rather strong, isn't it?
Re: (Score:1)
Yes, it is strong. Do you disagree with my statement about surgeons? Assuming you do not, then think about it from my perspective: I've worked on several large-scale mission-critical software systems where I personally used most of the practices I listed. I have also seen others use these practices to the same degree. In every case, the results have been clear: zero-defect software is possible and can be done _faster_ than "normal" development. By "zero-defect" I mean that the handoff from development
Re:What if... (Score:4, Insightful)
So true. The biggest proponents of Scrum/Agile are the "instructors." It's just propaganda to make you think that Scrum really works. While it might look great to the MBAs and other execs, it just doesn't work in the real world, at least at any company that has a budget and wants to actually make a profit. I'm sure it would work beautifully on side projects, non-profit projects, etc... where you're not concerned about money, though.
Oh yeah, and a case in point on the GP's propaganda:
I no longer think of developers as professional if they fail to use these practices.
So, he resorts to telling programmers, basically, that they're not professional if they don't use Scrum. Trying to appeal to that person's guilt and shame. Sorry, but I don't fall for these "shame" tactics. Just a tactless, tasteless ploy to try and lure people to Scrum.
Re: (Score:1)
Actually, what I stated is that if you are using Scrum, you must also use the Agile Engineering practices to be successful and if you are not, then I do not consider you to be a professional developer.
If you aren't using Scrum, then I have no opinion about your engineering practices or your professionalism. I suspect that the engineering practices are valuable outside of a Scrum environment, but I don't have enough experience with non-Agile environments to be able to comment with any degree of certainty.
I get it... (Score:4, Informative)
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.
Re: (Score:2)
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.
Well, your opinion would be in direct opposition to the processes employed by NASA to reach insanely high code quality. I found an article from 1996: The Write the Right Stuff [fastcompany.com]. Although they do agree creativity is stifled, it does indeed result in better software.
And I, as a professional programmer, think there are certain _must_ practices. If you fail to do these things, you aren't doing a good job and you aren't acting as a professional (e.g. documentation, source code management, testing). For small triv
Re: (Score:1)
FWIW, adding staff to improve productivity is anti-Agile and no good Agile consultant, trainer, coach or ScrumMaster should recommend this course of action. Hopefully every single person who is in a position of "expertise" around Agile has read "The Mythical Man-Month" by Brooks and Martin Fowler's article about Scaling Agile. Both of these provide significant arguments against growing software teams/organizations to solve productivity problems.
Re: (Score:2)
Re: (Score:1)
At my (successful, multinational and rapidly growing) company we usually don't do pair programming, but every check-in has to be reviewed and approved by another developer. This works well, everyone has to do their bit and any sub-optimal code gets kicked back to be rewritten. Fear of looking like a code monkey tends to ensure people do it right the first time anyway. Generally any "did you think of X" insights from another developer's perspective come within 15 minutes of reading the case notes and your ch
Re: (Score:2)
So anyone who doesn't use pair programming is not being professional? It's unusual to hear tosh as unadulterated as that. Pair programming is useful only if you're employing newbs, idiots, or people otherwise unfit for the role you've given them.
Don't get me wrong, I consider multiple eyes essential. Quite the opposite. However, that kicks in during a process called "review", not "editing".
Re: (Score:1)
> I no longer think of developers as professional if they fail to use these practices.
So anyone who doesn't use pair programming is not being professional?
No: if you are using Scrum and if you are not using the complete set of Agile Engineering practices, then you are not being professional. Sorry if the context wasn't completely clear.
Re: (Score:2)
All I see there is religion. Only your way is the right way, just replace "professional" with "saved".
Re: (Score:3)
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.
Washing of hands is based on the scientific germ theory, which is backed by mountains of evidence.
Every buzzword you just listed is a mere whim. A preference. A particular style that works for some teams, and not others, mostly for mysterious and unknown reasons.
What you just said basically amounts to some priest admonishing a fellow man of the cloth for not properly anointing the bust of Christ with scented oil. He's doing it wrong, doesn't he know?
I've seen these software development fads come and go, and
Re: (Score:3)
Re: (Score:1)
Washing of hands is based on the scientific germ theory, which is backed by mountains of evidence.
You are right. I used an analogy. Although I can't claim that there is a scientific germ theory equivalent for the practices I listed, I can claim that I have mountains of evidence based on my own practice, the practice of my peers, and the converse, but the consequences of the lack of practice. At a broad level, this can be seen in the Standish Group's "Chaos Report" (e.g. from 2008) where Agile projects are more successful than all types of non-agile projects to a degree that has both business and stat
Re: (Score:2)
I can't claim that there is a scientific germ theory equivalent for the practices I listed...
I could skip replying to the rest of your comment, because you admitted my point, but you seem to have misunderstood my finer points, so I may as well...
First off, I understand TDD and I know the difference between TDD and Unit Testing. I love refactoring, and when IntelliJ IDEA was first released, I thought it was like the light of God shining down from heaven upon me. I've done pair programming. I get it. What I'm saying is that none of those can or should be applied without knowing when to apply them, wh
Re: (Score:2)
There was a study done at NCSU by Laurie Williams [agilesweden.com]. It showed that pair programming decreased errors, but took more overall effort to achieve similar functionality. Did the additional effort due to pairing work better than, say, additional effort put into code reviews? Who knows. It's very hard to compare these things. And that's the best study out there on the topic of pairing.
In reality, you're right - it's all pretty much snake oil. In the end, it's not process that saves your ass - it's the people on the
Re: (Score:2)
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).
Oh it's perfectly understood, but there's two issues:
1) It's never executed perfectly. There's always going to be some code that rely on some crazy behavior or some corner case that isn't documented by any test case and functionality will cease to work. The fact that you can go back and blame someone else for writing the shitty code and/or not making a test case doesn't change the fact that the code failed now, during your refactoring. That's what everybody who isn't reading the code will see, the customers
Re: (Score:1)
I didn't say they were unprofessional because they don't agree with me. In the organizations I work with, a quick poll shows that about 5% of developers have even tried TDD, etc. (That's a made-up statistic, by the way, but the order of magnitude is correct. I have actual data somewhere, but it's not handy since I'm in China with my office back in Canada.) I'm saying that there is a standard of conduct and results that most developers don't live up to (fact) and that if you look at other professions thi
Re: (Score:1)
I wish I had mod points to mod you _way_ up!!! Agile requires significant changes in behaviour and is extremely hard to do properly... That said, the results even with that effort are truly worth it.
Re: (Score:2)
I was thinking exactly the opposite - It seems to me that certain types of creative tasks simply do not lend themselves to lots of iteration and refinement... Writing, for example, tends to get worse the more people mess with it. I'm guessing that movie scripts are the same. Obviously there's room for improvement on most kinds of projects, but I just don't see how you do iteration on writing a story or building a jet engine... at least not iteration in the sense of progressive refinement and adding feat
OpenAgile for non-software (Score:2)
FWIW, OpenAgile [openagile.com] 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 pr
Oh, great... (Score:3)
...more Cult of Management techniques being inflicted on the world.
Management tool? (Score:2)
I do not use it as a management tool, rather, I use it more as a "patchwork" tool to facilitate easing of the workflow
Re: (Score:2)
...more Cult of Management techniques being inflicted on the world.
Managementology?
Re: (Score:2)
What do you expect? We're minting MBAs at a higher rate than ever. Those people need to go do something to prove that middle management is value added.
Scrum is not originally a software methodology (Score:5, Informative)
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. [wikipedia.org]
Re: (Score:1)
True enough... and often forgotten by organization that are adopting Scrum. Scrum is by far at its best when it is used for product development (software or otherwise) and if it is used in other situations (e.g. IT projects, operations, etc.) it needs to either be modified or its results won't be very impressive.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Yes, the NHS in the UK has used it for a number of projects for many years.
Re: (Score:1)
It's not a magic bullet. Simply a technique.
Creativity Killer (Score:3, Insightful)
Re: (Score:1)
Working in the game industry i found that creativity was heavily hampered by scrum, even after doing several adjustments to the process.
I have a totally different experience (I was working in the mobile phone business, which is kind of similar to the game industry you mention). I worked for two major mobile phone companies "doing scrum" from 2006 to 2011. It took me years to finally see the beauty of scrum really working in my team, and then I realized one important thing:
You can't do agile unless you really want to do agile and make an honest effort to do it "by the book". You can't make compromises and expect it to be "magical". You start
Me no get it. (Score:2)
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 [agilemanifesto.org], 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 A
Re: (Score:3)
Good software engineers will make things work be it with XP or Waterfall. Bad software engineers will fail regardless of methodologies.
This. A thousand times this.
I often feel like writing a watershed paper called "Software Methodology Considered Harmful". In the end, the people involved on the software team and how well they work together are the most important determining factor as to the success and/or failure of a software project. Process in organizations often exists as a way of trying to paper over
Sigh. Headline and TFS... so wrong. (Score:2)
Agile methods like Scrum and Kanban didn't even start in the software development field. They've been used in manufacturing for longer.
SCRUM stands for SCRrewed Up Management (Score:3, Insightful)
... especially when non-technical people are in charge of this process. One can't map short term deliverables properly to a creative process.
Maybe non-software projects is what it is good at (Score:2)
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 pro
My biggest problem... (Score:4, Insightful)
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.
Re: (Score:2)
The "Daily Stand-up" is a way to monitor the sprints progress and adjust the sprint accordingly to make sure the sprint goal is met at the end of the sprint. If someone is stuck on a task for a day, maybe he needs help. Also its harder to hide and do nothing for a week, telling the same bullshit story everyday gets old very quick. Agile is about team work and team's need to know what everyone is doing to meet a team goal.
From your comment I read you are a loner, you don't care what others are doing, you don
Re: (Score:2)
If someone's stuck and needs help, let him ask for help. If you have people on your team who hide and do nothing for a week, you should fire them.
As for meeting a team goal, if I agree to
Re: (Score:2)
If you want to monitor the sprint's progress, have people send status update e-mail to the project leader or have the project leader go around go around and ask people individually. S/he's the only one who should care. There's no reason to force everybody into a room at the same time even if it's only for 15 minutes.
E-mail? Whaaa, help! You mean everyone CCing me more bullshit. Not more e-mail, please! E-mail is really the biggest productivity killer ever, or is it PowerPoint?
If someone's stuck and needs help, let him ask for help. If you have people on your team who hide and do nothing for a week, you should fire them.
If life was only that simple. Often people are too proud to ask for help, they think they can find the solution themselves even if it takes them some more days.
Of course you fire the lazy fucks, but sometimes its hard to spot that some is not really productive, certainly if management has no clue what developers are doing.
I saw many small companie
Re: (Score:2)
You need to read more carefully. I wrote, "... have people send status update e-mail to the project leader ..." I never said anything about sending e-mail to everybody on the team, via Cc or otherwise.
FYI: My current project does weekly progress updates by e-mail (to the whole group, contrary to my suggestion). I filter all such e-mail since I couldn't care less.
Re: (Score:2)
I understood clearly, just wanted to illustrate why I don't like e-mail and why I do like short face-to-face updates.
Also just because you can't derive all the context you need from a text message as we noticed in this short comment conversation.
But I guess you couldn't care less. ;-) have nice weekend.
Re: (Score:2)
That's funny, I have always been curious about what everyone is doing, even operations and sales. I have found this knowledge extremely helpful for both my projects and my career.
Re: (Score:2)
In general, what problem(s), other than satisfying your curiosity, does having such knowledge solve? Please give concrete examples how such knowledge has actually helped you do your job or advance your career.
Re: (Score:2)
Well for one, I always know what is coming down the pipe so I could get my team and I on the juiciest projects and avoid the loser/death-march projects. I would also get called to do prototypes and demos so upper management became familiar with me, so it was easy to ask for large pay increases.
Exposure to OPS has increased my ability to troubleshoot environment issues.
Re: (Score:2)
As for doing prototypes: if you're a good developer, your boss will know it and call on your for special tasks. Your boss should be your champion. (More generically, a boss should be the champion of everyone under him/her.) If your boss isn't your champion, you need a new bos
Re: (Score:2)
You have a good view of how things should happen but that is not how the usually occur, at least from my POV.
I am sure there are other successful outlooks that work too this is just my personal experience.
Jobs program for the useless (Score:1)
Agile nothing new in other industries (Score:1)
Agile / Scrum method vs Brainstorming (Score:2)
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 ?
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:Agile / Scrum method vs Brainstorming (Score:4, Funny)
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 !!
Re:Agile / Scrum method vs Brainstorming (Score:4)
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 ?
Nice! (Score:2)
Very well thought out and informative. Thank you!
Re: (Score:1, Offtopic)
What a Scrumbag!
Re: (Score:1)
Re: (Score:1)
My hunch is that at least some of the GP's post was computer generated nonsense and subsequently edited. There is certainly some [newscientist.com] 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.
Re: (Score:3)
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 pr