Agile Doesn’t Have the Answers

Agile doesn’t have a One True Answer for software development.  Agile gives you a structured way to seek feedback on your on-going exploration.

A predisposition to believe in a One True Answer for anything is one of the worst hindrances to grokking agile development.

Because many methodologies that came before agile were delivered as answers to problems rather than means to effective explore problems – including the methodology itself – folks are still getting hung up on out-dated habits that themselves act as obstructions to agile development’s essence.

Agile development isn’t a “solution” to anything unless it’s done in a way that encourages exploration and has a strong focus on harvesting feedback.

When I hear folks say, “…and so we turned to agile because we thought it could solve our problems,” I hear the predispositions of a generation of methodologies that were sold as solutions rather than as inquisitions.

Agile will show you more problems than you ever thought you had before you start to see some progress against these problems.  And that progress will come from your open exploration of the truth of your problems rather than from a cork board with index cards, ten-minute daily meetings, and monthly deliveries.

Agile doesn’t deliver answers, it only offers you a way to create a safe place to ask hard questions and the permission to try find the answers.

Posted in Agile | Leave a comment

Smurf… er, Scrum

I started doing something recently that I wish in retrospect hadn’t occurred to me, because now I can’t stop.

I was at a presentation recently where the speaker used to word “scrum” as a prefix for everything that his team does.  At some point it occurred to me that, for some folks, “scrum” had become the System.Object of terms.

This led me to reflect on the only other culture that I knew of that has a universal word: The Smurfs!  As soon as this regretful thought crossed my mind, I started subconsciously replacing “scrum” with “smurf” every time I heard the word.

Smurf Room.  Daily Smurf.  Smurf Planning.  Etc, etc, etc.  And unfortunately, I find myself snickering now when I hear someone talking about scrum for the absurdity of it all.  Kinda like imagining your audience in their underwear.

So, if you and I are ever having a conversation about scrum and I start snickering, please don’t assume that I’m laughing at you for your interest in scrum… I’m just having an inner moment of smurfrette’s disorder.

Posted in Agile | Leave a comment

Yesterday’s Agile

Been thinking about what’s next for agile development…

TDD is still young, but not as young as it was.  BDD is creating greater artifact, process, and team unification opportunities for test-first programming in an agile process.  Some of tomorrow’s practices are already starting to appear, but there’s a possibility, as is usual with all things human, that today’s agile activists can either be tomorrow’s agile activists or tomorrow’s agile friction.

Agile development has only had one generation of progress.  If the second generation is just around the corner, then today’s agilists’ identification with the practices that they are known for may be the very weight that slows the transition.

The transition to the second generation of paradigms of any old thing in any old lifetime is a difficult transition.  The transition to a second generation paradigm is the event that brings people face to face with the impermanence of the ways and means that they may have likely become identified with in the first and only generation.  Getting to tomorrow’s agile will be as much or more of a process of letting go as it will be a process of acquiring additional – sometimes historically contradictory – knowledge and practices.

So, will today’s TDD celebrities in the .NET world be able to let go of the practice that has become a big part of their identities and move forward with an eye toward progressiveness as they did in 2001 when NUnit started many journeys into unit testing, TDD, and greater agile?

What will tomorrow’s agile practices be?  Will we have the energy to move forward with verve and vigor as we did back in the day?

Posted in Agile, Commentary | Leave a comment

Monorail vs. Rails Isn’t a Meaningful Question

Monorail vs. Rails doesn’t seem like much of an interesting question.  In our work recently at Dovetail, we found that a much more interesting question is something like, “Should we be building forms-over-data web apps on .NET?”

If I have to build a web app on .NET, I’d use Monorail… but I’m beginning to see the use of .NET for most web apps along the lines of the proverbial use of a bazooka to swat mosquitoes.  I can see a possible (or likely) future, where I will not ordinarily choose to use .NET to build a web app unless I was forced to do so… assuming that .NET isn’t significantly overhauled at some point.

If you’ve gotta build a web app on .NET, then Monorail and the Castle Project is could very well be your project’s saving grace, and you should really consider trying it out before you build another web app on “raw” ASP .NET and webforms.

From my perspective now, Monorail is to ASP .NET as ReSharper is to Visual Studio.  Without Monorail, ASP .NET seems a bit primitive, incomplete, and not just a little odd considering how hard ASP .NET as a web app framework tries to pretend that it’s not a framework for building apps on the web.  Before VB, folks were built business apps using C++.  If ASP .NET remains fixated on its current course, I wouldn’t be surprised if ASP .NET will be to Rails as C++ became to VB.  My own experience of Rails points to .NET being overkill for most of what we need to build most web apps.

