Doing Business in Real Time
The global economy has a life of its own, it lives in real-time, and we are all part of it. Hello brave new world.
Experience shows me (again and again) that agility is not about working fast but about finding elegantly simple solutions to business problems. You'll know you've found an elegantly simple solution when the business people agree it solves their most important and immediate problems and when the developers know the solution can be built and tested in 30 days or less.
Unless you find a solution that meets these two criteria, it’s not possible to be agile. And often, because people can’t find these simple solutions, they mistakenly claim that agility itself doesn’t work. They come to this conclusion because they attempt to be agile by cramming complex solutions into short development cycles through working harder, longer, and faster.
That attempt has as much chance of success as trying to cram ten pounds of you-know-what into a five pound bag. Inevitably, the bag breaks, and then there is a mess to clean up.
[ I do lively presentations on this and related topics - mhugos@yahoo.com ]
An elegantly simple solution (a robust 80% solution) doesn't do everything (there isn’t time for that), just the most important things. Finding this solution is not easy; it’s the creative part. It requires business people to figure out what tasks out of all the tasks they perform are the most important ones and what system features they need to handle those tasks. Then developers have to figure out how to build and test a system to deliver those features in the short amount of time available.
Business people need (at least temporarily) to suspend the notion that everything they do is complex and difficult (they can certainly revive that notion later when talking to the boss about a raise). A skilled JAD facilitator who walks them through a process mapping exercise will almost always be able to uncover those most important tasks because in drawing out the sequence of tasks in any workflow, and their inputs and outputs, it becomes obvious which tasks are the most important.
Then it’s the turn of the technical people (at least temporarily) to suspend the notion that everything they do is complex and difficult. After the most important tasks are identified, business and technical people engage in an open give and take exploration of features needed for those tasks and how such features might be built in 30 days or less.
Developers can’t cling to the idea they have to write a lot of code to get things done (this is hard because they often believe their value is based on writing lots of code). They have to think about ways to leverage existing systems and data and combine components like databases, spreadsheets and web browsers with only small chunks of custom code to deliver the features business users want.
This is what the future looks like. One of the world’s largest software companies endorses this idea (can you spell VSTO?), and other people also know this to be true.
If developers insist on writing lots of code, the project will not be agile. You know things aren’t going well when more developers get added to the team, and they start working 12 hour days, and they stop updating the project plan, and nobody really knows what is going on because everybody is so busy. Then they find long days aren’t enough so they start working weekends as well; and then they burn out.
Indeed, the developers do churn out thousands of lines of code, but it’s just a symptom of their failure to come up with an elegantly simple solution. It isn’t possible to write thousands