Agile Velocity, Author at Agile Velocity

Blog

Will Agile Deliver? Getting Your Peers On Board With Your Agile Transformation

By: Agile Velocity | Aug 04, 2018 | Agile Transformation, Article, Leadership

It takes a village to make an Agile transformation successful in any company. Leaders who’ve decided to implement Agile often find they need data and success stories they can offer their peers so the entire leadership team understands, supports, and feels confident in the decision to transform. The following are talking points for you to share with your colleagues.

So, will Agile deliver? Yes!

In 2017, VersionOne’s 12th Annual State of Agility Report reveals that organizations are seeing positive results in the areas they set out to improve when they decided to undergo an Agile transformation. In fact, “four of the top five reported reasons for adopting agile” are also reported to be the areas most-improved by adopting agile. These include:

Alignment between business leaders and departments

Agile organizations put heavy emphasis on transparency and communication between all levels of the business, allowing for clear alignment on goals and the quick removal of impediments.

Management of changing priorities within the business

The iterative nature of Agile accommodates for a business’ ever-changing priorities, giving leaders the time to reevaluate often and pivot in response to market changes as opposed to falling behind competitors.

Productivity

Agile principles and practices increase productivity by limiting waste in the production system complexities, such as handoffs, dependencies, late integrations, etc. This results in the reduction of repeat work, defect costs, and failed initiatives because issues are uncovered earlier in the process.

Delivery speed/Time-to-market

An iterative release cycle also allows teams to release smaller, bite-sized chunks of a product more often. Instead of getting tied up in (incredibly) long-term plans, teams typically release products every 2-4 weeks. Once an organization becomes predictable like this, feedback loops are tighter, giving the organization the ability to give customers higher quality, more valuable products.

Agile has proven time and time again to bring benefits to every level of an organization. Thanks to these benefits, it has rapidly taken over software development and is now spreading to other departments from marketing to human resources and beyond. Today, results of an Agile transformation are branching out to include things like more leads, higher employee engagement, and more recruits.

How do you ensure a successful Agile transformation in your organization?

As with any aspect of business, when you understand and utilize best practices, you see more impactful results at a quicker rate. But don’t take our word for it–take it from others just like you.

For their 2017 report, VersionOne surveyed 1,492 people in Agile organizations from around the world and put together a list of their top 5 tips for success in Agile. These tips included:

1. Developing internal Agile coaches

2. Using consistent practices and process across all teams

3. Implementing a common tool across teams

4. Investing in external Agile consultants and trainers

5. Protecting your Agile transformation with an Executive Sponsor

Over time, we found leaders are more often than not looking for a way to make informed business decisions with confidence. Without a predictable cadence of delivery, organizations are usually flying blind when it comes to making decisions about sequencing work and planning for how those decisions will impact their market and the forecast of all initiatives in flight. Agile is helping companies across many industries solve these problems.

We hope this article provides you with a few key points to bring up to coworkers when chatting about Agile. If you’re interested in learning more about how we help organizations build lasting agility, check out our Agile Transformation Services page. We’ve incorporated these top 5 tips coupled with a focus on producing desired business outcomes into our approach to ensure lasting organizational change.

Blog

Webinar Recap – Scaling Agility: 5 Practices to Get Your Organization Started

By: Agile Velocity | Jun 29, 2018 | Agile Transformation, Leadership, Webinar

Webinar: Scaling Agility: 5 Practices to Get Your Organization Started from Agile Velocity

In this webinar, Mike and Bryan discussed different tactics and practices that organizations can take as they begin to scale agility across the organization. You can find the webinar summary and Q&A transcription below.

Summary

Start Simple

There are a number of really good Agile scaling frameworks out there–SAFe, DAD, LeSS, Enterprise Scrum, etc. Some can appear overly complex and scary at first glance.

Start simple. Don’t immediately align with any specific framework. There are some common best practices that most of the scaling frameworks out there recommend, so just start there. Then evolve and grow over time by adding a bit more here and there as your organization’s needs dictate it.

5 Practices to Start Scaling Agile

Scrum of Scrums

Chances are you are familiar with the Daily Scrum that is held every day within the Agile Team, to synchronize efforts around the plan for today. Scrum of Scrums is a scaled version of the Daily Scrum – to ensure that the cross-team work is synchronized.

Product Owner Sync

The purpose of the PO Sync is to ensure alignment of the product vision and work-related content across all involved teams. SAFe and Scrum @ Scale scaling frameworks recommend this scaling event.

Program Backlog

When multiple teams are working on the same program, it is important to establish the Program Backlog. The Program Backlog is created and maintained by the Program Manager role or perhaps even a Product Owner from one of the teams. The Program Backlog consists of features in priority order.

Dependency Identification and Scheduling

One of the biggest risks when scaling Agile is inter-team dependencies. To mitigate these risks, teams working on the same program should plan together (iteration planning and/or release planning) to identify the dependencies between teams.

Dependencies are bi-directional in that there is both a giver and a getter. To ensure visibility, each dependency should be tracked within the Team Backlogs as either a “Give” or a “Get” as shown in the diagram.

A “Give” is where one team provides a specific deliverable to another team on or before a specified date or iteration. A “Get” is where a team receives a specific deliverable from another team by the specified date or iteration. A “Get” user story will typically involve integration activities across teams.

Common Integration Environment

You will need to establish a common integration environment for multi-team programs. Ideally, this is done prior to iteration 1 to ensure demonstration of working software from the integration environment each and every iteration.

Typical activities in establishing a common integration environment include:

Server setup
Network access
Continuous Integration (CI) tooling
Source code repository program mainline branch establishment
Test case automation
Automatic deployment migration from local to integration/staging environment

Questions from 5 Practices to Begin Scaling Agility Webinar

Where does the security testing occur on slide 14? Is it assumed to be part of the unit & validation tests?

Yes. In an Agile organization, security concerns need to be considered as we go within each iteration. This leads to unit testing and functional testing for the security requirements.

What is your recommended “planning” approach for a given development timeline (e.g. 6 weeks or 1 qtr)? Specifically, getting ahead of cross-team dependencies.

I recommend quarterly release planning with an emphasis on identifying dependencies and making them visible. SAFe has an excellent technique for this called the Program Board.

Are the % usage of SAFe vs LeSS vs others just in the US or across the world? I have heard the LeSS is more commonly used in Europe and possibly Asia.

The cPrime survey referenced received responses from all over the world.

Understanding there is a Scrum of Scrums (S2), what are your thoughts on scaling that further to a “Scrum of Scrum of Scrums” (i.e. – S3) or even an S4? We’ve seen this implemented to create sync points across multiple trains (S3) and value streams (S4). Thoughts on this?

Scrum of Scrums is definitely fractal and can be scaled up as needed. Specifically, a “Scrum of Scrums of Scrums” is useful in coordination of large solutions involving multiple programs (or Agile release trains) as you mention. I personally have never seen it beyond 3 levels (S3), but it is theoretically scalable to the nth degree.

What works best for Scaling, Scrum or Kanban?

Both can be scaled. Many Kanban teams take a “Scrumban” approach by including some best practices of Scrum–in particular, the Daily Scrum. Thus, scaling up to a “Scrum of Scrums” is a natural extension to the daily planning event.

If you’re looking to start a SAFe^® implementation, we recommend starting with Leading SAFe^® training. You can explore our public and private training options on our Leading SAFe^® training page by clicking here.

Blog

Webinar Recap: Agile Leadership: A Manager’s Role in Organizational Agility

By: Agile Velocity | Apr 23, 2018 | Leadership, Video, Webinar

In this webinar, Agile coaches, Braz Brandt and David Hawks, discussed the evolving role of the Agile manager, a development path to evaluate and design manager growth, and how this affects an organization’s agility. See below to watch the recording, read the executive summary, and get answers to additional questions from our webinar audience.

Recording

Executive Summary Of Webinar

Here are the main takeaways from this webinar. If you’d like to dig into the ideas in more detail, we added the timestamp for each talking point.

In this webinar, Braz and David dig into the Learn stage of Agile Velocity’s transformation framework, The Path to Agility®. Most organizations don’t spend enough time focusing on organizational level change at this stage. [min. 1:00 – 2:00]
Companies hire great engineers and a great engineer doesn’t always make a great manager. The two roles require a very different set of skills. [min. 6:12 – 7:11]
In the past, companies have commonly used the Command and Control model to manage employees, where managers focus on creating repeatable processes. This doesn’t work anymore because problems faced by organizations today are more complex and more dynamic than they have ever been. [min. 7:45 – 9:30]
The role of the new Agile manager is not to tell their employees exactly what to do, but to create the conditions that allow for a team or an organization to probe, sense and respond to emerging customer and market opportunities. Responsibilities of a new Agile manager:

Defining and evangelizing a clear and compelling vision
Creating alignment and clarity
Provide mentoring and career growth paths
Circulate and advance learning
Help maintain consistency across teams, squads, trains, divisions
Create and maintain high-performing teams empowered to solve business problems [min. 11:00 – 13:30]

