Throughout our Getting Started With Agile series, we’ve dove deeply into each of the 4 main values of the agile manifesto. During this dive, we’ve unpacked not only the intent behind each value but also the underlying ideas and concepts that led to the creation of that value.
In this final installment in the series, we’ll discuss concrete strategies for applying each of these values so you can put these ideas into play with your own team.
The first value of the agile manifesto stresses the importance of the interactions that occur on our team over simply relying on processes or tools. Few would argue the importance of this, but how do you encourage these interactions on your own team? The first step is identifying how well your team is collaborating in the first place.
While it can be easy to recognize pockets of healthy of collaboration on your team, spotting a lack of collaboration can be more difficult. A great place to start is understand how reliant your team is on your existing processes and tools. For example, does the majority of your team’s conversations seem to happen only on comment threads in your project management tooling?
If so, then it might be time to take a break from this tooling to see if doing so encourages more face-to-face interactions on your team. To do so, try stepping away from your favorite project management tool for an iteration to see how your team solves for situations where conversations can no longer occur from a keyboard. With any luck, you’ll find that your team learns the benefits of communicating in real-time throughout the day and even seeks out more opportunities to do so.
Even if you decide to bring this tooling back into your process at later a date, your team is likely to have a newfound appreciation for the true value that it can provide along with a healthy wariness of the dangers of over-relying on it.
The second value of the agile manifesto reminds us the only true measure of progress for our team is delivering working, usable software. All other measures, such as design artifacts delivered, documentation created, or even velocity, are nothing more than supporting actors in service to this goal. But what do you if your stakeholders seem to be focusing on the wrong measures of success for your team?
If you find yourself in such a situation, then your first step is to shift the conversation to uncovering the actual value that your team is trying to produce. Once you’ve done so you can then discuss how the current measures that your stakeholders are focused on map to that value.
Maybe your team is seeking to increase sales by adding new and differentiating features to an existing product, or maybe your team is seeking to improve your organization’s operational efficiency by streamlining an existing tool used deep in your organization. Whatever your team’s goal is, odds are that the number of pages of documentation that they are producing along the way isn’t the best measure of whether they’re on track to achieving it.
Once you’ve helped your stakeholders see that your current measures of success may not be as informative as they once believed, you can then begin to explore other measures that may be more indicative of your team’s progress.
Your next iteration review is a great place to start this conversation. You can begin by reviewing what the goals of your project actually are and then discussing whether the progress your team has made since the last iteration review has actually moved the project to its the goals. Once everyone has a better understanding of what progress actually means, you can then begin to tease out more meaningful measures of success of each increment of working software your team delivers. This may include metrics such as user adoption and satisfaction, uptime or other quality metrics, or revenue directly generated as a result of that increment. Whatever metric you choose, as long as it’s dependent on the delivery of working software, you’re likely to find that it’s much more indicative of your team’s long-term success than number pages of documentation written.
When was the last time you interacted directly with your customers? At the last iteration review? Only after the last release? Not since your project kicked off? Customers who?
The third value of the agile manifesto, reminds us of the importance of working closely and collaboratively with those who are the most likely to hold the key to our success…our customers.
Time and time again we see that one of the greatest predictors of a project’s ultimate success is how closely that project’s customers are involved throughout the process. But even with this experience, many teams are still hesitant to invite their customers into the fold.
For many teams, encouraging deeper involvement from their customers pushes them out of their comfort zone. In addition, many customers simply look to their development teams as the experts and are unaware of the value that they themselves can bring to the conversation. But regardless of the reason that collaboration does not occur, it’s our responsibility as agile software development professionals to bring our customers into the conversation.
A great place to start is to begin inviting your customers to your team’s iteration review to give them the opportunity to provide feedback on work that’s in progress. But once they’re there, don’t give them the luxury of simply sitting quietly.
A successful iteration review is much more than a mere demo, it’s a productive two-way conversation. Your customers should provide constructive and specific feedback to your team on how closely the work that they’ve produced will serve their needs once it’s released. But don’t settle for a simple thumbs up or thumbs down…dig deeper to understand why the team’s work is or is not inline with your customers needs. This will help everyone better understand the ultimate goals of the project and enable your team to make more informed decisions along the way.
Finally, if the conversation during the iteration review reveals that changes to the project should be made, strive to make these changes sooner rather than later. Incorporating changes quickly, even as soon as the next iteration, will help demonstrate to the customer the power that their feedback can have to positively influence the direction of the project, even while it’s in progress.
If you’re really putting working software in your customers’ hands each iteration then you’re likely to learn a lot about your product…some of which might be unexpected.
The fourth and final value of the agile manifesto tells us that one of the greatest keys to success of agile teams is their willingness to adapt to change as it occurs rather than insisting on following a predefined plan. Yet, despite this, many teams cling tightly to outdated and obsolete plans even when everyone secretly knows that these plans bear little resemblance to reality.
If you find yourself in this situation, then it’s time to have an honest conversation with your stakeholders about how the reality of your team’s situation compares to the plan that was originally laid out. But don’t despair, all hope is not lost.
There are always options to rethink your plan and still deliver the value your stakeholders need. One of the simplest options is to discuss the impacts of lengthening your schedule. However, pushing the delivery date often isn’t an option for many stakeholders. In these cases, then it’s time to consider whether every feature that was originally desired is still critical to the project’s success. For example, could some features be removed or at least deprioritized to later release?
Finally, there’s a third option that’s often missed by both teams and stakeholders. Rather than removing features or pushing delivery dates further out on the horizon, consider whether the complexity of features that are already slated can be simply be reduced. By reconsidering what the true goal of each feature is, teams often discover simpler and more efficient ways to achieve that same goal as the project progresses.
However, adapting to change isn’t limited to just your project plan. Often our original ideas of how customers will benefit from our project or the needs that it will fall flat once our project sees the light of day. But by listening to our customers’ feedback on each increment of product and incorporating that feedback into future increments, we can continuously adapt and evolve our vision of the needs our project will fill and improve our project’s chances of success.
Thank you for joining us on this journey to better understand the agile values that comprise the core of the agile manifesto. By building a solid understanding of the ideas that underlie each value of the agile manifesto you’ll not only be better prepared to apply the true ideas behind these values, but also better positioned to recognize opportunities where you can begin applying these values with your own team.
For it’s through the faithful application of these values that you’ll be able to greatly improve the odds of success of your own team.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
Tags: How to
