Yesterday a client asked me about the difference between Agile Software Development & Scrum (development), followed by whether it was possible to apply the same frameworks to a traditional business practice or environment.
Recalling an earlier article I wrote back in May on Executing with Strategic Speed, where I briefly touched on the importance of agility, I was inspired to delve into this topic further.
One need only note the following Wikipedia definition to understand my excitement at answering the initial question; Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
Note the key words / terms used here such as disciplined, frequent inspection, adaptation, a leadership philosophy, teamwork, self-organization, accountability, best practices, rapid delivery of high-quality. I especially love how it ends.. business approach that aligns with customer needs and company goals. How can you turn down an offer like that?
Back to the initial question, I went on to differentiate these terms in the following manner
- Agile (Software Development) is a methodology; a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams
- Scrum (Development) is a framework (subset within a methodology); an iterative, incremental framework for project management and agile software development
The words Agile / Agility themselves refer to the ability to change position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, endurance and stamina. However, the key to guaranteeing Agile effectiveness is the regular use of pulse checks. In addition to other relevant articles regarding the framework for pulse checks, if you do a search on this site you’ll find at least another 12 references to how & why this simple little tool is so effective. Agile without pulse checks will only guarantee cost over-runs, delayed delivery cycles & misalignment on market/business requirements.
First, think of the Product Backlog as your goals or desired outcomes as a consequence of the successful execution of your strategic plan.
Second, think of the Sprint Backlog as the next allocation of work that’s been committed to over the course of the coming quarter, but hasn’t yet been assigned deliverable dates and or milestones.
Third, before you schedule your next Sprint, which could be a 1 week, fortnight or month interval of consistent work period, start working on your S.M.A.R.T.E.R. metrics which will actually define the activities to take place in order to achieve a desired & predefined outcome.
Let’s pause for a moment.. I prefer the mnemonic S.M.A.R.T.E.R. to the previously used S.M.A.R.T. because we now add Ethical & Reevaluate into the equation. I strongly agree we were missing before this type of checks & balance before. When you want to accelerate anything, there is always a compromise involved. You’re either going to compromise quality, client satisfaction, cost, deliverables, time or something else. It’s important to evaluate what you’re willing to compromise & will minimally affect your company or strategy as a whole. This is the key to ensuring you don’t become a slave to processes, goals or objectives.
Right, now that we’ve got that clarified let’s move onto the last bit which is the Working Increment or the Deliverable itself. Only through pulse checks along the way, what is commonly refereed to as Mid-Sprint meetings, processes or evaluations will you ensure that what you initially set-out to have as an outcome will actually be delivered. This is also a great time to validate the market or strategic relevance of the same against the original goal. Here I’m speaking more in terms of a business practice, but it’s still relevant to software development as well.
Now think about your own business, or even life goals. How can you break down that BIG vision or desired outcome into smaller deliverables that will still give you a sense of achievement & chip away at the larger overarching goal? How can you spoon feed your clients, your families or your own needs in a continual / contiguous process instead of going for the Big Bang approach? Warning.. Big Bang is riskier & you might just find the answer at a moment that is no longer relevant for you or your business.