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! 

NEW TEAMMATE ROUNDTABLE

We love welcoming new teammates to the TGG family! Over the past year we’ve had a variety of talented professionals come onboard, add to our culture, and help clients maximize their potential.  

Recently, we held a TGG Roundtable with three teammates who joined us this year to discuss their transition to, and time with, The Gunter Group. We invite you to read the questions and answers below, ranging from first impressions, to client work, and even TGG’s four legged friends.

Thank you for taking time to visit today. To get us started, can you share when you joined The Gunter Group and briefly tell us about your professional background? 

Heidi Brown: I think I might be the newest in this group, my start date was September 13th. My professional background consists of time in technology and healthcare, and work centered around systems analysis, project management, and program management.  

Samya Thangaraj: My first day with TGG was June 1st, 2021 and my background is in strategic work focused on healthcare and technology, data visualization, business analysis, and employee engagement.  

Anton Cotelo: Well, I moved to the United States from Spain in March of this year and started with TGG on June 15th, 2021. A large part of my professional background is centered on industrial engineering, project management, and data analysis.

What are three words you would use to describe your time at TGG so far?

Heidi: Supported, engaged, and challenged.

Samya:  I was going to use “supported” and “challenged” also! I’ll go with community, growth, and fun!

Anton: Engaged, professional, and friendly.

What were your first impressions of TGG?

Heidi: When I started the interview process I immediately found that the TGG team had authentic soft skills and strong professional skills as well. This made the process very refreshing and genuine. I felt that the TGG team really wanted to understand my background and skill sets.

Samya: How personable everyone is, really stood out to me. I also appreciated that everyone has each other’s best interests in mind and the emphasis on technical skills but equally important, personal skills.

Anton: My first impression started before any of my interviews because I really tried to become familiar with the company and the leaders at the company. In that process it seemed like TGG was a family environment and once I started talking to more and more people with TGG, I could feel the family environment right away. It wasn’t forced, it was very natural between everyone in the company. The entire team was incredibly helpful, always available, welcoming, and checked in regularly.  

How are you currently supporting a client organization?

Heidi: Right now I’m helping a global sportswear manufacturer create a strategic roadmap that helps support a large end-to-end workflow.

Samya: I’m working with a client on a large data migration project between two platforms, and identifying ways to make the systems and reports more efficient and effective on the new platform.

Anton: I am helping a client automate and streamline processes in order to free up time for the organization’s personnel so they have more time to spend on high level strategic initiatives and developments for the company.

What do you see being something that is really important for organizations to consider and/or develop in your area of consulting in the next 1-3 years?

Heidi: The first thing that comes to my mind, working in a space with a lot of systems that need to talk to each other in real time, is the need to focus on strengthening organizational culture and engineering around APIs and data integration across systems.

Samya: In terms of the technology space, integrating and updating platforms and software while streamlining reporting to help make it more valuable, efficient, and effective.  

Anton: There are a lot of trends but I think it’s critical to walk before you run, especially in regards to data and technology. Really gaining an understanding of where your organization currently stands and identifying what the best path forward is for your group.  

What have you enjoyed most about your time with TGG so far?

Heidi: I’d have to say the number of people who have been willing to support me along the way, with both internal and external circumstances. It’s really helped me hit the ground running.

Samya: In short answer I would say the people. To elaborate a little I would say working with such a diverse group of skill sets and talented people across various spaces has been awesome. And getting to meet people one-on-one has made it even more enjoyable! 

Anton: The cross-functional, yet compatible skills of the team has been really cool to see — and when I say skills I mean hard skills and soft skills both. 

We’ll end on an easy one, with all the talk about dogs at recent TGG events — who from TGG has the cutest dog?  

Heidi: Dan’s new puppy, for sure!

Samya: Well I have to say my own dog, Garbanzo, of course!

Anton: Trisha’s definitely because it’s the only TGG dog I’ve actually held.

—

