SHARE:
Is Agile Really That Successful?
When done well, Agile teams enable companies to be responsive to market changes, stay ahead of their competitors, and focus on business value and customer needs in a cost-effective and efficient way. The challenge with Agile methodologies in large enterprises, however, is that one integration mistake can easily lead to many. The way in which enterprises integrate the methodology can go off the rails, and a process that’s supposed to create an advantage for companies becomes a detriment to their success.
Thinking about executing a company-wide Agile transformation? Below are the most common Agile pitfalls, along with steps you can take to avoid the same mistakes and optimize your probability of success.
Lack of communication.
As in many areas of the workplace, a lack of clarity and communication in large organizations or enterprise teams can spell disaster and cause things to quickly fall apart. Large enterprises often have large teams with many remote members, so clear and open communication across the team and its managers is particularly essential.
For everyone who will touch the Agile project, and especially for those working remotely, it’s important to make it easy to information-share and collaborate. The right Agile project management tool will help facilitate this rather than hinder it, particularly when you’re working with a distributed team. Modifying the structure of your teams is the long-term goal, and aiming to get business units aligned in the meantime is the short-term goal.
Not getting everyone on the same page.
When it comes to successful Agile implementation, it’s important to make sure your organization’s project team is “all in.” Having necessary resources and support is critical, and a lack of either can cause your process to break down. Transitioning to the Agile approach requires a shift in mindset, and implementing an Agile process while still relying on waterfall or other legacy strategies for some of your operations can be confusing to team members and detrimental to your success in the final product. Agile culture supports elements like rapid movement, faster release cycles, and continuous development. When there’s a lack of overall organizational support or unwillingness by team members to follow Agile principles and values, it likely will fail.
It’s also likely that your Agile team will need to intersect on projects with non-Agile team members. Reinforcements on your part for cross-functional teams may be necessary to ensure smooth communications between teams. Realize that non-Agile teams that work on a different schedule than their Agile-team counterparts may not understand the importance of adhering to the Agile team’s timeframe. It’s up to you to facilitate this understanding.
To succeed in getting everyone on the same page, you must be hands-on with the transformation for all key stakeholders (even those not directly involved with Agile projects) to ensure that they’re on board and will be supportive in fostering an Agile environment. Extoll the benefits of Agile with lunch-and-learns and other educational opportunities to help shift the mindset of your organizational culture. Helping those from the top down understand how Agile can help them reach their short- and long-term goals, and how the results of Agile projects have the ability to make far-reaching positive impacts across the company, can help hesitant individuals or departments get on board.
Contradictory methods of measuring success.
The way your organization measures success must also be consistent, as Agile results shouldn’t be based on traditional frameworks. If the performance-management objectives of the management team aren’t aligned with the development team, the objectives of the organization as a whole may need realignment.
Following rules that aren’t providing value.
Everyone has slightly different work styles, and when it comes to working on an Agile team, it’s no different. In fact, it’s arguably even more vital to observe and honor this distinction. Are you being too rigid with the decisions that have been made in your Agile development process? As “Healthy Software Developer” Jayme Edwards points out, some people love to code but hate documentation. Forcing this type of worker to document every little thing simply because it fits a textbook definition of “Agile” actually goes against the spirit of what Agile is supposed to help your team do.
Edwards advises managers to stop doing what isn’t working, and instead adjust to your team’s unique needs. Don’t do something just because it’s traditionally an Agile “rule” or in the “Scrum Guide” if it’s really not providing value for your team.
Putting in a process that allows everyone to work differently and work to their strengths, rather than demanding that everyone work the exact same way, can be much more intuitive and successful.
Focusing on business needs over team and customer needs.
When Agile processes are only being mandated and driven by the business, instead of the people doing the work, problems arise. Agile processes aren’t about delivering products faster, but when it’s sold as such it misses the point and puts pressure on people to produce as much as possible in a short amount of time. The result? A product that doesn’t provide value to the customer, unaccounted for scope creep, or increased revenue to your business.
Too-large teams.
By design, it’s easy for teams to get too big in a large enterprise structure, and too-large teams can be disastrous for Agile teams in particular. Too-large teams can also result in more complexity, bigger and less-efficient meetings, and lower productivity. These types of teams often also suffer from multiple bosses within a team, which hinders the spirit of self-management and individual decision-making, and discourages the innovation typically found on a flat-structured Agile team.
What Is The Recommended Size Of An Agile Team?
According to many experts on the matter, the optimal number of members for an agile team size is about five to 11 people.
To combat this, Amazon has a rule called the “two-pizza team.” The ideal team should be small enough that its members can be fed with two pizzas. Regardless of the rule you implement, the end result should be more engagement, connectivity, and cohesion across your team. Only partially assigning team members to an Agile project can also lead to a lack of commitment to the cause and resentment among team members. It’s advised that to keep Agile teams stable, you dedicate people to the team and do not move them between or across teams as demands ebb and flow.
Failure to get feedback.
Scrum is about change, not speed—and it adds an extra step on the front and the back by design. On the back end, it’s about getting valuable feedback from customers to find out what the customer didn’t like, or where the team went wrong. After realizing that, the step on the front end is to adapt to what the customer wants, and in turn adapt and change the backlog.
Failing to hold “retrospective” meetings to make sure you avoid making the same mistakes next time will doom you to repeat them. Put someone in charge of scheduling these regular meetings, and make team members feel safe and supported in honestly discussing what went well and what didn’t. Make adjustments as needed, and continuously evaluate and tweak the process to fit the team’s and the customer’s needs.
Not adopting an Agile mindset.
Agile coach John Yorke says that the three main reasons he sees so many fails in a framework like Scrum is due to each role (scrum master, product owner, and the development team) failing to adopt its key mindset. It’s crucial, he says, for the scrum master to have an Agile mindset, for the product owner to have a customer mindset, and for the development team to have a production mindset toward delivering a well-designed, high-quality, and maintainable product that fits the customer’s needs. When any of these key mindsets are missing, things begin to break down.
Lack of experience with Agile.
Many enterprises try to implement Agile without first understanding much about it or how to successfully integrate it into their organization. Sometimes, companies try to implement small projects within a large context or, alternatively, turn large-scale projects into Agile processes. Trying to do this without the right knowledge in place will make your project much more likely to fail.
Another element of this is taking on an Agile project management tool that’s too complex and difficult to use, which can result in a breakdown in process and team members’ frustration or refusal to use the tool.
It’s important to take a step back and ask the right questions before diving into Agile:
How do roles change within this new approach to developing software?
o What does it mean to work in iterations?
o What are our current strengths and limitations?
o How will Agile affect the various roles on our teams, and how will we train team members?
o What metrics will be important to measure success? How will we obtain them?
Create a game plan and determine how you’ll provide necessary experience through pilot programs, coaching, and training. Managers need to be fully involved and understand how self-organization works, and set up an environment where that can thrive. Creating a testing strategy is also essential, as is providing adequate training for QA personnel and selecting a good Agile test management tool. By keeping these challenges top of mind and developing a cohesive map of strategy and tactics before your large enterprise dives into Agile, you’ll set your organization up for success.
SHARE: