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

The greatest wisdom of agile

[Cryacin]

Is understanding the difference between an estimate, and vision on a problem.

Agile / Scrum method vs Brainstorming

[Taco Cowboy]

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

[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:Agile / Scrum method vs Brainstorming

[Taco Cowboy]

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

[eulernet]

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 ?

Re:$10,000 CHALLENGE to Alexander Peter Kowalski

[knuthin]

What a Scrumbag!

Architecture

[TheLink]

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.

Re:Architecture

[Anonymous Coward]

I expect some parts of scrum would be 'ported' relatively easily. I think designs are already done in an iterative way, at least.

Re:Architecture

[Anonymous Coward]

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:Architecture

[sourcerror]

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:Architecture

[91degrees]

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.

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:Architecture

[hakey]

Pouring of concrete is analogous to software going to golden master. The architecture design effort that agile would apply to is everything that leads up to that point. Also architecture isn't just about making buildings that don't fall down, not every defect leads to jail time, some defects just mean the building isn't as nice as the client hoped for.

Re:Architecture

[Xest]

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:Architecture

[Anonymous Coward]

Going back far enough, the ad-hoc method of Architecture known as Gothic fits the bill. If a wall wasn't strong enough, they added flying buttresses.

While a building can be structurally sound after working for decades, they would fail at implementing contemporary features.

Re:Architecture

[Anonymous Coward]

In other words; the consequence of applying true agile methodologies to Architecture is likely to be well deserved jail time.

I think it would be used in the drawing / blue print phase of the building, either internally at the architects' offices or with the client.

A print with the client may be 1-2 weeks long where you'd come back and show the clients the kitchen/ducting/electrical drawings you did since the last meeting and get feedback for further revisions. Internally, you could have daily (?) scrums to look at any changes that have been drawn.

Once the blue prints are "done", you have to get them approved by the civil engineers and then the local municipality, after which you can't really change much—unless you go back to get re-approval for anything 'big' (i.e., more than moving a few light switches).

Re:Architecture

[K. S. Kyosuke]

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.

Re:Architecture

[Shinobi]

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:Architecture

[Anonymous Coward]

Right; and they had regular collapses. In those days workers were expendable. In exactly the way which wouldn't be accepted nowadays in most places.

Re:Architecture

[Anonymous Coward]

Oh sure; But this isn't agile; this is "waterfall". The entire thing which which separates agile from waterfall is the believe that you have to build the thing to test your plan. At some point you are just saying "wouldn't it be nice if we talked to each other regularly". If you think that that's a new "agile" wish then I have a bridge to sell you.

Re:Architecture

[Anonymous Coward]

Architectural Consultant here reporting for duty!

In commercial construction, the "design team" (Architects, Engineers, Consultants, etc.) have been working on the building for 1-5 years (or more... I've seen 15 years personally, and heard stories of decades) before site prep even happens. Often if it's a replacement building at a university or college, there's still a building on the site while we're designing everything.

The major milestones are thus:

Programming: Figuring out all the various purposes the building needs to serve, and how much space to allocate for that, and what spaces need to be next to each other.
Schematic design: "cartoon-level" design where you test fit all the parts together, and come up with a rough design for the exterior of the building
Design development: Taking the SD drawings and reports and refining them into a solid, constructable design. Usually doesn't include details, but you see the building come together here.
Contract documents/Construction documents: Final design of every element, down to bolts and finishes, to a biddable state.

The CD's consist of sets of drawings (a typical 1500-student high school has about 250-300 30"x42" sheets, and ~500-1000 pages of specifications) that are then published for contractors to bid on.

Anyway: the process of going from Programming to Contract Documents is of iterative design. You try things, see if they work for everyone else. If they don't, you restart. However, it's not a matter of actually constructing the building (outside of virtual models), it's a matter of designing the building.

Re:Architecture

[Anonymous Coward]

I am not sure agile methodologies would work with architecture. Agile was conceived as a set of tools to control empirical processes (imperfectly defined, unpredictable outputs). It fits with software development because the product owner usually doesn't know what he really wants until he/she sees a demo of the work in progress, therefore adjusting the tasks and priorities.

In architecture I think you have a very defined output (the finished design) and once you start pouring concrete you cannot change the location of pillars and windows anymore.

Re:Architecture

[mcclurg]

With the advancements in modeling, especially BIM, a team could look at the completed design and associated model as the product. These models are now getting advanced enough that the client could provide constructive feedback after using the model. With the current waterfall method, there is very little scope to feed back these issues to the design team, as they will move on to the next project immediately after handover. Or even better, the architects don't just throw the building over the wall to the structural engineers, but used Agile to work collaboratively with the structural, M&E services and other stakeholders to produce the final design/model. But the fundamental issue is these models and processes take more time up front, which means much higher design fees. Many clients will struggle to justify the expense. Until a financial payback is found to justify using Agile, I'm not sure if it will be viable.

Re:Architecture

[K. S. Kyosuke]

That's construction work what you describe, not architecture. And the "finished design" is more like finalized source code than the initial specification.

Re:Architecture

[Anonymous Coward]

I'd imagine that the precursors to agile (TPS and the like) are a better guide for the architectural field than the agile that's preached for software development. As software developers we can break and rebuild very liberally in ways that don't work in the physical world and we can experiment in ways that are much less costly than if a physical item needed to be produced.

Re:Architecture

[Anonymous Coward]

Agile didn't start in software. If it can work for designing automobiles, it can probably work for designing buildings.

Also, so much of the architectural process is done in CAD these days that you probably can apply agile principles to the design phase of the project while still having a finalized design long before you start pouring the concrete.

Re:Architecture

[Anonymous Coward]

This was a very early attempt.

http://images.travelpod.com/tripwow/photos/ta-00bd-789e-bde6/leaning-tower-of-pisa-1173-1373-florence-italy+1152_12916059992-tpfil02aw-28533.jpg

Re:Architecture

[frank_adrian314159]

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:Architecture

[Anonymous Coward]

Another example

http://www.wired.com/images/index/2008/12/tower_580x.jpg

Re:Architecture

[Anonymous Coward]

With digital models you can do agile in the early design stage with the customer. During the production of the final drawings for the permit process you have to make adjustments to fit with the requirements of the city planners and other stakeholders, like the valid complaints from the neighbors and engineering changes. After that, you have to make adjustments to the construction drawings for clarity, for risk management and for sudden changes which don't require another tour through the city planners. During the construction, you often have to make small changes and adaptations for building mistakes and other surprises, like changing suppliers. A scope of the whole project can significantly change anytime along the changing financial conditions. An agile environment is naturally spawned from these challenges.

Re:Architecture

[Anonymous Coward]

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.

I love how you set the tunnelling machine to "comedy goldmine", pointed it at the mountain, turned it on, and just stood back.

What if...

[MonoSynth]

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:What if...

[RD_Sid]

I think Agile is more of a "getting things done" sort of a methodology. It doesn't care what you're developing or how stable the thing will be. It just forces you to create and manage something which can't be created through a static set of rules. For e.g. you don't need Agile to assemble a car, it's all taken care of by machines. But you can apply Agile to the unprectictable areas, be it S/w, management, research etc.

Re:What if...

[bondsbw]

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:What if...

[under_score]

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:What if...

[Anonymous Coward]

I wish I had mod points for your comment.
All of these practices: refactoring, unittests, pair programming, continuous integration, ... This is what we need. These are some of the things making technology projects more professional.

Oh, how I wish everyone would support these practices in my company. However, there are some who even still argue 'automated tests are not needed, manual testing is all we need'.

Re:What if...

[Anonymous Coward]

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.

Re:What if...

[under_score]

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...

[Anonymous Coward]

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.

Amen.

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.

Re:What if...

[Anonymous Coward]

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 changeset, so unless it's a really complex issue I don't think the overhead of pair programming is justified.

We do everything else you list though, and I would agree all these practices are necessary for enterprise quality software.

Re:What if...

[under_score]

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:What if...

[fatphil]

Having had the misfortune of witnessing many different methodologies (a word that I hate - it's a nonsense word when used in that context, it is not a study of methods, it is merely a method), and a wide range of teams with varying experience, I think that Agile does have its uses. It's good for making sure that sloppy non-self-motivated people keep making progress. There's nothing software-engineering-specific in that, it would work just as well in a many contexts (such as producing a textbook with many authors, or even creating an album if you're a band like 60s/70s Pink Floyd). Of course, whilst the micromanagement would be annoying, more than objecting to that I'd rather not be working with such a team of sloppy and non-self-motivated people.

Re:What if...

[Anonymous Coward]

Software is completely different. You create it once and after the first release you have to support it for eternity.

According to an agile line of thinking, this premise is false. Instead you start with nothing, and then support if for eternity, in small increments.

What's wrong with a waterfall model of thinking is that when you do try to create it once as you say, you end with something suboptimal because you fixed the requirements/spec before you fully understood the problem - you deprived yourself from the ability to learn. If you have to support your early mistakes for an eternity, it's easy to see it's not the best approach.

If you're interested, I recommend The Design of Design by Fred Brooks, as he explains the best designers (in a very broad sense of the word) don't use a waterfall model, au contraire. He makes the case computer professionals should try to emulate the best designers, not the worst. :)

Re:What if...

[fatphil]

> 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? 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:What if...

[Anonymous Coward]

Agreed, I've worked on a couple of projects with extremely dogmatic scrum masters. We ended up doing scrum really well, but our delivery was awful.

Re:What if...

[bertok]

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 without exception they fail at being scientific, they fail at consistently achieving their goals, and eventually get replaced with a shiny new method which is just as un-scientific.

Okay, enough waffle, let me give you a concrete example: test-driven development. Sure, it sounds great. You write tests, they pass, and if you break something then the test will tell you. Except that it's not so simple:

- You can't predict unexpected problems.
- Expected problems aren't really problems, are they?
- Tests can give a false sense of security by reporting 100% success despite the prolific presence of bugs not tested for. This can result in major scheduling issues when the software fails unexpectedly.
- It is impossible to write quick & simple tests for a HUGE range of things one would most want to test for: ACID compliance, memory leaking, safe multi-threading, security, etc... Some of these things just have to be done exactly right the first time, like a maths proof.
- Tests take time to write. In many cases, doubling the amount of code written.
- Changes to the code like refactoring often require changes to the tests, potentially doubling the cost of maintenance.
- Tests are usually written in the same language as the code being tested. Gotchas with the language like Javascript's and PHP's "==" vs "===" are likely to be repeated in the tests too, leading to false results.
- Someone who doesn't know how to write code correctly probably won't know what tests to write to really put their code through its paces. Programmers who do know how to write code correctly, probably won't benefit quite so much from testing.
- Tests are most popular with developers using languages with weak built-in protections, like weakly-typed or dynamic languages. Where's the study comparing the relative merits of dynamic languages plus tests vs using a statically-typed language on its own? Nowhere.
- If a test fails for the wrong reason (badly written, test engine issue, etc...), then time may be wasted fixing a bug where none really exists.

That's just off the top of my head.

Now don't get me wrong, I'm not saying that test-driven development is bad -- far from it -- but what I'm saying is that it's not always the best approach, and NOBODY knows when it is or isn't the best approach. Neither you, nor anyone else, can give me a convincing argument of when it is right and when it isn't, because there is no evidence either way. There is no "theory" of project management that can be applied, like germ theory. There's just guesswork, and rules of thumb, and blind application of a rule that worked for one project to another where it may not actually apply. All I ever hear are anecdotes: "Oh, TDD worked great for my PHP website written by beginner programmers, you'd be an idiot not to use it". Meanwhile, I'm a veteran, write code in a safe and statically-typed language, and rarely if ever find bugs in my code after it ships. When I do, it's something obscure that tests would not find, like the incorrect use of case-insensitive collation in a SQL sort statement.

Same thing goes for refactoring, or pair programming, etc...

I've tried both. I like refactoring, but again, i

Re:What if...

[Anonymous Coward]

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.

And with that you've immediately alienated 100% of the programmers while working with said programmers is your job. Either you are making stuff up on the internet and this isn't really your job (what I'd expect) or you should look much closer to home for ineffective behavior. People are not unprofessional just because they disagree with you.

Re:What if...

[todrules]

Oh, "pair" programming! I always thought they were talking about "pear" programming. I was like, "WTF do pears have to do with programming?"

Re:What if...

[todrules]

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:What if...

[Kjella]

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, your project manager, your boss. And the universal reaction is not "How great that you found this bad code, the code base is much cleaner and better now" it's "Aaaaaaaaaaaargh stop breaking our product". It doesn't matter who wrote the shitty code, it's whoever flings it at the fan who gets the blame.
2) Because it doesn't provide any tangible functionality, it's entirely opaque to anyone else whether you're actually doing anything useful or even working at all. There are a lot of coders that just like to redo code perfectly usable code because they don't like the style or structure, like if the code was an art project in itself. Without a trust between the managers and the developers that when they say a refactoring is necessary it really is, it won't work because you won't be able to show it. You can show them the code, but they will never grok it. And the manager has to have the spine to say they need a break and not deliver things in order to keep delivering things, which isn't easy if he's got deadlines looming. Save your bacon today, hope for a miracle tomorrow is how all managers work.

Re:What if...

[Joey Vegetables]

I had a lot of trouble learning to do TDD well because for a long time I confused it with unit testing. They are related, and complementary, but separate disciplines, and it is best not to confuse them. The way I approach TDD right now is to try to gather testable (though not necessarily complete) requirements, write tests to verify them, design smaller components that will implement these requirements, write the tests and then implementation, and continue to divide the problem into smaller pieces until the implementation is complete. The unit tests validate the functioning of the individual components, but they do not drive the overall design; functionality tests do. The functionality tests tell you if you've broken something in a refactor or redesign or in whatever other way. The unit tests, ideally, help you to find the broken piece(s) quickly. Both kinds of tests help to ensure that your architecture and design is testable, and thus verifiable, and thus far less likely to break. Mocking can be used to simulate the behavior of other systems outside of one's control (e.g., databases, legacy systems, etc.), including error conditions these systems may encounter or errors connecting to them, so that the software within one's control can respond in an intelligent manner if things beyond it go wrong. I've been accused of being a TDD skeptic, and, indeed, I don't think it's appropriate everywhere, but it is broadly useful in many areas of software development and it helps to teach and enforce other good architecture, design and coding practices. Unit testing is great but it's only one component of TDD, and, often, much less important than comprehensive behavior and integration testing. It should still be done where possible, because seemingly small changes and refactorings can cause subtle breakage that the unit tests can catch quickly, especially if they are automated as they should be, possibly before an integration build is even attempted.

Re:What if...

[Anonymous Coward]

In my practice with software teams, I no longer think of developers as professional if they fail to use these practices

Your professional situation seems to demand that you do this, but it's not a particularly good viewpoint. Ironically, the advocates of 'Agile' generally demand that terminology be strictly applied even if they don't necessarily change the way people *actually* do work. I've seen 'requirements' change to 'user stories' with nothing more than the header on a document changing. I've seen status meeting invites get an 'information update' to change the title to 'scrum'. I've seen project plans basically do a search and replace of the word 'milestone' with 'sprint'. I've seen two types of outcomes from the change: nothing at all changes about the way the project is developed but the names to describe the process; a project wither and die because they at least embraced the defer uncompleted work to the next sprint to feel better about the fact they never got to release level product.

As a consequence, people evangelizing the way of 'Agile' make money for largely doing nothing. Projects managed well always have done elements preached in 'Agile' for the most port, it's just common sense with lots of words wrapped around it. People acting like before 'Agile' came along, the software development world was lost and Agile save it kind of piss me off.

Re:What if...

[Anonymous Coward]

...and what's wrong with agile is that software is built before the problem is understood and a solution can be designed. Its a lot of "hero" (and that isn't a good thing here) developers jump in and start building stuff. if buildings were built that way they'd be falling down all the time.

Re:What if...

[rmstar]

I'm not sure how to reply... can you clarify please where I unconditionally asserted "the need for a given practice or methodology"?

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:What if...

[ATMAvatar]

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:What if...

[Anonymous Coward]

Agile sounds excellent for Radio. It's a formalization of not planning ahead and working with blinders on.

Thing I like technology is the lack of "other peoples opinions" and having to convince people that I am right. I don't need to engage in long, drawn out debates, I can just build what I see and the evidence speaks for itself so I don't have to.

The area this falls down is not "how can it be achieved" but "what should be achieved". That is to say, Agile is a great way to take money from people who have power but no vision.

At the end of the day, I hate Agile, though I take the money and follow the process. I hate it because every day, it's made me just a little stupider than the day before. The quality of what I produce has dropped dramatically using this process, and I know it, and it makes me a little ashamed of myself.

Agile developers are hackers in the most pejorative sense of the word. You can't help but be reduced to hacking when you're not looking ahead any further than the next sprint.

Re:What if...

[Anonymous Coward]

That was quite insightful, wish i had not used up all my mod points before scrolling down to your post.

Re:What if...

[JDG1980]

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:What if...

[Anonymous Coward]

You are my hero. I've been on an extreme agile / scrum based project for 2 years now. We quintupled our staff and have done less than the previous year before the "scrum master" took over. There are countless meetings for collaborative stake and the junior programmers have just as much say as the leads and seniors - which makes it a constant process of explaining why certain things have to be certain ways. Has software quality gone up - yep undoubtedly - but the cost has been absolutely huge - going on 8 mil for 2 years with no real end in sight. Lastly, I too have always thought the velocity was miss-used - just like a "scrum" - that's a rugby term and doesn't match the purpose of what a stand-up is supposed to do. Software engineering is a skill - people who think they can read a couple books and become master craftsman of development are demented and counter productive to real work getting done.

