FIRST STEPS AND HELPFUL FRAMEWORKS
(Agile Series Part 6)

In this series, we discussed different ways to apply an Agile mindset and common Agile practices in pragmatic ways that make sense for your organization and your culture. A pragmatic approach to Agile can work not only for development teams, but many other teams and departments across an organization.

The idea of adopting Agile methodologies into your organization may seem daunting. However, our experienced team has helped businesses of all sizes accomplish this exact goal, and we are confident that Agile principles can deliver meaningful results to your organization. In this article, the final entry in our series, we boil down the first steps leadership teams can take to build their Agile muscle and the frameworks to utilize along the way. 

Leadership is critical for Agile to be successful, particularly for an organization trying to drive forward a large digital transformation. Leaders need to set the right culture so that iteration, transparency, and collaboration can happen without fear of failure. Leaders need to empower teams, so that they have a degree of autonomy (on how they work and what the solution is), help teams remove their impediments, and prioritize dependencies when there is an impasse. 

Agile leadership is synonymous with servant leadership, but it doesn’t mean mob rule and “anything goes”. When leaders are supportive of the outcomes and the value Agile teams are delivering, as opposed to managing features or the project, leaders help cultivate an Agile organizational culture. When leaders accept the degree of uncertainty and give the teams the space to figure “it” out, this allows leaders to be less involved as managers and more focused on the strategy, identifying recurring pain points and themes to be addressed. It is important for teams and leaders to establish a cadence and process, in order to provide the right level of transparency and iterations for leaders to see what’s going on and for teams to collect feedback. 

Notice that to this point there hasn’t been a reference to scrum, kanban, SAFe or any other framework. This is intentional because an organization can be successful by being Agile and not just doing Agile, which is the common reason why many Agile programs fail. A leader or organization doesn’t need to sign up for a particular framework, although they certainly can if it makes sense. There can be meaningful value in those frameworks, but a pragmatic approach to agile is a great way to start adopting those Agile values and benefiting from them.

Often the most lightweight process, with clearly defined objectives is the best approach to set up an organic, iterative approach. The Agile Manifesto, which is shorter than a paragraph, simply calls out the importance of ‘People over Process’, ‘working software over documentation’, ‘customer collaboration over negotiation’, and ‘responding to change over following a plan’. This allows for an inherently pragmatic approach for teams to iteratively work. 

Agile frameworks do provide some tools and concepts that can be leveraged to help improve a process and team collaboration. This blog series called out three specific concepts that can be leveraged for an organization of any size, regardless of formal organizational “agility”. The first of these tools is the Retrospective. 

Retrospectives, or retros, are powerful moments for people and teams to take a step back and reflect on things that work well that should be continued upon, but to also identify what are those opportunities where the team can do something differently. Some organizations also call these a post-mortem or in the military they are referred to as an After Action Review (AAR).  The retro is a facilitated conversation so the team can be free to think and participate and is intended to be a simple tool for the team to learn. 

Big Room Planning is another concept typically associated with Agile planning, but can be used universally. In a Big Room Planning session, leaders will talk about business goals for the iteration (typically a quarter, but could be a Program Increment, a PI). This is a great opportunity for leaders to inform teams how their work directly impacts the business. In addition to aligning on shared goals, the other added benefit is Big Room Planning brings teams together to plan out the work within a certain time boxed iteration.

Some leaders may question the value of pulling everyone from the teams together to stop working on what they’re currently doing, just to plan the next iteration. They may see this as an incredibly expensive meeting and push back on the value. Although there is an upfront investment for preparation, Big Room Planning can actually save meeting time, as well as reduce risk by making sure teams are clear on what work is coming up and giving them space to talk through complex problems earlier in the planning process. Regardless of whether a team is waterfall, Agile or somewhere in between, it’s an extremely valuable exercise to bring teams together to align on shared objectives and honestly talk through dependencies to plan the work through the next iteration.

