Agile software development has its own manifesto which lays out the values and principles of agile process. Lets try to look beyond (or may be just deeper into the meaning of) the essential four value statements. Self Organizing Team over Control & Command Team. Responsibility to deliver lies with the team and not with a centralized manager who is calling all the shots with a team of resources to control and command. The team has the power to commit and it collectively strives, brainstorms, and works to meet the commitment. Team is cross functional and have no fixed roles. It self organizes to fill in any role or responsibility and work around any strength or weakness to get the job done. Jeremy D Miller has some very valid points to support People in a self-organized team are able to make decisions themselves and accordingly adapt to changing situations. Command and control grunts have to wait for the boss to tell them what to do Agile done over just done. In agile development, when we say a feature is done, we should really mean “DONE”. When a piece of functionality is picked up from the backlog and developed as part of a sprint, it might very well be a working code and implements the intended requirement, but is it really done?. Kelly Waters does provide an answer In agile development, make sure that each feature is fully developed, tested, styled, and accepted by the product owner before counting it as "DONE!". And if there's any doubt about what activities should or shouldn't be completed within the Sprint for each feature, "DONE!" should mean shippable. Michael Nygard comes with a new definition of done where he comes up with a checklist of dozen points for a feature to satisfy before it can be termed as DONE. Enough Design over big up-front design. In agile world we know big up-front design is not the way to go before we get down to implementation. As defined by Armon Rotem-Gal-Oz, may be just enough design up front will do. Agilists tend to down play traditionalists reliance on Big Design Up Front (BDUF) and they are right. More often than not, Big Designs without underlying code that demonstrate it actually works and integrates well prove to be a waste of time. Steve McConnell thinks there is definitely a shift In ten years the pendulum has swung from “design everything” to “design nothing”. But the alternative to BDUF isn’t no design up front, it’s a Little Design Up Front (LDUF) or Enough Design Up Front — ENUF Code Reuse over cut and paste. Never repeat yourself, do it once and keep using the effort again and again. Do it by reference and not by value. Code should be designed in a way to enable it to be reused rather then mere cut and paste. Cut and paste in no way is an example of code reuse it is just a way to invite maintenance nightmare. Dale beermann puts it right The problem is that code reuse doesn’t just happen naturally. Reuse must be a core element of the design to be made possible. Code reuse becomes much more relevant when we talk in terms of code reuse in test cases. Roy Osherove's idea. If we don't all realize that in the real world tests have to be as maintainable (or even more so) as production code, we won't come out of the middle ages of unit testing. Pair programming over code review There has been a lot of debate over the applicability and feasibility of programming in pairs and does it really improve the quality of the code. A person who has done it knows it is really true. Not only there is a very good chance that the code is much better quality wise with far less numbers of bugs or hacks but it goes a long way in keeping the communication of ideas and design decision going within the team. Jeff Atwood at coding horror has some good comparison points on pair programming over code reviews The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you. but concludes In the end, I don't think it's a matter of picking one over the other so much as ensuring you have more than one pair of eyes looking at the code you've written, however you choose to do it. When your code is reviewed by another human being -- whether that person is sitting right next to you, or thousands of miles away -- you will produce better software. That I can guarantee Stand up Meetings over status meetings The idea is to keep the meeting very short that is the reason everyone stands but it is much more then communicating the status. The purpose is to show the commitment to the team and to the project, communicate the current status, plans and progress to the team rather then the manager, identify the impediments and keep the focus for the ultimate goal. This is how it is described by Mountain Goat Software The daily scrum is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other

i kinda lost trust in the good faith or good will of most ppl behing agile methods, and the new methodologies in general they say too much to fill more books to sell, and most of them don't code (at least i don't any famous opensource project major talent who is into this methodology thing) all of what they say can be summarized in few words. 1. learn your tools/fremawork/languages well, that way u will be educated hence (i hope) competant to do what they as u 2. dont be lazy, work hard, dont spend too much time chating or listening to mp3z or whatever 3. be brave face and solve the real problems, dont be afraid of coworkers or ur manager, say it as it is, and deal with it really this all, anything more, and ur selling me a scheme!!! most projects that fail, fail because of who the programmers are (incompetant, lazy, coward), not because of what method they use!!!!

Ali, please, if you want anyone to take your opinions seriously, try writing them in actual sentences. I am just astounded when I see the readership of a website catering to professionals think it is acceptable to write comments in the same syntax they use texting their friends. Find the key. You are not an lolCat.

Ali, please, if you want anyone to take your opinions seriously, try writing them in actual sentences.