Re:What if...

[Anonymous Coward]

The GP stating that if you're not using Agile/SCRUM then you aren't "professional" is nonsense but here's some things I would say about software development. Frequent milestones that track towards major releases are good, integrating QA with dev is good, frequent team communication about the progress on their work is good, high levels of involvement with customers is good (though sometimes frustrating). None of those things are unique to SCRUM, and not all of them are possible depending on your business/environment. In my experience you need *some* process, but the success or failure of the process is much more reliant on the quality of the team (including management) than it is on which process you're using. I've worked on waterfall teams that were successful and SCRUM teams that were abject failures. All of the right processes in the world won't save a bad team of un(der)-skilled workers. Good teams with any reasonable amount of process is likely to lead to development success. It's important to note that development success might still lead to business failure. These things just happen.

Re:What if...

[under_score]

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 senior person doesn't have to constantly fix idiots' work and instead can focus on the cool work.

Re:What if...

[under_score]

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 to QA, then to pre-production then to production all resulted in zero defects found over the course of, in one case, several years. Just to be clear, the software I'm talking about is distributed, high-availability, high-transaction rate, multithreaded software running on thousands of servers and in all cases delivered either on-time or early. If you can find specific examples of this level of quality and productivity without using the practices I list, then I stand corrected: it is possible to be a software professional without those practices.