As part of Big Room Planning, teams should have an understanding of how long it will take to complete certain tasks. One of the benefits of Agile is understanding flow and Velocity of a team. Velocity at its core is the simple measurement of the rate at which a team consistently delivers business value to an organization’s customers. Teams that understand their Velocity can more predictably and sustainably deliver value, which can protect teams from burnout, as well as give leadership more confidence in estimated delivery targets.

All of these concepts and techniques are ways to apply Agile concepts to your organization, regardless of if you’re “Agile” or not. Each organization is different and therefore “Agile” will show up differently, which is perfectly fine. The changes required for Agile to thrive can be hard and take time.

Our team at TGG can help you experience the benefits of Agile work streams without the stress of doing it alone. Click below to connect and explore how Agile in action can impact your organization.

VELOCITY: DRIVING TOWARDS CONSISTENT VALUE DELIVERY
(Agile Series Part 5)

When working with organizations or teams new to Agile, one observation we have noticed time and time again is the misunderstanding of velocity as an Agile metric. Many teams view velocity as something that denotes efficiency and can be controlled or improved if, “done right.” Other teams think velocity will provide exact timelines for delivery of a piece of code similar to how work is assigned. While velocity does provide insight into how much work can be completed during a given iteration, its true value lies in empowering teams to prioritize and right size their work to create an achievable roadmap with consistent value delivery to customers.

This article is a simplified overview for teams outside of software delivery to creatively apply velocity to their work. 

Velocity as an Agile Metric

Velocity, at its core, is the simple measurement of the rate at which a team consistently delivers business value to an organization’s customers. For most Agile teams, value delivery can be broken down into small units of functionality called user stories, which is a replacement for traditional team member role requirements. During each timeboxed sprint, teams will typically work to complete a number of “stories” from a product backlog that, once completed, will be released to the customer. 

To ensure the team is not committing to more work than they can realistically deliver during a timeboxed sprint (also called increments), the team will estimate each story, giving it a number of “points” that represent relative complexity (not Level of Effort) needed to complete that story. The total number of story points that can be included in a given sprint is determined by the team’s velocity. For newly formed teams, there are formulas and best practices that can be followed to set an “initial” velocity, but determining a team’s actual velocity is best calculated over a set period, typically 2-4 sprints. 

While calculating a raw velocity number is straightforward, and a quick activity, utilizing it as a metric to empower Agile teams and drive consistent value delivery is not a one-size-fits-all approach and takes dedication, trust, and time to build. To facilitate that unique growth, here is a list of nuances about velocity that consistently come up in retrospectives:

• A Team’s Metric – A team’s velocity is based on the relative sizing of the stories they are working on through the duration of the time-boxed period. As such, their calculated velocity is unique to their team and any direct comparisons of velocity across a program will be meaningless. Said bluntly: do not compare raw velocity numbers across teams; it’s comparing apples to oranges. If you are looking for a way to compare teams, consider looking at a team’s consistency of velocity against the success of meeting their commitments. A team with an inconsistent velocity may be on track to over- or underestimate their capacity to deliver on their commitments.
• Variance in Velocity – While some level of variance is anticipated, especially with immature teams, the drive should be for a consistent velocity iteration over iteration. Consistency in velocity enables teams to confidently size work and create product roadmaps that reliably release value to customers. An inconsistent velocity (increasing, decreasing, or waffling) is a sign that the team needs to reflect on their process and determine areas for improvement. This could be as simple as ensuring users’ scores are clear and simple to understand, or more complicated, such as eliminating external dependencies that can delay work.
• Team Visibility – Velocity is a team metric and should be a visible and active part of all planning meetings and especially the retrospective. This allows the team to be introspective and honest regarding their capacity and capabilities. It also provides the opportunity to identify whether anything has changed that impacts the team’s capacity to continue delivering against their historic velocity.
• Capacity / Capability – When teams have an established, consistent velocity, but are continuously under delivering against business objectives, it can mean that there are not enough people allocated to complete the work and/or existing people are not adequately trained against new technologies employed by the organization.

In a software setting, story points and velocity can be seen as a science, but in utilizing a pragmatic lens, these concepts can be effectively applied in all categories of work. A pragmatic approach to determining velocity creates healthy team dynamics, a collaborative culture, and more engaged employees. 

