I recently had the opportunity to attend a three day Agile development workshop. At a very high level, Agile development values making small, iterative changes over short periods of time, unlike traditional software development methods that generally involve a large release at the very end of a project. If you’ve heard terms like daily scrum, product owner, and sprint thrown around at your office, chances are at least part of your organization has implemented or is attempting to implement an Agile approach to development.
A Very Brief Introduction
A complete intro to Agile is way beyond the scope of this post, but I’ll narrow it down to the main points. Agile development begins with a product or application change backlog. Then, a team made of developers, a product owner (business resource with knowledge of the application/product), and a scrum master (meeting/conversation facilitator) is formed. A few changes are selected out of the backlog for the team to work on, at which point a 1-4 week ‘sprint’ begins. During those 1-4 weeks, the team meets daily to discuss the plan for the day and ultimately finish the chosen items from the backlog. When the changes are complete (according to your ‘definition of done’), there is a sprint review with the stakeholders, at which point they hopefully sign off and the process is repeated again, pulling more items out of the backlog. The core idea is incremental, deployable changes, instead of trying to tackle all of the items in the backlog at once and releasing in the very distant future.
One Big Productivity Method
I like to experiment with various productivity methods to find what works for me, and I couldn’t help but think of Agile in the context of one giant, team based productivity method. It seems to borrow a lot of core ideas from personal productivity methods. For example, during each sprint, there is a ‘To-Do’ board where the team is constantly moving items from ‘Not Started’ to ‘Working’ to ‘Done’. Agile also focuses on the idea of constant refinement and prioritization of the backlog. These are two of the key concepts behind the ‘Getting Things Done’ framework. You could even make the argument that a sprint is really just one big Pomodoro.
Where Does the DBA Fit?
Another idea of Agile is that for the most part, team members should be dedicated the current sprint. This can be a hard sell to DBAs because in most organizations, the number of developers is far greater than the number of DBAs. I had some conversations with the Agile experts running the workshop, and they said if this is your situation, it may make sense to pull the DBAs out of the normal scrum team and view them more as a service provider, or if you have multiple sprints going on across your devleopment team that require DBA time, the DBAs could form their own scrum team. I like the former suggestion as it seems like it would be a better fit for most organizations. If developer scrum teams view the DBA as a service provider, they can reach out and determine the lead time necessary to get DBA assistance, and build that into their sprint planning.
Agile development seems like a step in the right direction. Getting started quickly and showing progress by getting things done incrementally instead of all at once I believe can have a positive mental effect on people, which ultimately leads to a healthier work environment. We all know how good we feel when we cross off a nagging item on our to-do list, and Agile is trying to make that feeling a more common occurrence. I think the core principles can be applied not only in software development, but also in other business functions and your own life as well to create positive change.
Is your organization using Agile, and if so, has it been successful? I’d love to hear about your experiences!
