Agile is a philosophy for approaching software development that focuses on fast, iterative development cycles. The method is based on software delivery over documentation, consistent communication within teams and with users, and flexibility during product development.
While Agile is meant to be flexible, there are still guidelines and best practices to effectively implement the method into a company’s daily practices. The philosophy may be easy to grasp, but implementation takes work, patience, cultural changes, and a lot of communication both inside and outside of your team.
Whether you are the driving force behind adoption, the manager responsible for change management, or the developer in the midst of new team structures and processes, this list can help you find your way to true software agility:
Make sure the project management tools your team uses are in-step with agile processes, otherwise you are handicapped from the start.
Ideally, your work management and project management tools are developed with agile as their primary focus. According to the 12th Annual State of Agile Report by VersionOne, the top recommended tools by companies developing with Agile is VersionOne and Atlassian’s JIRA.
One of the most cited reasons for Agile implementations to fail (either specific projects or the entire transition away from waterfall) is lack of support from key leadership and stakeholders in the outside organization. Implementing Agile requires major organizational changes to create self-organized teams, creating and filling positions that may not have existed. This can cost time and money, result in a temporary slowdown in projects, or trigger fear of change in some team members.
Without a good understanding of Agile, it’s a leap of faith for key stakeholders to make that investment on the promise of better software output. This is a leap they are often unwilling to take.
The only way to avoid this risk is to constantly communicate with stakeholders to elevate their understanding. This includes why agile is so valuable and how it is being implemented. Everyone, especially upper-level leadership, should be bought in and willing to invest time and money to ensure the implementation is successful.
Generally, Agile implementation is driven by developers and/or by executive teams. What this means is that, too often, middle management is playing catch-up to understand the value and help drive the change. Ironically, middle management constitutes the front lines of change management.
As with outward communication, managers responsible for leading their teams through change must be bought in, understand the value, understand the process, and understand the best practices. This way they can become trainers for their teams and help with communication to outward business.
The core functional unit of effective Agile implementation is a cross-functional development team focused on a common goal. Too often, having this cross-function can result in either a loss of focus or a loss of functional growth. Matrix organization is meant to solve for this, as contributors have two direct managers with unique purposes.
The key to making matrix organization work is ensuring the purpose of each manager is crystal clear. One manager is there to lead what is being delivered (the software deliverables). The other manager is function-specific and is there to lead how work is being done (the software language, best practices, functional training).
Because Agile focuses on fast and consistent delivery of functional software over documentation, another pitfall is proceeding with development before the design is finished, or even started! This can lead to expensive rework later to scale products or even just to get people using it.
Design sprints apply the Agile principle of short delivery cycles to design. Timing these sprints to fit into development sprints will help ensure that any work being groomed has at least wireframes and a sense of the UX needs, and any work being committed in a sprint has clear visual guidelines (when necessary).
The team I was involved with had three people considered to be “business owners”: Product Owner, Product Manager, and UX Designer. By creating clear communication lines and responsibilities for each, this team was able to stay hyper-focused and hyper-effective.
More than just having them on the team, invite them to your standups, grooming, planning, and problem-solving meetings. By cross-training, they will more effectively integrate with development (like writing clear and concise stories). By representing the user, they also ensure the team always sees the value of the work they are doing.
Run concise and focused meetings only with those people who need to be there. Don’t start problem-solving during daily standups. Don’t argue priorities if a sub-group of people have come together during a sprint to solve a technical problem. A pitfall of Agile’s value of communication is that it can be taken too far, with too many meetings and not enough heads down time to deliver.
Constant delivery of functional software can put pressure on teams to ignore technical debt that doesn’t have a clear functional value-add for the business. It’s always hard to prioritize “it’ll do the same thing, but the code is cleaner” over “it will do something new.” However, when the natural entropy of a growing code-base goes unchecked, the ramifications can be big. There can be issues scaling, delays adding new features, mystery bugs and more.
Communicate this risk to the business owners on the team and agree to reserve a very small amount of effort to technical debt on every sprint. If this work is delayed too long, eventually it will become necessary to stop all new features and fix it, and no matter how much communication you have, stakeholders will not be happy about that.
This is a critical cultural shift for any change. Important changes do not happen overnight; they are a process with a learning curve. By valuing learning over success, you reframe “failures” as “opportunities.” The most effective teams know that failure is actually a necessary part of any process, so the best thing is to fail early and cheaply. It’s a good thing, as long as you can learn from it to increase chances of success moving forward.
Everything here I learned from my scrum master: with the right one you won’t need articles like this! A scrum master should be present every step of the way for this very purpose. They support and guide the people and processes that implement the agile philosophy to deliver valuable and desirable software.