The “Working Software” Paradox
- August 17th, 2010
- Posted in Systems Thinking and Technology
- Write comment
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
I am not a huge fan of information technology as my readers know. More often I find that technology has entrapped workers rather than liberated them.
Too many technology projects have the wrong aim . . . to save money. The focus needs to be on customer purpose which brings us to the “working software” paradox of the Agile Manifesto.
You see in software projects we have stakeholders with different aims. Executives are looking for project plans, contracts and revenue recognition. The development community typically is drawn down to writing requirements, coding, testing, fixing bugs, etc. under the constraints of these executive imposed dates in the project plan. The real customer for software should be the worker that has to deal with it on a daily basis. But too often it is their management that is unfamiliar with the work that buys a solution that doesn’t solve the problem. Sound familiar?
So the question becomes, how do we get to “working software?” What works for the executives doesn’t necessarily work for the people who do the work. Developers are caught in the middle of trying to figure out whose definition of “working software” they should embrace.
My experience with Fortune 500 technology organizations highlights this paradox. Plans, schedules, documentation, etc. create more expense, but give managers needed information to hit the financial target. Many of the causes of costs are instituted by the managers and executives themselves in command and control fashion.
Let’s face it, the real work is done by software developers and I believe that developers or architects should be in the work with the people that the software should be helping. Let the developers/architects “get knowledge” by studying the system with the workers and managers. Change can be emergent rather than planned.
I have seen too many plans made without knowledge of the work in software development. Where business analysts write requirements and developers lose context to the software they are developing. Lack of context creates poor knowledge and subsequently “non-working software.”
Context and knowledge are lacking because executives believe that hiding expensive resources – like developers and architects – saves money. Again, this creates more costs as iteration after iteration fails to meet the end users needs.
In creating usable software, value can be derived by getting knowledge by those that do the work. Developers/architects, the end user are those people. There focus should not be clouded by command and control actions that add costs and diminish customer purpose.
Leave me a comment. . . share your opinion! Click on comments below.
Make the new decade a profitable and rewarding one, start a new path here. Download free from www.newsystemsthinking.com “Understanding Your Organization as a System” and gain knowledge of systems thinking or contact us about how to get started at tripp@newsystemsthinking.com. Reach him on Twitter at www.twitter.com/TriBabbittor LinkedIn at www.linkedin.com/in/trippbabbitt.
Tripp Babbitt is a columist (Quality Digest and IQPC), speaker, and consultant to private and public service industry.
I have been in the same industry/company for 20 years. When I look at our services overall performance and customer value, it has remained the same. Despite Blackberry’s, laptops, huge reporting databases, GPS systems, our customers get the same service results. Despite having a large back office with IT, routing coordinators, another manager, CMS, IVR, we have the same results. Im now working on the 95%, the system and push back on any new technology until we better understand demand.
thank you for your blogs
Excellent post! My only question and concern: how prepared are corporations in changing their thinking and therefore their approach? What’s your experience with your clients?
“The real customer for software should be the worker that has to deal with it on a daily basis. But too often it is their management that is unfamiliar with the work that buys a solution that doesn’t solve the problem.”
Exactly!
But I feel like the suggestion of having developers work with real end-users doesn’t necessarily address this problem. It may produce software that the end users would love, but that their managers don’t buy.
It reminds me of Paul Buchheit’s article “If Your Product Is Great, It Doesn’t Need To Be Good” http://bit.ly/a3ou2o. After discussing how important usability is, Paul adds a great kicker in a “disclaimer” at the very bottom of the article:
“This advice probably only applies to consumer products (ones where the purchaser is also the user — this includes some business products). For markets that have purchasing processes with long lists of feature requirements, you should probably just crank out as many features as possible and not waste time on simplicity or usability.”
My question is, how do we solve this problem? The purchasers don’t feel the pain and frustration of using bad software in the same way that the actual users do. So how do we persuade the purchasers to choose more-usable, but possibly less feature-rich, products over less-usable, but possibly more feature-rich products?
I just was working with a large insurance company where we did put the developers with the workers and the software emergent from this relationship works both for the workers and customers reducing costs dramatically as we worked only on “what matters” to customers Technology enabled the worker and the system. No project plans and no business analysts . . . didn’t need them.
Executives and managers that think such a thing can’t happen are wrong. They have bought into command and control management and this will be their and eventually the company’s downfall. Organizations that embrace the work and not the hierarchy will win in the new economic age. The rest will be dinosaurs.