Why leading agile teams focus on customer value
How well do you know your customers?
🧐 Well, you know they use your product…
🧑💻 You sometimes write user stories for them, but not based an any particular persona…
🕵️ You did talk to a customer once; it was interesting, but now you aren’t sure where those notes went…
So that you can provide value to your customers, you really do need to get to know them well. What are the goals, motivations, and pain points that bring them to your product?
This is pretty important stuff, so let’s take a look at 7 reasons why it’s good to have a healthy level of customer obsession in your agile teams...
1. Agile and customer value go hand-in-hand
Agile is all about the customer. At least, it should be.
It’s right there in the first two agile principles:
(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Manifesto For Agile Software Development
If you want to take an agile approach, you’ll definitely be putting your users at the heart of your development.
2. Each sprint should deliver a better product, and more value, for your customers
One reason why agile should (in theory - we’ll expand on this shortly) benefit your customers is that every two to four weeks, you’ll ship something new. It may not be a whole new feature each time, but every update, UI improvement, and even every bug fix is delivery of incremental improvement.
This is kind of a big deal when you compare it to traditional project management approaches.
With a waterfall approach, customers could be waiting months or even years before seeing any changes. In many cases, by the time updates were released, customers, technologies, and requirements had moved on.
But by taking an agile approach, you:
- Consider and incorporate user requested updates, features, and changes at any time
- Regularly add new features to a roadmap and incrementally roll them out in weeks or months, rather than years
- Can see early on if something’s not working, because you invite your users to report issues and provide feedback right away
- Show your users how the product is developing and growing
- Keep your product moving forward, and the customer is moving forward with it
- Grow the value your product provides to your customers over time.
However, it’s important to note that all of these really awesome benefits only apply if you’re prioritising your backlog and choosing features with your customers’ best interests at heart.
3. Agile teams need to know what’s valuable to their customers
“There is a chasm between the output of a team and successful outcomes for their customers. And the success of a team is measured by outcomes, not code.”
Nick Muldoon, CEO and Co-Founder, Easy Agile
Your customers have their own priorities, and they won’t align with the priorities of your business unless you make your customers the primary concern of your business.
Your developers likely want to work on projects that they find exciting or fulfilling, so the best way to motivate your agile teams is by building empathy with the people they’re building for. The most successful teams get a kick out of delivering the features that matter most to their customers. Because if you’re not solving their most important problems, your customers will find someone else who will solve them.
4. Customer focus leads to better quality products
When you’re obsessed with your customers, you deliver products that actually matter.
Your whole business, from leadership, to engineering, to HR and Marketing; all need to stay focussed on the people that your business is aiming to attract. When your development teams understand your customers and develop with them in mind, there’s a much better chance that they’ll build the right things at the right time for the right people. And this is critical to the success of your product and organisation.
It’s also a great way to avoid building bloated products with unnecessary features.
5. An agile customer focus is better for planning and prioritising
The worst backlogs are huge ‘to-do’ lists; task focussed and likely to be out of date. The best backlogs however, align with the customer journey, are informed by feedback from your customers, and attempt to tackle their greatest pain points.
Without a solid understanding of your customers to inform your backlog, you could end up planning sprints, versions or even entire increments that don’t deliver anything useful or move the product forward for users. And that’s a pretty costly risk.
6. Customer feedback makes agile teams better
Teams who are obsessed with customers love getting customer feedback, whether it’s via customer interviews, surveys or just having a chat about their experience.
Customer feedback is incredibly powerful because it can help you:
- Understand your customers - Know what their biggest problems are and what they care about most
- Motivate your agile team - Help your team understand the problems they’re solving, the difference they’re making, and that their work is meaningful
- Spot trends and patterns - Ensure your product adapts to what’s in demand right now and what your customers will need in the future
- Make better products - Find out what’s not working so you can fix it
- Track your progress - See whether customers are happier with your product over time
- Stay relevant - Because products and companies that solve problems stick around long-term
- Get buy in - When your customers are involved in the process, they’ll feel more committed to the product, which can reduce churn
- Improve retention - Reduce churn and keep your customers for longer when you incorporate their feedback and ideas into your product
- Make data-informed decisions - Stop relying on your assumptions and let the data drive your strategy
So customer feedback is obviously awesome, but what do you actually DO with it? How do you share it with the team and turn it into actions? Well, that’s where user story mapping comes in.
7. Agile user story mapping is all about the customer
Most agile teams run user story mapping sessions to discuss what functions and features are needed in the product. User stories maps are a visual tool for customer focused development, ensuring your customer journey stays front and center throughout development.
This is where customer feedback comes into play. When your team can access a wealth of feedback from users, they can write user stories informed by real data. This gives them a much better chance of prioritizing features that will add value to users right away. Faster time-to-value. Sounds great right?
This makes backlog prioritization and sprint or version planning so much simpler, because the whole team shares a picture of what is important to the people who use what they are building. The team knows what they should prioritise next.
Improving your customer-focus is a solid strategy.
If your team isn’t exactly obsessed with your customers, maybe it’s time to change that?
Because if you’re focusing on your customers, you’ll make more of the right decisions about what products, features, and requirements you need to work on. You may not get it right every time, but if you’re involving your customers, you’ll soon learn what doesn’t work. Your team will find it easier to make decisions, you’ll waste less time, and you’ll build a better product, that keeps getting better.
Win win.
Related Articles
ProductStory Maps: A visual tool for customer focus
This past May John Walpole of Twitter presented Story Maps: A visual tool for customer focused development at the Facebook Technical Program Manager event in Silicon Valley. And our product, Easy Agile User Story Maps for JIRA, got a shoutout — thanks John!
Watch John’s lightning talk now:
John Walpole is a Technical Program Manager at Twitter in San Francisco. Prior to joining Twitter he was an engineer, product and program manager involved in the Xbox, Azure and Windows projects at Microsoft.
In this lightning talk, recorded at Facebook, John explores story maps as a way to figure out what your agile software development team should focus on (in order to satisfy customer needs). Story maps keep the customer journey front and centre during development and make it clear what should be included in a team’s sprint. For more on story mapping see Understand what your customers want with agile user story maps.
WorkflowGet to Know Your Customers: A Field Guide to Creating Customer Personas
What is a customer persona?
Customer Personas are fictional generalizations of your most valuable customers.
They help teams understand their customers by bringing together demographic information like age, gender, location, and income, alongside psychographic information like interests, frustrations, and personal or professional motivations.
What are user personas?
Now It might seem trivial at first, to come together as a team, mocking up what seems like fake dating profiles for your most important customers.
However, this exercise sets the foundation for other agile practices down the track, and its benefits are often undervalued.Agile experts have called for more cross-functional teams, which means this knowledge of who the customer is, is no longer the sole responsibility of your Sales and Marketing team. Everyone is responsible for understanding who the customer is.
Teams that have a shared understanding and alignment around who is actually using the solution they are delivering are more likely to succeed.
Building customer personas helps teams to address the following questions:
- Who are our customers?
- What are their common behavioral patterns?
- What are their shared pain points (professional and personal)?
- What are their goals and objectives?
- What general demographic and psychographic information may influence their decisions?
- What drives them to make purchasing decisions?
- Is the customer the buyer or decision maker?
There are two steps you can take to answer these questions and start to identify who your customer personas are:Firstly, broadly define your personas
It’s not crazy to think that most companies will have some broad idea of who at least some of their customer personas are. This knowledge is accumulated over time and is based on customer feedback, support requests, conversations/interviews, and initial market research.
This knowledge is not to be underestimated and is a great starting point before looking towards analytics to flesh these personas out into more specific detail.
Secondly, look towards insights and analytics
Once you’ve come up with a few customer personas, it’s time to flesh them out with qualitative and quantitative data.
So where can we find this information?
Look at sources like:- Website Analytics
- Facebook Insights
- Customer Surveys & Polls
- Industry reports
- Customer Interviews or
- In-Product Analytics
After looking through all of this information you can map back the data against your original assumptions.By the end of the exercise, you and your team should have a pretty good idea of who your customers are, and how to best service them, communicate with them and build solutions for them.
Customer personas in Jira
Once these personas have been developed, the challenge is choosing where to store them.
Making the personas highly visible should encourage your team to consider them each time new work enters the backlog. You want them to think, “What would Sam the System Administrator think about this new feature? Would she use it? How would she communicate its benefits to her team? What are some of the problems Sam may encounter on first use?”
That’s why we created an app for Jira - Easy Agile Personas.
Easy Agile Personas enables you to create and keep your user personas in Jira alongside your work, so the entire team can keep the customer in mind.
Whether you choose to use Easy Agile Personas or not, the customer personas you develop are vital to building user story maps.
Agile Best Practice12 Agile Principles to Motivate Your Team and Delight Your Customers
At Easy Agile, we embrace agile principles (of course), and we strive to help software development teams put agile methodologies into practice. However, with so much to get done each day, it's easy to lose sight of the core principles of the agile manifesto.
You're probably thinking that you read the agile principles before and now put them into practice...all day, every day. Why do we need to revisit them?
You don't need to memorize the principles. They're much more of a guiding light than a rote process. But lining up the agile principles against your everyday agile practices provides reinforcement that you're putting them into action. This also helps you identify areas for improvement. 🙌
The continued relevance of the agile manifesto's principles
The agile manifesto focuses on:
- Continuous improvement by responding to feedback and change
- Allowing software developers and cross-functional teams to organize in a way that embraces collaboration and interaction
- Involving customers in the development process and responding to their feedback
The manifesto outlines 12 agile principles which are the bread and butter of agile software development. We'd like to provide practical context to these agile principles, so we're going to organize them into three categories — building working software by being organized, helping teams collaborate, and tactics for keeping customers happy.
Getting organized so you can build working software
The first few agile principles we'll review revolve around the concept of working software — a product your customers can use as early in the software development process as possible. You’ll adapt it as you get feedback about what’s working well and what could be improved. This is in contrast to a waterfall methodology to development, which is a more linear approach that typically does not allow for iterative updates.
Creating working software you can continuously update is one goal. But, that's easier said than done without the help of purpose-built tools like Jira, whose goal is to help agile teams manage their chosen agile framework, whether it be Kanban or Scrum. (You can read our guide on the differences between Kanban and Scrum...or how to use them together. 💪)
Now, let’s look at which of the 12 agile principles fall into this category — #3, #7, and #8 — and how Jira helps implement a framework that adheres to them.
Agile principle #3
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
Atlassian (the makers of Jira) sums up the embodiment of this principle perfectly in its definition of a sprint: "A sprint is a short, time-boxed period when a Scrum team works to complete a set amount of work."
While agile sprints run over a short period of time, running them smoothly takes a lot of work for product owners and software developers. Luckily, Jira provides ways to streamline that work — check out our guide on automating parts of your sprint.
Agile principle #7
"Working software is the primary measure of progress."
Sprints can help you ensure that your team delivers working software incrementally. If planned well enough, a sprint can serve as a stopping point for the release of your next batch of features and functionality to your end-users.
Agile principle #8
"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
Agile frameworks like Scrum can help measure if a team is maintaining a consistent pace. Within sprints, effort can be measured in different ways like agile story points. As sprints are completed, Jira automatically creates a visual report of how many story points a team is completing from sprint to sprint in its velocity chart.
Time for team collaboration
You're an agile team delivering working software and using a super-tool like Jira to plan your work and track your progress. But you need a human touch to truly follow agile values. Please welcome agile principles #4, #6, #11, #5, and #12 to the stage.
Agile principle #4
"Business people and developers must work together daily throughout the project."
Daily stand up meetings are a manifestation of this principle. In this meeting, each team member addressed three topics: (1) what they worked on yesterday; (2) what they're working on today; and (3) what is preventing them from making progress today.
Agile principle #6
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
Whether it's in an in-person or remote meeting, conveying information is tricky — but (phew) we've already addressed that with practices like daily sprints and velocity charts to exchange information across team members and to visually review team progress. And you'll soon see other ways that agile software development teams organize and communicate with each other.
Agile principle #11
"The best architectures, requirements, and designs emerge from self-organizing teams."
Well, first, what exactly is a self-organizing team? It does not need outside direction or micromanagement to figure out what to work on and how that work gets defined and prioritized. These teams figure out how to plan their work, iterate to deliver that work, and then collaborate on how to continually improve. The agile ceremonies of Scrum — stand up, sprint planning, sprint review, and retrospective — are a working example of this.
Agile principle #5
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
Ok, so we went out of order on this principle — but for good reason. Following principle #11 makes sense because good self-organized teams are inherently motivated. They work together to figure out how to get the job done and to help each other when someone is stuck. That said, it's important to have defined roles in an agile team, like a Scrum master who can motivate and give feedback to team members.
Agile principle #12
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
This principle perfectly describes a retrospective — a team meeting to reflect on your most recent sprint or iteration of work and to discuss how to improve for the next one. By answering these questions: (1) What went well?; (2) What could have gone better?; and (3) What can we adjust to improve for next time? your team is collaborating and interacting in an effort to become more effective.
Achieving customer satisfaction
Last, but certainly not least, in the agile principles are customer needs. Who is your customer? What are their needs? How do you respond to their feedback to make sure you provide a working product that they love? Enter principles #1, #2, #9, and #10.
Agile principle #1
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
It turns out that to satisfy your customer, you need to understand who your customer is. 😉 This takes work. A proven methodology for figuring out who your customers are is to create customer personas. These are fictionalized profiles of your customers that document things like their behavioral patterns, their shared pain points, and what their general demographic information looks like.
Agile principle #2
"Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage."
Requirements can't be effectively changed unless they are defined and made visible to stakeholders for feedback. Even if that feedback causes change late in a development cycle, that's ok! (You'll probably also receive change-inducing feedback on the working software you've already delivered. 😎) Tools like a product roadmap or a user story map that provide visual views of your product backlog help give your customers and stakeholders a platform to have the ability to provide feedback.
Agile principle #9
"Continuous attention to technical excellence and good design enhances agility."
One word: retrospective.
Ok, two more words: sprint review.
In the context of principle #9, the retrospective and sprint review are two agile ceremonies to use to continually adjust your software's quality and design to best meet your customers’ needs.
Agile principle #10
"Simplicity–the art of maximizing the amount of work not done–is essential."
Imagine you had views of your customer profiles (personas), a visual mapping of their journey through your product (user story map), and a prioritized view of your plan to deliver your product (roadmap). What a time to be alive! If you're doing all three, chances are your team has pretty great insights into whether or not you're getting the right work done. 💪
Putting the 12 agile principles into action
Now you understand how the agile principles have been formed into agile frameworks and how tools like Jira can help agile teams run with those frameworks. We've also mentioned three effective ways to put these principles into action, and our products make it easy to do.
- Easy Agile TeamRhythm supports agile teams from planning through to review with features that support user story mapping, backlog refinement, sprint and version planning, and team retrospectives.
- Easy Agile Personas for Jira provides teams with a customer-centric approach to backlog refinement.
- Easy Agile Roadmaps for Jira gives visual insights for teams and stakeholders around the vision and plan for a product.
- Easy Agile Programs is a complete PI Planning solution that makes scaled cross-team planning and execution easy.
Check out all of our agile solutions in Atlassian's marketplace!