It’s important for Agile Managers to gain the skills needed to be a great manager—when managing yourself and others. Take the time to work on yourself and think about how you approach management and growth. [min. 13:30 – 21:30]
Grow structures to support mastery. It’s important to provide guilds, communities of practice, etc. to your employees so that they have the resources to continue to grow and improve. [min. 21:30 – 22:22]
Energize people with purpose. Remember your “why” and always communicate this to your teams. [min. 22:22 – 23:08]

Need more guidance when it comes to agile leadership? Learn more about how Agile Velocity can help you and your organization grow through true agile leadership.

Book an Agility Discovery Session with an Agile Coach.

info@agilevelocity.com | 512.298.2835

Read on for answers to questions we did not get to answer during the webinar as well as some additional resources on managing others with agility.

Additional Questions from the Audience

1. Do you recommend having a manager manage a guild? Should you have responsibility for all of a testing guild or a development guild? What are the positive and negative aspects?

Long-term, I wouldn’t. If our goal is creating the organizational resilience that’s provided by empowered, high-performing teams, then the guilds—or Communities of Practice, or whatever other names you create for these “cross-team” collections of people with similar skill sets—then those teams should also become high-performing, self-managing teams.

Where I see traditional “line managers” playing a role with these guilds in the long-term is more of a servant-leader, ScrumMaster-type of role. Much like a ScrumMaster helps to see the larger picture and helps a delivery team keep their commitments to themselves and the larger organization, a modern manager takes on a role to support these guilds. Managers can help the larger organization address the impediments our guilds uncover and help provide the guardrails our guilds need to remain effective.

There are times that people within our organization don’t take ownership for their guilds. In those cases, managers need to step into a “seed” role, to create the initial guilds, encourage participation, and create a path to shifting leadership of these guilds from managers and management to guilds self-selecting their leaders regardless of positional authority. As a manager, I was ultimately responsible for the growth and advancement of my staff; as a modern manager, I want to make sure that I provide the structures and space for my staff to grow both in their craft and as individuals. Trusting our teams—delivery teams and guilds—is a key component of helping your staff develop.

2. What would you say is the best approach for a newer Agile Manager to empower a team who has not always functioned well together to begin using Agile Scrum framework and have them collaborating with one another?

As I read this question, I’m struggling with the assertion that a Manager can empower a team. In her book, Powerful, Patty McCord says “A company’s job isn’t to empower people; it’s to remind people that they walk in the door with power and to create the conditions for them to exercise it”. Our role is to stop taking our team’s power away. It’s a subtle but important distinction.

If we recognize that the job of Management in the Management 1.0 and Management 2.0 models was to put limits on the power of the individual in service to consistency and predictability of output, then the question becomes something new – “What am I doing as a Manager to take power away from my team?”

That said, one of the most powerful things that a Manager can do is to create the expectation that the team has the resources and authority it needs to deliver on the items in their backlog. Then, when things arise that prevent your team from delivering on their work, the expectation becomes that Managers and Management have vestigial processes and procedures in place that need to be examined and fixed. Our organization shifts from providing things to our teams—ideas, projects, resources—to supporting our teams’ independence and excellence.

3. If Leadership/Management of a distributed, multi-country, multi-vendor organization wanted to go for Agile, what is your recommendation?

Start with “why”? What are they trying to solve? Faster time-to-market? More visibility? Greater predictability? From there, identify the major pains they are feeling. Until those two things are understood jumping to a framework suggestion would be, for lack of a better word, irresponsible.

4. Do you feel that SAFe®, which has more of a larger organizational view and engagement, positions organizations for better (or worse) Agile adoption?

The answer depends on your perspective. If you are looking for team-level Agile transformation, then SAFe® would probably not be a good option. However, if you are looking at a larger scale Agile transformation across programs (multiple teams), portfolios, and business, then SAFe® is a good choice for scaling Agile.

Some agilists feel that SAFe® is intrinsically not Agile, but in reality, every SAFe® level emphasizes iterative/incremental development, work decomposition, ruthless prioritization, WIP limits, pull-based flow, and lean economics—which are all hallmarks of Agile.

5. How would you go about helping a waterfall Project Manager transition into a more agile approach?

Helping them identify what skills they have to support agile teams and products would be key to making sure they have a smooth transition. From there, we would help them find places to lean in and find potential role options in support of teams delivering a product.

6. When do managers own the responsibility of knowing or being aware that “they” are the constraint to the team motivation and performance decline? Something like proactively, participative leadership.

As soon as possible. Henrik Kniberg, an Agile Coach at Spotify, says that “If an organization doesn’t like honesty, they won’t like agile”. Building a continuous improvement culture means being open and transparent about what is slowing down progress. Unfortunately, this sometimes means it is our actions or the system we are creating that becomes the constraint to improvement. This is hard but should be something that is identified as early as possible.

7. With our Executive Leadership, there has historically been a focus on delivery (points), and we see the need to shift the focus toward the outcome. Realizing this is a potentially large discussion, do you have any quick points to help us with this transition?

Showing usually speaks volumes more than words. Show them this quick 40-second video, then discuss how working really hard on the wrong thing is still working on the wrong thing no matter how hard, fast, or efficiently you work.

8. From industry experience, in which organizational structure is agile more successful? Flat structure or hierarchical structure?

The flatter the structure the less potential for communication breakdown. Making sure there is enough support for each person as far as management goes without creating artificial boundaries between decision-makers is essential. If leadership is truly providing vision and direction and those closest to the problems are empowered to solve them, then the levels of hierarchy can be beneficial to limit the distribution of support.

Resources

Resources on Learning to Manage Yourself and Others:

In an Agile Transformation, Transparency is to Empower, not to Micromanage by David Hawks
Agile for Executives White Paper from Agile Velocity
Management 3.0 by Jurgen Appelo
Managing for Happiness by Jurgen Appelo
“Drive” by Daniel Pink
“The Puzzle of Motivation” – Dan Pink @ TED
“Start with Why” and “Find Your Why” by Simon Sinek
“Developmental Sequence in Small Groups” by Bruce Tuckman

Blog

Why we don’t re-estimate story points

By: Agile Velocity | Mar 26, 2018 | Article, Product Owner, ScrumMaster

To estimate or not? To re-estimate or not? This short article will tackle the second question. We’ll weigh in on #EstimateGate in a later blog post.

Most teams are tempted to re-estimate stories once the Sprint has begun; as teams put fingers to keyboard, it is natural that they learn more about what is actually involved. Hence, the temptation to re-estimate story points because (and this is just a guess based on our coaching experience), they want to be right, or accurate.

(more…)

Blog

Webinar Recap: Backlog Refinement Q&A

By: Agile Velocity | Mar 09, 2018 | Product Owner, Scrum, Team, Video, Webinar

With Backlog Refinement, you can address many challenges teams face, like unpredictable delivery cadence. However, a lot of people still have questions around this (unofficial) Scrum event. This webinar will help clear things up!

In this webinar, Reese Schmit and Brian O’Fallon tackle your questions on Backlog Refinement, like:

Why is there so little structure around Backlog Refinement?
How do I sell Backlog Refinement to my team?
When does Refinement begin? Is it continuous?

See below for our full webinar recording and transcription.

Transcription

Introduction

Brian: Hi there, my name is Brion O’Fallon. I am an Agile Coach here at Agile Velocity. I have been in the software world for about 20 years, and I have been doing Agile for about 10 years. I was in a small company that was acquired, and I was a Project Manager who was told to become a ScrumMaster. I did that and fell in love with it. For the last 10 years, I have been in all different kinds of Agile roles, including ScrumMaster, Product Owner, Manager, and more recently, an external coach who goes in and helps clients implement different Agile methodologies.

Reese: Hi, I am Reese Schmit, and I’m also an Agile Coach here at Agile Velocity. I’ve been in software somewhere around 15 years. Most of that has been in some form of Agile, W-agile, Scrum-erfall, “We do Sprints so we are Agile!” type of environment. In that time, I have worn many many hats: everything from QA to Tech Writer, UX Designer to finally ScrumMaster about 7 years ago. Since then, I have been coaching teams. I counted this morning, and I am somewhere around 50 teams give or take.

So in that time, I have seen many Backlog Refinements–a lot of good ones and a lot not so good ones. Hopefully, we can share some of the wisdom that we’ve gained over the past few years to help you guys get your Backlog Refinements back on track. So without further ado, Brian Fallon please take us away!

Brian: Before we jump into some of the tips, tricks, and common patterns we see out there in the field, I’d like to like to give a little context to what Backlog Refinement is really all about. At its core Backlog Refinement is a conversation between the Product Owner, who has a vision for the product and some specific requests of what they want the team to do, and the team who is actually going to be implementing it. We ask the Product Owner to come into Backlog Refinement with a clear vision of where they are trying to take the product and some specific “what” style requests. We need to have conversations about value and the requests of the team. When the team can interact with the Product Owner and come to a common understanding with them, the team will also get a sense of how big the project is, and they can give the Product Owner that information, so the Product Owner can make an informed decision about what should be prioritized.