Interested in learning more about how our great culture comes to life? Click here and see what fuels our team, our relationships, and our work. 

Ready to jump in? Our TGG team is growing and we are currently hiring! Click here to see our open positions and apply.

TGG BOOK REVIEW – SCRUM

Over the past year, TGG consultant Josh Bathon has provided book reviews for The Project Management Institute of Portland. Throughout the coming months we will periodically share some of the reviews that previously appeared in the PMI-PDX newsletter.  

Book: Scrum by Jeff Sutherland

Agile project management is not a fad. Over the past 20 years it has become the dominant organizational system for software development, and has also started to flourish in other industries as well. You have most likely come across either an agile tool or an agile team, such as Scrum, Kanban, or SAFe. You might even have an agile certification; PMI offers the PMI-ACP (Agile Certified Practitioner) and agile theory is included in the PMP and CAPM.

Regarding agile, there are thousands of books and tens of thousands of articles online. Everyone has an opinion. So if you want to learn more, where should you start? Why not learn from the founder of Scrum, the most popular agile methodology out there?

In his book, Scrum, The Art of Doing Twice the Work in Half the Time, Jeff Sutherland is a master teacher. He slowly unravels the various parts of Scrum, illustrating with examples from his clients over the years. The goal of his book is to make Scrum usable for people who don’t work in software. And he succeeds. 

Transitioning to agile can seem like a paradigm shift for many people but Sutherland demonstrates how this change doesn’t have to be dramatic. Throughout the book, he works through various aspects of Scrum, breaking them down into digestible chunks that could be used by anyone, anywhere, anytime.

Take for example a venture capital company which decided to embrace Scrum in their daily operations. Investors, management, researchers, and administrative staff all started to use Scrum to organize their work. Sprint planning, daily standups and team retrospectives resulted in transparency: everyone could see what was currently being worked on, major blockers were identified early and the team regularly reviewed the way they worked. These small changes had large benefits: the average work week at the company dropped from over 60 hours to less than 40, and the team started completing almost twice as much work.

A key problem with agile project management is the army of purists that help implement it. They advocate for strict adoption and rigorous adherence to an entire system. But this dramatic, one-size-fits-all approach fails because businesses come in all shapes and sizes. This book is different. Sutherland provides practical advice for adopting agile, using real world examples of success. 

This is a must-read for project managers, even for seasoned agile professionals. I have 2 scrum certifications and have worked in several agile environments, and I still found Sutherland’s book to be a valuable exploration of how and why to use agile. In my experience, it’s hard to do agile without understanding why it works. Level-up your skills with this quick read, straight from the founder of Scrum himself.

FROM OUR PARTNERS: TGG PROUD TO ANNOUNCE OUR NEWEST PARTNER,
TONY SCHWEISS

2021 has been an important year in The Gunter Group’s journey. We named a new Partner, Matt Bader, at the beginning of the year, and now we are proud to announce our newest Partner, Tony Schweiss. What a great way to celebrate our 10th Anniversary!

Tony joined TGG in 2014 as a consultant after a career as an Officer in the U.S. Navy, and as a project manager in the construction industry. Over the last seven years, Tony has become a leader in our company, continually delivering stellar client service, developing new markets in Nevada and California, coaching and mentoring other TGGers, and supporting clients in Oregon. 

Tony has had a profound impact not only on our company’s business, but also on our Culture. At The Gunter Group, we take our Non-Negotiables seriously, and Tony embodies each of them. We are excited and proud to have Tony as an owner in TGG.

We are excited for our future at TGG under Tony and Matt’s leadership. To the next 10 years (and beyond)! 

TGG RANKED AS A BEST SMALL FIRM TO WORK FOR IN THE NATION BY CONSULTING MAGAZINE

For the third year in a row The Gunter Group has been recognized as a “Best Small Firm to Work For” in the nation according to Consulting Magazine.  