I am just astounded when I see the readership of a website catering to professionals think it is acceptable to write comments in the same syntax they use texting their friends.

Find the key. You are not an lolCat.

While I disagree with pretty much everything Ali wrote I couldn't care less whether he wrote it in grammatically correct English or pigeon. What matters to me is that he conveyed his message clearly, and that his comments was relevant to the topic in question

Agile is probably the single best consulting business model ever created. Whether or not it produces software that's of superior quality or not is beside the point. It lets you go to a client, and sell them a never ending project and absolve yourself of any failures. Pure Agile (with a capital A) methodology is essentially made so that no one will ever follow it exactly. Let's write all of our requirements in the form of "stories" on index cards and tape them to the wall. Ahh-now I see why so many previous projects failed, no index cards! Then, let's assign two programmers to every coding assignment rather than one. Somehow doubling the cost of development leads to a total cost savings. It doesn't take long before you realize that pair programming is a waste of time and money, and that having stories on index cards adds no real value other than making it look like you're doing stuff. And that's the beauty of the whole thing. It's made so that no one WILL EVER FOLLOW IT EXACTLY! So when a project fails, well, it's just because the project didn't follow the methodology, and Agile consultants are absolved of any responsibility (we TRIED to tell you to follow the methodology!) Not only do you never have to accept responsibility for any failures, but as requirements change you just keep tacking on more iterations. You can stretch a 6 month project out for a couple of years if you play your cards right. What was once a nice payday has turned into a steady cash cow. That's the real beauty of Agile, it's more profitable and failures are never your fault. Sign me up!

In my opinion Agile does not restrict anyone from following all the standard process of documentation. Documents/ artifacts can be one of the deliverables. The key focus with Agile is early user feedback and also helps better tracking of the project to avoid mistakes and helps change the direction at an early stage as detected. Another key focus is re-prioritizing the backlog based on the business value for the user. The traditional model (Waterfall) is good but has some rigidness of steps and does not allow fallback. In my Organization we have been following SCRUM for around a year now and it is a mix of both. It has been working pretty well for us. The team will commit to the deliverables for each sprint cycle. The time estimation for each task is collectively decided by the team and the estimation gets better and better in each sprint. Here's how we do it: 1. Prioritize product backlog 2. Sprint Planning 3. Finalize goals & deliverables 4. Task break down 5. Sprint Review 6. Sprint Retrospective There is always a SRCUM Master & Product Owner who are the facilitator and will track the project for its goals and deliverables. They do not make decisions but can always suggest, the team finally decides the direction. There are some decisions that the team alone do not make; like selecting the stack, software, hardware etc. It will always have the management involvement. There is a member from architecture team for guidence as a shared resource. There are members from other departments / streams who are commited / shared resources in the project. The only thing I get confused by is the definition of Cross Functional Team : It is said that everyone should do everything when needed to achieve the goal; Here my opinion is that it should be a team consisting of members with different skillsets rather than everyone should do everything when needed. I being a developer do not wish to write requirements / test cases (these are not unit test cases) / do load testing / performance testing. I am sure this will be a bottleneck in the timeline and may not be the right representation of a Cross Functional Team.

Just to clarify, my post was talking about the Thoughtworks, Big-A Agile, not the more general agile/iterative philosophy. Steve Yegge had a good post about what he calls good agile vs. bad agile. You can read it here if you're interested: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

Steve Yegge had a good post about what he calls good agile vs. bad agile. You can read it here if you're interested:

http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

I think what's worth pointing out in that blog is that the "good Agile" written about at Google is very notable for how much respect it places on developers and how empowered everyone is. I haven't read all the Agile books out there, but I do know that the "Lean Software Development" series is pretty adamant that nothing that claims to be "Agile" is worth anything if the people doing the work don't feel respected or empowered (I know "empowered" is business-speak, but I'm currently at a lack for a better word). It sounds like that the concepts in that book would mesh very well with what Google is doing. Also, it would seem to me that the term "Agile" is naturally failing to hold its meaning as more and more people talk about it. Just like "SOA". Maybe even "object oriented". "Domain driven design" might be the next one to fall as it becomes more popular, and people start using it to mean different things. I do think this is a case where it's important to distinguish principles from practices. Pair-programming is a practice. I've always thought that it sounds pretty lousy. But the principles behind it make a lot of sense. I think those principles could fall into the "Agile" bucket, whereas I would not see those principles being in the "Cowboy" bucket, for example. So there's plenty to bash about practices that Agilists recommend, just like there's plenty to bash about Waterfall and Cowboy practices. What's more worthwhile is to look at the principles they're trying to achieve. Though that's not nearly as enjoyable as just making fun of what people are doing. =)