Re:What if...

[under_score]

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.

Re:What if...

[under_score]

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:What if...

[JDG1980]

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:What if...

[under_score]

> 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:What if...

[under_score]

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 statistical significance. This data does not get to the detail of specific Agile practices, but instead provides broad stroke confirmation of the experiment with Agile in many organizations.

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 like your analogy, but like mine it does not constitute proof either way.

I've seen these software development fads come and go, and without exception they fail at being scientific, they fail at consistently achieving their goals, and eventually get replaced with a shiny new method which is just as un-scientific.

Okay, enough waffle, let me give you a concrete example: test-driven development. Sure, it sounds great. You write tests, they pass, and if you break something then the test will tell you. Except that it's not so simple:

I'm glad you picked this example because it is concrete and I can rebut most of your points:

- You can't predict unexpected problems.
- Expected problems aren't really problems, are they?

TDD doesn't claim to predict unexpected problems... rather it claims to prevent unexpected problems. TDD is not the same as unit testing. TDD is writing failing tests first then only building the absolute minimum amount of code to make the tests pass, then refactoring to clean up the code, then making sure all your tests still pass, and only then checking in your code and moving on. This means that full TDD results in 100% passing unit tests with full code coverage at all times.

- Tests can give a false sense of security by reporting 100% success despite the prolific presence of bugs not tested for. This can result in major scheduling issues when the software fails unexpectedly.

It is true that some bugs can still creep in even if every line of code is test driven as there can be unexpected interactions. This is why you also need ATDD, CI and Pair Programming. These practices are a system and while they have some value in isolation, their full value is only realized if all are done.

- It is impossible to write quick & simple tests for a HUGE range of things one would most want to test for: ACID compliance, memory leaking, safe multi-threading, security, etc... Some of these things just have to be done exactly right the first time, like a maths proof.

I have written TDD code which had ACID compliance (two-phase commits, journalling, high-availability including resistant to server failure), safe multi-threading (and admittedly this was challenging to use TDD for, but I did it), security (actually not that challenging for certain levels of security, but I am not an encryption expert so that dimension of security I don't have personal experience with). For me, the proof that your statement is incorrect is simply that I have seen these things done with a net positive impact on quality _and_ schedule.

- Tests take time to write. In many cases, doubling the amount of code writ

Re:What if...

[under_score]

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 this lack of conduct and results would be considered unprofessional (my opinion, but shared by many others who are concerned about software engineering). I hope to be incendiary so that developers wake up from their status-quo sleep and realize that they can actually do great work instead of releasing S##T to users and businesses who hate them for it. There are enough people interested in doing this that I charge mid-four-figures per day for my services. I'm definitely not making stuff up.

Re:What if...

[under_score]

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:What if...

[Anonymous Coward]

Consider:
1) "If you want these antibiotics to cure you rather than harm you, you _must_ take them according to the instructions."
2) "If you want to drive to work, you _must_ be sure your vehicle has enough fuel."

Those two statements are the exact form he used - "If you want the Scrum methodology successfully, you _must_ use the agile engineering practices that it prescribes."

He did not say, "If you want to develop software, you _must_ use Agile."

Your response is a typical overly-defensive shot from a developer who thinks that "writing software" is some sort of special art that only he understands how to do, and that "writing software" is some sort of amazing "creative" process, which will deaden your soul if you're not allowed to express the uniqueness of your individual special snowflake-ness. In short, it underscores exactly why software "engineers" are not "engineers" in any real sense of the word. As long as you continue to assert that your work and practices are some sort of unmeasurable, unknowable, indefinable "artistry," you will be looked down on by real engineers as nothing more than a pretentious keyboard jockey - in the same way that a "janitor" calling himself a "sanitation engineer" would meet with howls of derisive laughter. You want to be an engineer? Great, start behaving like an engineering discipline.

