Skip to content
Best Practices Ethics & Culture

Agile Webinar Primer: An Overview Of Agile Methodology

On June 16th and 17th, Star will be hosting a webinar on how to apply the Agile Methodology to your compliance program. To get you ready, we thought we’d offer an overview of this game-changing project management process

Over the last few months, your StarCompliance blogger and his fellow Star team members—literally every employee in every department at Star—have been undergoing Agile training. Five years ago, maybe even two, this would have been a highly unlikely scenario. Agile has long been viewed as the sole preserve of software development teams; it was, after all, invented and codified by software developers to improve the software development process. And while it’s likely the case that most Agile training today is still directed at those working in software development, the principles and philosophy behind Agile can and is being applied—successfully—to disciplines well beyond that original confine.

In that spirit, on June 16th and 17th Star will be hosting a webinar on how to apply the Agile Methodology to financial compliance. Allison Bacher of Quantum Of Value—a consulting and training firm that specializes in applying Agile practices to businesses of all industries and sizes—will be joining Star’s Director of Product Strategy & Marketing Tim Ward to offer actionable advice for how financial compliance teams can apply Agile to their everyday workflows. To get you ready, following is an overview of the Agile Methodology in general.

The story of the Agile Methodology’s genesis is so, well, storied, that your blogger’s wife—who works in software development—could recite the key events by heart over morning coffee. It goes something like this. In 2001 a group of 17 software developers met at Snowbird, Utah—a ski resort—to discuss what they saw as a serious problem. Software development had become mired in the sludge of corporate bureaucracy. Where it once had been nimble and responsive to customer and market needs it was now ponderous and numbingly slow to react. This makes sense: software as a professional and personal tool had been in regular use since the early 80s. As the companies that made it became bigger and bigger they naturally became more planning and documentation driven, and less agile. As result, by 2001 they had lost touch with customer and market needs.

Out of this meeting, the Snowbird 17, as they came to be known, wrote the Agile Manifesto. At just 68 words, it’s extraordinarily concise, but it’s not an exaggeration to say the principles expressed therein started a revolution in the world of software development. And the companies and teams that embraced these principles rediscovered the nimbleness they had lost. Here are the original 68 words:

Manifesto For Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation 

Customer collaboration over contract negotiation 

Responding to change over following a plan 

That is, while there is value in the items on the right, we value the items on the left more.

The Snowbird 17. Sequestered in the Rocky Mountains for a critical meeting that produced a key document from which a revolution flowed. Kind of like America’s Declaration Of Independence. It’s all very Founding Fathers. And perhaps also like the Declaration Of Independence—a founding document with principles that got much needed fleshing out in the US Constitution—so the very concise and high-level Agile Manifesto got its needed fleshing out in The Twelve Principles Of Agile Software, also created by the Snowbird 17 at their Utah redoubt. Here they are:

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity—the art of maximizing the amount of work not done—is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 

In this case, everything. This methodology is called Agile for a reason. The word “agile” gets at everything the Snowbird 17 and successive generations of adherents felt the software industry needed to be at the time, and would always need to be. Synonyms for agile include lissome, lithe, light-footed, flexible, spry, and, of course, nimble. Here’s a selection of key Agile terms that get at key Agile concepts, pulled from the Quantum Of Value website. View this very comprehensive glossary in its entirety here.

Agile Processes
Based on process-centric and iterative development. Requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

From Lean software-development methodology. It has three components: (1) a visual system for managing work; (2) limits to the amount of work in progress; and (3) work is pulled not pushed through the system.

Planning Poker/Estimation
A consensus-based technique for estimating workload. Mostly used to estimate effort or relative size of tasks. Planning Poker is useful for building team cohesion and fostering self-organizing teams.

Daily Stand-up
The 15 minute (maximum) daily meeting where team members coordinate their activities for the next 24 hours. It is purely for members of the team, and is not the time for reporting or for any other person to ask questions.

Self-Organizing Team
A team that manages itself through various means of communication and recurring, structured meetings. Such teams solve development issues together as a whole and decide on the best solution.

A timebox within which work is completed: that is, items from the product backlog are built and meet the definition of “done.” A Sprint may be anything from one week to thirty days.

The final, formal meeting at the end of every Sprint, used to reflect on how the Scrum Team worked. The focus is on what went well, what didn’t, and what can be improved during the next Sprint.

Scrum Board
A physical or electronic board representing the state of tasks in a current Sprint, often divided into to-do, in-progress, and done.

User Stories
A way of conveying work to be done, specifying the problem not the solution, and presented as an informal statement of the requirements (usually fitting on a 3×5 index card).

Story Points
The relative scale of effort required by a team to implement a User Story.

The Velocity of a team is the number of Story Points associated with stories that are finished over a given period of time, often one to four weeks. For instance, if the team completed eight stories that were each five points during a four week period, then their Velocity is 40 Story Points every four weeks.

A software development process in which progress flows through phases of conception, initiation, analysis, design, construction, testing, and maintenance, and can mean the customer sees nothing or next to nothing until near the very end. Highly iterative Agile was designed to be the complete and utter opposite of Waterfall.

As mentioned earlier, Agile has moved well beyond the sphere of software development—it’s processes and principles applied to a wide range of industries and disciplines. The Quantum Of Value website alone offers a sizable list of recognizable, non-software companies as clients, including: Barclaycard; Mastercard; Tesco; Chelsea Football Club; and the University Of Essex. And as you, StarBlog reader, already know, Agile has recently been pulled successfully through the halls of StarCompliance.

As a software development company, it certainly made sense for the Star development teams to adopt the Agile Methodology, but it’s also made a significant impact on marketing, your Star blogger’s home. Our small department already held daily standups—we’re a lean team of which a lot is expected, and we all have to be ready to shift focus rapidly as priorities change—so in some ways we were Agile long before we called it that. But we’ve also recently been through a Planning Poker/Estimation exercise, in preparation for incorporating Story Points and Velocity into our team processes; this will help us get a better handle not just on individual workloads but also team workloads. And because every department at Star now uses, or soon will be using, the dialect of Story Points and Velocity, marketing will be able to speak that common language and communicate more clearly with other departments on any project in motion.

Ready to discover how the Agile methodology can be applied to your compliance program? Join us for the FREE Star/Quantum Of Value webinar Applying The Agile Methodology To Your Compliance Program and find out: Tuesday, June 16th or Wednesday, June 17th.