We had so much fun at Keep Austin Agile this week! We hosted Agile City Limits with a special guest-star appearance from Mathew McCut-out. Some might say it was alright alright alright…
At Agile Velocity, we focus on business outcomes over practices. From our experience, transformations are most successful when aligned around a compelling purpose for change tied to what business outcome(s) you want to achieve by implementing Agile. The Path to Agility® approach has identified 9 Business Outcomes organizations are often after when embarking on an Agile journey.
9 Business Outcomes of an Agile Transformation:
Employee Engagement
Employees are more satisfied in their work, willing to go the extra mile, passionate about the purpose of their jobs, and committed to the organization.
Customer Satisfaction
Customers are satisfied with the experience, benefits, and outcomes when using your product or service.
Quality
The product or service meets the expectations of the market for usability, reliability, etc.
Speed
The time it takes to deliver an idea into the market.
Predictability
Teams maintain a predictable cadence of delivery enabling the business to make informed business decisions.
Innovation
New ideas, creative thoughts, or novel imaginations provide better solutions to meet new requirements, unarticulated needs, or known market needs.
Market Responsiveness
The ability of the organization to pivot quickly to respond to ever-changing market demands.
Productivity
Increase the business value realized while maintaining or reducing costs.
Continuous Improvement
The ability of the organization to relentlessly pursue optimizations in all aspects of business functions.
At the event, we asked attendees to “Choose their Headliner” aka select their driving business outcome, here are the results:
The top business outcome selected by Keep Austin Agile attendees was Customer Satisfaction. Customer Satisfaction is often a focus for many organizations because is earned, never given. When customers are satisfied, or better yet, love your product/service, it means your organization is solving real problems for them. It means you’re always looking for better ways to engage with your customer and understand their needs. The bi-product is the ability to provide your organization with clarity and focus. It means you’re saying ‘no’ to more of the distracting things so you can say ‘yes’ to the right things.
The Path to Agility map highlights key Agile Outcomes your organization should focus on for each of the 9 business outcomes. For Customer Satisfaction, these Agile outcomes are highlighted in the image below.
By leveraging the Path to Agility approach, we align your entire transformation around what you are trying to achieve, making sure you focus on what is important. You can learn more about our approach to transformations, here.
What is your driving business outcome and why? Comment below.
This past weekend I went to an Agile meetup and a particular question kept coming up in many variations, “Whose agile is it?” And the answers equally had many versions–Some sided with ‘software teams’ and said, “Agile only works for development teams”.
Others sided with ‘executives’ because they are the influencers. And some, including me, were scratching our heads thinking, “have we strayed too far from the why behind it all?”
Finding the Why Behind your Agile Journey Agile, as many of us have experienced, is a culture and a mindset. An organization with a compelling purpose to improve, regardless of software or business teams, experiments with a set of practices, and iterates through them operates with agility. Success comes to those that are intentional and holistic about it.
When trying to master a new skill, practice and support lead to permanence. Similarly, during a transformation journey, top-down support and bottom-up practice lead to Agile maturity. Focusing on the WHY behind an Agile journey unites the whole organization to prioritize the need for change and creates resilience to resistance. When leaders acknowledge, celebrate, and support the WHY, people in the Organization feel safe to experiment and excel.
Embrace Change, Celebrate Wins I have witnessed both. Leaders that mandate the transformation without truly standing behind the purpose, eventually blaming it on Agile, and those that have internalized, walked along with the members of the organization, experienced the shift, supported the challenges, created room to fall, and celebrated even the smallest wins.
I remember, when I was supporting a major transformation at a financial organization, a team had accomplished a 100% say/do ratio during a sprint–which was consistently slipping for them for a few sprints. When the VP of the technology department learned about this, he formed a human chain and brought the entire floor to applaud the team and their accomplishment. He said it was important to acknowledge the win and didn’t measure, small or big. It was an accomplishment worthy of celebration. He openly encouraged, empowered, and supported the transformation.
Making Sustainable Change Purpose is very personal. It varies for everyone. A new level of clarity is attained when it is acknowledged. For example, I have learned through many failed attempts that yo-yo dieting does not result in permanence. In order to make real change, I need to make a lifestyle change. It’s a mindset shift. I had to intentionally focus on the reason behind my desire to be healthy. I had to allow myself to feel safe when I failed. The final why that clicked for me was when I realized, clean eating aligned with my philosophies of clean earth and leaving it better than I found. THAT was my compelling purpose!
The question is not whose Agile it is, the question is, do you have a purpose for change? Without that, you are trying to solve a puzzle with a lost piece.
So ask yourselves again, what’s YOUR purpose for change? Share if you don’t mind via comments below.
The second article of this series talked about success criteria and how to facilitate the voting process. This time, we talk about a critical aspect of PI Planning. Whether onsite or online, how do you make this event valuable and fun.
We’ve talked about how the social aspect of PI Planning is really important and why it makes PI Planning magical. Are there other reasons why onsite PI Planning is your preferred venue versus online? It’s definitely for the things that happen in the margins. When you are online, you need to precisely plan every interaction. When you are together in a room, you’re going to have unexpected conversations and those are always good surprises.
There are also physical interactions and jokes that inject fun that can only happen organically when you are in person. For example, during one PI Planning, we had a business leader show up in full disguise. He had on sunglasses and a hat so nobody knew who he was. He wandered around for the first 20 minutes but we couldn’t figure it out because it had been a while since we’ve been in person. Once he got up to the front of the room and started sharing his business vision, people were like, “Wow, is that [leader]? Then he took his hat and wig off and everyone figured it out.
The other thing that’s a lot easier in person, is the ability to wander up and listen at the outer edge of any conversation. It’s a lot like an Open Space, you can use the Law of Two Feet and wander over to where you are interested. That cross-pollination of conversation is what yields the best results.
How do you inject fun and create space for cross-pollination online? In one case, our RTE pre-printed fake event tickets. He did a mail merge so it had everyone’s individual name and assigned them a ticket. The QR code on the fake ticket actually worked! When you scanned the QR code, it took you to the online planning board.
We also had a theme for every one of our PI Planning events, whether it was remote or not. The first one was remote and we went to Hawaii. The second one, also remote, we went to Tahiti. The third one was onsite and we went to Florida (as a theme). The music matched the location: Hawaii was Hawaiian, Tahiti was Polynesian, and Florida was Miami Vice sort of music.
In order to create space for cross-pollination, people will need to be able to move around. For online, we had separate breakout rooms where people could self-select into the conversation they wanted to be in. Prior to the event, you should think about whether you’re going to intentionally send people to breakout rooms or if you are going to allow them to self-select. In the instance of PI Planning, I believe self-selecting works best; people need to be able to choose when they drop in or leave a conversation.
There will be times when you need to gather everyone together in one room, such as when it’s time to listen to the plans or when we’re going to do the confidence vote. I suggest having a main room for that.
Another good idea we use to successfully encourage people to bounce around from room to room is setting up a lobby for lost and found. When someone is thinking “I don’t know where to go” they can go to lost and found and the person staffing that room will tell them where they should be.
I think the biggest reminder about facilitating a remote event is that you have to prod people for that cross-pollination. If you’re physically in a big room, it’s easy to walk over or ask someone to weigh in. But when you are remote, you have to remind people to drop into breakout rooms and encourage them to contribute to the conversation. There’s a lot of lurking that can go on but you should not be shy. Raise your hand, turn on your camera, come off mute, and say “I’m here because I have a question. Can I interrupt you guys?”
Do you have any advice for people who are more introverted? How do you make a more inclusive, welcoming space? Fun helps with that. The RTE’s and the coaches’ job will be to create a light, safe environment where anything can be said. Scrum masters are a good conduit to those conversations. During the event, we’ll bring all the Scrum Masters together three or four times throughout the day to discuss how much people are cross-pollinating and if we need to keep an eye on [issues]. If there’s a team that needs some help, a coach may decide to join the Scrum Master. Sometimes we’ll create a third ad hoc grouping if we need to get to two rooms together.
If you’re in person, it is easy to tell whether the event is going right or wrong. If the teams are on two different sides of the room and you don’t see people going back and forth, something is not right. It’s much harder when you’re remote to know if things are going well. You need to go out of your way to drop in the breakout rooms and listen. If it’s dead silent, after joining a room for five minutes, it’s probably not going well.
What supplies do you need for in-person? You need tons of stickies, dozens and dozens of stickies for each team. You need a big chart or foam core board for each team to visualize their plan on. At the front of the room, you’ll need a large program dependency board where we plan who needs what when. You’ll also need red string and scissors to map those dependencies.
You can also use props to increase excitement about the theme of the event. Go to the dollar store and grab sunglasses, confetti, or some sort of table swag that will lighten the mood. This is not conference room planning. It should be fun!
If it’s a train of any size at all, you’re likely going to need audio and visual support. You’ll need projectors and mics so everyone in the room can see and hear what is going on. You’ll also likely need to help people get used to being on the mic. I always have to remind people that if you can’t see the mic in your hand, then we can’t hear you.
What do you say to organizations that may prefer the online version because it’s cheaper and easier to coordinate all of those people? Well, [online] is always going to be cheaper. The question is, are you getting the same value for the 2-day investment? You’re still taking people away from whatever they’re doing for those two days because we need their full attention even online.
[My opinion] is the cost of food, room, and travel for anyone who’s flying is probably worth the investment given the increased value that you’re going to receive from being in-person. Although we’ve gotten good at [remote] PI Planning, and we’ve been kind of forced to do it, I’m not sure I agree that we’re getting the exact same value [when compared to onsite].
Some companies have a work-from-anywhere policy, but they also have this idea of “Moments that matter.” PI Planning is one of those moments where most companies, even if they have a remote policy, have seen the value in coming together on location for planning.
If there are people that couldn’t attend in person, would you try to incorporate them in a hybrid way? You can review and discuss on a case-by-case basis. If someone really can’t get there or if they have health concerns, we will adapt and figure out a way to make it work.
[Hybrid] is tough. The level of toughness depends on whether the person needs to contribute or not. We had some people that were remote that needed to see the leadership decks and the output of the event–passive consumers of the plan–and that works fine. The hard part is when you need to contribute in a hybrid environment.
During the last hybrid PI Planning event I was a part of, a few team members that were remote, were on the laptop Zooming with the rest of their team. It was hard to hear though…. In the middle of the event, we actually ran out and got some Bluetooth speakers that we wired to each team so they could hear their remote members and vice versa.
Any last words of wisdom? It was awesome being back in person. I would always choose to do PI Planning in person if you have the means. It may turn into alternating between remote and in-person. If you can, you should always do [in-person]. I would fear to lose in-person PI Planning completely because they are so effective at reaching the intended outcomes.
Especially when it comes with a dollop of advice, guidance, mentorship, and new perspectives.
We’re bringing back Coffee with a Coach! During this time, you will have the opportunity to ask our coaches questions about anything related to productivity, employee engagement, innovation, agility, product development and management, transformation–you name it.
About Coffee With A Coach: When: Second Friday of every month Time: 8am CT (bring your own morning beverage) Who Can Register: Anyone with questions, those seeking to gain a new perspective or understanding, people looking to network and meet new peers (we encourage you to share the link) Zoom Registration Link: There are no sessions to register for at this time.
STATIK (Systems Thinking Approach To Implementing Kanban1 2) can be a great technique to help teams get up and running quickly, even teams that are using Scrum.
Applying the STATIK approach leverages the first principle of the Kanban method, “Start with what you do, or know, now”, in order to help avoid over-thinking how existing work, structures, and/or roles “fit” within Scrum. To be clear, I am not talking about what is commonly referred to as “Scrum-ban”. Applying this approach designed for Kanban can dramatically accelerate the forming and improvements of a Scrum team.
As a long time practitioner and coach of Scrum, I’ve observed many teams struggle getting started with the framework. Change is hard for most people and we often get resistance at first. Even though the level of change is relatively low with Scrum, it can be a challenge for some teams to get started in certain environments.
A couple of anti-patterns I see repeatedly include:
Management struggling with how to address new role definitions like Scrum Master and Product Owner among other aspects of the framework. This causes anxiety and distractions for teams who simply want to get started working together.
Teams jumping into Scrum without getting grounded on the nature and characteristics of their work or ecosystem. This often means the teams are just going through the motions and may be slow to build shared ownership of their work and outcomes.
Over the years I’ve tried a few different approaches to help teams get started. I learned about STATIK from a colleague several years ago and began applying it as a model for my Team Chartering workshops. I have used this approach to help teams form and establish norms for them to work toward–including how they will norm around Scrum.
The STATIK method helps answer the following questions:
What is the purpose of the team?
What are the products or services we provide and to whom?
What is the current way of working?
What are the sources of dissatisfaction?
What are the sources of demand?
What are our current capabilities?
How does work flow through the team/system?
What kinds of services are there?
How to design a kanban system that allows us to visualize and manage the work?
For the purposes of this topic, I will be referring to the “kanban system” (lower-case ‘k’) rather than the Kanban (upper-case ‘K’) method, since I’m not limiting the use of STATIK to teams implementing Kanban. The kanban system represents the elements and boundaries of the team’s work. For a Scrum team, that may include from the point an item enters their backlog until the point they declare it “done”.
Here’s how it works –
At a high level, STATIK involves the following steps:
Understand ‘fitness for purpose’ and identify sources of dissatisfaction
Analyze demand
Analyze capability
Model the workflow
Discover classes of service
Design kanban systems
Roll out – socialize and negotiate, measure, inspect and adapt…
Using STATIK with a Scrum Team
Setting up the workshop: To make it relatable, I provide a “Story” card for each of the steps and set up a simple kanban board to visualize the activities as we progress through the workshop. For each Story, there are Acceptance Criteria that represent the activities that we will work through together and enable the team to agree on what is ‘good enough’ for the team to move forward.
This is how I design the chartering agenda
As with any team activity or workshop, it’s important to properly set the stage and get everyone connected. A simple connection exercise could be to ask the participants to consider and discuss the following:
What are the major characteristics of our Work, our Team, or our Process?
How do these characteristics impact our delivery?
How do these characteristics influence our decision-making?
This gets them thinking beyond just “We do ‘X’” and opens up the door for the Systems Thinking aspect of this. *NOTE: Depending on the knowledge and experience of the team, you may need to provide a brief overview of Systems Thinking3. I’ve generally found it’s not a critical barrier to running this workshop, but a little overview never hurts.
Step 1: Understand ‘fitness for purpose’ and identify sources of dissatisfaction
The intent of this step is to explore the criteria that define customer satisfaction and define the “fitness criteria” such as lead time or quality. These determine how the customer evaluates whether the service or product delivery is acceptable, or “fit for purpose.”
When working with teams that are applying Scrum, I will adapt this step (since Scrum addresses these differently than Kanban) by discussing fitness criteria, as well as conditions for success and the norms that they will need to agree on in order to fulfill their purpose. The team will create their Definition of Done in steps 5 and 6 and establish appropriate mechanisms to measure and enable customer satisfaction.
This step can be facilitated as a single story, but I tend to break it into two separate stories so that the team has a full appreciation of their current state before moving on to the next steps.
Story 1: As team members, we want to define and validate our Purpose and our ability to fulfill that purpose, including conditions of success, so that we have a strong sense of our team identity.
Acceptance Criteria
We have drafted a mission statement and team slogan
Our Values and supporting Norms are known (We believe in… Therefore we will…)
We have defined high-level Conditions for Success
We are able to serve the needs of the Customer
Story 2: As team members, we want to discover areas for improvement, what our customers and stakeholders are saying, and delivery or quality challenges we are facing, so that we can be more customer-focused and start building a backlog for continuous improvement.
Acceptance Criteria
We have exposed all relevant Sources of Dissatisfaction and/or things we struggle with
We have visibility to and understanding of Customer and/or Stakeholder feedback
A backlog for Improvement has been created or updated
When forming new teams, Story 1 is a great way to get teams started and centered on their team identity. Prompting questions can be something like–“Why are we being formed as a team?”, “What do we stand for”, “How do we want the rest of the organization to view us?”.
At this first level, I try to emphasize fun and safety, keeping it light and even a little idealistic. Things get much more detailed and analytical later, so providing engaging and uplifting conversations right off the bat sets a positive tone. During this step, I typically encourage brainstorming, but will also work in some form of diverge-converge activity to get ideas generated and shared.
A few things that quickly emerge here–introverts & extroverts, visual thinkers & critical thinkers, as well as those who “just want to start doing the work” & those who “want to feel like we’re a real team”. Don’t try to solve or fix any of that. It is, in part, what will define their norms as a team.
When working with existing teams, Story 2 may be a bit more impactful. Hopefully, there is data/feedback available from a prior Retro and directly from customers and stakeholders to leverage. If so, we will pull in the relevant data and/or feedback and go through some sort of a “reconnection” activity, asking everyone to write a few stickies (physical or virtual) for each item from the past Retro, relating to how it impacts them or their thinking. We may do some dot-voting on items to see what people view as most important or impactful. If there is no prior feedback or data to reference, this presents an opportunity to do a Retro and seek feedback from others.
Before deciding what format would best serve the team, I probe into their norms and experiences. For example, if they’re not doing regular Retros–why is that? Or, maybe they’ve been doing them, but they don’t seem valuable or meaningful to everyone.
From here, I can then choose the approach that would be most impactful, rather than just repeating a technique they’ve seen before. One technique I find works well, in this case, is using the Sailboat/Speedboat format4. This is a great visual, metaphorical way of exploring how well, and under what conditions, a team is performing. We can glean insights and specific, practical ideas that will be used on upcoming steps.
If there is no recent customer or stakeholder feedback available, we will craft a simple survey or questionnaire that can be sent out. In this case, keep it simple, but try to create a sense of urgency so the team can get feedback quickly that they can use right away.
Step 2: Analyze demand
Story: As team members, we need to analyze sources of Demand, so that we have a shared understanding of who is requesting services/product from us and the characteristics of the items in our backlog.
Acceptance Criteria
ID primary (if not all) sources of demand – including from whom/where, frequency, complexity, and impact of requests
Understand the various characteristics of the requests and how that translates into work in progress
Agreement on critical gaps or risks to our ability to effectively deliver
Here we explore Demand. What are the characteristics and origins of our work? For a Scrum team, some may simply say, “we pull work from the backlog that our Product Owner has prioritized”. While this may be technically correct, we need to go beyond that to understand all of the sources of demand, as well as answering questions like:
How frequently does demand come to us? (known as ‘arrival rate’ in Kanban)
How complex is the work?
How much variability do we have?
What are our customers asking for?
I find it valuable to start with Stakeholder mapping. There are a myriad of formats, but I tend to start with a basic context diagram to visualize the team’s key stakeholders. Are they consumers or contributors, internal or external? Understanding these first two dimensions can help answer questions about how we communicate or interact, how frequently we interact, and where they fit in our overall workflow.
Once we understand Demand, we can then analyze the team’s capacity, or capabilities, to serve that demand.
Step 3: Analyze capacity
Story: As team members, we need to analyze sources of Demand and our Capacity to respond, including the skills and capabilities we need, so that we have confidence in our ability to deliver effectively and optimize our work.
Acceptance Criteria
ID primary (if not all) sources of demand – including from whom/where, frequency, complexity and impact of requests
ID our Capacity to focus on the work at hand, including the core skills and capabilities needed to deliver. (Initial Skills Matrix developed)
Agreement on critical gaps or risks to our ability to effectively deliver
This is another step that I will adapt for Scrum teams. I will use one of two techniques: a) Market of Skills activity or b) Skills Matrix creation. My choice of technique depends on how I interpret the teams’ level of creativity or analytical preference.
The Market of Skills approach tends to suit teams that are more playful, open to exploration, or may have more of a “Clan/Collaborative” or “Adhocracy/Creative” cultural orientation.
Market of Skills is gamification that uses the metaphor of a market where you may sell goods. In this exercise, you are selling your skills and unique capabilities to your team members. When using this technique we may include a variety of skills beyond just the technical skills needed for the job. Someone may include musical skills or that they’re good at puzzles–this makes it fun and helps team members connect with each other on a personal level.
The Skills Matrix modeling may fit better with teams that are “all business”, very serious about their work and/or more of a Hierarchy/Controlling or Market/Competing cultural orientation.
A Skills, or Competency, Matrix activity is more direct and analytical. Step 1 is focused on identifying the technical and soft skills needed to do the work. Step 2 is to have each team member self-assess their competency level with each skill. Teams may choose how they want to reflect this–using a numeric scale (0-5), shading a quartile (see example), using symbols, etc. The key here is to encourage safety and honesty without judgment.
After each team member has self-scored, the entire team can then review the matrix and discuss the patterns they see. Where are the gaps or weaknesses? The team can then discuss how they will deal with that.
The bonus benefit of this technique is that the team can also use the Skills Matrix to identify knowledge sharing and cross-training opportunities. If a team member is an “expert” in a specific area where others may be novices, they may agree to form mentor-mentee relationships.
While these techniques are most commonly associated with forming new teams, I have worked with many existing teams that have never done this sort of analysis and benefit from it as well.
Step 4: Model the workflow
Story: As team members, we need to model how work, information, and decisions flow through our team/system so that we have visibility to where we will need to define explicit policies and potential bottlenecks as we design our kanban system
Acceptance Criteria
Visual representation of how work flows through the team – May start with “most common” items and/or “happy path” workflow, then iterated to refine for exceptions or more rare scenarios
Activities that provide the most knowledge are identified
Tag potential bottlenecks or gaps that will need to be resolved
I often find this activity to be the most interesting and impactful, particularly for existing teams. When I ask “Does everyone know what our process is for getting things done?” everyone usually nods and says “yes, of course.” However, once they start visualizing it, it’s not uncommon to see multiple versions emerge. It’s not that people don’t know their process or how work and decisions flow through the team. But, until they start mapping it out, they hold a bunch of assumptions and interpretations that may or may not be valid. That’s the power of collaboratively modeling the workflow.
David Anderson1 recommends asking the question, “What activity gives us the most knowledge?” I love this question. It helps the team think beyond the tasks they perform and gets into the meat of their learning and decision making. Building “why” and “how” into the system is just as important to the “what”. I encourage teams to map this into their workflow/kanban system and to incorporate it into future retrospectives.
Depending on the size of the team, we may break out into multiple, small groups (diverge), then re-group to compare and contrast. Ultimately, the whole team needs to agree on a reasonable representation of how their work, knowledge, and decisions flow through their system. (converge).
For new teams, it’s obviously a little different. It can vary a bit depending on whether they are: a) newly formed, but experienced with the context or delivery approach, or b) new to everything – each other, the work, the context, etc. In either case, it’s more of a greenfield discovery activity and is generally done as a whole team rather than the diverge-convert approach. For new teams especially, it’s important to remind them that “perfection is the enemy of progress”, meaning we’re not going to get it perfect the first time. We just need to get it “good enough” so that we can start to do the work, then inspect and adapt as we go.
In all cases, it’s not uncommon that the team will identify multiple “what if…” or “yeah but…” scenarios. If time allows, explore those that may be critical or impactful. For the rest, we tag those as “exceptions” and may add an item to the backlog to iterate through those in the near future.
Step 5: Discover classes of service
Story: As team members, we need to define the various classes of service that will require specific, Explicit Policies (rules), so that we are able to design our Kanban system to effectively optimize flow and give everyone awareness of the ”rules of engagement”
Acceptance Criteria
Key Classes of Service are defined, including prioritization, service level agreements, definition of done, etc.
Team agrees on all explicit policies (rules) related to each Class of Service
A Class of Service is a set of policies which describe how something should be treated.
These definitions provide clarity on how to prioritize items as well as what and how we may handle an item, how to decide which items are more urgent–needing to be worked immediately–versus items that can wait.
A common example for a Scrum team might be to define how they handle new development work versus product support or maintenance work.
Often, the sources of dissatisfaction activity can uncover new or different Classes of Service. Teams may also need to define items with different business risk profiles that need different policies. Class of Service definitions (Explicit Policies in general) help teams deal with potential challenges from stakeholders (e.g HIPPO or WSFL challenges), as well as issues related to flow, WIP limits, and bottlenecks.
Another common definition for Scrum teams is the Definition of Done. This is a form of an Explicit Policy and may be defined as a general definition for the team or it may vary depending on the rules or boundaries associated with a particular Class of Service.
Step 6: Design kanban system
This step is one of the reasons why I think STATIK is so effective. We don’t jump into designing the kanban system until we’ve done the discovery and analysis in the earlier steps.
Story: As team members, having now defined and analyzed the primary nature and conditions of our work, we need to design our kanban system, so that we can begin managing and improving our way of working
Acceptance Criteria
All Team members agree to an initial kanban system that will enable them to begin managing and improving the flow of work
The kanban system is visible*
Scrum teams often take the value of a well-designed kanban system for granted. After all, the Sprint is set and the Sprint Backlog is our “To-Do”, so all we need is to show “Doing” and “Done”. Right? Well, not always. Scrum was designed to deal with complex, adaptive problems.
So, our kanban system should be a proper representation of the complexity and adaptiveness that the team needs to manage. Many teams have both new development and production support to deal with, multiple products that they’re responsible for, or multiple external dependencies that cause wait states or other flow variances. The more complexity that a team has to deal with often means they need a more sophisticated kanban system.
There is no right or wrong way to design your kanban system. I encourage teams to be creative and emphasize the things that enable flow and collaboration.
Step 7: Roll out–measure, inspect, adapt…
To close out this workshop, we do a “team priming” activity. This activity was co-create with a former colleague of mine, Daniel Lynn. He and I have paired on countless workshops and engagements.
Story: As a team, we need to be able to start doing and measuring our work and find out what our current impediments are so that we can hit the ground running and ideally be able to deploy an increment or change to production in our first sprint.
Acceptance Criteria
Create a flipchart or other artifact reflecting:
Tools we need
Knowledge we need
Environments we need
People we need
Identify and communicate impediments to delivering a shippable product increment
Create the team’s Technical Backlog (user stories w/ acceptance criteria)
Communication plan/feedback loop for stakeholders
In this step, we discuss whether the team will maintain both a physical and electronic kanban board. Most, if not all, of the electronic tools have both Kanban and Scrum views built-in. I encourage teams to maintain both a physical and electronic board (often within a tool like Jira or VersionOne) for a while to give them both the tactile and electronic experiences in parallel. It’s much easier to experiment and update a physical kanban board than to change a template in a tool.
However, given the global remote workforce trend (new normal), having a single physical board is not as feasible as it once was when we had more co-located teams. So, instead I recommend using a virtual “whiteboard” tool, like Mural or Miro, or something simple like Trello, that can be easily modified and experimented with in lieu of a physical board.
Roll it out, socialize it, experiment, and… inspect and adapt.
Closing
Whether you’re launching a new team or already working as a team with Scrum or any other approach, consider trying STATIK to see if you can gain better awareness, alignment, and visibility into how the team works.
What ideas or concerns has this article raised for you? If you’ve tried and/or adapted STATIK with your team share your experiences and insights below.
It makes me nervous just thinking about conflict in the workplace. It brings to the surface old insecurities, hurt feelings, and power struggles. Through my education there was a constant mantra–No one likes a pot-stirrer, don’t rock the boat, grin and bear it –here are a million different phrases, but they all boil down to basic conflict avoidance. Moving into the professional world it is repeated in different ways, often under the umbrella of creating good workplace culture. Conflict is an unavoidable part of life and it will find you in the workplace.
A close friend once told me that all conflict comes from an expectation not being met. At first, this seemed like a gross oversimplification and I blew it off as idle conversation but it stuck in my brain as I began a new chapter in my career, becoming a Certified Scrum Master. Servant leadership, being the buffer between my team and our stakeholders, helping set and meet goals… it all entranced me. I wanted to be good at my job and be liked within the team. Conflict wouldn’t have a place in my team, we would be a well-oiled machine running through Kanban tickets like a dream. All decisions would be unanimous and in the best interest of the company. Laughter would fill all our meetings. It would be like a Hallmark movie.
Please, take a moment to laugh at how ridiculous that image was.
Introduce the next player in this story, March 2020 along with its trusty sidekick. Covid 19. Our team went from meeting daily in the office to meeting over Zoom, and the Scrum Master role went from an interesting idea to an official role in my life and a very important part of keeping my team together.
The solution.
Our team decided to split into two teams, consisting of six members each. The Scrum Master for the other team had more experience leading than I did, she is well respected in the company and is often referred to as the glue of our group. Those old insecurities kicked into high gear and fueled my determination to be the best.
I did what most people do, I took to the internet to find ways to help guide my team through the upcoming months. I poured through articles on Scrum and Kanban, videos on women in leadership positions, dug into the Thomas-Killman Strategy, read David Marquet’s Turn the Ship Around, and reached out directly to my trusted coworkers for guidance. It became obvious that my fear of conflict was not going to do the team justice and I was going to have to step far out of my comfort zone.
I reached out to people in the company and practiced interactions–we ran through scenarios of conflict management and I tried different ways to handle it until they sounded natural. I worked with my husband on long monologues of reassurance, collaborative language, and repetitive goals. I forced myself to allow silence when it felt deafening to me and opened the door for criticism on my abilities to facilitate our retro and planning sessions. I put our goals high on the Kanban board so they wouldn’t be forgotten. I got used to playing the devil’s advocate and finding holes in plans that I thought were the best course of action.
Still, my team was struggling. Each day I saw the tension building and I felt the let down of the situation in my core. I expected to work hard and to have struggles, but I didn’t expect it to be quite this hard or this personal. The other team had their share of storming, but they were coming out on the other side. And the better they did, the more pressure I felt and the more personal I took each ceremony. I set my own expectations too high, and they were not being met on any front.
After a particularly bad week, I packed up my car and drove to West Texas to see an old friend. The whole way there and throughout my stay, I contemplated if I was right for the Scrum Master role at all. Maybe this was a sign that I should run, and that my team would be better off without me involved. My friend allowed me to wallow for about a day, and then did what friends do best and brought me out of my own head. She reminded me why I was drawn to the role to begin with. She pointed out how many of the conflicts within the team had nothing to do with me, the work, or the company. The more I distanced myself from the conflict the easier it was to see how I could use the strategies I learned in each situation. I was no longer the center of the problem. I was an observer.
Slowly, it got better. We reorganized the teams to remove some of the conflict between members. Eventually, we compressed into one large team and I handed off the role of Scrum Master to my colleague. As she took over the role I continued to learn and observe how she handled conflict.
What I Learned.
I still struggle with conflict management at work. My nerves creep in at every furrowed brow or sharp tone, but I’ve realized that as I continue in my career and through different roles I will look back on this time and use these lessons to grow. It’s not uncommon for the Scrum Master role to attract a helper personality like mine–the ones who want to be the fixer in a situation and shrink away from conflict. As those people, we have a lot of learning to do in order to successfully fill the role and serve our teams. Through research, continued education, and practice helpers can be some of the best Scrum Masters. Check out our Advanced Certified ScrumMaster workshop to learn how to level up your conflict management and facilitation skills.
Avoiding – Sidestepping the conflict with the hope it will resolve itself and go away.
This was my go-to. Avoid, avoid, avoid. Laugh it off. Leave the room. Don’t make anyone know you are uncomfortable. This has its place in some aspects of life but in the virtual workspace, it created more stress and anxiety for me. I quickly scratched that one off my list of tactics.
Accommodating – Going out of your way to satisfy the other party’s concerns, often at your own expense.
Another go-to! Take on extra tasks and work to make everyone else happy and feel heard. This is a short-term fix, but long term it leads to 12 hour-days, burn out, and sleep-deprived work. We all have to accommodate every day, it cannot be a one-way street to resolving conflict at work.
Compromising – Finding an acceptable resolution that partly satisfies both parties, but neither is fully satisfied.
We learned this style as children and it has its place. The problem with compromise on a high-stress team is that someone gets the short end of the stick. When there are daily conflicts, that stick gets shorter and shorter until all that is left are disgruntled team members.
Competing – Trying to satisfy your desires at the expense of the other parties.
Finish the project first. Make the most money. Have the highest NPS. Competition drives success and it can make a team soar. But it also can tear a team apart from the inside and negatively impact the whole business. Competition is only healthy if it’s checked frequently.
Collaborating – Finding a solution that entirely satisfies all parties involved.
The golden ticket. The win-win-win model. Collaboration is wonderful, necessary, and needed in every part of life. It’s hard to achieve and requires all members to be willing to talk and to come to an agreement. For example, if Larry refuses to speak to John and John refuses to see Jessica’s point of view, the team cannot collaborate.
Is your organization well underway implementing DevOps? Or maybe you’re just getting started with a DevOps initiative? Did you know you can maximize your chances of achieving desired business outcomes by combining DevOps with an Agile transformation?
You Keep Using Those Words…
When you hear “Business Outcomes,” “DevOps,” and/or Agile transformation” – what comes to mind?
We’ll share our definitions. (If you disagree with our interpretations, contact us…we love a good exchange of ideas!)
Business Outcomes
It’s more than outputs.
These are the highest-level objectives of your organization. The big WHY. They are key inputs for your business and technology discussions around WHAT to work on. They are measurable outcomes – goal posts – that provide feedback on HOW your initiatives are doing.
DevOps
It’s more than continuous delivery.
DevOps is the practice of software development (Dev) engineers and of IT operations (Ops) working together during a product’s entire lifecycle, from design through development to production support, in order to shorten the total lead time (from concept to cash) and to provide predictable delivery of high-quality products.
Agile
It’s more than “Scrum.”
Agile is an iterative approach that focuses on collaboration, customer feedback, and small, rapid releases in order to satisfy the customer through early and continuous delivery of value. While the Agile movement originated in software development, it has been applied to much more: from medical devices to spacecraft, as well as engineering, marketing, and education.
Agile Transformation
It’s more than “Training, Titles, Ceremonies, and Tools.”
It doesn’t come in a box (or inside a cloud). It ain’t a silver bullet.
An Agile transformation is a rethinking and reworking of how your organization engages technology, people, and processes to achieve specific business outcomes. It is the relentless pursuit of continuous improvement.
What’s the Pay Off?
Agile transformations and DevOps initiatives are complementary. Can you have one without the other? Sure. However, if you put the two together you have the opportunity to align the tech side of the house with the business side. This combination will enable your enterprise to gain faster feedback, reduce risks while also obtaining meaningful business outcomes.
We’ve identified nine common business outcomes, all of which are positively influenced by Agile+DevOps. (Reference: Harvard Business Review Analytic Services Survey, Sept 2018).
In our experience leadership tends to “Want them all, equally. And NOW” Sorry. If everything is important, you know the saying, nothing is. Prioritization of the organization’s highest-level objectives, to avoid whiplash and to create focus, should narrow the field down to no more than three.
Employees are more satisfied in their work, willing to go the extra mile, passionate about the purpose of their jobs, and committed to the organization.
Customer Satisfaction
Customers are satisfied with the experience, benefits, and outcomes when using your product or service.
Quality
The product or service meets the expectations of the market for usability, reliability, etc.
Speed
The time it takes to deliver an idea into the market.
Predictability
Teams maintain a predictable cadence of delivery enabling the business to make informed business decisions.
Innovation
New ideas, creative thoughts, or novel imaginations provide better solutions to meet new requirements, unarticulated needs, or known market needs.
Market Responsiveness
The ability of the organization to pivot quickly to respond to ever-changing market demands.
Productivity
Increase the business value realized while maintaining or reducing costs.
Continuous Improvement
The ability of the organization to relentlessly pursue optimizations in all aspects of business functions.
It will be challenging as there are many potential impediments that could derail the transformation without the right support.
From organizational silos to legacy technology. From the need to ensure security and compliance, to the lack of the right skills and even the right mindsets among employees.
The good news is that there’s a path through. For over a decade, Agile Velocity has been helping enterprises chart and benchmark their progress during change initiatives. We’ve observed patterns of change, learning, and growth that move through five different stages, each building on the learnings from the previous stage. The Align stage is the first stage of the journey while Adapt requires a significant amount of agile maturity.
Align
Align the initiative with measurable business outcomes and define a clear transformation roadmap.
Learn
Establish foundational practices and a culture of learning by empowering teams to take ownership of their work and process.
Predict
Maintain a predictable cadence of delivery, enabling organizations to make informed business decisions.
Accelerate
Optimize the full value stream and shorten the time-to-market.
Adapt
Embrace organization-wide adaptability in order to quickly respond to market demands.
For software powered organizations (we could make the argument that 99% of all businesses fit this description), DevOps can significantly improve their ability to progress through the latter stages of Predict, Accelerate and Adapt.
Science has proven that introducing change into any system will result in a period of chaos until a new status quo is achieved. When adopting DevOps practices or undergoing an Agile transformation, organizations will experience a temporary decrease in performance before integrating new practices enables a new, more performant, status quo.
Many leaders don’t acknowledge or plan for the “dip” that accompanies the learning stage – adding more change, producing more chaos, resulting in failed initiatives. Any organizational change must have leadership support along the entire journey or it will be short-lived or fail outright. With leadership support and by using the stages as a guide, time spent in “chaos” can be reduced.
Like the authors, we believe that “Leadership really does have a powerful impact on results. . . . A good leader affects a team’s ability to deliver … how the team manages its work and develops products. All of these have a measurable impact on an organization’s profitability, productivity, and market share. These also have an impact on customer satisfaction, efficiency, and the ability to achieve organizational goals.”
Some of the key transformation elements which require leadership involvement include:
Sense of Urgency
Identifying and communicating the compelling reason(s) why the organization should change
Ensuring alignment around the compelling purpose has been achieved at all levels
Roll Out Strategy
Defining an initial transformation roadmap, one that takes into account organization structure demands, top risks, and incremental rollouts
Aligning teams to value
Enabling Action
Facilitating change to support the overall transformation
Resolving organizational obstacles and impediments with urgency
Continuing to communicate the change vision (rinse and repeat)
Cultural Shifts
All transformations require shifts in culture and mindset. How big? The standard answer: “It depends!” Some situational variables are current organizational levels of
Many organizations attempt transformations with disappointing results. If you perceive a gap between where your organization is and where you want it to be, we can help. Our client roster is filled with Fortune 500 companies and growing businesses alike – all of whom have benefited from our expertise.
We’ll help you shorten your feedback loops – so you can build the right thing, the right way, for the right people, at just the right time.
What, if anything, about the way people are leading today needs to change in order for leaders to be successful in a complex, rapidly changing environment where we’re faced with seemingly intractable challenges and an insatiable demand for innovation? from Brené Brown, Dare to Lead: Brave Work. Tough Conversations. Whole Hearts
Agile Velocity hosted a series of online conversations exploring the most crucial leadership questions of the day.
Each session included a panel of distinguished guests who provided their honest and hard-won perspectives.
Bill is a sought-after international thought leader and author of Leadership Agility. He focuses on the new mindsets and skillsets that leaders need for a new business environment that is complex, uncertain, and very fast-paced.
Dave Snowden is the founder and chief scientific officer of Cognitive Edge. His work is international in nature and covers government and industry looking at complex issues relating to strategy and decision making. He has pioneered a science-based approach to organizations drawing on anthropology, neuroscience, and complex adaptive systems theory. He is a popular and passionate keynote speaker on a range of subjects and is well known for his pragmatic cynicism and iconoclastic style.
Andrea Tomasini is one of the founders of agile42. His background includes experience in product development, system architecture, business, and strategic analysis, lean coaching, organizational change, and agile leadership. Andrea has trained and coached a diverse range of teams and helped many companies in various industries in implementing agile methods like Scrum. These days, Andrea works primarily as a Strategic Coach, supporting Agile Leaders in the process of transforming their organization, strategy, and culture to achieve greater agility and resilience. Being an international expert in the area of Agile Leadership, he is currently pioneering data capture and analysis methods in complex organizational structures and working on a book on ORGANIC agility.
Lyssa Adkins is an internationally-acclaimed, inspiring coach and teacher. Her current focus is on improving the performance of top leadership teams through insightful facilitation and organization systems coaching.
Carolyn Dragon is an engaging and highly talented coach, facilitator, and presenter. Visionary, enthusiastic, and grounded in results, Carolyn is a leader in learning, growing, and inspiring women’s personal and professional leadership development.
Lyssa and Carolyn co-lead TENWOMENSTRONG – a group that brings together circles of dynamic and inspiring women leaders to live their life on purpose.
Expert on adaptive leadership, former submarine commander, and author of Amazon #1 Best Seller: Turn the Ship Around!, Captain David Marquet imagines a workplace where everyone engages and contributes their full intellectual capacity, where people are healthier and happier because they have more control over their work, and where everyone is a leader.
Andy Worshek is a keynote speaker, guest contributor, and Intent-Based Leadership expert. He served with Captain Marquet on the USS Sante Fe as Combat Systems Department Chief, later advancing to Chief of Boat on the USS Cheyenne.
When going through an Agile transformation, Agile teams often feel like they have a good handle on Agile and Scrum. But when asked about their progress toward the business outcomes their organization hopes to achieve by implementing Agile, their answer is not as confident.
This is not unusual. More often than not, leadership has not fully considered what business outcomes they hope to achieve through Agile. However, when pressed, they usually agree that their real interest isn’t in doing Agile. It’s actually rooted in the need to achieve important business outcomes like increased speed, customer satisfaction, market responsiveness, etc. Focusing on business outcomes enables the organization to look at the transformation from a broader perspective and understand that it impacts all levels of their organization. So how do you ensure teams are working towards your organization’s desired outcomes??
In this article, I have identified 6 signs that indicate your Agile teams and leaders need additional training to effectively identify and achieve your organization’s desired outcomes via Agile.
Sign #1 : Teams lack clear team purpose
Teams that are unable to articulate the organization’s customer-focused vision and how their work ties into the greater whole (organizational strategy, vision, roadmaps, etc.) are disconnected from the urgency and business outcomes driving the change. Without focus on desired business outcomes, teams won’t operate with their stakeholders and customers in mind.
Through training, leadership and team members can learn how to clearly define which factors determine their success and how to implement effective feedback loops to validate the value or their work with customers.
Sign #2: Teams lack clarity regarding roles, responsibilities, and working agreements
Setting expectations around the way the members of an Agile team or group of teams prefer to work together creates a foundation of openness and accountability from the start. Organizations requiring teams to work with other teams often lack best practices for effective multi-team coordination and collaboration.
In training, Agile teams gain clarity around roles and responsibilities, a shared and accepted set of working agreements, definitions of when work is ready to start, and what constitutes being “done” which can help teams get empowered to implement this new way of working.
Sign #3 : Inconsistent alignment on Agile experiences, best-practices, and terminology
Agile practices are often translated from multiple team members with different experiences implementing Agile. This can result in a lack of consistency on practices and terminology, and create hybrid mashups of various practices such as Waterfall, Scrum, ScrumBan, Kanban, XP, etc. This lack of consistency in understanding and practice impacts team effectiveness and is further amplified when operating at scale in large solutions.
Creating and maintaining a common foundation of knowledge can minimize the negative impacts of this and allow Agile teams and leaders to focus on what matters most.
Sign #4: Practices are disconnected from the underlying Agile principles
When teams and leadership are disconnected from the underlying Lean-Agile Principles and practices, they don’t understand the “why” behind Agile practices and ceremonies. Rather than embracing them, these principles and practices are often viewed as overhead and micromanaging, which often results in teams just going through the motions with low engagement and a lack of transparency.
This disconnect from a deep-rooted appreciation of the desired Lean-Agile mindsets and value of building self-organized and empowered teams, leads to organizations not moving past command and control project-based thinking and practicing Scrum in name only.
Sign #5: Ineffective story writing and work prioritization practices
In an Agile pull-based system of incremental delivery, it is very important that teams and the Product Owner constantly refine and prioritize work. This requires the Product Owner to work closely with their stakeholders and teams to make tough choices. The Product Owner should be taught effective techniques to help them make these choices based on highest business value delivery.
This pull-based system requires good story and feature writing skills, continuous refinement, and transparency at all levels of the organization and results in appropriately detailed, estimated, emergent, and prioritized backlogs.
Sign #6 Teams are not delivering potentially shippable product increments frequently
An essential Agile principle is that teams should deliver working software frequently–ideally every couple weeks. If teams are not regularly demoing their fully integrated and potentially shippable solution in a production-like environment your organization likely suffers from development silos, lack of automation, and immature continuous integration and deployment practices. To be a market-responsive organization, the capabilities to deliver frequently and quickly get feedback are critical.
However, teams often lack necessary skills to implement development best practices such as pair-programming, refactoring, Test-Driven Development, emergent architectures, and Agile automated deployment strategies. Without the infrastructure in place to remove obstacles and enable frictionless promotion of code to deployment and eventually to customers, teams will be unable to deliver frequently.
Conclusion
If your teams exhibit any of the signs above, Agile training is a simple, cost-effective solution to get your organization working towards your desired business outcomes. Explore our Agile training services to learn how we can help address your Agile teams’ specific challenge.
Traditional product backlogs can get confusing. They typically start off with a high-level list of features, called “epics”. However, as the team starts decomposing the epics during refinement down to sprintable user stories, it’s easy to “lose the plot” and the only person with the decoder ring is the Product Owner (PO). The PO is the only one who knows how all the stories tie back up to the feature and how they relate to each other. One resulting failure pattern is incremental deliveries that create poor user experiences. This is because the release was composed of stories that in principle were of high business value but were functionally dependent on stories that were of lower value and were therefore deferred to future releases.
By leveraging the Path to Agility approach, we align your entire transformation around what you are trying to achieve, making sure you focus on what is important. You can learn more about our approach to transformations, here.
The 
The Market of Skills approach tends to suit teams that are more playful, open to exploration, or may have more of a “Clan/Collaborative” or “Adhocracy/Creative” cultural orientation. 
Is your organization well underway implementing DevOps? Or maybe you’re just getting started with a DevOps initiative? Did you know you can maximize your chances of achieving desired business outcomes by combining DevOps with an Agile transformation?
Agile Velocity hosted a series of online conversations exploring the most crucial leadership questions of the day.