This "soulless, creativity sapping" argument is bullshit, and you know it - it's trotted out to justify ANY bad practice or bad behavior the keyboard jockey thinks he shouldn't have to change. (Do a search on soul & creativity in one of the frequent "boy hackers working with girls" articles here to see what I mean - apparently behaving professionally is also "soulless and creativity sapping" for these hackers.)

And I am a developer, too, and I've been working for nearly 20 years as a developer. I'm just so sick of hearing from over-promoted cowboys how "special" their process is and how "unique" their work is - it's NOT. Refusing to adopt standard practices is a result of your own insecurities and belief that you should be irreplaceable in an organization - and the best way to guarantee that is by asserting that your special artistry requires a special knowledge of special processes to write the software. I, for one, cannot wait for the time where people who make this assertion find themselves un-hirable.

Re:What if...

[frank_adrian314159]

There was a study done at NCSU by Laurie Williams. 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 team. Hire good people that work together well and it doesn't matter what process you use - you can pretty much throw them together in a room and they'll figure out how to give you what you want based on what they figure out about their own strengths and weaknesses.

Most process work is needed by companies who (a) don't want to do the hard work of hiring and compensating good people but (b) have to get software cranked out nonetheless. For those organizations, I'd just recommend picking something and then letting the local teams adapt - it's not going to make more than a 5% difference either way. Chances are, your issues are not at the engineering level anyway, but in places like HR, how much you want to pay people, or sales or product managers over-committing. In the final analysis, no amount of engineering process work is going to fix that stuff.

Re:What if...

[Josuah]

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. 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 trival activities these aren't necessary any more than a builder needs a blueprint or safety specifications for a dog house. But if you're building an office building you better include the necessary processes and cut out the "creativity" that might kill someone.

I do think there are two pressures that negate acceptance of the sort of process that NASA uses to produce such great software. The first is that it can be boring. Most people do not like their jobs to be boring, even if told that it's important. Other industries have regulations that require engineers to do boring work. Software developers are not subject to any such requirement unless the company mandates it (e.g. ISO9001). The second is that, unlike NASA, most software companies are competing for customers at a cost of time and money. And customers generally accept "good enough" software as long as it is cheap and available. Cutting corners to meet those demands is an obvious result, just like teachers cut corners to meet test requirements or banks cut corners to meet earnings expectations.

So I expect your opinion, produced from the varied experience in the tech sector you cited, is that the process gets in the way of you shipping and generating a profit. That's a valid argument. It is also valid to argue that many agile processes will not produce better software, when employed by some people. However I do not agree that a manager is unprofessional to mandate a process and fire employees who do not comply.

Re:What if...

[Anonymous Coward]

please - as a physicist this term misuse makes me want to commit violence - what are the units of a scrum's velocity exactly?

The units are story points. Velocity isn't about measuring how well a team is producing, it's about measuring how much they produce against their own estimates so that you can get a general idea of how much they can get done in a given amount of time based off future estimates. When developers give estimates that relate to time, they're almost always very wrong. Making abstract estimates and then correlating them with time based on past performance tends to be more accurate and lets people do more accurate planning.

Agile isn't about being able to produce more stuff faster. It's about being able to figure out how much you can get done and then getting it done so that you have the flexibility in planning to not waste time doing the wrong things. Velocity helps convert from developer estimates to actual time.

Re:What if...

[bertok]

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, which you can't do. I can't do it. Nobody can.

No amount of explanation of how a buzzword works will make my point invalid. It's still not scientific, and doesn't always apply. Until it is a science, it is snake oil, as far as I am concerned.

Go back in time a little bit. Remember when Object Oriented was the buzzword of the day? The purported advantages of OO sounded an awful lot like the advantages of popular project methodologies: OO would help prevent code breaking, because new code would not change existing working code. OO would help big teams work together by defining interfaces. OO would help encapsulate code to prevent bugs creeping in due to excessive cross-dependencies. Etc...

Now, go and tell Linus Torwalds that he's an idiot for using a non-OO procedural language on one of the biggest and most successful programming projects of all time. I'd love to see you have that conversation.

This is a lot like you saying that every programmer should be using Agile, even though there are enormous and wildly successful projects out there were produced without Agile.

I've heard more than a few anecdotes of Agile not working, and resulting in major problems. Sure you say, maybe they just didn't apply Agile the right way? Maybe they didn't get it? That's a lot like saying the priest just didn't pray hard enough, that's why his church was struck by lightning. He should pray harder! He should pray the right way! No? How about penance? Maybe even self-flagellate, see if that works?

This means that full TDD results in 100% passing unit tests with full code coverage at all times.

Code coverage != testing for everything that needs testing. That's one of my points.

Yes, or even tripling the amount of code. But if you still measure productivity in any relation (positive or negative) to lines of code written then I'm not sure we have much else to talk about.

There's an awful lot to talk about, because time is money. Tripling the LOC could send many projects over budget, and hence into failure. Just because the code passes tests, doesn't mean the project is a success. Which do you think businesses care about most?

Actually, refactoring (including test refactoring) is a significant part of the effort...

You misread what I said. I assumed refactoring is a given. Based on that, a TDD project will also require changes to the tests. A non-TDD will not, saving time. Some refactoring processes are 100% safe, and TDD just adds pure overhead. I'm thinking of the type of refactoring done by IntelliJ IDEA or Visual Studio, where the refactoring is automated and done on a statically typed language.

TDD is not unit testing.

It isn't, but it's a superset. I was talking about test-based development methodologies in general, not just TDD specifically.

I've used TDD with C++, Java, Objective-C, C and Pascal.

