Although firmly seated in the .NET industry, I try to keep tabs on the other camps to see what they’re up to. A lot of people are now really starting to master what we today call agile software development. They’ve harvested the benefits agile has had to offer – and they want more. A profound example of this is the concept of continuous deployment(read his follow-up too), as explained by Timothy Fitz:

“The high level of our process is dead simple: Continuously integrate (commit early and often). On commit automatically run all tests. If the tests pass [automatically] deploy to [production.]”

Johannes Brodwall has a thoughtful post on what the future of software development may look like. His vision is a mainstream adoption of continuous automation: continuous testing, distributed source control, continuous integration, continuous deployment.

I’m left wondering – where’s the .NET community? Are we lagging behind the curve? If you’ve not yet picked up on the concepts that we’ve been preaching about the last few years, such as continuous integration and unit testing, you should be getting worried about being able to keep up – the leaders of the pack are already moving on.

This autumn, I’ll be giving a series of talks at the MSDN Live conferences across Norway, where I’ll both be discussing and demonstrating some of the ways we can push the envelope with agile software development within the .NET space.

Often when people are talking about the concept of technical debt in software, they relate it to cleaning up “quick and dirty” code. I'm not convinced that this is what Ward Cunningham was really talking about when he first coined the term.

To me, technical debt is the natural, inevitable result of evolving requirements. Code that was perfectly written to model the requirements as they were known two months ago, may detoriate and become inadequate or even incapable of supporting the implementation of todays requirements. This is really the essence of Agile software development: We write code to model the world as it is known today, with less regard for what may be known tomorrow. Then, as we discover more knowledge, we pay back the debt we owe for the assumptions we made by remodelling and refactoring the code.

So please don’t think that you can use technical debt as an excuse to write quick and dirty code that you’ll come back and “fix” later. Paying back technical debt is about keeping your code clean – which implies that it was, in fact, clean to begin with.

Imagine two teams, A and B, both working on the same piece of software. How do you solve the problem arising from team A having a work item X which they cannot implement because it requires something that team B are working on to be done first?

Whenever a dependency is obstructing progress, you probably have a missing or leaky abstraction.

Take a step back and consider the boundaries of what you are trying to achieve. Team A shouldn't really care how team B solves X. So let them pretend that it has been solved! The accept criteria for their task should be independent of team B's efforts anyways; the tests that team A come up with for their task should be executed in isolation - in other words under the assumption that everything else works. I've written about this at a lower level before - the same principle of dependency inversion applies here.

Of course, later when both team A and team B are done, they merge their work into an integration branch where integration testing etc happens.

At risk of sounding like a broken record, I’m once again writing a post about the importance of following good technical practices. Martin Fowler posted a new entry to his bliki earlier today, where he writes that “whenever I've listened to prominent Scrummers they've always emphasized that you must have good technical practices to succeed with a Scrum project. They don't mandate what those technical practices should be, but you do need them.”

Now I doubt I fall under the definition of what Fowler refers to as ‘prominent Scrummers’, but I agree with what he claims they’re saying. If you’re looking for a mandate on what these practices are, Jeremy D. Miller summed it up quite nicely a couple of months ago – I quoted him back then too in my Recipe for Tasty Agile Soup post, but I think it certainly bears repeating:

“You wanna work adaptively instead of the ol' fashioned plan driven method?  Fine, but you've got to make that adaptability safe.  You need rapid feedback cycles to know when you're getting off the rails (customer demos, TDD, Continuous Integration, automated acceptance tests, static code analysis or some sort of equivalent).  You need to take steps that make continuous design methods safe and effective (simple design, a constant attention to design fundamentals like the SOLID principles, and an intolerance for technical debt).  And your team needs to be retrospective about its work to make adaptions as they become necessary.”

Back to Fowler. He goes on to say that “the scrum community needs to redouble its efforts to ensure that people understand the importance of strong technical practices”. Absolutely – but then, strong technical practices should be important to any serious team of developers, regardless of the methodology they have chosen to apply. Fowler acknowledges this, saying that “it isn't methodologies that succeed or fail, it's teams that succeed or fail” before closing by quoting from the Agile manifesto that Individuals and Interactions are more valuable than Processes and Tools.

Over the weekend, there’s been some discussion on the interweb about why Agile is “failing”. James Shore (Agile consultant and author of the book Agile Development), wrote a post on his blog about the perceived Decline and Fall of Agile:

“…many people who call me already have Agile in place (they say), but they're struggling. They're having trouble meeting their iteration commitments, they're experiencing a lot of technical debt, and testing takes too long.”

He goes on to describes why these teams are struggling (emphasis mine):

“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.”

The big selling point of Agile has always been that it will let you, well, be agile. Employ an Agile process (like Scrum), and you’ll have a happy customer who will be allowed to influence the project and change the direction it is taking along the way. As James writes, however, this is the result of employing an Agile process, which implies that there is some input required to produce this result. In a follow up succinctly titled Dirty Rotten ScrumDrels, Uncle Bob Martin puts it in layman's terms, explaining that “it is neither the purpose of scrum nor of CSMs to make engineers out of us, or to instill the disciplines of craftsmanship within us. That’s our job!”

Go figure – developing great software requires competent, dedicated engineers. StructureMap author Jeremy D. Miller follows upwith the recipe you and I need to follow in order to cook up a tasty soup of Agile:

“You wanna work adaptively instead of the ol' fashioned plan driven method?  Fine, but you've got to make that adaptability safe.  You need rapid feedback cycles to know when you're getting off the rails (customer demos, TDD, Continuous Integration, automated acceptance tests, static code analysis or some sort of equivalent).  You need to take steps that make continuous design methods safe and effective (simple design, a constant attention to design fundamentals like the SOLID principles, and an intolerance for technical debt).  And your team needs to be retrospective about its work to make adaptions as they become necessary.”

I’ve written about this before; you cannot reasonably expect to successfully employ an Agile process if you aren’t writing Agile code.

I’ve been advocating that we include the impediments on our Scrum burndown chart where I work, in order to visualise where we could have been if we’d been able to eliminate them. As a result, we now have a burndown chart which looks like this:

This is an artificial chart with fake data, but it shows the idea – that by including a series in the chart which shows the time spent on impediments subtracted from the burndown, we can see where we would have been if there were no impediments: in the fake chart above, we’d actually have finished a full day earlier…

Most of our impediments are support cases which we can’t really remove, but the statistics helps us make room for them when planning our sprints.