—

Do you have questions about how an Agile approach can help your organization meet its strategic goals? Our highly skilled consultants can help you turn a mountain-sized project into an attainable endeavor that will propel your organization in the year ahead. Click below to connect with our talented team!

THE RETROSPECTIVE AND KEYS TO SUCCESS
(Agile Series Part 4)

Lesson Learned events provide a wealth of valuable information that can be applied from one project to the next. For example, on a past project our team assisted a client build and launch a new initiative. Upon completion of the project we attended the project post-mortem (also called retrospective, retro or after action review). We reviewed the project stages, explored processes that were used, and examined team dynamics. There was a lively conversation about communication and process breakdowns, and an encouraging discussion highlighting wins along the way. 

We developed a comprehensive list of recommendations with the client team which were reviewed by the organization’s PMO and adopted into the day-to-day management of other projects. For our TGG team that Lessons Learned meeting was yet another example of the value and importance of retrospectives.  

The Impact of the Retrospective

The result of asking this question in an agile setting is a regular review of the team’s activity, called a retrospective.

The retrospective is an event in agile frameworks, a chance to “look back” while still in the middle of the work. It is a chance to review not only the team’s performance, but the systems, processes, and working culture that lead to performance. The goal is continuous improvement, to review and adjust the way that the team works in order to constantly improve delivery of day-to-day work and digital transformation efforts. 

The main theme of the retrospective is accountability. The team looks back at the past few weeks in order to hold themselves accountable to promises that were made. If the team falls short on promises, they make adjustments. If the team has been successful, they try to understand the reasons for that success with the goal of repeating it in the future.

Regardless of the format, a retro should be a judgment-free space, where the team can openly discuss failure and successes in the spirit of learning. A retrospective is one of the most important ceremonies in an Agile system. There are plenty of books and blogs on different facilitation approaches to retrospectives, each depends on the team and its culture.  

Our take: simpler is often better and can yield a richer conversation, which is why we prefer to focus on two roles and four questions. We’ll explain:

• Role: Facilitator – This is the only defined role in a retrospective. This is usually someone on the team, possibly a scrum master. The first goal is to create an atmosphere of trust, where the whole team feels comfortable engaging. Pay attention to setting, personalities, and culture. The facilitator is always thinking ahead to the retrospective; for example, when the team encounters a roadblock this person records the experience and suggests to the team, “This would be a good topic for our retrospective.” The facilitator is accountable for the success of the retrospective.
  • Tip:  Facilitators, make sure you know your team. Temper the talkers, and engage the less vocal, introspective members by gathering written feedback in advance of the meeting. Work with the personalities you have on the team, ensuring that everyone has the chance to engage. 

• Role: Participants – This is the team closest to the work. In the interest of maintaining an atmosphere of open and honest communication to glean the most meaningful feedback, be thoughtful as to who, specifically, to include in the conversation. It’s best to limit participants to people who know the work and can make changes that would benefit the team. 
  • Tip: Tell the participants, and make them aware, that their candid feedback is the most essential ingredient for an effective retrospective. 

• Question: What did we promise to do vs. what did we actually accomplish? This question provides a baseline for the conversation and aligns the participants around a shared understanding of the exercise’s objective. This question promotes accountability by considering the promises made vs. the promises that were kept. If you’re looking for metrics, some helpful ones include burndown charts or say:do ratios. 
  • Tip: Don’t spend too much time on this question; it’s simply intended to be a foundation for the following questions. 

• Question: What worked well? – Beyond providing a morale boost by celebrating success, this question serves to identify strengths with the intention of converting strengths into habits. Turning positive results into rules for operation is the “machine learning” mechanism for the team. Silence here is an indicator of siloed work, a lack of confidence or cohesion, or even burnout. 
  • Tip: If participants are struggling to think of things to contribute, bring back recent kudos or recognitions as a primer for conversation. 

• Question: What didn’t work well? – This is your chance to learn from mistakes or identify ways to improve. This question promotes accountability for shortcomings, with an eye toward actionable improvement. The keyword is actionable–this isn’t a chance to complain, it’s a chance to change. Keep things constructive: rather than searching for blame, search for improvements. 
  • Tip: It would be rare for a team to be silent here. If your team is struggling to name areas for improvement, be ready with a couple coaching questions to help the team unpack the potential reasons why. You might discover they need more challenging work or perhaps there could be conflict within the team. Silence can mean there is still a perspective waiting to be heard and understood. It’s rare for a team to be silent here. 

• Question: How will we adapt? – Every strength and weakness identified in the previous questions should have an action assigned to it in this question. This is a chance for your team to hold itself accountable by making an agreement. This question only has power if the team can keep its word. In the next retrospective, circle back to the agreements that were made in this question. 
  • Tip: Write these answers down, and make them visible. Once the team agrees on how to adapt, post those agreements on a board, in a chat, or anywhere else people will be sure to see them. 

The beauty of the retrospective is its simplicity. It’s not limited to software development, or even IT. Any team can adopt this ceremony on an iterative basis, adapting it to their needs and situation. The power of the retrospective is in its effects: know your goals, and iteratively improve the way you pursue them. That’s pragmatic; that’s agile.

—

Our goal at The Gunter Group is to help our clients maximize their potential through thoughtful action and tangible results. Click below to connect and discover how the TGG team can help you achieve your strategic objectives.  

THE POWER OF BIG ROOM PLANNING
(Agile Series Part 3)

It would be no surprise if you were to look across any organization today and find at least one or two teams organized around delivering value to the business using Agile methodologies. Over the past couple of decades Agile has permeated many organizations on some level, but Agile is still thought of by many as primarily relating to IT and engineering teams. It’s a process in which teams work together in time-boxed iterations, often called “Sprints,” with each sprint representing a short term plan to deliver against a continually shifting backlog of work across a multitude of stakeholders. 

The development of new digital capabilities has grown more complex, and organizations are looking for ways to speed up the delivery of those capabilities to market. To achieve this, many businesses look to lead their organizations through digital transformations and scale Agile beyond just IT teams. 

While there are many frameworks that organizations utilize for scaling Agile (SAFe, Large Scale Scrum, Disciplined Agile Delivery, etc.), there is one common element across all of them: a need to plan and coordinate across multiple business and IT teams to promote consistent value delivery quarter-over-quarter, year-over-year. That’s where Big Room Planning comes into play. 

What is Big Room Planning?

Whether it is referred to as PI Planning, Quarterly Planning, or any other creative name an organization chooses, Big Room Planning is a simple idea that builds on the Agile principle of promoting transparency and effective communication through face-to-face conversations. It is a one-to-two day event where all teams required to deliver value against the goals of the business come together in a “big room” to coordinate and collaborate toward a shared understanding of how to accomplish the goals over a period of time (typically a quarter). 

That’s a bold statement and seems relatively “easy” if all that’s needed is to get everyone in a room talking, but the difficult part is ensuring that the appropriate preparations are made so that the meeting is set up for success with clear expectations.

Each organization is unique and there are many different strategies and implementation guides that can be applied in preparation for a Big Room Planning event. Typically every event follows similar elements that can be adapted to an organization’s unique needs. An example outline of this is shown here:

1. 1. Context Setting – Sometimes when teams are working in the weeds of a given capability, it’s hard to know how or why decisions are being made which then impacts the ability to deliver effective solutions against the objectives for that business. By providing context at the beginning of a planning session, leaders share the current state of the business and how solutions being developed are addressing customer needs. This, in turn, provides guardrails as teams are prioritizing quarterly goals.
2. 2. Vision and Roadmaps – Product Managers provide a vision and roadmap for individual capabilities (features) that have been prioritized to meet specific business needs. Teams will use these features to break down and define the work that is needed for the quarter. Special attention should be made if there has been a shift in priority from one quarter to another so that teams can see how their contributions ladder up and make a difference. 
3. 3. Team Breakouts – Teams use this time to break down and size the features into backlog items and create a plan that is visible to all other teams. If there are any dependencies or risks identified, they are raised and provided to the appropriate supporting team. Once the team has broken down the features and understands their capacity to achieve these features, they draft objectives that can be committed to for the quarter.
4. 4. Plan Review – During the plan review, all the teams come back together from their breakouts to present their plans. During their review, teams highlight risks, dependencies, and impediments to their proposed quarterly objectives. At this point if there are any concerns with the proposed plans, teams are asked to adjust their plans and then present the revision until all teams have come to an alignment on the quarterly objectives, risks, and dependencies.
5. 5. Confidence Vote – Once a plan has been approved, teams are asked to conduct a confidence vote on their commitment to the objective they included as part of their plan. If there is a lack of confidence, the plan should be evaluated to ensure realistic delivery within the timeframe allotted, and the team should propose changes as needed so that all team members feel confident in their ability to deliver.

The Power of Big Room Planning

When strictly looking at the hours needed for a Big Room Planning event, many leaders might wonder if it is worth the investment. While this must be evaluated by each individual organization, we have found that typically the result is well worth the initial investment. Big Room Planning can deliver value in the following key areas: 

• Prioritizing Business Objectives –  Big Room Planning drives visibility toward competing priorities across stakeholder groups and provides a forum by which decisions can be immediately made to ensure all teams can align to a common business objective. 
• Dependency Mapping – Digital products are complex and require multiple teams to complete. Big Room Planning allows time for identification of cross team and cross organization dependencies to ensure an appropriate runway has been provided to deliver commitments. 
• Transparency – Including all teams and stakeholders in the planning builds trust and confidence in the organization’s ability to consistently deliver value against commitments. 
• Capacity Planning –  By having a roadmap and estimating the features during the team breakout, Big Room Planning provides teams with a clear picture of their capacity during the quarter to deliver against their commitments.
• Risk Reduction – With many teams working to deliver value for the business, there is always the possibility of something being overlooked. While no process can ever truly mitigate all of the risks associated with complex change, Big Room Planning begins to break down those barriers by promoting the right conversations.

Conclusion

Big Room Planning can drive consistent value delivery, a shared understanding of business objectives, and a clear quarterly roadmap that meets the needs of the business transformation objectives for teams to follow. To achieve these values, it’s important to remember that there is no one-size-fits-all approach and the event should not become a rote exercise to check a box. As with everything Agile, organizations should continuously adapt and improve the process to promote engagement from all stakeholders and break down barriers so that the space is created to engage in meaningful conversations.

—

Big Room Planning and other Agile initiatives can be overwhelming. Our team at TGG can help you experience the benefits of Agile work streams without the stress of doing it alone. Click below to connect and explore how Agile in action can help your organization. 

AGILE: REALIZING SUCCESS THROUGH A PRAGMATIC APPROACH
(Agile Series Part 2)

Everyone has an opinion: Agile works for tech, but not for business. Agile is a tool used by consultants to squeak the wheels and bill more. Agile transformation is just another buzz phrase. Agile is a fad. Even in the tech world, Agile is beginning to fall from grace. An increasing number of articles counsel developers to drop Agile and its many rules. Even the founder of one of the earliest Agile frameworks thinks that it’s time to abandon Agile.  Agile has its fair share of naysayers, and not without reason. Many have been burned by a framework that made big promises but led to bigger problems. 

Agile certainly has its limits, but for those organizations open to change, we have developed a point of view to help our clients find success while transforming their business. Even if an entire organization decides “not to go Agile” there are certain concepts and planning activities that can still add value when applied.

In this blog series we’ll introduce concepts and opportunities to apply big room planning, retrospectives, and velocity to teams outside of software development. We’ll share ideas that leverage the intent of these activities and reinforce the mindset that these efforts don’t have to be complicated. Before implementing any changes, keep in mind that simple is better, and then iterate from there.

It Doesn’t Have to Be That Complicated

This article by Lindsay McGregor and Neel Doshi describes how the principles of Agile can become inverted when leaders and organizations only go through the motions. The authors point out that this backwards setup is a symptom of a deeper problem: software organizations set up Agile processes and tools, but also build out detailed plans and comprehensive documentation, rather than allowing the teams to simply collaborate on delivering valuable products for their customers. Organizations can inadvertently overcomplicate the process, making it feel more like “small waterfalls” under the auspices of Agile.