You've just named 4 unsafe languages, and one that has type erasure and is typically littered with casts from "object" which is functionally equivalent to "void*". Mmm... safe.

Try using C#, F#, Haskell, or a similarly modern languages with proper type safety, extensive use of templates, and higher-order programming.

Re:What if...

[Anonymous Coward]

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.

A good agile environment forces (yes forces) efficient cross training. If you are a manager, that's great, because if your top individual contributor quits, you can replace him with his junior counterpart. That, in my opinion, is job security. Expecially for their manager.

Re:What if...

[fatphil]

So if a bunch of wannabe-academics come up with a new methodology called the "Scrum-but-without-pair-programming" methodology, which contains everything from scrum except pair programming, and people buy into that, then even if they follow it rigorously, those followers wouldn't be "professional".

All I see there is religion. Only your way is the right way, just replace "professional" with "saved".

Re:What if...

[Instine]

http://en.wikipedia.org/wiki/Pseudoscience#Use_of_misleading_language My point: Use of objective, scientific terminology falsely affords a veracity to a given subject, in many pseudosciences. Scrum, in this sense, could be described as a pseudo science. The storypoint is not an objective unit. But velocity, in common parlance, is. You see a graph (a quantity/value based representation) of a scrum's 'velocity' and you have a certain warm feeling of empirical certainty/reliability. That something here was measured. But a storypoint is a quality not a quantity. The graph is meaningless. And I mean entirely meaningless. And it misleads the audience. Making them think quantitative facts have been reported. When actually subjective assertions have been manipulated and described in a quantifiable context. This is irresponsible. But gives the impression of being highly responsible. It misleads.

Re:What if...

[Anonymous Coward]

Velocity is a subjective measurement to begin with. Moving at speed x - relative to what? In direction Y - relative to what? Measurements become even MORE hinky at very high speeds (e.g., 2 objects moving away from each other at 0.99c.)

A story point is an estimated measure of effort that a given feature will require to implement. scrum velocity = "story points per sprint." If you want to get truly offended by it, you'd get upset over the fact that it's a *directionless* measure, so "speed (units/time)" rather than "velocity (units/time + direction of travel)" would be the appropriate term. But I guess when all you've had is Physics 1 & 2, you might forget those definitions in your haste to be pedantic, huh Junior?

Now stop being an obnoxious cunt. We get that you've had your feeling hurt by scrum somewhere in the past - stop acting like your objection is based on any rational thought process, you're simply issuing a knee-jerk reaction to somebody with a "new methodology" asking you to do things differently. It's upsetting to have your little comfort zone disrupted, we've all been there. Ranting about how "misuse" of a term makes you want to commit "violence" just makes you look like an idiot.

Re:What if...

[Anonymous Coward]

Don't waste your time trying to argue it here, Slashdot mostly has two types of developer now:

1) Complete amateurs who think they know something about software development, but as soon as they make a post make it clear they have zero experience, but swallow everything the following have to say without recognising they're swallowing outdated crap. These are also the ones that think PHP is a good language.

2) Grumpy old developers who failed to move with the times and think that C/C++ are the only languages anyone would ever need. They think Agile is useless because they are simply not Agile, they do not have the mindset for it, they are outdated in their ways. These are the people who also regularly complain about ageism and how people wont hire them because of their age, when in reality their age isn't the problem, it's their failure to keep up with technology.

The genuinely talented developers out there span all age ranges, so it's not fundamentally an age issue. The genuinely talented developers get Agile, they recognise that it's about moving software from a model of selling a product (which doesn't work, because change is too prominent in producing succesful software), to selling software development as a service which ensures the customer gets what they pay for. The genuinely talented developers are language agnostic, they'll work with whatever makes sense when they have the choice, or whatever they're forced to work with if they're tidying up one of the above's mess. Unfortunately, you'll struggle to find this final category on Slashdot, they're a rare breed here now, forced out largely by the prevalent idiot class consisting of the first two. This is precisely why on Slashdot there are hoardes and hoardes of people crying about outsourcing, ageism and so forth - none of these things are real actual problems if you're a competent developer.

Re:What if...

[Anonymous Coward]

Speak for yourself, we've completed plenty of Agile projects succesfully. We don't always use it but we use it where it makes sense, and in some situations it's actually been great for protecting profit.

Perhaps you've never worked in a client facing environment, but with a bad client, the classic development process goes something like this:

1) A spec is produced after all the analysis etc. is carried out
2) Some months pass as the product is developed, end product is shown to client
3) Client likes it for the most part, but has changed their mind about how something should work, either you bite the bullet and take the cost, or they submit a change request. Either way it costs one of you more, and it may well cost you more of the client has noticed that you didn't quite write a tight enough tech spec to defend yourself from it legally such that you're forced to eat into your profits or even make a loss to fulfil their change of mind.

Or, a naive client, being suckered in by a bad company:

1) A spec is produced after all the analysis etc. is carried out, a time estime is given
2) Company providing the software actually overquoted the time required by an order of magnitude, client grossly overpays. You may think this is their problem, but when they find out you face bad press, no repeat custom- they came to you because you're supposed to be professionals, not cowboys.

Scrum protects both parties, it means the client only gets what they pay for, and it means the provider only has to give what the client has paid for. If you think that somehow prevents you making a profit, you have a lot to learn about business, or, your business is just completely full of fail. If you're doing 2 week sprints then a scrum software project can only ever at worst go 2 weeks out of control (otherwise you're not actually practicing scrum), your client has visibility at the end of each sprint at worst (and if you're following best practice and are colocated with the client, or a rep from the client is colocated with you, they have visibility through the full project). This is in contrast to classic development paradigms where it can be months between visibility of the project, and the client may well have paid for a project that's ultimately of little use to them. You could argue that you get the client involved more often to avoid that, but at that point you're using Agile tenets anyway so you'd basically be admitting that Agile does actually have some merit even for you.

Most often though the real problem surrounding scrum complaints is that people practicing it and complaining about it are doing so in a half-arsed manner and don't actually know how to do scrum, they're just following some random steps. Also scrum requires your devs to be competent and transparent in your work, if you have shirkers, people who like avoiding responsibility for their failings, don't like to own up to problems etc. then yes, it wont work then either.

I don't really know what the answer is for people like yourself, your complaints against scrum don't even make sense, one of the major selling points of scrum is that it actually provides far better visibility on projects, and offers far more control over preventing it running out of control and hence inherently protects profits, so when people like yourself come up with profit arguments I can only guess that you don't actually know what scrum is, or haven't actually practiced it. It's not perfect, and it's not always the best solution for every project and every business circumstance (for small projects it has too much overhead sure, but if all your projects are that small then anything will work and scrum isn't trying to solve a problem you have, it's trying to solve ones you don't have, problems that only occur in larger projects than you deal with), but for most software development projects it's still better than the alternatives.

I agree scrum isn't easy to jump to, it takes a massive change in mindset for both the individual, the team, the company, an

Re:What if...

[patniemeyer]

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 features as in the agile software sense.

Re:What if...

[Anonymous Coward]

Sorry for the late comment. One question can be asked about a development methodology: does it reduce coupling in the system? It is claimed TDD does it. So is it claimed for the OO techniques. It is ultimately measurable and reducible to the basic, traditional concepts of modularity. A counter-acting tendency is the race for performance which tends to introduce strong coupling in the system. The fight is between the implementation of the functional and qualitative requirements, although these are often dependent of each other.

Re:$10,000 CHALLENGE to Alexander Peter Kowalski

[Anonymous Coward]

And your a cum guzzling gutter slut!

OpenAgile for non-software

[under_score]

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.

Oh, great...

[__Paul__]

...more Cult of Management techniques being inflicted on the world.

Re:Oh, great...

[Sulphur]

...more Cult of Management techniques being inflicted on the world.

Managementology?

Re:Oh, great...

[benhattman]

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

[jools33]

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.

Re:Scrum is not originally a software methodology

[under_score]

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:Scrum is not originally a software methodology

[multimediavt]

Neither is what is labeled Agile. Those techniques I learned in architecture school in the early 1990s. We just learned those techniques as how you get things done when designing for other people. No slick name for them. I suspect those techniques had been taught to architects (at the school I went to, anyway) for decades before I got there. Honestly, when I first heard of Agile software development a few years ago I looked it up and went, "Huh, those guidelines are the same 'common-sense' things they taught us in architecture."

Re:Scrum is not originally a software methodology

[biodata]

This. We were doing this stuff in software development in the 90s as well (large consultancy firms). Agile is just some marketing name for one way of doing things.

Re:Scrum is not originally a software methodology

[Xest]

Yes, the NHS in the UK has used it for a number of projects for many years.

Management tool?

[Taco Cowboy]

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:Management tool?

[Anonymous Coward]

"easing of the workflow".

All these buzzwords and their associated processes are just ways to make people pretend that easy things which they do badly are in fact complicated.

Scrum Agile NPR

[Anonymous Coward]

gotta go AC on this one...

I don't know about the radio programs it creates but I have seen the sotware it created and from a user perspective I can't think of a single good thing to say about it.

Re:Scrum Agile NPR

[91degrees]

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.

And in other news..

[Anonymous Coward]

Project costs due to increasing endless meetings and bureaucracy are sky rocketing.
Business owners rub their hands together as they leech blood from their clients making small european countries collapse into debt.
More at 11.

Programmers see agile is a lie; on to new suckers.

[Anonymous Coward]

Programming, Motherfucker Do you speak it?

Re:$10,000 CHALLENGE to Alexander Peter Kowalski

[todrules]

Did somebody forget to take their meds? Seriously, though, if you're writing shit like this, you need serious help, because that is a writing of a madman. You have a tenuous grasp on reality, at best. Please seek medical attention.

Creativity Killer

[mnt]

Working in the game industry i found that creativity was heavily hampered by scrum, even after doing several adjustments to the process.

Re:Creativity Killer

[asr_br]

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 making compromises, it stops working, plain and simple. The reality of the industry today is that a lot of people claim to be doing agile, but then you look closely and this is what they tell you:

- I'm using my bug tracking tool, because boards and papers are superfluous
- I still have my project manager (PM) around, because that's the way the hierarchy works in the company
- I don't need a Product Owner, the PM can do its job
- I don't need a dedicated scrum master, we can rotate developers to "conduct meetings"
- Estimating in points doesn't make sense for us, so we use hours instead
- Tracking velocity is too abstract, it never works
- I don't have testing together with the development because my QA team is in China
- 3x4h meetings every sprint? WTF? You expect my whole team to spend 12h in meetings at every interaction?
- ...

You want to do agile? Fire the product managers, hire secretaries to be scrum masters (computer background is a plus, but they're below the developers in the hierarchy) and put a UI designer or customer to be the product owner. And don't expect it to work on a distributed team: UI Designers, Developers and QA should attend all of the core meetings and should all work together in the same room or building. And doing it right is *HARD*. It took my previous team 2-3 years to "get it", but the results were awesome. Now I work as an Engineering Manager for an opensource company, doing upstream development... I don't have any expectation of ever implementing agile/scrum in my team, because I know it won't work in this scenario.

Agile, schmagile.

[Anonymous Coward]

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).

Re:Agile, schmagile.

[Anonymous Coward]

Bingo. Apparently scrum means "we have a big list of things to get done, and sometimes everyone has to work long hours to get them there".

Sorry, I thought that was called "a job".

Transfer of knowledge

[Anonymous Coward]

That's all it is. Ideas, knowledge, thoughts, images etc. I've been using Atlassian products in the transport industry for the last ~2-3 years and it has really taken off as a strong project management, auditing, accountability, collaboration, documentation and more importantly and strangely enough - a motivation tool.

Re:Transfer of knowledge

[TheSkepticalOptimist]

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.

Sigh. Headline and TFS... so wrong.

[astro]

Agile methods like Scrum and Kanban didn't even start in the software development field. They've been used in manufacturing for longer.

But...

[Anonymous Coward]

Is it webscale?

SCRUM stands for SCRrewed Up Management

[nickmdf]

... especially when non-technical people are in charge of this process. One can't map short term deliverables properly to a creative process.

Re:$10,000 CHALLENGE to Alexander Peter Kowalski

[MattBecker82]

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.

Re:Architecture ... Actually ...

[multimediavt]

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?

Nice!

[charnov]

Very well thought out and informative. Thank you!

Me no get it.

[luis_a_espinal]

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.

Re:Me no get it.

[frank_adrian314159]

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 the problems of not wanting to pay for decent practitioners or making a corporate culture that's so awful that no one decent actually wants to work for them. If you like methodologies, you generally like looking at people as functional units rather than people - and that's a problem in itself.

Maybe non-software projects is what it is good at

[TheSkepticalOptimist]

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.

My biggest problem...

[pauljlucas]

... 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.

Re:My biggest problem...

[Quazion]

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't work in a team.
I think you are doing something wrong if you think you work in a Agile environment, by just doing Daily's.

Still I wonder why you can't spend 15 minutes a day with your fellow colleagues. I seem to like social interactions...

Re:My biggest problem...

[avandesande]

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:My biggest problem...

[pauljlucas]

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.

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 a deadline, I'm going to make that deadline. If I think I'm going to be late, I bring it to my boss's attention. If everybody did that, we'd all meet the team goal.

I work in a team only insofar as there are other people in my company who are all working on the same product. Just as an example, I really don't care what changes the guy who works on the parser is making or what his progress is since his work does not affect me being able to do my job.

BTW: I never said I work in an Agile environment. I didn't specify what my environment is. It's irrelevant to my point. All I described was my biggest problem with Agile.

Re:My biggest problem...

[pauljlucas]

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.

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:My biggest problem...

[avandesande]

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:My biggest problem...

[pauljlucas]

Knowing what coming down the pipe doesn't sound like the kind of information you get at Daily Stand-ups. Daily Stand-ups should only be about what everyone is currently doing, not what management has decided for the near-term future.

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 boss.

Alternatively, nothing prevents you from talking to your boss whenever you please. Bosses should have an open-door policy.

In short, there are other (better) ways to accomplish what you want without needing anything so mind-bogglingy boring and a waste of most people's time as a Daily Stand-up.

Re:My biggest problem...

[avandesande]

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.

Re:My biggest problem...

[Quazion]

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 companies where developers (or other personal) are telling their boss, this and that, and thus and so. But in the end they deliver nothing.
This is an issue with the managers, just trying to saying its not so easy as you describe. Shame it isn't, but it just isn't.

BTW: I never said I work in an Agile environment. I didn't specify what my environment is. It's irrelevant to my point. All I described was my biggest problem with Agile.

True, I am really sorry.

Re:My biggest problem...

[pauljlucas]

E-mail? Whaaa, help! You mean everyone CCing me more bullshit. Not more e-mail, please!

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:My biggest problem...

[Quazion]

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:$10,000 CHALLENGE to Alexander Peter Kowalski

[Anonymous Coward]

Also, curiously, the style reminds me a little of the text of OT III.

Not surprising given the mental history of that author. :)

As mentioned by another AC up there, the troll in question is actually a pretty well-executed mashup of APK's style with the word salad of Gene Ray's Time Cube.

(APK doesn't appear to be schizophrenic, merely obsessed with HOSTS files. Kinda sad; I like HOSTS files, I use 'em for the same purpose he does, the differences is I know it's an inelegant and imperfect solution. He's done more to discredit the use of HOSTS files than anyone in the "do it right and set up a firewall" crowd ever could. Gene Ray, on the other hand... :)

Long as we're going down the rabbit hole, for an unrelated example of word salad consistent with schizophrenia, check out Gabrielle Chana, who made Fark yesterday. Some sort of reincarnation of Catherine the Great, telepathic wife of Vladimir Putin and Brent Spiner (yes, "Data" from Star Trek), and yes, something even weirder about the Jesuits. Mental illness isn't pretty, but it can be pretty amusing.

Jobs program for the useless

[yt8znu35]

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 get it...

[gosand]

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.

What Agile Scrum means to me.

[Anonymous Coward]

    In my experience as a dev Scrum/Agile means working with a large team of poorly skilled, poorly motivated devs (offshore and H1 B), fixing and debugging thousands of lines of crap copy and pasted code, and spending every evening on a SCRUM call. I consider these working conditions unacceptable. Now if I see an opening mention Agile or SCRUM I consider that a red flag, and will not entertain such a position. The advent of Scrum/Agile combined with the excessive use offshore teams and H1B developers has degraded working conditions at the companies that use these methods to the point where I will not consider working for these companies anymore.

Agile nothing new in other industries

[pandymen]

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.

We used Scrum to plan our wedding.

[Anonymous Coward]

The wife and I are both in the industry, so it was only natural. It was a pretty big wedding, and we were able to pull it off without any wedding planners.

Car companies are catching on.

[Anonymous Coward]

Looks like Toyota is getting on the bandwagon. They are stealing all these Agile ideas and reinventing them. They call it 'lean' or something