I have been involved in a series of posts on both my SRMM Blog (see post) and the PMI Voices on Project Management blog (see post) that have stirred up sections of the agile software development community.
Despite the Agile Manifesto focusing on providing excellence to stakeholders, many Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’. Whilst this may be true (although I somehow doubt it in anything but the smallest and simplest projects) it ignores the needs of the project’s key stakeholders.
Most IT projects exist to enhance the capability of the organisation. Consequently the software development is only one part of an overall project to change the organisation, deliver new capabilities or similar. In these typical circumstances, the IT component needs to meet predetermined requirements; any change in the IT capability delivered requires changes in other parts of the project. In fact the best IT solution may turn out to be an unacceptable business solution.
Meeting the needs of the businesses key stakeholders demands discipline and communication not just within the ‘scrum’ or XP team but to the customer’s managers. This needs at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed to support the business. Adequate documentation and effective communication are essential.
This post is not suggesting a return to Waterfall or other heavily documented software development process (they don’t work very well anyway – refer the Standish reports) but rather for an appropriate level of documentation to meet the genuine needs of senior management stakeholders. Saying ‘trust me’ is not enough and is not good stakeholder management.
Identifying the key stakeholders, assessing their requirements and expectations and then managing these key relationships so the stakeholders realistic expectations can be realised definitely involves up-front planning and effort, needs tools and methodologies such as the Stakeholder Circle® and involves on-going monitoring and control but is, I would suggest, worth the effort. Your project is unlikely to be seen as successful if the stakeholders expectations are not realised!
In most aspects of life the long term enjoyment of real freedom required a significant measure of self discipline. The agile extremists may do well to consider this and focus on meeting the needs and expectations of all of the stakeholders involved in their work.
Pat Weaver
Lynda Bourne
Aavssitedev's Blog
Lynda,
I wish you well in this pursuit. I’ve gone down this path several times in the past. The advocates of agile speak to “appropriate” documentation, and “the right amount of this or that.” No actual guidance of course.
The myth of “waterfall,” of course is it is not used in the domain it was invented. “Waterfall” methods are forbidden in the US DoD acquisition process, since they were discvered to be falwed in the late 70’s.
The red herring approach as a selling strategy works for the uninformed.
In our US DoD and NASA work documentation is part of the product development lifecycle for all the right reasons. Finding the right reasons in IT is hard work, and because it is hard work, easily skipped for more enjoyable efforts – coding.
I think in the end the merger of agile software development techniques and system engineering processes (www.incose.org) will bring light to all this nonsense about agile being the magic bean that fixes enterprise IT.
Our spaceflight and aircraft flight controls programs use all the elements of Scrum (not called Scrum) embedded in a DO-178B full verification and validation process domain – all guided by systems engineers.
Now there’s a thought… proper systems engineering and even using the underlying ideas in CMMI to ensure consistency in quality………
This post feels like a troll or flame war waiting to happen, but in an effort to assume it is an honest inquiry…
To your point “The mantra is ‘give the software developers free reign and you will get better software’. “… this is not agile. If this is your only exposure to agile, then you have been surrounded by people claiming to be agile that don’t get it, or they get it, but have done a horrible job of applying it or explaining it (aka, they don’t get it). If you go to the heart of the Agile community (say Agile 2009 next week in Chicago), you will find that Agile teams are very controlled environments, just not rigid.
You later stated – “Most IT projects exist to enhance the capability of the organisation. ” Agile purists like myself would not agree with this statement. Projects exists to provide business value to your users/customers. If in your company, all the users/customers are internal… then I can agree with you in your context.
As for documentation… documentation doesn’t prove anything. Working software proves an understanding of scope. Acceptance and purchase of the software by the end customer proves the team understood what was needed. I do agree with you that agile adopters initially drop too much documentation and put themselves at risk. Many mature agile teams eventually find a middle ground of “just enough” documentation. After working in companies that cranked out documentation that nobody read, I understand how this issue is a problem and agree with you in some part. But, documentation doesn’t add value for the end customer… it only adds value for you to keep moving forward. (If you need help or install documentation, then maybe your product isn’t usable enough?)
My best advice is to cast off the mainstream hearsay about agile because it is now being bastardized and abused. People are slapping agile on their process for attention without understanding it, and the industry at large is becoming misguided. This same evolution happened with CMM, Six Sigma, ISO, and all other new ideas. It’s part of business.
If you want to really understand Agile… keep an eye on the PMBOK. The PMI institute is formally absorbing Agile approaches into PMI right now. This implies with history and data that agile is adding value, is complementary to current ways of working, and is a desired direction to head in.
I was fortunate to see Agile implemented in a global 50 company and how it turned the company and culture around. I’m a believer, but I know that a lot of people are getting the wrong message/explanation. If you have questions, feel free to troll the Agile groups on LinkedIn or send me an email.
You’re half right Kevin,
My beef is with the Agile Anarchists that use the ideas embedded in Agile as an excuse for no discipline and no accountability. Unfortunately these advocates seem to be overrepresented in the blogsphere. Business centric Agilists have a battle to win mindshare in the millions of businesses resisting a move towards improving software development practices. Shifting entrenched senior management views focused from ‘command and control’ needs the sensible, business aware, stakeholder centric approach I have been advocating in a range of blogs that have been roundly attached by the more extreme members of the agile brigades.
I do disagree with you on two points though:
Firstly the ONLY reason a business sells a software product/development to an external client is to enhance the businesses itself. IBM, Infosys and a range of other successful IT organisations exist to sell software and services to third parties but I can assure you the reason their management persist with this strategy is primarily focused on ‘what’s good for their businesses’. Fortunately in a competitive market what’s good for their business translates into delivering exceptional service to clients. And by the way, the only reason a third party will buy software is to improve its business, it is just the communication chain to the people actually planning to use the software to create value is longer. There is absolutely no point in developing software to develop software – there has to be a business benefit somewhere or the whole process is a complete waste of money and resources.
The second is documentation – yes in 30 years of ICT project work I have seen truckloads of wasted paper. However, the RIGHT documentation is still essential. Generally this is business focused documentation and it is the only way to demonstrate to senior management what they are getting for their money. Most senior management will not spend time attending workshops etc – they need to see the final concise documented outputs. These stakeholder communications are essential, and in 99% of businesses involve either electronic or paper documents. Successful communication to a recipient is done in the form the recipient is happiest with if you want the communication to work! How the developers develop their work internally is up to them but again coming back to documentation, one of the key stakeholders for every IT project (usually ignored by everyone) is the next team of developer in 3 years time, who will need to understand what’s been built and how it works so they can maintain and enhance the code.
Both of these points have been canvassed at length on my posts on PMI’s Voices on PM blog, here, and on my SRMM blog.
I’ll throw these two thoughts out just to balance the agile banter…
I’ve recently read a lot of Seth Godin’s (Tribes) work, and I’ve caught up on Jim Collin’s (Good To Great). Neither are agile related or software related, but I find that there is a huge overlap in the underlying principles. For me, this is a validation of the agile movement.
I agree that the blogosphere is riddled with idiots before experts. The question is (since we both blog) which side of the line are we both on? Check this out: http://sethgodin.typepad.com/seths_blog/2009/08/willfully-ignorant-vs-aggressively-skeptical.html 😉
As for the business vs. end user debate… we’ll have to agree to disagree. After spending 7 yrs in the field of usability, I am biased on this. Again, Collins and Godin make the same points I make. I can’t support that IBM exists to support itself and therefore must make it’s customers happy. The difference between Toyota (the Toyota Production System is the basis of Lean and the seed of Agile) and American auto makers is that the American companies did what was best for the business and Toyota did what was best for the customer. Look how that is turning out!
BMW recently stated that the best business is insuring that the customer returns and not the product. To me, this is an example of putting the customer’s business value first and knowing that profit will follow.
I think you are completely misunderstanding the business drivers of business Kevin. Certainly businesses survive and thrive because they understand the only effective long term strategy is to help your customers succeed in their ambitions. But don’t ever forget the first (fiduciary) duty of any commercial business is to the long term benefit of its investors/shareholders.
The difference between Toyota and GM was the topic of my post, Short termism -v- long term survival – Toyota had by far the better strategy for its business survival. Similar debates surround corporate social responsibility (CSR – statistically organisations that embrace CSR do better then those that don’t) and the organisations attitude to its stakeholders (the topic of my new book, Stakeholder Relationship Management: A Maturity Model for Organisational Implementation).
GM and the other big US car manufactures patently did not do ‘what’s best for the business’ they responded to short term imperatives such as the quarterly share price and executives bonuses at the expense of the health of the business and the long term wealth of their stock holders. The net result, GM stock holders lost everything, stock holders in other US vehicle manufacturers almost everything. In contrast, Toyota’s stock holders are probably quite pleased with the strategic decisions their management made.
Interesting… I’d put the long term benefit of the customers first, the employees second, and the investors last.
Why? Because I hate seeing investors and CEO’s walk away with lots of money at the cost of employee compensation and long-term customer relationships. In my mind the business exists for the sole barter of services between the collective employees and the collective market… the investors/shareholders are simply a bystanding enabler taking advantage of the situation.
I would even argue that a really good business might not actually need investors/shareholders because it would always be profitable (I’m ignoring the eventual point where the company is swallowed by someone larger).
But now I digress even further from the original topic…
As a Fellow of the Australian Institute of Company Directors, I think you are letting the sort of unethical and plain bad management that led to debacles ranging from Enron to the GFC cloud your vision.
Ethical management and corporate governance is about balancing the competing needs of all of the organisations stakeholders, balancing long and short term goals and being socially responsible (CSR).
The good news is empirical studies consistently show organisations that focus on these objectives also consistently out perform those seeking short term and excessive profits. This sort of long term, sustainable success is not achieved by the simplistic win-lose scenarios favoured by American MBAs. It needs mature, pragmatic governance and a focus on win-win.
One of the problems in the states is that people in large companies with many layers of management started focusing on personal upward mobility and stock profit and somewhere along the way lost focus on customers and value.
My view is not limited to Enron… that’s a ridiculously extreme example. I can look at most of our healthcare, auto, music, or telecom industries here in the states and find more examples of businesses focusing on short term profits instead of long term value than the opposite.
I big portion of this back and forth may simply be subtle differences in our cultures and interpretations of our words combined what the business environment around us. When I look back at the original post, the reason I commented was because it seemed that Lynda was anti-agile and I wanted to provide some balanced insight to statements she made about Agile that seemed to be based on impression instead of actual Agile experience. Agile is at a point right now where the hype is outpromising the reality. Having experienced an agile transition in a global 50 company where it helped projects go from 2 years behind schedule to only 6 months, I was hoping to provide some balance.
Pingback: August Posts « Stakeholdercircle’s Blog