Reese: One of the things we see a lot is that Backlog Refinement is treated as a spectator sport. Everyone comes in, sits down, and it’s the Product Owner’s show from there on out. One of the things that we can do as a team to get really prepared for Backlog Grooming is… to be prepared. Honestly, go through the backlogs top few items and dig in. Whether that is thinking of questions, digging into the code, or going and talking to the rest of your team about the top items. That’s going to set you up for a really really collaborative Backlog Refinement.

Product Owner can set their team up for success by either sending out an email saying “these are the top things that are going to be in contention for Backlog Refinement”. If you are using something like Jira, you can set up some designation in there. Making sure your team has the opportunity to look forward is going to make Backlog Refinement successful for everyone.

Brian: It goes without saying that the Product Owner has to be prepared, but the team having context before going in can really help with that collaborative interaction.

Reese: If you walk into a book club and only one person has read the book, it is not going to be a great conversation, so really come in prepared.

Brian: The next thing that kills that conversation is having only one person driving the conversation. That can mean everything from a very Product Owner, presentation-centric way of doing things, but another one that we see a lot is one person who’s driving the tool. If you’re using Jira and you have one person with a keyboard in front of them, entering in all of the notes, and scrolling through the screens it’s almost impossible for the conversation to remain collaborative. Everyone just ends up staring at that one person as they struggle to find the right button or type up the last note. We really don’t want to have just one person driving. We need it to be a collaborative discussion.

Reese: One way you can do that is to give everybody a pad of post-it notes and a sharpie. When you are talking about acceptance criteria and people are asking questions, anyone can write it down. One of the best ways I have found to up-level your Backlog Refinement is to turn the TV off. If everyone is co-located, you can just turn it off. When you sit in front of a big TV in one of those comfy conference room chairs, you probably lean back and relax. That doesn’t create collaboration. Everyone needs to be up, engaged, and actually on their feet.

Write out the user stories on post-its and bring them in. Then the Product Owner is able to get everyone on their feet to look at the user stories collaboratively. You can even put up a white sheets of paper so that people can scribble out little mocks which creates a really awesome environment for the whole team to get engaged.

Brian: If you do use a tool, which almost everybody does nowadays, print out those user stories. Put them on the wall and have everyone go around with a pad of post-its and put up the acceptance criteria as you come to a shared understanding.

Brian: When we go through backlog items, we’ve noticed a couple things that are problematic. If the stories are not vertically sliced, that is going to make it very difficult to have a value-based “why are we doing this” discussion.

For example, if the item is giving a new, fun capability to users, it’s really easy to get behind the value we’re delivering. If the item is “insert database table here…add two columns… insert trigger.”, it is near impossible to get excited about it. This also makes it difficult to bring your whole mind and creativity to solving the problem, because you have really been presented with a component task.

Reese: The other thing I see a lot is that backlog items are too small. We want big meaty valuable things. Do you laugh when Scrum books say “about four to six items in the backlog for the Sprint?” No, that’s real, that’s a goal, those are big meaty things for the whole team to work together and collaborate on. When you are in Backlog Refinement, you are having a meaty rich discussion digging deep into “Why this thing is going on and what you can accomplish”, rather than “That button goes to there.”

Brian: It is hard to remain vertically sliced when we get so small. I know that you’ll get a lot of advice to slice backlog items as small as possible, and that may be an end state. but it’s hard, at first, to conceptualize something that small and still keep it vertically sliced. We’d rather you keep it vertically sliced and a little bit bigger.

Results: It looks like about 50% of you guys are at 3-5 Items.

Brian: If you are getting through fewer items than you want to, there are a few patterns Reese and I have seen out there. The first one is when the team wants to dive way too far into what’s being requested. And I know that that sounds a little at odds with what we were just saying a minute ago. We’re trying to have this rich conversation where the Product Owner is laying out the value and getting the team excited about the goal, but I have seen that sometimes teams get caught up in asking very detailed questions that aren’t related to the point. We’re trying to understand the value and the goal not rattle on minor points that need to be figured out as we get into the Sprint. The consequence of that is the discussion goes on too long, you lose people, and the engagement slips away. We want to have that discussion as long as it takes to make sure that we are all on the same page about the value of it, what we are trying to do, and the intent of the story. Once we are there, let’s cut the conversation off.

Reese: I’ve seen people trying to get answers to a lot of questions that are not going to change the size. We might want to have those answers before we start working because while it is pretty critical but it’s not going to change the size of the item

Brian: There will be other opportunities to talk about the details. As long as we can get to the intent of it and we can understand how to size it, we are giving enough information back to our Product Owner so they can make a great, value-based decision about priority.

Reese: We also see people digging into the “how”. If you are tasking out your stories in Backlog Refinement, then you are digging way too deep in the “how”. Save that for Sprint Planning, when you’re really about to dig in and start doing the work. I just had a conversation with a team this past week, and we were talking about how we pull ourselves back up. I used this analogy of cooking:

Reese: Have you ever cooked dinner for yourself?

Brian: Yeah

Reese: Have you cooked dinner for your family? Is that bigger or smaller than cooking for yourself?

Brian: Way bigger

Reese: Have you cooked dinner for a dinner party, say 75 people?

Brian: Oh yeah

Reese: How about a big backyard BBQ, bigger or smaller than the dinner party?

Brian: Much Bigger!

Reese: Did we talk about recipes? Did we talk about what food you are going to bring? We didn’t have to go to the store or do any of those things but you know whether it is bigger or smaller. We are not experts on cooking, but we are asking people who are experts at building software to size things bigger or smaller. So really digging into that how is not necessary to understand whether it’s bigger or smaller than the story that we just talked about.

Brian: What we’re really going for is just enough planning to give the Product Owner the information they need to prioritize. There will be more opportunities as a technical team to dig into the tasks required to do that job, but we don’t have to do it right off the bat.

Questions & Answers

Reese: We’re going to jump into a few questions from our CSM & CSPO alumni to give you guys a few minutes to put your questions in.

All other the meetings are very defined in Agile/Scrum (day, time, length) Why is there so little structure around Backlog Refinement?

Reese: It is not an official Scrum ceremony.

Brian: Yeah, it’s a little bit shocking because it will show up in every class you will ever attend on Scrum, but it’s really not an official event. Scrum is great at picking up things in the prioritized backlog, defining how we execute on them, and how to refine our product and process but it is pretty silent about how things get into the product backlog.

Reese: It says you need to spend up to 10% of your time preparing for the Sprint ahead but it doesn’t say how. So while it’s not official, it is a best practice to do a separate Backlog Refinement, outside of Sprint Planning. We know that we’re not very good at just coming in, being revealed a backlog, being told what it is for the very first time, and then committing and figure out how to do it all in one meeting. Separating that by a few days is going to give the team a much higher chance of success in their Sprint.

When does grooming session occur in a Sprint?

Brian: It should be during the Sprint. We recommend that it happen a couple days or more in front of Sprint Planning. This will give folks time to think it over, do some exploration, or give the product owner a chance to get clarifying questions hashed out so that you are ready to go by the time you hit Sprint Planning.

Reese: Some teams will do it on the off week of their Sprint Planning (for two-week Sprints). So, every Wednesday at 9 am we know we have a to be prepared for a meeting, whether it’s Backlog Refinement or Sprint Planning.

Who’s responsible for grooming?

Brian: The Product Owner is responsible for making sure there is a groomed backlog, but Backlog Refinement is a participatory event that the whole team–Product Owner, ScrumMaster, and everyone–should work on collaboratively. It is the Product Owner’s responsibility to make sure it happens but it is the whole team’s responsibility to join in and collaborate on it.

What’s the difference between a Backlog “Refinement” and a Backlog “Grooming”?

Brian: New name for the same thing. It had cultural implications in some countries that were not positive so as the industry has migrated, we have shifted to calling it Backlog Refinement.

What if you have remote workers? How can you incorporate them into the meeting in an active way? What is the best way to enhance participation in a virtual conference?

Reese: Anything that you can do to create more of a collaborative environment for your remote folks is going to create a lot more success.

You could use some sort of online collaboration software like Google Docs or BoardThing. Anything that you can do to have everyone be able to input information. If one person is remote, sometimes it is better for the collaborative environment if everyone acts like they are remote. Meaning everyone has a keyboard to be able to input things so the whole room is not looking at a whiteboard while the speaker is behind all their backs and they are trying to collaborate with the one person on the phone.