Here’s a question that I’ve been floating in my community lately: “What assumptions lead you to believe that .NET is the right framework to build web apps on?”  One of the more common answers can be boiled down to something like, “Because we made a lot architectural decisions up front that we can’t correct now, and because of this the mosquitoes we’re swatting are now as big as elephants… which are more effectively swatted with a bazooka.”

So, if you’re building web apps on .NET, what leads you to assume that you shouldn’t be building on Monorail?  And even more fundamentally, if you’re building web apps on .NET, what leads you to assume that you should be building on .NET?

There are reasons for either of the three choices, but we technologists often fail to actually make a choice as much as we choose not to choose for not being even aware of our choices.  How do you know that you’re using the best, most productive tools?

Posted in Design, Ruby and Rails, Web | Leave a comment

Accountability: Behavior-Driven Development’s Other Leg

Accountability is a huge part of agile development.  Behavior-Driven Development (BDD) drives accountability deep into development by having developers maintain the language of the business through the continuum of development process artifacts from user stories, through specifications, and into the application code.

BDD tools support accountability by surfacing specification documents from the executable descriptions of the application that developers have incrementally created through the plain-old Test-Driven Development process with a BDD framework like RSpec.

Stakeholders rarely get a glimpse into the stuff that developers are doing until shippable functionality is shipped, at which point, the software speaks for itself.  But simply having working software in-hand isn’t always enough, if it were, the drive for ever better acceptance testing tools and practices wouldn’t exist.

Part of our accountability to stakeholders rests in proving that we implemented what they assumed we would implement, and that we understood their requirements in the same way that they understand them.

In BDD, developers engage customers in a feedback dialog in the language of the business.  A customer would say, “I want you to implement X in such-and-such a way,” and the developer replies, “I understood that you’re asking me to implement X in such-and-such a way.”  This is partly what it means to say that a story is a placeholder for a conversation.

Using a BDD framework, developers write executable versions of the customer’s user stories and the acceptance criteria of those stories, and does so using plain business language.  If the customer were to read the executable specifications that were written by the developer, he should recognize the requirements that he laid out.

The BDD specifications become part of the feedback dialog, except that they do so in the form of a report that is generated from them specification code rather than from a conversation.  The report doesn’t replace conversations, but it does support the dialog and it gives concrete testimony to the developer’s understanding of the requirements at the time that he implemented them.

A stakeholder can read the specification document and gain the confidence that the developer understood the requirements, or that he misunderstood them.  As long as the developer strives for an ability to capture the specifications in clear and sensible language, a stakeholder will recognize his business behaviors and processes in the spec doc.

Subsequently, when the developers discipline themselves to write executable specifications in the language of the business, they are caused to think through the wording of a specification and this causes them to be constantly immersed in the consideration of the domain and the domain language.  Class libraries and API’s that emerge from this kind of consideration typically have a much greater affinity to the business domain that the application serves, and this is also a form of accountability.

By ensuring that the application code respects the domain language, the application code is more recognizable and thus easier to understand, which makes it easier to learn and easier to change and to maintain.  Keeping the software code true to the domain is a critical part of an application’s resilience to change and resistance to rot.  From a BDD perspective, respecting the domain language is as fundamental a design principal as testability.

BDD instills a 360 degree accountability feedback loop.  Stakeholders write stories; they add acceptance criteria to the stories; developers talk to stakeholders to understand to business of the story and to get an earful of the domain language; developers capture the acceptance criteria in domain language as executable specifications using a BDD tool; developers implement the application code using practices and patterns like Domain-Driven Design that further respect and enforce the domain language; stakeholders are given access to a report that is generated from the executable specifications that are themselves based on the domain model, and this report is used to vet the developer’s understanding of what was to be built.

A specification document is a developer’s way of saying, “I heard you ask me for this, and this is what I built (handing the user the spec document).  Have I correctly advocated your needs to the software?”

The spec document along with working software to play with as well as some form of customer acceptance test give the customer a tremendous amount of confidence that the developers are building the right thing, and that communication between customer and developer is unfettered.  This feedback also helps the developer to built better and more accurate abstractions, and doing so through the plain-old Test-Driven Development processes helps him build the right thing in the right way according to solid design principals.

Through BDD stakeholders and developers work to remain accountable to each other for the clarity of communication that ensures successful product development.

Posted in Agile, Behavior-Driven Development, Design | Leave a comment