I have used limited portions of Agile methodologies however adopting the entire process is a tough sell. With no overriding project plan and requirements which change with each iteration how do you estimate the total cost for the project? Try selling a client on the statement "we're not exactly sure how many iterations this will take but we're sure it will cost you less than a waterfall approach... and no we won't give you a fixed bid or delivery date commitment." As for the feature backlog. How many times have you sat in a meeting with project stakeholders who classify every single feature, defect or issue as critical. I'd love to meet a product management team who can distinguish between critical, high, medium, and low without me renaming them as "end of the world", "show stopper", "must be fixed ASAP", and "critical". On the topic of SCRUM I do have to give credit to the concept of the Sprint Plan. I've found it highly effective method of predicting and tracking the project's progress along with curbing "Student Syndrome".

Try selling a client on the statement "we're not exactly sure how many iterations this will take but we're sure it will cost you less than a waterfall approach...

Here's how it works in a nutshell. At the beginning of the project you get every user story in good shape and have the developers estimate them. You begin your first iteration, pulling in what the team feels is a realistic number of user stories to complete. This is done over and over again the progress, measured in accepted user story points, is plotted on a chart called a burn chart. After three of four iterations (velocity is small and volatile at first) you have enough information (user story points per iteration ) to get an idea as to whether or not the project is in trouble. I'm being real with all of you, there is nothing exotic here. If someone in your organization, or an outside consulting firm is not doing this and they are calling it Agile, then they are probably new to this.

and no we won't give you a fixed bid or delivery date commitment."

ThoughtWorks has delivered successfully under both of these conditions.

It lets you go to a client, and sell them a never ending project and absolve yourself of any failures.

Try to look at it as though it gives you the opportunity to fail fast. By fast, I mean at the end of the first iteration (and every one after that). If your team doesn't produce working tested software at the end of each iteration, find the problem (whether it's the consultants and/or on the client side) and fix it. Retrospectives are a good time for this.

So when a project fails, well, it's just because the project didn't follow the methodology, and Agile consultants are absolved of any responsibility (we TRIED to tell you to follow the methodology!)

Projects can fail for a lot of reasons, even if the methodology is followed. If your consultants are telling you that their process is somehow above this, consider doing business with someone who is more realistic. Also, you should be holding them responsible for delivered working software at the end of each iteration.

Not only do you never have to accept responsibility for any failures, but as requirements change you just keep tacking on more iterations.

Changing requirements can shorten or lengthen a project.

- Self organizing teams In my experience, such a thing does not exist. No team that exceeds the magic number "3" (code re-use, no magic number please!) will cease to be self organizing or will spend most of its time self organizing. And this is in the good case where people have no grunts against each other and there is no external "someone has to take the blame" pressure on the team. Also, noone can be a Jack-of-all-trades, so a team just can not "work around any obstacle" if the team does not contain the required expertise, product knowledge etc. In day-to-day work, priorization issues are sure to arise as well. They will not dissolve automatically. Teams may not need "command and control", but they need leadership and decision making. Some excellent programmers are very bad in deciding anything....

+1

- Self organizing teams

In my experience, such a thing does not exist. No team that exceeds the magic number "3" (code re-use, no magic number please!) will cease to be self organizing or will spend most of its time self organizing. And this is in the good case where people have no grunts against each other and there is no external "someone has to take the blame" pressure on the team.

What I have seen happen when there is no clear leadership is that often one person will attempt to make themselves the leader by bullying others. The problem is that this person may not really be the best leader, just the biggest *******. I think Agile is a reaction to the "process over results" approach that has become so popular. And in a lot of ways this is good. However, I think that this movement has made the classic mistake of letting the pendulum swing too far in the other direction instead of trying to seek the sweet-spot of 'just enough' management.

What I have seen happen when there is no clear leadership is that often one person will attempt to make themselves the leader by bullying others.

As opposed to saying pretty please will you all work together? Yeah. THAT works. How would you suggest moving a stuck team forward? I think if I wear a cheerleader skirt I'll get fired. But seriously, more often than not a team contains a least a couple members who will fight against any sort of progress. Sometimes these people are directly opposed to the project. Sometimes they simply fear the project leaving the domain that they understand...especially when their domain is making pretty powerpoint slides. Either way they work to keep the project stuck. Someone needs to make them move.