Our experience has taught us to take a different approach. Things fall apart when people underthink the business case and overthink the implementation in search of panacea in a set of rules, roles, and rituals. 

Our take: understand the WHYs behind the Agile, identify why you think you need it, and only do what works. Go beyond that and you’re flirting with failure. 

Things Fall Apart 

Why does Agile fail in some organizations and not others? Why do so many business transformation programs fail? Among the reasons, here are some of the issues we think are most important (and a few ways you can mitigate them)

1. A Focus on Process and Not Customer Value: The Agile manifesto (which is only 68 words) values “Individuals and interactions over processes and tools; working software over comprehensive documentation.” Unfortunately, too many Agile implementations focus too much on “the process” as opposed to focusing on how the process is designed to add customer value faster. 

A simple fix: make sure each planning activity focuses on value-add outcomes. Focusing on solving problems, iterating, and learning to meet the needs of a customer (a customer can be a consumer, or an internal business stakeholder or customer) – will naturally lend itself to some evolution, and that’s okay.

2. Workers Fear the Unknown: Humans need habits, and in fact they can’t function without them;  so naturally teams of people need some level of organization and process to deal with the unknown and manage expectations and fears around change. As with any initiative that involves change, ‘the whys’ of an Agile implementation will be questioned, and should be clearly articulated consistently and frequently. Otherwise, as time wears on, Agile wears out. This is a guaranteed recipe for a failed adoption 

A simple fix: go slow, make sure employees understand why an element of Agile is worth embracing, and demonstrate the value of that element through storytelling or actual experience. 

3. Managers Fear a Different Unknown: Let’s be honest, waterfall can be easier for managing and reporting. A manager finds comfort in the 650 line project plan, even if that comfort is just an illusion. Red, Yellow, Green (RYG) statuses and percentages that can be applied to a timeline are easy to ingest and easy to report up the ladder. In an Agile adoption, a manager will often expect waterfall-like reporting, causing the team to reorganize their work to fit reporting needs and expectations. This can break the back of good iterative improvement.

A simple fix: the product owner can serve as the liaison between management’s reporting needs and the team’s work. It takes real effort to translate iterative progress into timeline reporting, but it’s not impossible.

4. Bad Press Around Agile: Some people think Agile is only helpful for software development; some think Agile isn’t helpful at all. Beyond the negative opinions, it can be hard for an employee to understand exactly how an Agile implementation will impact their job. All of this can limit your team’s appetite to adopt elements of Agile. 

A simple fix: keep it relevant. If you want to introduce a regular retrospective to your team, you don’t have to have them read the Scrum Guide. Take the time to package an Agile element in terms specific to your people.

5. Agile Tools Are Intimidating and They Can Replace Talking: An Agile implementation is often accompanied by new tools.  Along with adapting to a new organizational method, your team also has to learn how to use JIRA or Trello. This can be intimidating, and often mutates conversation into simple status reporting on stories. The tool replaces conversation and interaction, which is the opposite of what Agile teams should do (“Individuals and Interactions over process and tools”).

A simple fix: again, keep it relevant. You don’t need all the bells to do Agile well. If the tool helps, then make sure everyone understands why. If it doesn’t, then ditch it.  

Whether your organization is considering a full Agile implementation, or looking for opportunities to improve collaboration and iteratively deliver value, remember to start small, and build on success. If at times it feels like process for process sake, or the tools or frameworks are making it harder to collaborate, take a collective step back with the teams to review and make adjustments. Since every organization and culture are different, Agile processes are going to look different and that’s ok. What’s most important is that teams are empowered to iterate, experiment and adapt as they deliver value for their customers.

—

Do you have questions about how an Agile approach can help your organization meet its strategic goals? Our highly skilled consultants can help you turn a mountain-sized project into an attainable endeavor that will propel your organization in the year ahead. Click here to connect with our talented team!