Face-to-face communication is very important and any online collaboration software that you can use to do this will make a huge impact. We like to use Zoom and a conference room camera for our company meetings so that we can always see each other’s faces. I did this the other day with three people who were on the phone, and we were able to use a whiteboard. We got a really good camera and made sure that everybody could see our board. We wrote really big on the sticky notes, and when we were reading something off we would make sure to hold the sticky note up to the camera so that they could see. Through this tactic, everybody was really able to engage.

Brian: Another thing I’ve done, is sometimes the ScrumMaster, who probably isn’t as active in this meeting, will act as a scribe and make post-its on the behalf of the remote team members. That only works if there are one or two remote team members though. If everyone is distributed, then you should use an online tool.

Why not do a little bit of refinement every day?

Reese: That can absolutely work. I’ve had teams who spend 15-30 minutes after stand up every single day refining the new things that are coming into their backlog. They were doing Kanban, so it worked really well for them to have a continuous refinement process. If that is something the teams want to do, do what works for you guys. Do something, try it, retro on it, and make sure that you are updating it to fit your team’s way of working.

What are the “other opportunities” for the team to dig into the “technical how” of a task ahead of planning?

Brian: When we say Backlog Refinement is specific around creating a shared understanding of the value and intent of the story, and that it is not a place to go into the technical how, that doesn’t mean the team can’t go off and do some investigation.

I would caution you though. Digging into the technical how of a task ahead of planning makes me concerned that perhaps your stories are not vertically sized. If you need to resolve a technical approach in order to properly size something, that is legitimate. It shouldn’t happen too often but sometimes you will get a situation where, in order to be honest, you have to tell the Product Owner “I don’t know how big it is because I don’t know if we know how to do this.”

There are ways of resolving that, like spikes that you might do to look at a technology but just be careful. It sounds like potentially you are asking should we task out ahead of time and please don’t because you never know if that story that you think you are being helpful on and tasking out is actually going to be prioritized at the top of the backlog. Once you get into a groove, you’ll often times find that backlog gets tweaked, revised, and re-prioritized right up until the very end of the Sprint. Resist the temptation. Do the tasking in Sprint Planning.

Reese: Don’t always rely on putting a spike in the next Sprint. Then you have to wait to do the work until the following Sprint. Make sure you’re leaving a little bit of time between Backlog Refinement and the new Sprint so you’re not always booked up right into the very end of the Sprint.

As a ScrumMaster with a new or absent Product Owner, what is the first baby step I can take with coaching my new Product Owner on how to start refining without getting vacant stares?

Reese: You’ve got an opportunity to really help this person to become a really great Product Owner for that team. There are tons of books that they can read. (Mike Cohn’s User Stories Applied; Roman Pichler’s work, including his books and an amazing blog). You can also send them to a Certified Product Owner class that will give them a great foundation.

Absent of all of those things, just help them to really identify the who, the what, and the why on those things that are needed to get this feature or product out the door. This is going to be super helpful. Helping coach them to build a backlog, vertically slice stories, not be focused on technical specifications, and not translating a requirements document into user stories will help guide the Product Owner to build that backlog.

Would you incorporate your MVP’s in your backlog? What percentage?

Reese: Your backlog should definitely reflect the MVPs. I’m actually going to break MVP down a little bit. If we’re talking MVP in like the Eric Ries/The Lean Startup sense, in that we’re building the smallest thing that we can possibly build in order to learn something, absolutely. Your backlog should be made up of those experiments, and once you have determined what to build, that experiment has been proven, and you know which direction you should be going in, then your backlog is full of validated backlog items. You can now–with much more confidence–that these are the things that we can do to be successful with this product.

What should a PO do when a Sprint fails?

Brian: I bring that up in a Backlog Refinement meeting only because there are a few common reasons that Sprints usually fail: there was something inadequate in the backlog going into it or there were technical implementation questions that came up along the way. That is really worth digging into in your Retrospective to understand if there was something about the way the stories were understood or formed that might indicate a procedural improvement that you want to do in the next Sprint. In the case of a failed Sprint, Product Owners, be brave and transparent about it.

Is the PO aware of tech debt?

Reese: Technical debt is the corners we cut on the way to launching something. If we are going to have a mainatabale product in the market, then we should shore those corners up. We might have needed to get somewhere fast to learn something but we don’t want to keep that out there forever. If you start incurring too much technical debt, your velocity will eventually get to zero as the team swims in that spaghetti or pool of bubblegum and duct tape (which is the best way I have heard raging technical debt described).

The Product Owner should absolutely be aware of that, but it is the team’s responsibility to bring that up. In that time between Backlog Refinement and Sprint Planning, the team should go look in the code and see what is in there. If there is some technical debt that they need to shore up, then they should bring it up. That may end up being a separate backlog item or it may be a task inside of the story.

Could you explain a bit more on the 2 different types of definition of ready?

Brian: When we are looking at our stories in Backlog Refinement we are really trying to get the stories to a “ready” state, that the team could pull it in. One exception is if we understand the intent and the size of a story, but it is missing a particular item–like text that needs to be approved by legal or compliance. It is okay to say this story is going to be a 5, and we understand the intent, but please note that it is not ready. It needs that final component before we can pull it into the Sprint. Definition of Ready should be prominently displayed in your room when you are going through Refinement. Take lessons you have learned from prior problems and incorporate them into your Definition of Ready.

Reese: I have had teams use two Definitions of Ready, one was their gate into Sprint Planning. They also had a Definition of Ready when coming into Grooming. They did this for two reasons: to make sure the stories were ready for them to talk about and also as a barrier to the team, making sure they weren’t hyper groomed. The Product Owner wanted to make sure every single thought was addressed, and it didn’t leave a lot of room for the team to be innovative and bring their brains.

What if you are acting as both the ScrumMaster and the Product Owner? (I know it’s taboo, but sometimes it’s a reality.) How would that work in a backlog refinement?

Brian: It is a real challenge. During Backlog Refinement, you are supposed to be facilitating a meaty discussion around what the story is all about. However, as a ScrumMaster, you are also supposed to be enforcing the process that makes sure the team is being honest and open about how big the effort is. It will be very hard to keep both of those hats on simultaneously and not find yourself swayed to pushing the team into making smaller sized estimates in order to facilitate moving down your backlog.

Just how much should you fear a failed Sprint? How do you define a failed Sprint? Should a “failed Sprint” be celebrated as a learning opportunity?

Brian: The fear is that if your organization doesn’t allow people to stretch and fail or that you are going to sandbag. If you are going to suffer consequences of not completing your forecast, then any smart, quantitatively sophisticated person is going to make sure that they put enough of a buffer in there that it doesn’t go bad. I agree that failed Sprint can be learning opportunity. I wouldn’t even call it a failed Sprint! To be honest, that seems a little extreme. The lingo implies that if you are 10% off it is a failure, and it is not. It is a learning opportunity like you said.

Reese: You should dig into those things in Retro. Find out what happened–maybe we brought in things that weren’t quite ready. That may be an opportunity to create a Definition of Ready. Maybe, as a team, we didn’t take any time to dig into the code before the Sprint. We know that you’re going to discover things during the Sprint, we just don’t want it to be a catastrophic discovery. We want small things along the way.

Brian: But you will have those catastrophic discoveries. And when you do, I really hope that your organization can change the way it looked at it and learn something. When you go to a Sprint Review, don’t look at it as a demo of delivered items on a commitment. Look at it as a learning opportunity.

What are ways to win hearts and minds when the team is actively contradicting the best practices of Backlog Refinement? (Insisting on digging into the how, writing tasks instead of stories, etc.)

Reese: Mostly, we see that happen when there is a misunderstanding of what the intent of Backlog Refinement is. It’s important to show the value. Show them it is possible to size things without digging too deep into the “how”. Try doing an activity with the team where they are sizing a lot of items at once and not digging into them. Show them how it can be done, and they can start seeing the value.

Should stories be assigned in Backlog Refinement?

Brian: No, they shouldn’t be assigned in Refinement.They shouldn’t be assigned in Sprint Planning. What we are doing here is having a team understanding. It is a team forecast of what they can do. Don’t assign it to a single individual or else folks who aren’t assigned to that story won’t stay actively engaged.

Blog

Webinar Recap: Moving Beyond with Next Level Agile

By: Agile Velocity | Jan 15, 2018 | Leadership, Video, Webinar

Today, most Agile teams are trying to achieve predictable, fast delivery. While that’s good, it’s no longer good enough—not if we want to keep up in this highly competitive, rapidly changing world. So what is beyond Agile? It’s not just about teams anymore. Next Level Agility is about the ability of entire organizations to quickly adapt to market changes.

In this webinar, David Hawks discussed principles and practices that will be the future of all organizations who want to accelerate and improve their agility. During this presentation, he resets the bar on how great Agile organizations operate by moving beyond practices like user stories, project plans, stakeholder feedback, continuous integration, and velocity, and towards a new Next Level Agile Manifesto with an emphasis on Discovery over Execution.

Recording & Transcription

Introduction

