A giraffe, which I hold dear, once told me that agile application development is all about pace, straight forward thinking and relevance. I can’t help thinking that us humans, like to make things all so complicated, even when we intend them to be ‘agile’.
We adore rules and regulations, and a static algorithm is fantastic when your target is motionless. The nature of things is not as static and rigid and not having a timely response might lose us the patch. “Follow your own heart”, the giraffe would tell me, “it should be as good as anything else you might find, and you can always change the rules and adapt to the new situations as they present themselves”.
I couldn’t help noticing that there was a wide nose rhino, staring at us from the other side of a patch of coffee.
Grasslands and software projects usually exist within a particular window of opportunity. The grazing has to be finished before the grass disappears: the problem has to be identified, addressed and delivered before it becomes irrelevant. “It has to be done and over with before the dry season” the giraffe would say. Managing software projects with agility is all about keeping up with the changing seasons, and the other moving animals.
The rhino was eyeing us ferociously. He wasn’t going anywhere.
Sitting there, leaned against a baobab tree, I heard the ‘agile of three points’ coming from above, straight from the giraffe’s mouth.
- Always deliver functionality
- Develop in short manageable cycles
- Make use of the customer
These three principles form the conduct and rhythm of agile development: Combined together, they insure the growth of the product in relevance, while maintaining a steady flow of fresh capabilities under close supervision and immediate acknowledgment of the customer for every step.
“Is it clear yet?” asked the giraffe. Here is some more:
Delivering functionality
Delivering functionality has to do with the continuous effort of implanting new business ideas and capabilities into the product by way of every software drop. Functionality delivered alongside other non functional changes.
The principal has two immediate benefits.
From the customer’s point of view, each code drop brings some fresh and new solutions he needs for his business. After all, new functionality is exactly what he paid for.
From the development standpoint, the proper prioritization for new functionality prevents the product from freezing while the development team works in full capacity in revising and rewriting already working code.
I’m not saying that code maintenance is irrelevant. Software releases should be a balanced concoction of improvements both in business relevance and in code quality.
Short development cycles
Development in ‘short bursts’ is an all too familiar concept to the Agile advocates. This is a principal that has to do with the pace of the development and of the software delivery.
Having short and manageable development cycles insures close proximity for each issue between the time it is developed and the time it is tested. Nothing is lost by time or forgetfulness.
Another byproduct is by having pending and immediate deadlines; it is easier to keep the developers in check and optimal production.
Of course I’m letting go of many other aspects, but I think this captures the essence.
Customer involvement
This principal has to do with relevance. Nobody knows the business better then the customer. Hence, customer’s involvement in the application development is an asset.
Sounds so simple, but it’s probably the most difficult to practice. To make this happen, the customer needs to have focal points for every issue that might rise in development, and define direct access to these key professionals.
Having customer representatives on board during progress and status meetings might sound to some as walking naked in Times Square, but the other side for this exhibitionism is the total involvement of the customer in progress and prioritization.
And while involvement means cooperation and clarity means trust, the chances of the project to eventually ‘go live’ is as high as is can get.
Maybe next time I’ll have a short chat with the rhino.
I liked your three point description of core agile very much.
ReplyDeleteAlthough agile can be summed up so nicely, its practice requires great care:
* Breaking down bigger tasks into smaller ones that can be more or less individually developed and tested requires very clever approaches and a sound architectural understanding.
* Working with the customer is nice, but customer relations is not among the strongest points of good developers or software team leaders.
* Good developers tend to have a taste for "beautiful code", which always lead to some time spent on non-functional aspects.
Don't get me wrong, I'm not the rhino. :)
What do you think? Which one of these three points is the hardest in practice?
1st - Gilad, that is a wonderful way to present key principles! Keep it up.
ReplyDeleteI, too, love the majesty of giraffs. They also, so evidently, symbolize foresight in their very physiology
Erek, you are quite correct that solid architectural thinking is the only way to avoid development team distress and lost productivity.
But like all things in nature, it is a false premise that one can/should choose the SINGLE most essential feature or most important factor. The need for simultaneous effort internally (development team) AND externally (the customer) is a key perspective for any development project.
Yes, (some) developers are frequently the last person you want interacting with the customer. This is why successful projects have individuals, whether they be systems analysts, or developers who love a new puzzle, whose job it is to continually work with the customer and forge the mutual respect that is the fertile soil of a successful project.
The giraffe's true advantage is that he is constantly scanning the broader area and taking in more factors, making sounder decisions. Have you ever watched a giraffe run? It is poetry in motion.
Have you ever watched a rhino run?
Which aminal do you think your customer would rather ride on? Which would you?
Hank Mayers
hankmayers@reliatechconsulting.com
Hi Hank, Erek thanks for the comments.
ReplyDeleteJust to add to the things you said, I believe that letting the developers feel that they share the responsibility of the delivery helps a lot when it comes to joint effort. We all have the same goal and we all push together.
Having said that, of course there are decisions and considerations left for managers when selecting who does what and the particular guidelines we set for each task.
That’s why they pay us.
These are usually the variants in the development equation, and I deliberately left these out of the story.
I believe that these considerations are part of our flexibility and personal touch.
“Follow your own heart”, the giraffe would tell me, “it should be as good as anything else you might find, and you can always change the rules and adapt to the new situations as they present themselves”.