A LETTER TO THOSE WHO HAVE GIVEN UP ON AGILE
(Agile Series Part 1)

Dear Leaders,

Things aren’t working well. You get your product out the door, but your customers don’t like it. Your big quarterly upgrades are riddled with bugs. You’re constantly behind schedule, and your team is regularly distracted with problems or miscommunication. You know there’s room for improvement, but you either don’t have the time or don’t know where to start. 

This is the first in a series of articles exploring pragmatic steps you can take to implement an Agile mindset and practices. We’ll look at how you can help improve your organization’s ability to deliver value, drive employee engagement, and foster a learning mindset oriented towards growth that meets the needs of the customer. Change can be hard, but we can help.   

Shining a Light Into the Dark Corners

Are any of these scenarios familiar to you?

“We keep making the same mistakes.” Week over week, month over month, your teams stall in the same quagmires. Problems are built into the process; things never get better. As soon as you start to address a root cause, new escalations kill your momentum.

“We waste time on the wrong things.” Your team is stuck, but a new idea comes along and everyone loves it. Everyone is energized, and you’re propelled down the new route. After a month things start to slow down as the idea becomes a burden. Your team is stuck, but a new idea comes along… 

“I don’t know what my people are actually working on.” You run a complex organization, matrixed across multiple workstreams. There’s no way for you to know how everyone is engaged, and you suspect there is duplicate work hiding in the shadows. You know that transparency is needed, but every time you try to implement structure things fall apart after a week or two. 

“My team is operational: we’re too busy to level up.” Your body of work is open-ended: keep the lights on. You know there’s room to improve, but getting there is hard. Process improvement efforts have been inefficient and are sidetracked by immediate needs. At this rate, transformation will not happen.

“How can I justify changes to my product after all this investment?” Enormous expectations are on your shoulders, but the transformation outcomes are poorly defined. You have a constrained budget, and you’re nervous about the up-front investment in a prototype that will change as soon as customer feedback rolls in. Iteration is great in theory, but how do you demonstrate progress now when requirements start to shift in 3 months?

Agile Was Supposed to Fix These Problems

You bought a promise: Agile will solve these problems. Sold by words like iteration, transparency, and collaboration, you had your teams certified, added boards and huddles, and embraced a new way of doing things. 

But the problems didn’t go away. Months later, you found that Agile lost momentum. Your teams struggled to find value in dogmatic ceremonies, and a perceived lack of flexibility impacted adoption. Kanbans de-evolved into time tracking tools, huddles were abandoned when they stopped adding value, and everyone slowly settled back into the old way of working.

Agile was supposed to fix your problems, but it didn’t. It just gave the problems a new vocabulary and introduced new ways to frustrate your employees. 

You Need a Pragmatic Approach

Agile falls apart if the WHY behind it isn’t understood. People won’t adopt a new way of working if they don’t see value in it. Leaders need to foster an agile culture and processes that empower teams to enable better outcomes. This development won’t happen overnight, but iteratively finding opportunities to capitalize on quick wins will form a pragmatic approach on the Agile implementation journey. It’s also important to keep in mind that Agile will look different in each organization because each organization is different, and that’s okay. Agile mindsets and processes are built when leadership and teams are on the same page, with the same focus on delivering value to the customer.

Many of us at The Gunter Group have seen failed Agile adoptions associated with larger transformation initiatives, and we started asking ourselves why. In the process, we’ve developed a philosophy of Pragmatic Agile. Pragmatic Agile is a flexible approach. It starts from breaking down agile into core value propositions, and adapting those propositions to the unique needs of your business. 

The direct value of a more iterative approach to strategic change and improvement is obvious in most cases. The hidden challenge however, is changing behavior to truly be Agile. Join us in this series to understand what you can do today to start gaining value from your Agile journey. Agile can work for you. You can adopt it; we can help. 

—

At The Gunter Group, our driven employees make us who we are – a talented team of leaders with deep and diverse professional experience. The big firm model does not resonate with us–we prefer to collaborate, rather than tell you how to do things. If you want to go deeper with your Agile needs, don’t hesitate to reach out. We would be happy to help you strategize!