What I have seen happen when there is no clear leadership is that often one person will attempt to make themselves the leader by bullying others.

As opposed to saying pretty please will you all work together?

No, opposed to having clear roles and leadership responsibilities. The idea that a project can be run by a bunch of people all 'doing the right' things smacks of the fallacy of communism, IMO. I've been on a number of projects where the bully ran it into the ground. The biggest ******* was able to impose authority but wasn't really very bright. I've more situations where struggles between two people to assert authority over each other became more important than getting things done. Anarchy is not a strategy.

Yeah. THAT works.

How would you suggest moving a stuck team forward?

Don't start a project without a leader. If the project was started without a leader, management should pick one fast.

I think if I wear a cheerleader skirt I'll get fired.

That depends on where you work I suppose.

But seriously, more often than not a team contains a least a couple members who will fight against any sort of progress. Sometimes these people are directly opposed to the project. Sometimes they simply fear the project leaving the domain that they understand...especially when their domain is making pretty powerpoint slides. Either way they work to keep the project stuck.

Someone needs to make them move.

And that person should be the official leader. Throwing a bunch of geeks in a room and seeing who comes out alive might be a funny experiment but it's not a recipe for success.

What I have seen happen when there is no clear leadership is that often one person will attempt to make themselves the leader by bullying others.

As opposed to saying pretty please will you all work together?

No, opposed to having clear roles and leadership responsibilities. The idea that a project can be run by a bunch of people all 'doing the right' things smacks of the fallacy of communism, IMO. I've been on a number of projects where the bully ran it into the ground. The biggest ******* was able to impose authority but wasn't really very bright. I've more situations where struggles between two people to assert authority over each other became more important than getting things done. Anarchy is not a strategy.

And this was my point no.3 be brave don't be afraid or intimidated by anyone! People can easily get intimidated by others and abide to their ruling. Many people confuse being a people person by being bossy or by intimidating other to do they want, or if someone knows ur kinda shy, he can play on this too. Having people skills is really key here.

Yeah. THAT works.

How would you suggest moving a stuck team forward?

Don't start a project without a leader. If the project was started without a leader, management should pick one fast.

And that would be following the PMI standard thingie, each project should have one project manager, the idea isnt for him to be the boss, but, management need one and only one responsible for a project, for if the project fails or is late, they is a sinlge point of responsibility, else everyone will say "it wasn't me, wasn't my fault". When everyone in the team knows that only this one person will take the blame, they in normal cases do as he want whenever there is a conflict or anything, maybe out of pitty, i dont know, but most ppl i met act like this!

And that person should be the official leader. Throwing a bunch of geeks in a room and seeing who comes out alive might be a funny experiment but it's not a recipe for success

What happens when you are a developer, or other tech expert, and the official leader simply doesn't cut it? This happens a lot. Lack of leadership does not necessarily imply lacking an official leader.

And that person should be the official leader. Throwing a bunch of geeks in a room and seeing who comes out alive might be a funny experiment but it's not a recipe for success

What happens when you are a developer, or other tech expert, and the official leader simply doesn't cut it?

This happens a lot. Lack of leadership does not necessarily imply lacking an official leader.

Actually I don't think we really disagree much on any of this and that you just misunderstood what point I was making. There's a couple of ways to look at what you are asking me. In the military, an lower rank trying to take leadership against the desires of his commander is called insubordination or mutiny and is a crime punishable with court-martial. I don't necessarily think that software projects should be run like the military but I think it's worth considering why that is the case. Do you not see a downside to anyone who feels they are smarter or more adept attempting to assert authority over others? I think that what you have experienced may be similar to what I have experienced, that the management of a project or group is so bad that they only way things get done is if someone in the trenches takes control. From what I know of you, it wouldn't surprise me if you have done this successfully. My guess would be that you would be closer to 'benevolent dictator' than 'tyrannical despot' on the spectrum of self-chosen leaders. But without a clear leader, project success is a dice-toss. You might have a natural leader who will rise to the occasion with a team of people who are agreeable enough to follow good leadership even when it's not official. You might have a couple hyper-aggressive jerks battling over who will control a bunch of sloths who probably won't listen anyway. If you know you have a good leader on the team and expect them to lead, you should make that official and make their job a lot easier. I guess my point is that teams without official leaders represent a failure of management. Even if the official leader is poorly chosen, everyone knows where they stand and the failures and successes of that leader can be evaluated. And in the case where a 'true' leader make things happen while the official leader hangs back, either the 'true' leader or management should attempt to correct the situation. Honestly, I think this doesn't happen as much as it should. In the end, my whole point is that the idea of a self-managing teams is a crock. It's a big gamble and the larger the team, the less likely it is to work. I do think that avoiding micro-management and giving everyone the opportunity to make decisions and take responsibility for their choices is a good idea, however.

