I currently have the pleasure of working in one of those “waterfall-ish” shops where things actually work: Profitable projects get delivered in fairly predictable timeframes by sane people. They have a fairly “traditional” setup with business analysis folks who write old-style requirements documents (… few if any new-fangled “user stories”…). These are given to development for implementation, to be manually QA’d by the QA team. A few lone rangers not withstanding, practically nobody seems to write any tests.
How can this be … ? Aren’t we supposed to TDD/BDD/scrummerize everything, practicing kanbanilism for good measure? Blasphemous whispers in the Church Of Agile; Petty doubts: Have I joined a fringe cult …. ?
So what’s the difference? How do they get away with it? Situations where I’ve encountered “traditional” software development life cycles that actually worked all had the same combination of traits in common:
A healthy “that was then, this is now” attitude to requirements. A recent project is a good example: The “traditional” business analyst–produced requirements remained a living document which was updated throughout the delivery of the project. It could thus be relied upon to closely match what was implemented in the code. As much as anything, the habit of keeping it up to date led to many more conversations between BAs and developers than would otherwise have taken place, greatly helping everybody to understand the problem domain. Very importantly, the document also served as vital input for doing the second part of the trick:
Relentless QA. Unsurprisingly in the absence of automated test coverage, there were many bugs. QA used the “living” requirements document as their guide to making manual test plans. They were very well-organized in executing them and very proactive in sharing the results with the developers. The resulting back-and-forth further helped to grow a shared understanding of the system and it’s requirements.
Smooth Deployments. Calling it “continuous integration” would be a stretch, but they had their builds and deployments organized in a way which allowed for one or two QA releases per week.
Awareness. They were aware of test driven development, the potential advantages of Agile and many of the techniques. However, they had a large legacy code base and many organizational structures and developer habits which did not lend themselves to “Agile” without major changes and a lot of experimentation. It was a matter of “Koennen vor Lachen” (… German for “Easier said than done”. It doesn’t translate well.). Yes, sounds great, but how do we start … ?
Hard to say. Trying to do “Agile” without test-driven development is an extremely hazardous idea. At the same time doing TDD in legacy situations is a tall order. For a team of developers to start consistently writing tests in brownfield projects takes a lot of new ways of thinking and technical savvy which I feel absolutely has to go hand in hand with appropriate ways of managing the process: Without knowledgeable support and commitment by non-technical stakeholders the effort will die. (Very common scenario/attitude: “We don’t have time to write tests.”)
The practices of “waterfall done right” could serve as initial steps when iterating towards “real agile”. Compared to a seasoned SCRUM / Lean team at their best, “Zombie Agile” with living requirements, relentless QA and smoothed-out deployments is expensive, inefficient and somewhat dead. Nonetheless, it seems to be delivering a surprising number of good results.
The free CodeRush VS add-in which seems to do some of what can be found in Resharper is at:
I haven’t tried it yet, but look forward to give it a whirl.
The sample code for the “Refactoring Towards Sanity” can be found here:
IMPORTANT (and awkward): It turns out that WordPress doesn’t allow uploading .zip attachments, meaning that you’ll have to jump through the extra hoop of right-clicking the link, selecting “Save Link As…”, and renaming the file to RaceResultDemoBeforeRefactoring.zip.
See you at the session.
I’ll be in Regina for PrairieDevCon in June. It sounds like a lot of fun.
Started preparing for my “chalk talk” on refactoring project management and for the “dojo” on refactoring (… arguably easier to handle …) actual code. I’m looking forward to these sessions; Both have great potential for lively exchanges of in-the-trenches experiences. I have much to learn.
See below for the abstracts:
Moving Towards Lean In A Waterfall World
Moving from traditional waterfall-centric push project management to lean pull-based approaches takes more than putting a kanban board on a wall. Using a “real world” example, the audience is invited to help with identifying waste, maximizing flow and (perhaps most importantly at all) explore ways of getting buy-in from management and other stakeholders to whom this way of doing things is completely alien. Just for fun, we’ll try to use nice, easy to understand techie concepts and apply them to running projects: Refactoring (…. gradually change old ways of doing things, in small easy to digest steps), anti-corruption layers (… how to work with other parts of the organization who are in no position to try all this new-fangled stuff), etc.
Refactoring Towards Sanity
Working with legacy code is a fact of life. Re-engineering it all is costly and frequently impractical. This session takes participants through a minimalist example of how to carve “areas of sanity” from tightly coupled Big Balls Of Mud: Instead of re-writing the complete application, focus on the core domain. Gradually isolate key functionality from dependencies and side effects which affect the rest of the system, thus creating “safe” areas where code is under test, SOLID, etc.
(Tools: Visual Studio & Resharper)
Click to enlarge. Also available as PDF.
OK, a disclaimer: I’m a geek. I have learned to do some business-speak and googled the odd idea about how it’s done, but my instincts are questionable: I haven’t made my first million and therefore I’m not really qualified to give advice to those who have.
My specialty is to deliver software applications. Very often, situations present themselves like this:
- We are a team of developers. We have finite capacity and Conway’s Law rules us with an iron fist. By Seth Godin’s “hunters and farmers” analogy, we are farmers: We try to leave no stone unturned to make sure we build the right thing at the right time. In the face of (inevitably) changing requirements and (inevitable) learning-as-you-go about how the system should be implemented, we do our best to manage technical debt. It’s in our nature to strive for certainty, but we have a hard time getting it.
- We build applications for hunters: What we produce is a means to an end, to exploit a market opportunity, satisfy demand, help run the business (… a hunting tool of the trade …) more effectively. The hunter needs commitment: When is it going to be done? How much will it cost?
The hunter’s need for commitment and the farmer’s difficulty to give it in the face of (inevitable) change are a culture clash which dominates our industry. Untold millions are spent every day on experiments which prove over and over again that preventing (inevitable) change through waterfall project management and avoiding (inevitable) learning-as-you-go during project development is not the answer: It has a tendency to result in inflexible, expensive to build and dull end products. You can fairly hear the hunter’s howl of frustration:
“It’s a thinking machine, people! It’s the marvel of the age, one of the cleverest things ever! Why is it so #!!@$!! hard to make it do something smart……!”
The answer to this is a farmer’s answer which makes him howl louder still:
Building non-trivial software requires an incompletely understood balancing act between a complex set of trade-offs involving social interactions, technological factors and resource constraints. Working smarter beats working harder every time. Debate over what is meant by “smarter” is ongoing.
The current fashion for Agile and Lean delivery approaches looks promising and I remain cautiously optimistic that we’ll figure it out in the next 50 to 100 years.
In the meantime, in an extreme case of semantic diffusion, let’s see if we can hijack the concept of a balance sheet to identify a set of mutual commitments between entrepreneur-hunters and farmer-developers which, when in balance and taken with a grain of salt, might help to increase the chances of success:
|The team will not miss deadlines, but scope of what is delivered for the deadline is up to the development team.||We will not miss deadlines. we will do frequent releases.|
|I will ensure that features are clearly prioritized.||We will deliver the highest priority features first.|
|I will do my utmost to ensure that requirements are as clear and simple as possible. I will assist the team by minimizing scope.||We will minimize cost/effort by adhering to the YAGNI principle as much as possible.|
|I will ensure that the team has direct contact with end users to the greatest extent possible.||We will communicate clearly and skillfully, assisting management in reconciling conflicting user opinions, priorities and requirements and limiting scope.|
|I will not override technical decisions without clearly understanding the consequences in terms of technical debt.||We make all technical decisions with business priorities and the quality of the end user experience as the most important criteria.|
|I will support the development team in their efforts to adhere to the principles stated in the Agile Manifesto.||We will adhere to the principles stated in the Agile Manifesto.|
It’s far from ideal, but maybe it could save the odd million? Anything which results in less chaos and more predictability would be good … Spoken like a true farmer?
Started following the software_craftsmanship group where there is a thread on vouching mechanisms and their inherent problem. Who is an apprentice? What makes you a journeyman? A master? It seems clear that in terms of supply and demand, software development mastery is closely related to intelligence: Many of us are fairly certain that we have a lot of it. Ranking others “Ebay style” and being ranked ourselves is both highly subjective and somewhat discomfiting: What is our focus? Building great software or trying not to be voted off the island?
So what is a constructive way of telling what makes craftsmen tick? Who did they learn from? Who influenced their thinking? It seems that the question of lineage, in the Eastern tradition of acolytes and adepts, is of some significance.
In a fine display of craftsmanship, James Martin hits the nail on the head:
As an aspiring craftsman, I’d like to know who are the people that are well respected by other craftsmen because of something they’ve actually done, so I know who’s shoulders to stand on when I’m learning and honing my craft.
From the Wikipedia entry: