Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Wed, Feb 27, 2008 22:51 EST

|
Posted by: Michael Hugos in Best Practices Topic: ApplicationsBlog: Doing Business in Real Time
Current Rating: |
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.
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 of
I think I agree with the spirit of this post but disagree with some of the details. Or maybe I just need some clarification.
You state that an agile project lasts no more than 30 days – and that in itself is a measure of success. Therein lays my dilemma. Usually in agile development a 30 day sprint or iteration is just one of the many “periods” of development, not the entire cycle. Typical product development using agile methodology uses sprints or iterations that vary in length from 1 week to 30 days, but nowhere does it require completing an entire project in 30 days.
If you refer to solving an internal business problem (that may appear complex) then I would tend to agree with you, although even these situations may require a couple of sprints and cannot be deemed a failure or non agile if they extent to 2-3 sprints or more.
However if you are referring to software product development (since you refer to lines of code), you’re completely off. It’s like saying Excel or SAP or Oracle need to be developed in 30 days.
I have been running Development teams for many years and I have adopted an agile methodology about 8 years ago. Frankly – I will not do anything but agile; as it’s the only way I can ensure success and relevancy. In the last 7 years of practicing agile development I’ve built many successful commercial software products -- not once have I completed a product in 30 days. At best I can probably point out to building a prototype. Every single one of my products runs anywhere from 3 to 9 or n sprints of 30 days each, depending on complexity.
I find no correlation between the number of lines of code a developer writes and the success of the agile methodology. Lines of code are not a good measure of agility. I would argue that testability is a good measure instead. For example building certain functionality may require large libraries with lots of lines of code. Likewise, various development tools produce large amount of code as a byproduct… so every sprint you can have a large net influx of new lines of code. Does that mean one loses agility? Absolutely not! At the end of a sprint, one determines success based on accomplishing or not the goals of the sprint, not the number of lines of code a developer wrote.
The true criteria for successful development using agile is that at the end of the sprint you end up with an operational product, that is testable and has some level of QA, not that the entire system or product is finished within a 30 day sprint.
Agile forces both customer and developer to constantly prioritize the important features up font. That means that as you start the new sprint, you go again through prioritization, requirements, design, etc…
Your description of a “problematic” project is really not representative of an agile development style and bears no correlation to the reality of agile software development. Sometimes developers need to be added to the team based on plan. With agile you figure that out pretty quickly. That’s why you’re agile – you can react quickly to customer/product demand and requirements. Likewise, no one involved in agile development should ever claim that they don’t know what’s going on. That’s what daily scrums are for. Sometimes you do have to work 12 hours day… Development is exciting and that’s just part of it. Every successful product has these crazy experiences and stories as part of it.
One last point, sometimes demos of the system at the end of the sprint do crash and the lead needs to set the proper expectations with the business owners. A crash of the system is a very immature way to consider whether the business problem is in process of being resolved or not, or whether the goals of the sprint were met or not. The business owner needs to see above that. Bugs do happen – let’s not panic about it.
I do agree with you about the simplification paradigm and that the focus should be in finding elegantly simple solutions.
Hi Adrian,
I'm thinking we basically agree on agility with some differences in our respective techniques. You and I both believe that at the end of a sprint (or what I call a blitz) you deliver a usable product that has had QA and business people can put it to use right away.
It's understood that what is delivered at the end of a blitz is what I call a "robust 80% solution"; it isn't the whole application. The whole system gets progressively built out in iterative blitzes.
We also agree that nobody on an agile project should say they don't know what's going on since daily scrums or standup status meetings keep everyone up to speed. I see problems always occur when those daily meetings don't happen and developers start getting evasive about what they're doing (often out of fear they'll be penalized). The transparency required by an agile project takes some getting used to before people see why it is so central to the whole practice of agility.
And I agree that sometimes you do have to work 12 hour days and that is part of the excitement of development. But I try to make sure that the 12 hour days are used only sparingly so as to avoid burnout.
Agile project iterations generally last 30 days because that's a tight time constraint so it forces business and technical people to prioritize and focus on getting the most important system features done first. After people show they have the discipline and skill to get things done in 30 days then it's possible to lengthen the iterations to 45,90, or 120 if necessary.
But I need to see proof people can handle longer iterations without just lapsing back into the comfy, leisurely, futile, old waterfall method.
So, who sez agile projects last 30 days? I sez.
Best regards,
Michael
How about we all agree not to read the advice of "experts" who obfuscate already poorly-understood topics by coining their own non-normative vocabulary to describe it for selfish reasons?
This article makes an excellent point to not over think and over complicate solutions to business problems. One of the concepts that is an oversight in this article is that many times when you involve IT to build a solution (from scratch most of the time) which involves writing code the solution gets more complex than generally is needed.
There is a whole wave of Enterprise Applications that puts the control of building a solution into the hands of the people who need to solve the problem....the business person or unit owner.
These applications allow the business person to automate, measure, enable efficient workflow, and allows them to be able to report every step of the way to ensure the process is being executed as planned and that the problem is truly being solved.
No two businesses are alike and every organization has to approach each problem in a way that best suits their business. Additionally, no two business people are alike and a platform approach to solving business problems is what organizations are moving towards. Business users need to be able to build new solutions on the fly, expand upon current applications/solutions, integrate existing solutions and unify the information silos....with minimal involvement from IT.
The output of solutions should not only solve a business problem it should increase efficiencies along the way. Creating a simple solution to a business is not always the answer, applications should be made in a way to empower the business person and streamline a complex issue so that it is complex in design but not complex in implementation.