A while ago I took a class on Scrum and Agile Project Management. During the discussion on Scrum, it became apparent to me that there are several unchallenged assumptions in many peoples' minds that make accepting Scrum difficult. People assume that Scrum/Agile takes away something they have, but in reality they don't have it. People assume they have the assurance of a fixed schedule and proper documentation. In reality, they have neither. They are like security blankets. The thought of them makes people feel safe, but the reality isn't that they help.
The Agile Manifesto prefers working software over comprehensive documentation. That doesn't mean no documentation, but it does mean limiting the output of documentation. Some projects create reams of paper before writing any code. Their managers gain comfort from the idea that everything is planned well in advance. Unfortunately, that comfort is usually founded on hope, not reality. Projects that do a lot of documenting up front run into one of two problems. Either the project is in a straight-jacket and can't react when the plans are wrong or it does react and the documentation gets out of date. I have seen many a project with a lot of documentation that is completely useless because it hasn't been updated. The trick to getting good documentation is to use it. As with many things in life, if it isn't being measured, it won't be accurate. Moving to an agile project model may reduce the overall amount of documentation, but it shouldn't reduce the amount of useful documentation.
But how will the team know what to do? Won't there be miscommunication without documentation? No. Not if things are done right. If "customers" are close enough to give feedback on iterations and teams work to agreed-upon interfaces and integrate often, these problems can be dealt with.
The Manifesto also calls for responding to change over following a plan. Agile projects work on iterations. At the end of each iteration, the project will be in a working state and closer to the final goal. The difficulty many managers have is that Agile projects won't commit to getting all N features done by M date. With a more traditional waterfall model, marketing knows when the product will ship and what features will be present. It makes life a lot easier. Except that it doesn't. The dates are not realistic. With an Agile project, the team is just admitting that they don't know how long everything will take. This means everyone can react to the reality of the project rather than making plans based on unrealistic expectations that will be shattered later. The expected ship date is just a security blanket. Agile makes it clear you are giving this up (or giving up control of what features will be ready), but doesn't actually make the project any less predictable. It's merely exposing the unpredictability that is innate in software development.
Many of the objections to an agile or lean software project are based on perceived loss of control. The trouble is, that control is not real. Losing something you don't really have isn't actually a loss.
Maybe things are different for Microsoft but in the world I work in it would be commercial suicide to stop giving customers estimates of when particular feature sets will be available, they'd just go to our competition.
ReplyDeleteThe product I work on is used by our customers within a larger system and all the parts of that system have to mesh. Unless our product is available with a given feature set then the whole system won't work. When our customers build and evolve this system they need to know that all the various parts will work together, which means they need to have an estimate of what features we'll have and by when.
Upfront planning is never perfect but if it is done right and, crucially, the engineers doing the work buy into it then its close enough for the purpose it is used for, which is to allow our customers to plan their work.
Personally I think the Agile manifesto is a bunch of obvious platitudes. Who doesn't prefer working software? I prefer lower taxes but I also want roads to be repaired and 911 calls to be answered.
I think Agile could be appropriate if your requirements really are changing frequently or if you are building a product that has no external visibility or dependencies outside the development team. The number of projects where either of these are true is actually quite small.
There are also significant holes in Agile. For instance no Agile proponent that I have ever talked to can answer how you make Agile work with a team that is split across geographies, especially those with large time differences like USA and India. Agilistas also get very hand-wavy when presented with a project that includes hardware dependencies and when there are multiple teams working on interacting components.
The one thing I do like about Agile is the focus on communication and visibility. The engineer who goes away into a cave and emerges 6 months later with a big "tada" checkin is not tolerated and I think that is a good thing. There is no silver bullet to software development but improving human to human communication efficiency is still a rich area to mine. Of course that doesn't sell books or pay for consultants and training classes.
Ultimately the market will decide. If Agile really does provide significant productivity benefits then software companies that are using it will become more successful at the expense of those that don't. My bet however is that Agile will become like the Atkins diet, it will work for some people for some period of time but it'll fade away as the realization sinks in that the inherent complexity of the problem remains no matter how you tackle it.
I agree that running Agile projects across large multi-national projects, and in embedded projects, is a lot more complicated than for a small software-only team.
ReplyDeleteAnd Agile may in fact be a fad.
But if the term "Agile" disappears, I really hope that the following mindset changes that come from the Agile techniques (which really have nothing to do with Agile, but for some strange reason don't happen very often in other methodologies) stay:
1. Continuous Integration - it isn't enough for your program to compile and run, it must also not break anything else.
2. Quality starts at the beginning - get the test engineers working with development from day one, and find as many defects as possible up front
3. Get rid of the "US" vs. "THEM" syndrome: communication, communication, communication, by including project management, development and testing in the same team
4. Develop small things, and make sure they work, rather than developing a year-long project, and at the end nothing works.