For those who I haven’t had a chance to meet, I’m David Hawks. I founded Agile Velocity back in 2010. I do Certified Scrum Training and I am a certified Enterprise Coach–which just means that I’ve seen a lot of different environments and companies that are struggling. This talk discusses patterns that we have seen emerge at that next level of Agile which most of these companies are trying to reach.

The Current State of Agility

This slide (above) shows how most organizations might describe their current state of agility.

Many organization are at what I would call “Superficial Agility”. They are going through the motions. For example, they’re making their work visible (which is better) but there is still a lot of carryover. Maybe they don’t have a strong Product Owner or ScrumMaster, or they’re working in silos where they’re just throwing things over the wall to each other. They’re kind of doing Scrum but not being very Agile.

“Improving Agile” is an organization that is starting to have retrospectives with meaning. The ScrumMaster is trying to coach the team to be better, work is estimated, and we have some sense of velocity (that doesn’t mean it is consistent or predictable velocity). We are starting to improve but not to the level of predictability where we don’t have very much carryover.

In “Predictable Agility”, we are breaking down work, we’re swarming, and we have whole team ownership. That is a great state to be at if you can get to it. Here, we have a predictable cadence of delivery.

Finally, you are at what we call “Fast Agility”, where we are delivering quickly. We might have Devops or CI/CD, etc. We are delivering things into production, and maybe releasing one feature at a time. Our cycle time is short, and you might even be releasing faster than the sprint cadence if you are doing Scrum.

So I would like y’all to think about which one of these you fit it. Are you in Superficial Agility, Improving Agility, Predictable Agility, or Fast Agility? (See poll results from the live webinar below.)

The current state of benefits that people are striving for with Agile are:

Increased visibility so we can make better-informed decisions.
Continuous improvement at a team level where the teams are taking ownership of their improvement.
Predictability–not that we know exactly what we will deliver 6 months from now, but that we know we can get about 4-5 things done every two weeks and get them done-done.
Potentially shippable and even potentially into production so that we are shortening time to market.

These are a lot of the things that companies who come to us say they want. How would Agile make them more predictable, faster, and increase productivity? While those are great, that is what I would call Agile 1.0. What we are trying to achieve today, and what I’m here to discuss with you all today, is the next step. What is past Agile 1.0?

The Path to Agility®

Some of you have probably seen the Path to Agility® that we put together. If you are interested, we have a separate talk that goes more in-depth on this. The top level of the Path to Agility® is aligned with what we were just talking about–learning, improving agility, predictable agility, and accelerate. What we are going to talk about today is the last stage in the Path to Agility®, which is an adaptable organization, or organizational agility. So what does that really mean?

Agile Development: A History

In order to understand this, we need to understand where we came from and what has changed. Agile was born in 1995, and Scrum was presented for the first time here in Austin at OOPSLA’95. As you can see in the picture, it looked a lot different than it does today. There was the pregame, postgame, and mid-game back then. Scrum didn’t even have Sprint Planning or Sprint Retrospectives.

I remember writing code in 1995 and shipping CD’s and software off to my customer and never being able to see how it was used or if it was ever installed. We didn’t have visibility to where the software was running. In 2001 Agile is born and we now have the Agile Manifesto that was written with contributions from the Scrum community and more. That was 17 years ago that Agile was born and we’re still implementing a lot of the core tenants the same way as they were then. That helps us get to Predictable and Fast Agility, but I think that’s not enough anymore, and that is what we are exploring here today.

In 2006, we started to hear commercials talking about “The Cloud” and we’re like “What the hell is The Cloud?” I think that really changed a lot of the dynamics around what is capable today.

Now that we have our software in the Cloud, we’re able to deploy much quicker because we are deploying in an environment our company controls versus shipping CDs and/or doing major releases with on-premise software. The Cloud has also enabled the ability for us to get analytics and metrics because we have direct access to that machine, the logs, and the information/analytics of the usage. Whereas back in ‘95, when I’m shipping CD’s, I have no idea what people are clicking on or what flow they are using. The Cloud, Techstack, and things we are using today have really changed the dynamics of what is possible for us.

The other big thing that influenced development is smartphones. These have allowed our consumers to absorb software changes at a rapid pace. Before 2007, everybody was like “Nope, we’re only going to do three major releases year because we don’t want a lot of changes”. But now we’re used to Facebook updating all the time. There are always updates coming, and we’re always getting incremental changes. Our consumers, customers, or stakeholders are now used to the fact that software is just a continuous flow of things, tweaks, changes, and improvements. That has changed people–their appetite for receiving software has increased.

Next, we’ve got this whole thing called DevOps, which has now created the infrastructure that supports our ability to push software quickly, things like feature branching all the way to automated deployment with automated tests. We now have the ability to not only deploy things quickly but to monitor if we’ve broken something in production and to be alerted before our customers see it. This allows us to respond quickly and fix bugs before anyone even notices. DevOps provided that infrastructure, which was only possible because of the Cloud and SAAS and is now sustained by our consumers’ appetite for software updates.

I think these three major areas have really changed what is possible and what we are allowed to do with analytics and the visibility that we now have. When you also think about the rate of change that’s exponentially increasing, I think about it more as a rate of disruption: the ability for any company, anybody, anytime, anywhere to create a product that can disrupt your product. This is possible because the cost to get a new product built is so much smaller.

I remember a start-up that I was a part of–the first initiative that I did on my own in around 2003. Back then, in order for me to launch a new app and new site, I had to go rent a rack at a data center. I had to buy hardware and servers. I had to buy around $10,000 worth of Oracle licenses and other things just to get going. Today with AWS, I can pay 12 cents and have a server. If I have low traffic, it doesn’t cost me very much, so my barrier to entry is much smaller.

All of this technology can be accessed from anywhere in the world, and therefore, can be deployed anywhere in the world. Competition and choice is huge, so we now have to react quicker or somebody else is going to disrupt our market and disrupt us right out of business. With the current rate is disruption, we have to start reacting quickly or we risk being left behind.

That dynamic is what got us to this point: a state where Next Level Agility is imperative. We’ve got the infrastructure and the mindset that allow us to do Next Level Agile in a way that we didn’t have before. I’m not saying the Manifesto was wrong in 2001 but maybe it’s a little bit outdated now in terms of capabilities.

Next Level Agile

Benefits of Next Level Agility

When I think about what benefits we are really striving for with Next Level Agility, I ask myself questions like “Are we validating or invalidating our ideas as fast as possible?” and “How do we know we’re building the right thing?”

We’ve all heard the stat that 64% of the features we build are rarely or never used. We have a problem of building a lot of the wrong stuff. That takes time! If we could start honing in on building the right thing then we’re going to be able to address the market needs much faster.

How can we validate our ideas and assumptions? Or, more importantly, invalidate those assumptions as fast as possible? How do we get faster time to value so that the things we’re building are actually proven valuable things? I would assert that the finish line is no longer just “code in production”. I think now the finish line is that the code is in production and we have validated that it has solved the market problem.

That’s a very different way of thinking about it, because today, in Agile 1.0, we’re thinking about being fast. Now with Next Level Agile, I’m saying that being in production is not good enough. We have to prove that the product or code is solving the problem we validated production. I think team agility is great in Agile 1.0. However, in today’s world, we need more. We need organizational agility–agility that extends beyond the technological organization and throughout the organization as a whole.

Organizational agility is about how marketing can work in an agile way that is responsive and incremental and iterative. Or how HR can operate with agility. If the technology teams are Agile, but the rest of the organization is working within a waterfall plan driven mindset, there is going to be a lot of tension and friction. We’re still executing on a plan that has a lot of bad assumptions in it.

Organizational agility is about starting to change the mindset of the whole. We need a learning culture more than an execution culture. This allows us to have a faster response to change. We have the ability to be probing, sensing, and putting things into the market and getting validation back. If we want to be successful today, we need to be able to respond to those market changes and respond to disruption much faster, not just respond fast to delivering on a plan. That’s what a lot of Agile 1.0 Is doing, responding to a plan instead of market needs.

[Here, David asks the audience to write a Next Level Manifesto statement that embodies these benefits. What is a practice are we doing today that you think might not be the best practices? What would be the better practice? Follow this format: ______ over ________.]

Values of Next Level Agility

Here are the four values that I came up with:

Continuous delivery over incremental development

In Agile, we talk a lot about working iteratively and incrementally and getting pieces done. We get a piece done, then move into the next sprint to complete the next piece. At this point, the entire product could still end up taking 12 weeks to push out the door. How do we actually start getting continuous delivery of value into production instead of just continuous integration?

Discovery over Execution

I think about the learning part of it as discovery over execution–discovering more about the problem space and solution space. Emphasize the learning element over executing on a plan or executing on bad or unvalidated requirements.

Validated Market Feedback over Quick Stakeholder Feedback

Who are we getting feedback from? Sometimes, we convince ourselves we’re on the right track because stakeholders are saying everything looks good, but they are not actually people that use the product, nor do they have customer perspective due to innate bias.

