Agile, as a modern framework and approach to developing software, has evolved significantly over the last couple of decades. Today, agile means producing quality software in short, fast increments, also known as continuous delivery.
The rapid rate of technological change is forcing enterprises to reinvent themselves and provide more flexible approaches to addressing the needs of consumers and individual business units. This is precisely why agile adoptions and transformations are key. Business today is different than just three years ago, and organizations must be quick on their feet to keep up with the competition, or they simply won’t survive.
Knowing that agile is important is one thing, but the ability to properly implement the main principles, tools, and techniques of agile is another. Let’s explore several time-tested agile principles that, if properly implemented, will help your organization build innovative products that customers love.
Don’t Move Forward without Total Agile Buy-In
In order for agile to work, everyone in the organization who will make that transition needs to buy in. It’s that simple!
Now, it is obviously difficult to switch a team—especially one used to waterfall approaches—to agile overnight. It doesn’t work that way. However, a good way to onboard agile into an enterprise is to start with one product team and build consensus on the team through meetings, brainstorming sessions, and actual Scrum adoption in order to generate total agile buy-in within that team.
This means bringing all of your team members together—the UX team, the product owners, developers, and IT operations— and getting them out of their silos and introduced to agile.
It’s important to note that the entire organization doesn’t need to be agile to succeed. A prime example is BMW. It's not that you must roll out agile across the entire enterprise to succeed, it's that you need to roll it out within a complete business unit to be successful. While BMW's mechanical engineering side is unchanged, its software development side is totally agile, and they do not function at odds.
When You Know You’ve Nailed Agile Collaboration
There are a number of core principles and qualities that constitute a true agile project.
People over process and features over systems
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Putting people first means frequent and transparent communication to ensure that customer needs are being met at each stage of the development cycle. If the process or the tools drive development, the team is less responsive to change and less likely to meet those needs.
Within the Agile Manifesto, there are 12 key principles that characterize how agile works. Of those, three focus on the importance of collaboration:
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
In Scrum, we manage change in two-week cycles with whatever is being built set in stone, but what's happening next is constantly in flux until we commit to the work. This is reflected in the second underlying principle of the Agile Manifesto: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
No system is ever treated statically. In fact, you must work under the assumption that people, markets, demands, and everything related to the development cycle are in constant flux.
Iterative approach to product development and testing
Agile collaboration means that software development takes place in smaller segments, so that feature code is designed, developed, and tested in repeated cycles. This is undertaken through regular team sprints that produce working code, which can be regularly showcased to the customer.
The 10th principle behind the Agile Manifesto says, “Simplicity—the art of maximizing the amount of work not done—is essential.” This is probably the least understood principle but the one with the biggest implications.
The idea here is for development teams to focus on the “why” and then work backward to solve the customer problem. It’s the Pareto Principle, or 80/20 rule, in action: You have to ask yourself what 20% of the effort will yield your team 80% of the results.
Agile Team Roles You Absolutely Need
There are numerous flavors and approaches to agile and how to structure a team, but one of the most well-known examples is a Scrum team. A Scrum team is a cross-functional group, usually between five and 10 people, who have the skills, talent, and ability to define, build, and test a customer-friendly software solution.
My company has adopted the “Scrumban” methodology, a hybrid of kanban and Scrum, in order to support our needs as an agency and help us succeed in product development. For it to work for us, we use these three roles:
Agile project manager
The agile project manager is the facilitator of the agile development team and responsible for helping the team get the resources they need to reach their deliverables on time. This leader protects the team from problems and distractions and works with the product owner to ensure the development process is on track.
In addition to the classic ScrumMaster responsibilities, the agile project manager is involved at least peripherally in the decisions around the product and is empowered to provide lower-level product support, such as clarification on the details, or to make a quick decision on a feature, should the product manager not be available.
The product manager is in many ways the voice of the customer, and is ultimately responsible for the vision and definition of the product. The product manager ensures that the agile team works on the right features at the right time. This individual must liaison closely between the development team and customers to ensure a clear and deep understanding of what product features are needed in the application.
In addition to the classic product owner responsibilities, the product manager also helps the client understand our process and how to be a part of it, so they can take a larger role in development and be more involved with the creation of the product.
Scrum team members
The development team is a cross-functional group of members with the skills to build, test, and deliver digital products that customers and stakeholders love. That might include business analysts, user experience designers, developers of all stripes, and more.
The Scrum team is self-organizing and empowered by the organization to manage their own workflows. At the end of the day, it’s not just about coding, but working together to build an innovative product that is successfully tested and deployed.
Avoid These Roadblocks to Agile Collaboration
Many complex factors go into the success of an agile project. There is no magic formula you can point to and say, “This is the solution.” It’s easier to identify the roadblocks to an agile transformation.
With that said, there are many things frequently causing companies to trip over themselves when attempting an agile transformation. Here are my top four roadblocks for agile collaboration that frequently happen.
Unsupportive culture or environment
To work effectively, agile requires total buy-in throughout the organization. We’ve already discussed this point at some length above. But total buy-in also reflects a major cultural shift in the way an organization works, thinks, solves business problems, and delivers solutions.
Agile is a cultural transformation for any organization, and it’s easier if it starts with the executive leadership, but it’s not unheard of for organizations to start a transition to agile within a team and then gain support up the chain.
Unclear business goals
Developing a product just because it’s cool is not going to drive it through to successful delivery. From its start, an agile project must reflect the organization’s overall mission, vision, values, and goals, and those elements must be reflected in the actual work being done.
If there’s not a continual effort to organize the product roadmap into a series of incremental builds that are prioritized in a strategic manner, then the project will fail.
Limited agile skills
The success of an agile project really depends on the team’s synergy and their ability to work together proactively with passion to see the project through to completion. Coding skills are important, but they are not everything. It’s a given that your team will have coding and DevOps chops. But onboarding a team of strangers who don’t know the strengths and weaknesses of their colleagues, have never worked in an agile environment, or are stuck in a legacy mindset, are all recipes for disaster.
One of the fastest ways to fail at agile is to take a “mix and match” approach by trying to blend agile with waterfall under the wrong circumstances. It's not a matter of which methodology is better, but rather knowing when and where to use what.
Waterfall makes sense as a methodology in situations where you have a well-defined process to create a product, and you have “known unknowns.” It allows for the process to be optimized based on foreseeable issues, such as in manufacturing.
On the other hand, agile should be used when there is a lot of complexity, you have a lot of “unknown unknowns,” and the issues are not foreseeable. Agile uses the inspect-and-adapt method to account for those unknowns, allowing a team to react quickly and readily to shifts and changes in the marketplace and how the product needs to evolve.
Many enterprises are undertaking massive transformations to deliver faster and keep up with customer demands, but when this fails, it often can be traced to their inability to properly implement agile methodologies. By fostering a collaborative culture, encouraging the principles that support a true agile project, and being aware of the primary roadblocks to agile ways of working, you can set your teams up for success.