It is an honor to share that The Gunter group was selected as the #6 “Best Small Firm to Work For” in the nation for the 2021 rankings and finished in the top 10 for the third consecutive year.

When asked about this year’s recognition TGG Founders Mike and Ashleigh Gunter commented, “We are so proud to be recognized again as a Top 10 Consulting Magazine Best Small Firm to Work For nationally, alongside so many other great firms. It is an important recognition for us because we believe it reflects the culture we have worked so hard to build, and our amazing team. What a great way to celebrate our 10th Anniversary!”

The Consulting Magazine rankings were announced on September 9th, 2021 at a dinner gala in Chicago. Only 18 small firms were chosen for recognition, based on an annual survey of over 12,000 consultants from approximately 300 firms nationwide. Award candidates were evaluated across six different categories of employee satisfaction including, client engagement, culture, firm leadership, career development, and compensation and benefits.

To learn more about the 2021 Consulting Magazine Awards and see the complete rankings visit: https://www.event.consultingmag.com/best-firms-to-work-for

The Gunter Group is a management consulting firm headquartered in Oregon, serving the west coast with offices in Portland and Reno, Nevada. Learn more about us and the services we offer here.

EXECUTION PRACTICE Q&A WITH TRISHA BENNETT

At The Gunter Group we categorize our work into four practice areas: Technology, Execution, People, and Strategy, with client engagements often stretching across multiple service categories.

Our work within our Execution Practice supports clients as they pursue large transformation programs and change initiatives, in order to achieve complex and impactful objectives.

In this Q&A we explore our Execution Practice in greater detail with Trisha Bennett, Principal Consultant and Execution Practice Service Leader.

Tell us a little bit about the nature of work TGG focuses on within the Execution Practice:

Our Execution Practice is the intersection of all our practice areas and brings ideas to life for our clients. It’s about implementing strategies and using technology to align and serve people. These types of engagements usually take the shape of larger transformation programs or change initiatives. Our clients may think of these types of programs as focused efforts that just need to be executed, but we make sure that our team is bringing a perspective for how to realize strategic objectives through changes to the people, process, and technology ecosystem of a business.  

Tell us about a recent engagement supporting a client initiative:

We have partnered with a national insurance provider that is undergoing an effort to move from their 20-year old legacy on-premise ERP to a more flexible cloud based solution using Workday Financials. Our consultants supported the organization’s business transformation by leading the program management, technical project management, business analysis, process design, and training strategy and delivery. This engagement was a great example of how our consultants in the Execution Practice used their skills in analysis and project management to make sense of a complex organizational, process, and system environment in a way that was collaborative but with a relentless focus on outcomes.  

What do you anticipate impacting organizations over the next 3-5 years in the Execution category?

Organizations will do more projects in the digital space and these projects are going to require companies to show up differently for their customers and their employees. To make these changes happen, organizations can’t work in the same way that they were working. Internally these changes impact organization structures, internal communications, HR/hiring, and work has to be managed and measured differently. 

Tell us about one of your favorite projects your team has worked on:

Working with executives in translating their visions of the digital space into executable work for the teams that make it happen. These range from creating a new customer experience for a health insurance company to standing up apps for retail sales.

More about Trisha Bennett:
For nearly 15 years Trisha Bennett has partnered with business leaders to advise and lead strategic initiatives in the healthcare, insurance, retail, education, and veterinary services industries. Her career has focused on delivering best-in-class portfolio strategy, program management, project management, and analysis. As a Practice Leader, Account Leader and Manager, Trisha leads teams of consultants to support clients, solving complex business problems. She has a proven dedication to deliver and a reputation for building highly effective project teams by seeking clarity and understanding, even in the most ambiguous environments. Trisha’s management style is focused on collaboration, transparency, and meaningful communication. Trisha holds a BA in Supply Chain Logistics and Business Management from Portland State University; she is also certified as a Project Management Professional, Change Manager, and SAFe Agilist.