How to Nail Agile Collaboration and Build Better Products

[article]
Summary:
The rapid rate of technological change is forcing enterprises to reinvent themselves and provide more flexible approaches, so agile transformations are key. However, 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 time-tested agile principles that will help your organization build innovative products that customers love.

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.

Collaborative style

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.

Embracing change

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.

Project simplicity

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.

Product manager

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.

Fragmented approach

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.

User Comments

4 comments
Oluwabori Odunaike's picture

First there is nothing like a project manager role in Agile. Having a project manager mindset calls for micromanaging which ultimately gives them the false idea that they are "leaders" rather than servants. The Scrum Master is the facilitator and ensures agile principles are embedded in the team, as well as supporting the development team to achieve their outcome/goals.

Only the product owner has the final say in product decisions. No one else is empowered to make any decision on a feature. Not the Scrum Master or any project manager. And only the team can determine/clarify details of work to be done, by asking questions from the PO, not any project manager. The Scrum Master is there to ensure all these processes are followed to enable agility.

April 23, 2020 - 3:09pm
Matthew Chen's picture

Hi and thank you for the comment!

 

I absolutely agree with you that in Scrum there is no such thing as a project manager. However, the agile manifesto itself does not prescribe what roles are on a team because it is the philosoly of how we create software: individuals and interactions, working software, customer collaboration, and responding to change. I would like to focus more on the "individuals and interactions over processes and tools" portion of the manifesto.

Differnet teams have different needs and there's quite a few flavors of Agile out there in addition to Scrum that addresses those different needs. In Foxbox's case, we operate differently than a traditional scrum team because we are an agency and need to adapt to the how we building software for clients rather than build a product for one's own company. We started out following Scrum, but ended up experimenting with the roles of scrum master and product owner and have found that what we are doing now allows us to be more agile than if we were stricltly following Scrum. I would not perscribe my company's configuration to any other team without extensive conversation, experimentation, and buy-in, but this is what works for my team.

May 7, 2020 - 12:37pm
gehex iopmali's picture

Teamwork has already led many companies to success.  But I think teamwork would be better if people would see each other sometimes, not just from the monitor screen.

April 28, 2020 - 5:46pm
Matthew Chen's picture

I completely agree. While Foxbox is a remote first company, we take great pains to coordinate events where the team can get together and work in person, even if it's only part of the team at a time. Something is lost when you are remote only and have never met the person on the other side of the screen in person.

May 7, 2020 - 12:36pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.