We recently wrapped up a smallish project for a client that all started with an email. 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 defects that we found in some pre-existing code and handled a few small requests for additional work “while we were at it.” We feel confident our client now has something significantly better than before the 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 label 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 drive technical quality), we responded to requests, and we delivered working software.
We’ve read remarks of people who can’t imagine developing software with agility unless the work uses Capital-A “Agile” tools and “Agile” processes. We think there’s an irony that a certain amount of rigidity emerges as there is insistence upon the latter tools and processes (I suppose we might call it “Rigid Agile”). These things probably do sound good on the surface but we’ve considered the arguments and in the end we 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 and needed.
When we work in collaboration with clients’ existing teams, which is 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 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 might say that we were founded to build software with agility but now to avoid confusion we use the term “adroitly” … which means agility but even sometimes even without Rigid Agile.