Business Agility over Team Level Agility

Too often, I go into an organization and the leadership sees Agile as what the teams do and that they just need to help the teams be more agile, as opposed to thinking about this as an organizational or business problem.

Why Aren’t We There Yet?

What impedes an organization’s ability to achieve these higher levels of Agility? What is going on in your organization that’s keeping you from having potentially continuous delivery, a discovery kind of mindset, validated market feedback, or getting from team level to organizational Agility? [See poll results to these questions below.]

Here are some of the top impediments that I see:

Mindset Change from Execute on Assumptions to Learn Faster

This is a complex situation. We do not have perfect information, and we need to have more of a learning/discovery mindset. That mindset change has to happen at the top of the organization down to the bottom. It cannot go from the team level up.

Whole Organization/ Leadership Transformation

Leadership needs to be part of the transformation. It can’t just be technology or a couple marketing and HR pockets doing some Agile stuff. The whole organization or leadership has to go through that transformation alongside their teams.

Supporting Tech. Infrastructure (Test Automation, CI/CD, DevOps) in place

Do we have test automation? Developers who are engaged in writing test automation? Devops? Are we investing in continuous delivery? Sometimes that requires some architecture of our product to be designed for testability and to be designed in a way that we can deploy modularly.

Analytics Combined with Experiment Platform

Do we have analytics and the experiment platform to be running lots of A/B tests and things where we have a sample size? While Facebook may release every 12 seconds or something like that, they don’t release to everybody at once. When they have a change, they may release it to 5% of the market. Then, if everything goes well, they might expand that to 25%, then 50%, then 100% of their users.

Leveling Up: How To Reach That Next Step In Agility

Now let’s dig into the 6 practices that we could actually implement in order to make Next Level Agility happen.

1.Who are we serving?

I’ve seen a lot of companies shorten the feedback loop to stakeholders. We are doing sprint reviews with a bunch of stakeholders but no actual customers or users. So that means we are getting feedback from a middleman who is trying to represent the customers, but they’re making a bunch of assumptions and guesses that are bias to the features they wanted and how they thought it should be built. We don’t get feedback from the customer until they are actually using it and validating it. So we have to figure out how to shorten the feedback loop all the way to the market and customers in small incremental steps.

2. Hypothesis vs Requirements

Most people use user stories as a way of capturing requirements. While they are good at capturing certain things like the users intent, what impact we are trying to make for the user, how do we organize them in epics, features, and other things? User stories miss key elements like business objective. So if we had a story that said, “As a frequent flyer, I want to rebook past trips I take.” we’re missing the reason for building, the objective, the business goal.

I would much rather walk into a room with a team and tell them the objective and let them brainstorm on ways that we could solve that. Now the team is engaged trying to solve the right problem, we can make a hypothesis or in other words, our requirements. Then the experiment is the smallest thing that we can go build that would prove or disprove our hypothesis. On the left, we are thinking about discovery and learning (Next Level Agile), while on the right we are still thinking about execution and getting predictable (Agile 1.0).

3. Objective Decision Making vs Subjective Prioritization

Minimal Viable Product Experiment starts changing our thinking from a subjective decision to objective decision making.

For my triathlons, I use an App called RunKeeper to keep track of my run. One day a camera icon showed up. I clicked on it because I was curious. A window popped up that said, “Would you like to take pictures on your run?”. They hadn’t figured out the API or figured out how to take pictures yet. All they did was add the icon and question.

Their hypothesis was: We think people might want to take pictures on their run. So they added an icon and asked a question which was the smallest thing they could implement. It was an objective decision based on data and analytics that they used to help them find out what they should build next, also known as a data-driven decision.

4. Goal Driven Investment vs Budget/ Plan Driven

Imagine an initiative is funded with X money for X number of years. With budgets, we create a plan to spend the entire budget. My challenge would be for organizations to get out of that accounting process and to more of a finance process. If I’m talking to my CFO, the top part is talking his language whereas the bottom part is talking the language of the account. Goal driven investment would be saying, “I’m not going to give you $3M, but instead, I am going to give you $100,000 a month. However, in order for you to get the money for next month, you’ve got to come back in 30 days and convince me that we should still fund this”.

In terms of behavior, this is going to change the dynamic of what we’re going to do instead of just trying to execute on the plan in the budget. We’re going to start thinking about how do we have objective discussions every 30 days about what we’re learning and it might even encourage teams to go two months in and recommend that we don’t continue to invest in this because it isn’t working. The team is now engaged and taking ownership.

5. Release Continuously vs Integrate Continuously

With DevOps, we have to get to the notion of releasing quickly. If we are not releasing quickly, we are not going to be able to get something into production and learn quickly. We can’t just focus on continuous integration, we need to get all the way to continuous delivery. That is going to allow us the ability to respond and learn quickly. It is not just that we are moving fast, but that we are responding fast.

6. Measure Value vs Velocity

What are we measuring? Are we measuring in points? How many points were getting done? I hear too many people talking about how we need to get credit for all the work we did. That is an output mentality, and we want an outcome mentality for our teams and organization. It is not about how much code we get done, but how much of the right code we get done.

I like how Hendrick Neiberg puts in his video “It is about getting the most outcome with the least amount of output.” When I think about measuring value, I am not thinking about value in terms of dollars. Measuring value goes all the way back to the objective. Are we making an impact from an outcome perspective? While velocity is still a metric we should capture, it’s not necessarily the metric we should be focused on.

Connecting Our Values To Our Practices

On the left, we have a summary of those values and on the right, we have the six practices that I just walked through that correlate with those values.

[Here, we asked our audience: “Which of the practices on the right do you think is the most important?. See poll results below.]

Presentation Conclusion

Getting predictable and getting faster is what enables us to have this next level of Agility and be adaptable. We can respond to our market if we can push things into production quickly, and we can only push things into production quickly if we are able to have a predictable cadence of delivery. We can only do that if we have created a foundational culture of team ownership and team improvement.

Q&A

1.How do you emphasize discovery over execution while also adapting to change instead of just executing to a plan?

I think adapting to change is part of discovery but I do think that discovery and execution can compete with each other. As a startup, there is no execution because we are in discovery, we don’t know very much in that organization. At the other end of the spectrum, with maintenance work that is pretty well known there is a low risk that we’ve gotten it wrong. We understand it and just need to execute on it. I think most teams are more on the second spectrum but should be pushing somewhere in the middle.

As an industry, I don’t think we have all the answers on the best way to manage all of that work. One end of the spectrum is velocity, plan-driven, and predictable but in the discovery world, we don’t have that same level of predictability. We don’t have a plan that is fully laid out so we are iterating towards the target. We know we are done when we have achieved some of the objectives or have proved the hypothesis wrong. Distinguish the difference between that work and make that clear. You may have a team that is more discovery focused and a team that is more execution focused and that could be an interesting thing. There will also be teams where that is mixed. Here, the priorities should become tied to key objectives so that we can figure out how much time to allocate towards each side of the spectrum.

2. You mentioned having customers as a part of sprint reviews. How do you think a UX team who uses Scrum plays into that?

UX is really critical in this new world and can be one of the main conduits in trying to bridge the gap between the customers and the team. In Agile 1.0, I would say that I’ve always seen UX as being a representative of the team but working ahead of them, making sure the team has what they need. But in this world, they may be the person who is really helping drive production and partnering with product on the objective, the hypothesis, and the experiments that could be run. Sometimes that is classic techniques in UX, like paper prototyping and user testing.

At the same rate, I too often see folks go way too far to the right, being very analytical and research driven. I believe that the more analysis and research we do, the more we convince ourselves we are right without true validation of the market. We definitely want UX in this new world to start thinking more iteratively and incrementally and not fall into the trap of perfection. We’ve got to work in an iterative, collaborative way with the team. The team of product experts, UX experts, and technical experts together, taking through objectives and defining hypotheses and experiments. Everybody’s got their specialty they are bringing to the table but we are all working together to iterate towards the end goal.

3. What are your top three agile metrics that you would report to leadership?

It depends on your context. The metrics I would report would be less about output and velocity. If you are improving and trying to get predictable, then I would look at metrics like velocity, amounts of carryover, and predictability.

At this stage, what I would be reporting are business metrics and customer metrics. The metrics should be tied into the objective. An objective and various key results that drive towards your KPI’s. The other metrics are more internal for the team: velocity, what’s happening, owning our improvement. However, we ultimately have to think about the business outcomes.

4. If Agile 1.0 seems to be working for some of us, how will Next Level Agile become more necessary than traditional Agile?

I would say Agile 1.0 is sufficient, but not great for many companies. I think most companies and CEOs that I talk to are really challenged right now to keep up with the changing dynamics of their market and culture. The rate of the number of Fortune 500 companies that are going out of business is exponentially increasing, whereas 30 years ago if you were the Fortune 500, you expect to be in it for decades.