Actually I don't think we really disagree much on any of this and that you just misunderstood what point I was making.

...or perhaps I'm trying to incite debate...

Do you not see a downside to anyone who feels they are smarter or more adept attempting to assert authority over others?

I see a huge downside. As I was recently informed (by a guy encouraging me to come work for him), I have a problem with authority. Authority is kind of like nuclear weapons. One should only use it as a last resort.

I think that what you have experienced may be similar to what I have experienced, that the management of a project or group is so bad that they only way things get done is if someone in the trenches takes control. From what I know of you, it wouldn't surprise me if you have done this successfully. My guess would be that you would be closer to 'benevolent dictator' than 'tyrannical despot' on the spectrum of self-chosen leaders.

I've both succeeded and failed. Right now I'm actively avoiding such situations. What I'm trying to figure out is how to foster the rise of an acceptable leader within a headless team. Part of this is learning how to take the reigns without pissing off the good team members.

Even if the official leader is poorly chosen, everyone knows where they stand and the failures and successes of that leader can be evaluated.

Sometimes I wish I was patient enough to let this happen, but I simply can't sit back and watch a project I'm on fail.

In the end, my whole point is that the idea of a self-managing teams is a crock. It's a big gamble and the larger the team, the less likely it is to work.

I think crock is the wrong word. Different teams need different amounts of leadership. It's possible to establish a small team that can work without a clear day-to-day leader as long as you have high performance people with clear roles and direction. Basically if some of the primary leadership tasks have already been accomplished.

No, opposed to having clear roles and leadership responsibilities. The idea that a project can be run by a bunch of people all 'doing the right' things smacks of the fallacy of communism, IMO.

Not really communism. In capitalism people are just supposed to follow there incentives and it magically turns out to be good in the whole. But I agree, that's not exactly a good way to run a project.

I've been on a number of projects where the bully ran it into the ground.

I've been on projects where weak leaders have let the projects go out into limbo. There are all sorts of types flawed leadership that can destroy a project.

The biggest ******* was able to impose authority but wasn't really very bright. I've more situations where struggles between two people to assert authority over each other became more important than getting things done.

Yes, I've seen that as well. Or were one persons struggle to brown-nose executive management takes precedent over actual progress. I've seen that a lot.

Anarchy is not a strategy.

Sure it is. Just not a very good one.

I think the real question here is: In an absence of effective leadership, should a developer stand up and attempt to lead? That's a very personal question, and very context sensitive. Most people I know will not do it. What you need to recognize is that there is a difference between leadership and authority. Your "bully" is attempting to gain de-facto authority. He is not attempting to lead. There is also a difference between leadership and management. The PMI project manager will track everything as it runs into the ground. Leadership is something different. I know that's cliche, but it's true. Leadership is hard, and often not present.

No, opposed to having clear roles and leadership responsibilities. The idea that a project can be run by a bunch of people all 'doing the right' things smacks of the fallacy of communism, IMO.

Not really communism. In capitalism people are just supposed to follow there incentives and it magically turns out to be good in the whole. But I agree, that's not exactly a good way to run a project.

Well, in the original Marxist idea of communism, as I understand it, eventually the government dissolves once the system of everyone working together is in place. The authoritarian or totalitarian state that we associate with communism is, in theory, just a temporary situation. The reality is that people need incentives to work and will react extremely negatively when they perceive unfairness such as they are doing more but receiving the same (or less) credit. Having clear leadership allows the incentives (pay) be tied more clearly to the success of a project and less so to personal goals or desires.

Of the problems is that books on Agile methodology and Agile evangelists to a certain extend portray Agile methodology as the silver bullet. But in reality is that it is just yet another development methodology. I personally have seen it succeed only on non mission critical projects where: 1) The product manager only have a vague idea of what is really required and are overexcited to change the requirements as it is being developed. (usually a website as opposed to a web-application) 2) The teams consists of a bunch of cowboy “developers”, who only know how to code. (Note the usage “developers” which is different that “software engineer”. 3) People don’t like to be organized and they cover it up under the umbrella of “Agile” (And since teams on those project as small they try to get away with it) Yes I agree that projects need to be constantly steered and controlled, but this is not specific only to Agile!!