Recently we wrapped up a small project for a client.
It all started with an email from our client. There were a couple of phone calls getting started. Partway through development we needed to discuss details in an area of our client’s expertise; a little lengthier phone call with an exchange of concrete illustrations did the trick.
While engaged in the work we corrected some defects that we found in pre-existing code and handled a few, small requests for additional work to be done “while we were at it.” We feel confident our client has something better than before this project began – including the pre-existing code. The software is now running as desired, and we’re pleased to have executed the project.
Here are things we didn’t do: We didn’t have scrums. We didn’t pass a talking stick around the room. We didn’t use sticky notes. We didn’t document a product backlog. We didn’t write stories. We didn’t bother with labeling our engineering tasks with Agile buzzwords even though we could have. Our client was interested in working software.
Here are a few things we did do: we collaborated with our client, we created software, we used tests (with mock objects and data to promote quality), we responded to requests, and we delivered working software.
We’ve read blog comments suggesting there are people who can’t imagine developing software with agility unless the work uses (capital-A) “Agile” tools and “Agile” processes. There’s an irony we think that a certain amount of rigidity emerges with insistence upon the latter tools and processes (I suppose we should call it “Rigid Agile”). These things probably do sound good on the surface but we’ve considered the arguments and believe that creating the software is and should be the focus.
The simplicity of what we did certainly was influenced by the small scope of the project, but it also had to do with choosing what made sense to build the software our client wanted.
When we assist clients’ existing teams, i.e. a different scenario from the project mentioned here, those teams may have already chosen from among all kinds of specific practices or methodologies. We view our role as helping them to be successful in building the software regardless of the methodology that was selected. That’s because it’s not about the process: it’s about the software.
We’d like to say that we were founded to build software with agility, but now to avoid confusion we use the term “adroitly” … which means agility (even without Rigid Agile.)