While Agile 1.0 might feel sufficient, it is not. That is my challenge for you today. Think about how your market is changing, and the ways in which you’ll need to adapt. If you get comfortable, you are going to get your ass kicked soon by someone else in your market. If you are not creating organizational agility, your company is going to be struggling in the next 4-5 years.

Do You Need Help Reaching the Next Level?

If you have questions or feel stuck somewhere along this Path to Agility®, we’d love to talk to you, your organization, or your leadership team about how to help you accelerate through your Agile journey. Visit our service pages or contact us at info@agilevelocity.com for more information.

Blog

Webinar Recap: The Evolution of a User Story

By: Agile Velocity | Nov 02, 2017 | Agile Tools, Video, Webinar

User stories are a staple in Agile but it can still be a tough practice to master, particularly for newer teams. A user story is defined as a short description of a feature or product told from the perspective of the end user or customer. They typically follow the same simple format:

As a < WHO >, I want < WHAT > so that < WHY >.

Many Product Owners we work with find themselves struggling with when and how to break their epics down into actionable user stories. Another challenge? Team members get frustrated because the user story doesn’t capture all of the details needed to begin work and complete it successfully.

How do we fix this?

Our Agile Coaches, David Hawks and Braz Brandt discuss the “when” portion of breaking down epics into user stories and how you can get into a regular cadence of evolving your backlog through collaboration between Product Owners and the Dev Team in this recording of our December webinar, The Evolution of a User Story.

Q&A Transcription

1. Looking at the lifecycle of a User Story, as a Product Owner, how do I how do I balance PO responsibilities (stakeholder management, decomposing epics, etc.) with being available to the team so that they can continue to be a high performing team?

David: There’s actually some language that’s been lightening up in the Scrum Guide around who actually does all the work. Traditionally, it’s been the PO who does all the data entry and whatnot after Backlog Refinement. Now, it’s something that the entire team might help finish. When the PO is overloaded, the team needs to recognize that and find ways to relieve that pressure.

2. Where do things like Behavioral Driven Development (BDD) or writing in a Gurken format (given…when…then…) tie into the traditional User Story format?

David: So some people use these formats for writing acceptance criteria, and that can be helpful. For me, that can sometimes be extra overhead. I think teams might take things too far at times.

If you’re writing acceptance criteria in more readable language, and then those acceptance criteria then become automated tests, that can be pretty valuable because we’re not having an extra translation step. However, if you’re not doing BDD, and not actually automating those tests, then it might be too much extra ceremony or overhead for the team.

My advice is to make sure that you’re keeping a balance when trying either of these methods.

3. I find it near impossible to write plumbing type stories from the user’s perspective. I run a small team, so our velocity doesn’t always allow for user value in a single sprint when plumbing or re-plumbing is required. What is your advice? [Plumbing meaning the database code, the API layer, service, microservice, etc. The stuff underneath the product.]

David: Let’s take a look at this diagram:

What we see a lot of times is that teams are structured in terms of database, middle tier, or UI, etc. What we don’t want is to write a story from a component or architectural dimension. That’s not actually a valid story. So that’s probably the challenge that you’re running into: You’re trying to write a story for something that is actually a task. We need to think about writing the story from the user’s perspective. This could be a challenge for your team for multiple reasons:

Your team is made up of just people from that plumbing level (like one of the black ovals in the diagram). This could be problematic because then you have a component team. These teams are challenging because they don’t have all the capabilities to deliver a user story. So in Agile, when we talk about creating cross-functional teams, we mean a people from different levels creating a feature team, so that we get multiple capabilities and perspectives to form a functional user story.
You don’t need a user story for the issue! The re-plumbing question is a good example of this. This issue likely comes from a case of already having the functionality, but now there’s technical debt problems or refactoring that needs to be done. In that case, a user story might not be necessary. Remember, we don’t have to force everything into this user story format.

4. How do you handle stories that are highly technology driven? For example, an internal department delivering to a larger organization’s IT developers?

David: The first test I’m always going to apply is “Can we build a cross-functional team to simplify dependencies?” The Agile answer is to put as many of the dependencies on the same team as we can so that they are all working together. Conway’s Law tells us that we have a tendency for any structure built within an organization to mimic the organization’s structure. That creates issues in technical structures because it causes us to overcomplicate our technical architecture which can make it difficult to put all of those skills onto one team. Sometimes, it’s more than just putting people together and more about taking a look at that technical architecture and perhaps refactoring.

Now let’s say we have done all of that. At the other end of the spectrum, there’s a scenario where you need a system persona. Say the “customer” that you’re writing code for is a pharmacy system. In that case, it’s okay to write a user story from the perspective of that system persona. The team that writes that user story might not have a UI because they only deliver to that pharmacy system, and that’s just fine!

What we don’t want to do it abuse that technique.

Braz: Yeah, I’ve used that method quite a bit. It’s important to be thorough when it comes to external vs internal users so that you don’t get mixed up. It’s all about understanding the user perspective.

5. Your example involved 16 weeks of backlog refinement before the first sprint starts for the new features, but I often have a hard time getting the backlog refined 4 weeks prior to the start of the sprint. What is your advice?

David: First, when I think about the backlog, I think about it like this:

There are things at the top, maybe some larger ones in the middle, and maybe even some extra large items at the bottom. Typically, we want this backlog to have at least 2-3 sprints worth of ready stories. Some teams even like to include a Definition of Ready (DOR). So by the time we get to Sprint Planning, we have the top 2-3 sprints worth of stories refined.

Also, we want everything that’s in our current plan or forecast is sized—they all have an estimate on it. We want all of these things sized so that if something new needs to get added to our backlog, we know what/how much needs to be taken away to still keep our forecast on track.

If the stakeholders or teams are slow to provide necessary feedback, maybe you just need to set some time on the calendar, get them all in a room for an hour or two, and get stuff done. Incorporating a consistent cadence of backlog refinement with the team into each sprint could help you stay on top of your backlog as well.

6. The previous question mentioned 16 weeks worth of work. How does that translate into actual time spent for the team? Also, what are your tips on accelerating conversations with the team when it comes to trying to get everyone into the room and providing feedback?

David: As far as tips go, I would start by breaking it down. Let’s first take a look at how much time is truly spent with the team over those 16 weeks. If we spend 5 minutes in our first meeting with the team where we do rough order magnitude, then maybe 15 minutes in a Backlog Refinement session, then another session where we spend 10 minutes breaking down some stories into tasks, then time totals to somewhere around 30-45 minutes total as a team actually working on backlog refinement.

Braz: If refining the backlog becomes a team effort in Backlog Refinement, then the work of inputting things into Jira or on a board becomes something anyone can do.

David: If it’s the highest priority, then the team should swarm to get it done.

7. UX activities – how do you recommend accounting for these in context of User Stories? Do you recommend creating User Stories for UX work or define these as self-standing tasks or subtasks, tasks, or simply as acceptance criteria for User Stories?

David: It sounds like the first question we should ask is if the UX person is working as a member of the team or outside of it. That’s going to dictate your solution. Having that UX person as a member of the team is obviously going to be more ideal.

If the UX person is a member of the team, then we want to make sure all of our work is visible. How do we do that within a tool, like Jira? It’s not always simple, and there’s not a perfect answer. I have seen teams create a Jira ticket—not really a user story—as something to create visibility. These tickets are simply there to show what the team is working on. It could be called something like “Prepare for Stories 1, 2, and 3”. Tasks associated with this could be things like meetings. While this isn’t necessarily work that takes place under a story, it is reflective of what the team is really working on.

So don’t get too hung up on making everything a user story. The focus here would be to make your work visible to the rest of the team.

8. Do you create separate “user stories” (or some other card type) for technical work that needs to be done to realize a User Story? Like “Create Database Scheme”, or “Do Development Work”, etc.? If so, what do you call these card types, and what content do you put in them?

David: From a Scrum definition, we would call those tasks. Jira would call those sub-tasks—not to be confused with Tasks, Jira’s straight-out-of-the-box version of a User Story. Most of the time, these sub-tasks underneath user stories don’t have much detail at all. The reason for this is that the whole team is present as they’re being created and we’re only creating these sub-tasks for the next two weeks. If we were creating them 6 months in advance, we’d probably need more detail to recall what the heck we were talking about. When we’re only planning for a two week sprint, they’re fresh in our collective mind and we don’t need all of that extra work to be done.

As far as documentation of design and other things, Jira isn’t the place for that. Instead, you can put that on your favorite Wiki software, like Confluence. Sub-tasks or tasks are very transient things—they should go away after two weeks. If you have a co-located team, we even recommend tasking on a physical board where tasks are sticky notes on a wall so that you can just toss out the sticky notes at the end of your two-week sprint. Your stories should, of course, be documented in Jira, but the tasks aren’t meant to be extensively documented. You just don’t need it.

