Archive
Agile & Engineering Practices
Continuing on the previous post about agile failures,
One of the core principles behind Agile Manifesto is “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Isn’t that the exact opposite what we were taught in Software Engineering 101 course, ‘the cost of change increases exponentially over the lifecycle of a project. The later the change is the harder it is to do’. But welcoming change and building in increments without having a Big Up Front Design means having a reasonable cost of change curve. It is enabled by
- Having a automated test suite which serves as a safety net for changing code
- Willingness to refactor & Refactoring
- Continuous Integration
- OOP and Following Good Design Practices
Automated Test Suite is a must and Refactoring & Continuous Integration are enabled by it. Without Refactoring the code quality decays continuously. Continuous Integration is what makes sure we have quality (potentially shippable) code in the source control system always. Violation of encapsulation will be costly when you change something. OOP and good design practices are more important in an agile project where you welcome change.
Most of the projects are pressed for time. So if testing follows code ‘automated test suite’ is never a possibility because coding time will eat into our automated test suite time. So agile proponents advise to do the tests first. This way no code can ship without being tested & without having the license to change.
No BDUF <> No Design
On one end of the spectrum is BDUF and on the other end is No Design. Agile design is about drawing a line in between in the right place. How do we identify the right place. Kent Beck’s criteria Simple Design is the best.
Fowler explains all of this very well in his paper Is Design Dead?
To sum up
- Having a automated test suite which serves as a safety net for changing code and doing tests first.
- Willingness to refactor & Refactoring
- Continuous Integration
- OOP and Following Good Design Practices
- Simple Design instead of No Design or Big Design Up Front
are Implied assumptions of Agile. If any one of those assumptions is ignored, it is going to hit back hard.
Further complications could be factors like distributed environment, not having an onsite customer, no pair programming. But then “Engineering is not about perfect solutions, It is about doing the best you can with Limited resources” (The Last Lecture – Randy Pausch).
End of the day it is not the framework / method which matters, it all boils down to people. In case you ignored all of these assumptions in the beginning (because you did not know them or thought they were not important) you could still come back on track if
- you have the right set of people in place who could identify these in your early retrospectives.
- you have a supporting management who understand development and is willing to pay off the technical debt in phased fashion.
Of course it will be hard, but not impossible.
Talking about ‘The Decline and Fall of Agile’
James shore has a post on ‘The Decline and Fall of Agile’. I couldn’t resist quoting him here (emphasis mine).
On Engineering Practices
But because Scrum works in short cycles and doesn’t include any engineering practices, it’s very easy for teams using Scrum to throw out design. Up-front design doesn’t work when you’re using short cycles, and Scrum doesn’t provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt. Two or three years later, I get a call–or one of my colleagues does. "Changes take too long and cost too much!" I hear. "Teach us about test-driven development, or pairing, or acceptance testing!
More on Engineering practices
There are a lot of teams right now failing with Agile. These teams are working in short cycles. The increased planning frequency has given them more control over their work and they’re discovering and fixing some problems. They feel good, and they really are seeing more success than they were before.
But they aren’t working in shared workspaces or emphasizing high-bandwidth communication. They’re don’t have on-site customers or work in cross-functional teams. They don’t even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don’t use good engineering practices.
These teams say they’re Agile, but they’re just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It’s the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff–the stuff that’s really Agile–they’re setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won’t last.
On Certified Scrum Master training & Laetrile
It’s human nature to only do the stuff that’s familiar and fun, and that’s what has happened with Agile. People look at agile methods as a chinese menu of practices, choose the few that look cool, and ditch the rest. Unfortunately, the parts they leave out are the parts that make Agile work. Scrum makes it worse by ignoring important (but hard) agile engineering practices, and the Scrum Alliance makes it worse still with their armies of trainers–some good, some not–issuing dubious "ScrumMaster" certificates to people who demonstrated competence in connecting butt to chair for two days.
And
"Agile is hard, and you can’t master it by sitting through a two-day course."
And in the comments, its not about Scrum
Although a lot of people have taken my essay to be a condemnation of Scrum, that wasn’t my intent. Instead, I was trying to highlight the failures that I see and the factors that contribute to those failures. The biggest problem isn’t Scrum or even CSM training, it’s people eating dessert and skipping their vegetables.
That was pretty much the whole post. But I couldn’t resist quoting it. Please read it from his blog so that you get it in the full context (Quotes often do not capture the context). Its worth your time.
Walls Suffocate while Boundaries Communicate
Kelly Martens has a nice entry on a couple of Mental Models (I do not really know what to call them, hence I am calling them this way).
Sendhil's Cyber Home 