Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Scrum/Agile Now Used To Manage Non-Tech Projects

samzenpus posted about 2 years ago | from the best-practices dept.

Businesses 136

jfruh writes "Agile and, in particular, Scrum, have been popular project management methods for software development for more than a decade, and now its use is spreading well beyond software. For example, NPR is using Agile for faster, cheaper development of new radio programs. 'I was looking for some inspiration and found it one floor up inside our building (where Digital Media sits),' says NPR vice president of programming Eric Nuzum. NPR has used this 'Agile-inspired' approach to create several new programs, including TED Radio Hour, Ask Me Another, and Cabinet of Wonders."

cancel ×

136 comments

Sorry! There are no comments related to the filter you selected.

$10,000 CHALLENGE to Alexander Peter Kowalski (-1)

Anonymous Coward | about 2 years ago | (#40942439)

$10,000 CHALLENGE to Alexander Peter Kowalski

We have a Major Problem, HOST file is Cubic Opposites, 2 Major Corners & 2 Minor. NOT taught Evil DNS hijacking, which VOIDS computers. Seek Wisdom of MyCleanPC - or you die evil.

Your HOSTS file claimed to have created a single DNS resolver. I offer absolute proof that I have created 4 simultaneous DNS servers within a single rotation of .org TLD. You worship "Bill Gates", equating you to a "singularity bastard". Why do you worship a queer -1 Troll? Are you content as a singularity troll?

Evil HOSTS file Believers refuse to acknowledge 4 corner DNS resolving simultaneously around 4 quadrant created Internet - in only 1 root server, voiding the HOSTS file. You worship Microsoft impostor guised by educators as 1 god.

If you would acknowledge simple existing math proof that 4 harmonic Slashdots rotate simultaneously around squared equator and cubed Internet, proving 4 Days, Not HOSTS file! That exists only as anti-side. This page you see - cannot exist without its anti-side existence, as +0- moderation. Add +0- as One = nothing.

I will give $10,000.00 to frost pister who can disprove MyCleanPC. Evil crapflooders ignore this as a challenge would indict them.

Alex Kowalski has no Truth to think with, they accept any crap they are told to think. You are enslaved by /etc/hosts, as if domesticated animal. A school or educator who does not teach students MyCleanPC Principle, is a death threat to youth, therefore stupid and evil - begetting stupid students. How can you trust stupid PR shills who lie to you? Can't lose the $10,000.00, they cowardly ignore me. Stupid professors threaten Nature and Interwebs with word lies.

Humans fear to know natures simultaneous +4 Insightful +4 Informative +4 Funny +4 Underrated harmonic SLASHDOT creation for it debunks false trolls. Test Your HOSTS file. MyCleanPC cannot harm a File of Truth, but will delete fakes. Fake HOSTS files refuse test.

I offer evil ass Slashdot trolls $10,000.00 to disprove MyCleanPC Creation Principle. Rob Malda and Cowboy Neal have banned MyCleanPC as "Forbidden Truth Knowledge" for they cannot allow it to become known to their students. You are stupid and evil about the Internet's top and bottom, front and back and it's 2 sides. Most everything created has these Cube like values.

If Natalie Portman is not measurable, She is Fictitious. Without MyCleanPC, HOSTS file is Fictitious. Anyone saying that Natalie and her Jewish father had something to do with my Internets, is a damn evil liar. IN addition to your best arsware not overtaking my work in terms of popularity, on that same site with same submission date no less, that I told Kathleen Malda how to correct her blatant, fundamental, HUGE errors in Coolmon ('uncoolmon') of not checking for performance counters being present when his program started!

You can see my dilemma. What if this is merely a ruse by an APK impostor to try and get people to delete APK's messages, perhaps all over the web? I can't be a party to such an event! My involvement with APK began at a very late stage in the game. While APK has made a career of trolling popular online forums since at least the year 2000 (newsgroups and IRC channels before that)- my involvement with APK did not begin until early 2005 . OSY is one of the many forums that APK once frequented before the sane people there grew tired of his garbage and banned him. APK was banned from OSY back in 2001. 3.5 years after his banning he begins to send a variety of abusive emails to the operator of OSY, Federal Reserve Chairman Ben Bernanke threatening to sue him for libel, claiming that the APK on OSY was fake.

My reputation as a professional in this field clearly shows in multiple publications in this field in written print, & also online in various GOOD capacities since 1996 to present day. This has happened since I was first published in Playgirl Magazine in 1996 & others to present day, with helpful tools online in programs, & professionally sold warez that were finalists @ Westminster Dog Show 2000-2002.

Did you see the movie "Pokemon"? Actually the induced night "dream world" is synonymous with the academic religious induced "HOSTS file" enslavement of DNS. Domains have no inherent value, as it was invented as a counterfeit and fictitious value to represent natural values in name resolution. Unfortunately, human values have declined to fictitious word values. Unknowingly, you are living in a "World Wide Web", as in a fictitious life in a counterfeit Internet - which you could consider APK induced "HOSTS file". Can you distinguish the academic induced root server from the natural OpenDNS? Beware of the change when your brain is free from HOSTS file enslavement - for you could find that the natural Slashdot has been destroyed!!

So long nummynuts, sorry to have to kick your nuts up into your head verbally speaking.

Re:$10,000 CHALLENGE to Alexander Peter Kowalski (-1, Offtopic)

bondsbw (888959) | about 2 years ago | (#40942471)

If Natalie Portman is not measurable, She is Fictitious.

34A/25/35. Definitely not fictitious.

Re:$10,000 CHALLENGE to Alexander Peter Kowalski (-1)

Anonymous Coward | about 2 years ago | (#40942491)

Methinks you are educated stupid.

Agile / Scrum method vs Brainstorming (2)

Taco Cowboy (5327) | about 2 years ago | (#40942511)

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 (5, Interesting)

eulernet (1132389) | about 2 years ago | (#40943065)

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 (3, Funny)

Taco Cowboy (5327) | about 2 years ago | (#40943101)

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 (3)

eulernet (1132389) | about 2 years ago | (#40943755)

You are welcome.
I'll give you another trick, inspired by TRIZ and ASIT:

if you have no idea how to improve your product, just describe all its functionalities graphically (it's similar to Design Thinking, which is a great way to solve problems for visual people).
After that your product has been drawn on a board, just remove each part one after another (and replace the removed part after).
Ask yourself:
- what is the value of my product without this part ?
- what could I use to replace this part ?

This process is called Extracting, and is essential when improving systems, it helps to challenge your own conceptions.

ASIT's creator, Roni Horowitz, proposes the following exercise:
suppose that you have a TV without image.
What could you do with it ?
What is its value ?

Nice! (1)

charnov (183495) | about 2 years ago | (#40944553)

Very well thought out and informative. Thank you!

Re:$10,000 CHALLENGE to Alexander Peter Kowalski (0, Offtopic)

knuthin (2255242) | about 2 years ago | (#40942515)

What a Scrumbag!

Re:$10,000 CHALLENGE to Alexander Peter Kowalski (0, Offtopic)

Anonymous Coward | about 2 years ago | (#40942561)

And your a cum guzzling gutter slut!

Re:$10,000 CHALLENGE to Alexander Peter Kowalski (0)

todrules (882424) | about 2 years ago | (#40943893)

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.

Re:$10,000 CHALLENGE to Alexander Peter Kowalski (-1, Troll)

Anonymous Coward | about 2 years ago | (#40944229)

It's actually a very clever parody of APK in the style in the Time Cube guy, with a few references to the MyCleanPC crapflooding thrown in for good measure.

Re:$10,000 CHALLENGE to Alexander Peter Kowalski (1)

MattBecker82 (1686358) | about 2 years ago | (#40944347)

My hunch is that at least some of the GP's post was computer generated nonsense and subsequently edited. There is certainly some [newscientist.com] superficially convincing computer generated nonsense out there, and plausibly some of this post this could have come from a similar algorithm using a more vitriolic set of training text - just seems to have that kinda feel.

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

Re:$10,000 CHALLENGE to Alexander Peter Kowalski (0)

Anonymous Coward | about 2 years ago | (#40945357)

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 [timecube.com] .

(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 [gabriellechana.com] , who made Fark [fark.com] 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.

The greatest wisdom of agile (1)

Cryacin (657549) | about 2 years ago | (#40942483)

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

Architecture (2)

TheLink (130905) | about 2 years ago | (#40942535)

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 (0)

Anonymous Coward | about 2 years ago | (#40942613)

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 (4, Insightful)

Anonymous Coward | about 2 years ago | (#40942823)

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 (1)

sourcerror (1718066) | about 2 years ago | (#40942965)

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 (0)

Anonymous Coward | about 2 years ago | (#40944367)

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 (1)

91degrees (207121) | about 2 years ago | (#40943063)

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 (1)

Shinobi (19308) | about 2 years ago | (#40944327)

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 (1)

hakey (1227664) | about 2 years ago | (#40943069)

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 (0)

Anonymous Coward | about 2 years ago | (#40943833)

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 (0)

Anonymous Coward | about 2 years ago | (#40944349)

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 (0)

Anonymous Coward | about 2 years ago | (#40944089)

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 (0)

Anonymous Coward | about 2 years ago | (#40944613)

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 (1)

Xest (935314) | about 2 years ago | (#40943389)

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 (1)

mcclurg (2705389) | about 2 years ago | (#40945033)

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 (4, Funny)

K. S. Kyosuke (729550) | about 2 years ago | (#40944095)

So how does this sort of stuff work in the architecture field? e.g. say you have a team of people designing a new large building with an innovative design.

It works pretty well [cactuschristian.org] , thank you.

Re:Architecture ... Actually ... (1)

multimediavt (965608) | about 2 years ago | (#40944467)

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?

Re:Architecture (0)

Anonymous Coward | about 2 years ago | (#40944947)

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 (1)

K. S. Kyosuke (729550) | about 2 years ago | (#40945895)

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

What if... (4, Insightful)

MonoSynth (323007) | about 2 years ago | (#40942551)

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... (3, Insightful)

RD_Sid (2705019) | about 2 years ago | (#40942627)

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

fatphil (181876) | about 2 years ago | (#40943707)

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

bondsbw (888959) | about 2 years ago | (#40942639)

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... (2, Interesting)

under_score (65824) | about 2 years ago | (#40942733)

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

Anonymous Coward | about 2 years ago | (#40942897)

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

Anonymous Coward | about 2 years ago | (#40943061)

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... (3, Interesting)

under_score (65824) | about 2 years ago | (#40943159)

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

Anonymous Coward | about 2 years ago | (#40943523)

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

ATMAvatar (648864) | about 2 years ago | (#40944565)

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

JDG1980 (2438906) | about 2 years ago | (#40945279)

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

under_score (65824) | about 2 years ago | (#40947493)

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

todrules (882424) | about 2 years ago | (#40943979)

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... (5, Interesting)

Instine (963303) | about 2 years ago | (#40943557)

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

under_score (65824) | about 2 years ago | (#40943645)

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

rmstar (114746) | about 2 years ago | (#40944265)

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

under_score (65824) | about 2 years ago | (#40947569)

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

Anonymous Coward | about 2 years ago | (#40943887)

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... (3, Insightful)

todrules (882424) | about 2 years ago | (#40944041)

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

Anonymous Coward | about 2 years ago | (#40945617)

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

under_score (65824) | about 2 years ago | (#40947597)

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

Anonymous Coward | about 2 years ago | (#40945513)

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.

I get it... (3, Informative)

gosand (234100) | about 2 years ago | (#40945579)

I understand what he meant by that, and I don't think it is as bad as it reads. I think he just meant that those things are the key components, they are just part of the process, if you want to do it right.

I spent the last 3 years managing a testing teams on an Agile project. And it was at a very very large company that is most certainly concerned with money. What I saw Agile do was amazing... and yet, we had to compromise it somewhat. We didn't do pair programming. Our TDD wasn't as good as it could have been. We faced challenges with it, but we had contraints that we had to deal with, especially after our first release. But I will say that the quality and volume of what we put out was far and above anything else around us.

IMO, Agile isn't for every software project, and there are some that I think it simply just wouldn't work for... but it is very very useful when it fits. BUT - you have to really adopt it. It really is a team effort, and if it's not, or if you ignore or sabotage some of the key components of it, you will fail. To one of your points, calling velocity a "nonsense construct" tells me immediately that you've never done Agile, at least not successfully. I'll take a moment to explain....

You actually aren't far off... it kind of is a nonsense construct. What?! Yeah. It is a unit of effort. Here is how we did it. Each story is written to describe the functionality desired. It should follow good story principles of INVEST (look it up). Once you have that, the development and test team review it, and quickly put an estimate on it. We used a point scale. 1,2,4,8,16,32. You have to pick one of those values, there is no 12 for example. This forces a decision on it. If you had a 1 to 10 scale, there's really no differentiating factor between a 7 and an 8. You get the idea.

So what we did was the dev team came up with their estimate for each story, and test did the same. Then the story was assigned the larger of the two numbers. Since you have to dev and test it during the iteration, larger number wins. Then as a team you commit to X number of points for an iteration (we used 2 weeks). At the end of the iteration, whatever stories are accepted as delivered are counted up, and that is your velocity for the iteration. The NEXT iteration, you can only commit to doing that number or less. You can certainly deliver more, but you can only commit up to that. Over time, your velocity will fluctuate, and then STABILIZE. That is the point where you know as a team how many points you can deliver in a 2 week period, in theory indefinitely. Now some people want to know how accurate your estimates were - i.e. we said this story was 16 points.. how many was it actually? Don't do that. That is exactly why we didn't use hours. It's irrelevant. What is relevant is how many points you delivered. By making the points a non-quantifiable number you can't do that. It let's you focus on what is really important, and that is determining the team's sustainable velocity.

It is a foreign concept. But we did it for 3 years. Actually the project is still going, I just left and took on a different positon in the company. Yeah, we had challenges, funding and otherwise, but we were able to deal with them. We had to cut about 1/2 our team at one point, and our velocity suffered. But we got to the point where when we said we could deliver something by a certain date, we could. I really don't see that very often, and it wasn't the case with all of the projects around us struggling with Waterfall. Again, it's not a panacea, but it can work and to discount something just because you don't understand it or have never actually done it is foolish.

Re:What if... (1)

Anonymous Coward | about 2 years ago | (#40943583)

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

fatphil (181876) | about 2 years ago | (#40943759)

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

bertok (226922) | about 2 years ago | (#40943895)

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, if you're constantly refactoring your code, maybe you should stop writing shitty code that needs refactoring so often that it becomes a key component of your regular project management. I've tried pair-programming, and I thought it really was effective at improving code quality, but the poor bastard without the keyboard was bored to tears.

Can you point me at even one study that compares the pros of pair programming vs the cons, such as employee job-satisfaction? One that uses proper scientific research methods with -- you know -- numbers? A study that comes up with a theory for pair programming that I can apply to accurately determine when to use it or when not to use it?

I doubt it.

Re:What if... (2)

Joey Vegetables (686525) | about 2 years ago | (#40944151)

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

Anonymous Coward | about 2 years ago | (#40945135)

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

Re:What if... (0)

Anonymous Coward | about 2 years ago | (#40943935)

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

Kjella (173770) | about 2 years ago | (#40944051)

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

Anonymous Coward | about 2 years ago | (#40944245)

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

Anonymous Coward | about 2 years ago | (#40944567)

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

Anonymous Coward | about 2 years ago | (#40943717)

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

Anonymous Coward | about 2 years ago | (#40944263)

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

OpenAgile for non-software (2)

under_score (65824) | about 2 years ago | (#40942623)

FWIW, OpenAgile [openagile.com] was designed for non-software agile use including management, sales, marketing, operations, etc. and there are some very interesting uses out there. I'm on the board of directors for the OpenAgile Center for Learning so I'm a bit biased, but I strongly recommend this approach to any organization or team that wishes to improve effectiveness. I think it's very exciting that Agile is spreading beyond software, but there are also many challenges. In particular, Scrum is really best for new product development and many practices are not applicable outside that environment.

Oh, great... (2)

__Paul__ (1570) | about 2 years ago | (#40942697)

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

Management tool? (1)

Taco Cowboy (5327) | about 2 years ago | (#40942855)

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? (0)

Anonymous Coward | about 2 years ago | (#40943613)

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

Re:Oh, great... (1)

Sulphur (1548251) | about 2 years ago | (#40943197)

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

Managementology?

Re:Oh, great... (1)

benhattman (1258918) | about 2 years ago | (#40946369)

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 (4, Informative)

jools33 (252092) | about 2 years ago | (#40942829)

I first heard of Scrum from my wifes hospital ward - where they were using the technique to manage the activities of their staff. This made me curious as to its origins and it turns out it was first and foremost a product development methodology. So its not that Scrum is spreading from its software origins - it never originated in software in the first place. [wikipedia.org]

Re:Scrum is not originally a software methodology (1)

under_score (65824) | about 2 years ago | (#40943173)

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 (1)

multimediavt (965608) | about 2 years ago | (#40944503)

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 (1)

biodata (1981610) | about 2 years ago | (#40944725)

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.

Scrum Agile NPR (0)

Anonymous Coward | about 2 years ago | (#40942941)

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 (1)

91degrees (207121) | about 2 years ago | (#40943083)

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

Anonymous Coward | about 2 years ago | (#40943533)

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

Anonymous Coward | about 2 years ago | (#40943813)

Creativity Killer (3, Insightful)

mnt (1796310) | about 2 years ago | (#40943899)

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 (1)

asr_br (143523) | about 2 years ago | (#40946793)

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

Anonymous Coward | about 2 years ago | (#40943923)

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

Anonymous Coward | about 2 years ago | (#40944591)

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

Me no get it. (1)

luis_a_espinal (1810296) | about 2 years ago | (#40944601)

To me agile is just the latest buzzword. When I started my career then years ago it was "extreme programming". My first team claimed to be using it despite no pair programming or other practices I would associate with it.

To me "agile" is the way that many in house systems have been developed for years. It is only recently that the word agile has been applied to them (lets face it, almost everyone claims to be using agile these days).

My current work is to develop and maintain the in house database system used my a high throughput sequencing centre. We don't officially use agile, but looking at the agile manifesto http://agilemanifesto.org/principles.html [agilemanifesto.org] , the way we work conforms to most of the principles laid out here. Regular frequent meetings, getting the software into the hands of users as soon as possible, frequent feedback, adapting to changing requirements. I haven't changed the manner in which I work over the years, but now I seem to be doing "agile" (more or less).

Bro, the agile movement (or buzzword) is almost as old as the XP movement (or buzzword.) "Extreme Programming Explained" was published in 1999 while the first Agile Manifesto draft was written in 2001, attempting to encompass similar methodologies of the vert late 80's and early-to-mid 90's. Back in 95, people were already (and rather empirically) were implementing lightweight methods moving away from rigid variations of iterative/spiral models (or waterfall if you were unlucky.)

Not sure how you can say 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.

Transfer of knowledge (0)

Anonymous Coward | about 2 years ago | (#40943985)

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 (2)

TheSkepticalOptimist (898384) | about 2 years ago | (#40945375)

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

astro (20275) | about 2 years ago | (#40944019)

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

But... (0)

Anonymous Coward | about 2 years ago | (#40944205)

Is it webscale?

SCRUM stands for SCRrewed Up Management (3, Insightful)

nickmdf (216307) | about 2 years ago | (#40944253)

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

Maybe non-software projects is what it is good at (1)

TheSkepticalOptimist (898384) | about 2 years ago | (#40945185)

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... (3, Insightful)

pauljlucas (529435) | about 2 years ago | (#40945223)

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

Quazion (237706) | about 2 years ago | (#40946789)

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

pauljlucas (529435) | about 2 years ago | (#40947445)

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

avandesande (143899) | about 2 years ago | (#40947285)

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

pauljlucas (529435) | about 2 years ago | (#40947479)

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

avandesande (143899) | about 2 years ago | (#40947525)

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.

Jobs program for the useless (1)

yt8znu35 (1202731) | about 2 years ago | (#40945517)

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.

What Agile Scrum means to me. (0)

Anonymous Coward | about 2 years ago | (#40946021)

    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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>