I could not resist paraphrasing Oscar Wilde regarding Agile software development. I’ve been pondering for some time how to properly incorporate Agile in my “software development belief system,” and recently came across the following quote:
The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.
Try to guess who’s the author without peeking ahead…three, two, one. I’ll spill the beans in the next sentences, but suffice to say that I was expecting a prominent Agile author, perhaps one of the authors of the Agile Manifesto, but no. The author is Frederick P. Brooks, Jr., author of the The Mythical Man-Month, a book written in 1978!
The problem that I had with Agile is that for the longest time I considered it a work in progress. In the 1990’s all the rave was OOP, and then OOD and OOA, followed by the different notations that culminated with the UML. Back then, as a developer you were considered progressive if you knew objects. Objects were fashionable, chic, cool. Structured programming was old, boring, heavy. New systems were developed using RAD’s, Rational made millions selling UML tools, Java took center stage, development processes that used OOA/OOD/OOP and UML with use cases were in high demand.
Then in the new millenium came the Agile Manifesto. I became aware of the Manifesto early on, and in the following years, as developers came and went, I started hearing stories of success. Every time I asked, however, I did not get a full picture. Perhaps because I was asking the wrong questions, or perhaps because I considered that several of the authors of the Agile Manifesto were “jumping ship” after contributing heavily to UML…I was expecting that they would commit to a software development process that would favor UML, but that did not happen.
My “breakthrough,” if I can call it that, came late in 2009, when I was involved in a project long enough (ten months) to try new techniques and with the right team size, a known scope and domain expertise. We applied only an Agile wall and concepts from Theory Of Constraints, but boy, did it make a difference. One of the highlights of that project was “on time and on budget.” Very little overtime from the beginning, since I requested that no one would work overtime for the duration of the project. The project made use of…use cases and UML, not epics or user stories.
After that, I got the “itch,” but got formally involved in a real Agile project until recently, and I’m coming to appreciate the results. It’s still too early to see the real impact for using Agile, but the results are promising. Suddenly, being Agile is fashionable, chic, cool, and using UML and use cases is old, boring, heavy. Sounds familiar?
I believe that Agile is not panacea and it cannot solve all the problems. For one, the company organizational structure plays a significant role in the success of the project(s)–e.g., organizing with functional managers, strong matrix or independent projects. Another one is the never-ending need for people, and often times teams are short on proper product owners or Scrum masters. Yet another one is the commitment from upper management in Agile, and changing the way software is measured for success (e.g., throughput accounting). Saying that, there are multiple benefits to have focused, geo-located teams working together as one entity towards a single goal.
I also believe that UML and use cases contribute greatly to a system design when properly managed. A frequent problem with use cases is how to properly write them. After more than ten years of information on the subject, you still find UML artifacts and use cases that are poorly written.
Agile is still a work in progress, but to where? Eli Goldratt, author of The Goal and Critical Chain, provides some insight. Summarizing from Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, all sciences evolve from classification to correlation, to effect-cause-effect.
Agile methods have agreed on internal nomenclature (e.g., epics, user stories, backlog), therefore they have reached the classification stage.
Agile methods , individually, have reached the correlation stage by pattern recognition: techniques such as XP, Scrum, work.
Agile methods, however, have not reached the effect-cause-effect stage. I don’t think that this stage will be reached soon–perhaps by the end of this decade–, mainly because it involves measuring and agreeing on what needs to be measured, as well as the interdependencies among those measurements in order to predict the effect a given decision will have on the project.
This does not take any merit away from Agile methods. On the contrary, the positive effects from the results is a great motivator to reach the last stage and turn Agile methods into a science.
Now let’s go back and be Agile.
Se Habla C++ 