12 Principles of Agile (According to MercuryWorks)
In the beginning of 2001, a group of seventeen industry leaders who were looking for an alternative to the traditional, heavyweight software development processes convened in the mountains of Utah and authored the Manifesto for Agile Software Development. This document has become the foundation for Agile development, where individuals and team members, actual working software, collaboration, and responding to change is valued more than processes, tools, heavy documentation, contracts, negotiations, and rigidly following a big, up-front plan.
Within the Manifesto is a set of a dozen guiding fundamentals, known as the 12 Principles of Agile. Like many modern day software shops, MercuryWorks employs the Agile methodology (and mindset) to build enterprise software for our clients. However, since this Agile business has been around for over 20 years, the founding principles aren’t referred to as much as they once were when this was all new, so we’d like to take a moment and take it back to the roots.
Below are the 12 Principles of Agile, and how MercuryWorks uses these concepts daily:
Agile Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
MercuryWorks solves wicked problems. Ridding businesses of their problems is of the utmost value, and our teams deliver software rapidly—almost immediately upon engagement. If you are foreign to the Agile way, a major concept is its iterative nature. We break large chunks of work into small, manageable pieces, so we are able to deliver (and show) working software every two weeks, and in some cases daily.
Agile Principle #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Because we are Agile and therefore very iterative, we are built in a way that allows us to welcome change. We don’t plan for an entire calendar year. We plan for a Program Increment (~6 weeks), and then go to work. Within the Program Increment is two or three 2-week sprints, so if a client has a changing requirement, we are able to pivot in the next iteration.
Agile Principle #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
MercuryWorks holds this principle near and dear. It is a standard practice of ours to host a Sprint Demo, every two weeks, at the end of an iteration to show our clients what we have built and solicit feedback. Clients will be able to see and touch their investment, and then publish it “live” to production after giving a blessing during the demo.
Agile Principle #4: Business people and developers must work together daily throughout the project.
We subscribe to daily communication. We do this in several ways. First and foremost, our developers have a team meeting every morning (Daily “Scrum” or “Standup”). During this ceremony, the team members talk about what they accomplished the day before, what they plan on starting (and finishing) today, and any issues that they may be facing. This allows us to get feedback to the business, almost in real-time.
Mercury also uses skilled Product Managers to act as the business liaisons. Our Product Managers are intimately in-tune with their clients, and are able to speak on their behalf should the development team have questions about requirements.
Agile Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
MercuryWorks has many tenured developers who have been with the company for years. When we hire new team members, we have a rigorous interview process to ensure we are only hiring rock star consultants. Our teams of experts become trusted as a whole, and are self-organizing in many ways.
During our P.I (Program Increment) Planning, the individual teams present business plans to Mercury leadership, and once given sign-off, are given the environment to get work done, avoiding lag time by micromanagement. Our expert teams are then enabled to do what they do best, and that is deliver high-quality software in short, iterative bursts.
Agile Principle #6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The world has changed a lot since 2001. As a matter of fact, the world has changed a lot in the last 12 months. That being said, with the software development workforce being predominantly remote, “face-to-face” isn’t as commonplace as it once was. However, we heavily utilize video conferencing tools (Microsoft Teams, namely), meet daily, with cameras on, so that we can see each other’s smiling faces and talk about the most valuable (client) things…for that day.
We give the same treatment to our clients: dressed to impress, cameras on, and we meet often.
Agile Principle #7: Working software is the primary measure of progress.
In the Client Services space, this isn’t as cut and dry, but at the end of the day, we are a development firm, so our software speaks for us. We believe in this principle so much so that we have built our own custom software to keep clients up to date with progress. We have a tool called MyMWKS, which is a portal that each client has access to that delivers real time project metrics. At the end of each sprint, we actually have a feature called Progress Reports that emails a client with a list of all the new features that were developed, and what they can expect to see in the Sprint / Product Demo.
Agile Principle #8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
MercuryWorks has a very mature process which drives pace. “Program Increments” were mentioned earlier, but this is the ceremony where we lay out all of the work we wish to accomplish over the next 6 weeks. While that “P.I” is in-flight, we are working with our clients on initiatives that will be in the very next P.I.
We meet with our clients weekly to gather requirements and refine all of the items in the Product Backlog. We then meet with our clients bi-weekly to show off the features that are ready to ship. This keeps us in a perpetual feedback loop, where communication and collaboration run high, and the pace is organically sustainable.
Agile Principle #9: Continuous attention to technical excellence and good design enhances agility.
Mercury prides itself on its technical acumen and expertise. We use industry best practices, utilize cutting-edge technologies, employ the latest software tools, and have some wicked smart developers on our teams. Our DevOps practice, coupled with our Agile mindset, enables the teams to pivot on a dime.
Agile Principle #10: Simplicity—the art of maximizing the amount of work not done—is essential.
Our professionals think in MVP terms (Minimally Viable Product)—by definition, the smallest body of work that we can ship but still deliver value. Large, complex enterprise software systems and the list of features associated can spiral out of control rather quickly.
This is why working with a professional services firm becomes important, as our trained staff is able to compartmentalize, dissect, and focus on the things we need to do today, leaving all the work we don’t need to do until tomorrow where it belongs: in the product backlog.
Agile Principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.
“Self-organizing” teams have been mentioned earlier in this piece, but we’ll give it some greater attention here. Historically, the traditional pyramid-shaped enterprise slowed development progress. When there are massing “Change Order” and approval processes in place, it makes it difficult to get actual software features done.
Mercury’s team of rock star professionals have embraced the self-organizing cultures to focus on the most important metric: delivering working software.
Each team has a Product Manager who becomes an extension of our client’s business. Each team also has every necessary (technical) discipline to be self-sufficient. So, when the Product Manager is able to be the proxy-business owner, and there is a team with all of the tools, the only thing left for us to do is organize and deliver.
Agile Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
MercuryWorks does this both internally and externally. At the end of each sprint, the internal development teams host a ceremony commonly known as the “Retrospective.” Every two weeks, we take a look at the sprint that has just passed, assess what went really well (so that we can keep doing that), and what could have gone better (so we can solve that issue and avoid a repeat).
We utilize a similar format with clients. It is typical for Mercury to meet with its clients to do monthly reviews (of software features, roadmap, progress, budgets, future projects, all the things, etc.), and during that session we have made a practice of retrospectively analyzing the last month together. What went well, what should we keep doing, what could have gone better, and what do we do (together) to improve?
While Mercury didn’t invent the Agile methodology, practice, and mindset, we sure drink the Kool-Aid. This is a proven way for groups to work together and to foster collaborative environments. We’ll continue to ride the Agile bus as we create great apps, solve wicked problems, and forge passionate client relationships.