Braz: This takes me back to User Stories 101—it’s the 3 C’s. We can have a ticket and the ticket can describe some user value, but the ephemeral conversations that we have on a day-to-day basis about how we’re going to turn those tickets into real-life user value. Also, how we’re going to capture the outputs of those conversations in things like delivered software, just-enough documentation, and long-term artifacts.

Looking for more information on user stories? Check out these articles:

4 Characteristics of a Personable and Useful Customer/User Persona

Why You Need to Jazz Up Your Boring User Stories

Blog

Overview of Agile Scaling Frameworks – Webinar Q&A

By: Agile Velocity | Oct 20, 2017 | Leadership, Video, Webinar

We recently hosted a webinar exploring 6 major Agile scaling frameworks: SAFe®, DAD, LeSS, Nexus™, Scrum at Scale, and Enterprise Scrum. We had a blast, but we were unable to address all the questions asked during the Q&A portion.

You can find the recording below. We also took some time after the webinar to answer the remaining questions (below embedded video). We hope you were able to shed some light on the different scaling practices. If you have further questions, don’t hesitate to reach out. We will also be creating a white paper about scaling, with extensive coverage on SAFe®.

Overview of Agile Scaling Frameworks – Webinar Recording

1.What framework best fits (or is most adopted) by highly-regulated enterprises (such as financial services, healthcare, etc)?

Both SAFe® and DAD have constructs that make working in a regulated environment easier, such as solution intent, a repository for requirements, and traceability maps.

2. How do these frameworks handle the “exceptions”—last minute, high-priority items that do not fit into the regular timeline? How do you short-circuit the process?

All of the frameworks include the concept of a prioritized backlog, and several have backlogs for different levels. When a high-priority item comes in, the Product Owner (or content manager at the appropriate level) orders the request at or near the top of the Product Backlog. At the next Iteration Planning meeting, the new request is likely chosen.

3. Is there a checklist/comparison chart to pick the right and possibly best framework for an organization?

There are several comparison charts available from various sources. One good one is from Box. We certainly advise the use of an Enterprise Agile Coach to help you make the right decision, as it is often not just a single framework—most enterprises need a custom solution.

4. Do you have a list of companies or products that have successfully adopted each of these frameworks?

These lists and case studies are available on the websites for each framework.

5. Do these methodologies apply to other departments in an organization (with many departments e.g finance, marketing, etc.) OR are they meant for the IT Departments of organizations and software companies (whose only product is software)?

Each of these frameworks is generic and work quite nicely in non-IT environments. Over the last 10 years, more and more organizations such as HR, Marketing, Sales, Operation, etc. are using Agile and scaled solutions.

6. I’ve got about 5-7 Agile teams about to be realigned to newly defined product lines, most currently use Scrumban for execution. I’m leaning towards recommending LeSS to leverage the familiarity with ceremonies and cadence. We don’t have a critical need to incorporate business side at this time, which is why SAFe® was lower. Any pitfalls you see with this approach?

No pitfalls at all. LeSS is a great choice for you, especially if you would like to introduce some Lean economics type thinking into your organization. You may also want to take another look at Essential SAFe®. It is a 2-level approach for Agile teams and Agile programs (no business level).

7. Any quick advice on how to tell if an organization is “doing Scrum well”?

The classic evidence of “doing Scrum well” at the team level is each team is delivering business value each iteration, they are using WIP Limits to optimize flow, and they have tangible evidence of improvements over time.

8. Is the assumption for all these scaling models that “all teams will follow Scrum”? Are there any models for scaling that accommodate organizations with Scrum and Kanban teams?

Absolutely. Both SAFe® and DAD accommodate Scrum and Kanban teams quite nicely. Nexus™, LeSS, Enterprise Scrum, and Scrum at Scale are focused only on Scrum.

If you’re specifically looking to start a SAFe^® implementation, we recommend starting with Leading SAFe^® training. You can explore our public and private training options on our Leading SAFe^® training page by clicking here.

Blog

Daily Scrum Cheat Sheet

By: Agile Velocity | Sep 26, 2017 | Article, Product Owner, ScrumMaster

Daily Scrum Meeting Purpose

The goal of the Daily Scrum meeting is to synchronize and plan the team’s work toward the Sprint Goal over the next day (until the next Daily Scrum) meeting.

Attendees

Delivery Team
ScrumMaster (Owner)
Product Owner (Optional, but preferred)
Stakeholders (Optional)

Agenda

Make sure that the team starts on time. The ScrumMaster asks one of the team members to begin (if they do not take the initiative to start on their own).
Each Delivery Team member should briefly (minute or less) update the rest of the team on three key points:
1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Add other needed discussion topics or issues to a parking lot list as they come up so that they don’t interrupt the team quickly getting through an update from each of the team member.
Ask the team how they are progressing toward the Sprint Goal.
Once the normal Daily Scrum has ended, team members should stay around or plan to address items placed in the parking lot during the meeting

Meeting Prerequisites/Preparation

Make sure that these are done before each meeting.

Sprint Goal should be up-to-date and visible
Current progress toward the Sprint commitment in the form of completed work, remaining work, and what is in progress
Current Sprint Burndown chart indicating progress toward the Sprint Goal and ideal effort needed to reach the goal

Guidelines

Schedule a 15-minute block of time every day at the same time and location where the team can meet without being disrupted. This should happen close to the team’s work area or where they can review a current sprint board.
The Daily Scrum should ideally run by the development team, not the ScrumMaster. The ScrumMaster should ensure it happens regularly and is conducted well but may not need to even speak if the team is running it well
The ScrumMaster should ensure that the meeting starts on time, keeps moving at a reasonable pace, and stays on goal
The ScrumMaster is also responsible for making sure that identified impediments are recorded and addressed by someone

Anti-patterns

These are patterns or behaviors that lead to inefficient or ineffective meetings. They should be addressed whenever found.

Someone other than Development Team members speaking during the meeting
Team members focus on the ScrumMaster and tend to report rather than inform and collaborate with the rest of the team
Daily Scrum meeting doesn’t start on time
Meeting doesn’t occur daily
Daily Scrum meeting lasts longer that 15 minutes
Impediments have never been identified
Team doesn’t follow up on issues/impediments
Team doesn’t adjust the plan to meet sprint goals

Get started on the right foot. Learn about private Agile training.

Blog

Sprint Planning Cheat Sheet

By: Agile Velocity | | Article, Product Owner, ScrumMaster

Purpose

The Sprint Planning meeting is a two-part meeting where the team commits to a sprint goal for the next two-week sprint with a complete sprint backlog of prioritized product requests, their tasks, and sizes. The first part of the meeting is when the Product Owner presents the highest priority stories from the Product Backlog and discusses them with the team so that there is a shared understanding of what the work is. The second part of the meeting is when the team determines how they will accomplish the work and makes their commitment for the sprint.

Attendees

Delivery Team
ScrumMaster (Owner)
Product Owner
Stakeholders (optional)

Agenda

Part One – What work needs to be done

Review the Product Vision and Roadmap (Product Owner)
1. Product Owner reviews this to help focus the team.
2. Should be brief – typically not more than 5minutes
Review and discuss Product Backlog items that are candidates for this sprint (Product Owner)
Capacity Planning (ScrumMaster)
1. ScrumMaster reviews dates for next sprint with the team. Consider holidays, long meetings/trainings (half-day or longer), and vacation when calculating working days for each team member.
2. Daily capacity used is typically 5 hours per team member.

Part Two – How that work will be accomplished

Pull backlog items (stories, bugs, etc) into sprint (Team)
1. The Team, not the Product Owner, selects (in priority order) how many backlog items they feel confident that they can deliver at the end of the sprint.
If needed, review Definition of Done and update (ScrumMaster/Team)
Task out and estimate pulled backlog items (Team)
1. For each item pulled into the backlog, the team breaks down the work into smaller
2. Estimate each task in hours (16 hrs max). Most tasks should be able to be completed in a day.
Define sprint goal (Team and Product Owner)
Make commitment (Team)

ScrumMaster Responsibilities

Ensure that the meeting happens each Sprint and that all needed attendees are present and participate
Make sure everyone understand the purpose

Product Owner Responsibilities

Prepare and bring an updated release forecast and update the attendees on the state of the backlog and forecast
Prioritize the backlog and ensure the top priority stories are ready for the team

Team Responsibilities

Commit to work to be done during sprint

Cadence/Duration

Sprint planning should be held on the first day of a new sprint. The recommended time for the Sprint Planning meeting is two hours per week of sprint (i.e. four hours for a two-week sprint).

Meeting Prerequisites/Preparation

Make sure that these are done before each meeting.

Sprint Goal should be up-to-date and visible
Current progress toward the Sprint commitment in the form of completed work, remaining work, and what is in progress
Current Sprint Burndown chart indicating progress toward the Sprint Goal and ideal effort needed to reach the goal

Anti-patterns

These are patterns or behaviors that lead to inefficient or ineffective meetings. They should be addressed whenever found.

Get started on the right foot. Learn about private Agile training.