Month: February 2017

I funny thing happened since my last post…. I became a Certified ScrumMaster!

Some basic points before I ramble:  For the uninitiated, a ScrumMaster is one of the three roles that make up a Scrum team.   For the further uninitiated, Scrum is a software development process that attempts to fulfill Agile software development principles.

For the even further uninitiated, Agile is a set of principles that seeks to produce faster and better solutions via software by engaging customers early and often.  These principles have been distilled into the Agile Manifesto, which is generally one’s first introduction to Agile.  I’ve also recently been introduced to the Manifesto for Software Craftsmanship, which uses the cadence of the Agile Manifesto to add a focus on quality and professionalism to our work.

The main idea of Agile is that customer needs and value opportunities can and do change frequently, often several times a day.  Therefore, the process by which software solutions intended to meet those needs are built must be just as flexible, if not more.  This means that software developers and the customers they serve should not be held prisoner by yesterday’s expectations, but should be ready and able to respond to changes over the course of their projects.

One of the more popular frameworks used to help a development shop become more Agile is called Scrum.  Scrum consists mainly of static teams that focus on a cadence of time-boxed ‘sprints,’ each with their own concise and explicit goal.  At the end of a sprint, the team presents (and usually deploys) the finished software and gathers feedback on their work.  Additionally, the team self-evaluates and adopts changes necessary to improve their own performance.  They are then ready to proceed with the next sprint.

For our two day class, we were first presented with the history and framework of Agile. Then we were formed into teams and tasked with working through a simulation of Scrum.  This included planning our goals for the overall product, organizing sprints that would result in a production-ready result and presenting that result for evaluation.

I’ve been working on Agile teams for a couple of years now and am a fan of the approach.  One of the most valuable takeaways that I had from the class was knowing to observe the Agile principles before any process.  Scrum (or even Agile) is not a magic bullet that’s appropriate to all projects.  Therefore, you need to remember whether or not your approach is in keeping with the value you’re intending to realize, rather than just blindly following a process.  Some other explicit warnings were, “If you’re not automating you regression testing, you can’t be Agile.”  The same premise goes for controlling your inputs.  Meaning, you need to have that concise and explicit goal, rather than trying to ‘boil the ocean’ and do everything at once.