I’ve spent most of my development time in either waterfall or agile – but, at least at the outset, it was unintentional.
When I first set out to build a web application, I decided to simply do what was needed to deliver the best product I could – which meant, intuitively to me at the time, following a defined path: gathering and documenting the business requirements, designing and building out the database to match, wireframing and designing the front end, coding the front end, integrating the front end with the database, testing out the application, hardening the application, and then cycling through from there based on feedback from the business unit.
This, in a nutshell, was the waterfall SDLC.
And, while the product wildly exceeded expectations and became a market leader, it shouldn’t be a surprise it took me 18 months to build and deliver it. Waterfall works, but speed and adaptability certainly aren’t features.
Over time, we would catalogue feature requests and bugs, and then package up and release them once every 6 months or so. (Again, waterfall.)
Clients (internal and external) began to want their new features quicker, and certain bugs couldn’t wait until the next release (for example, because of the damage it could cause to the core data) – so I moved to releasing updated code every week, sometimes even faster, even when it only had a small slice of the backlog.
Although I didn’t know until later that we were shifting to an agile approach, this again simply seemed intuitive. We found the smaller iterations provided us with a higher-quality application – and, most importantly, happier clients.
One artifact of this switch was the ditching of “version numbers”. Before we moved to a faster release cycle, I kept track of what version we were on by “point releases” and “dot releases” (e.g. version 1.01.00 gave way to 1.01.01, which gave way to 1.01.02, which would at some point roll to 1.02.00 and so on).
Once we moved to weekly releases, it was kind of ridiculous to keep track of version numbers. At that point, the product was a dynamic, living application that was constantly changing – and it was (and is) a web-based SaaS, not a traditional desktop product. So, I ended version numbers (although we obviously still tracked source code changes internally).
I’ve since learned much more about agile development, including its processes, artifacts, and tools – and am a big believer in its benefits.
Proud To Be A Certified ScrumMaster.
Last week, I (finally) took the first step in formalizing my agile journey: I’m proud to announce I’ve earned the Certified ScrumMaster designation (CSM) from the Scrum Alliance!
The best part of earning the CSM certification was, like my journey to agile, somewhat unexpected.
I figured the Certified ScrumMaster process would be like any other certification – uptake the material, master it, and demonstrate mastery. But, I ended up learning more than just the testable material.
I discovered that the reason we succeeded at agile in my development work (even though unintentionally) was because we were a small team, with each of us having diverse coding capabilities. (Scrum requires no more than 9 team members, and does not recognize job titles – database programmers, UI designers, and QA testers are all “developers” in Scrum.)
And, true to agile, when we found a solution required a skill that maybe we didn’t know all that well, we went out and learned it (which, in Scrum, is usually called a “spike”). Agile doesn’t presuppose that you know anything, nor does it require the scrum team to have every needed skillset, but instead provides a solid framework to keep learning and adapt as product needs evolve.
I believe our ability to be nimble in development was a factor in why our law firm grew to a position of market leadership – we were able to deliver innovative solutions to our clients’ problems faster than others.
We were lucky to have stumbled into the right mix for agile to organically grow and thrive, but given the choice, I’d choose agile again (and again and again – yes, that’s my feeble attempt at agile humor).
How is your organization agile? How do you do Scrum?
If you’re an employer in the North Dallas area (Frisco, Plano, Allen, McKinney, Richardson, Addison, Carrollton, Irving, or Lewisville) – or have a remote-working IT position to fill – let’s connect and discuss your IT needs and related open position(s), particularly if you have needs centered on SQL Server.
–Best, SJ