Index

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.

WHAT IS AGILE ENTERPRISE ARCHITECTURE?
(AND WHY SHOULD YOU CARE)

In light of the work and results we have delivered to our clients over the past year, today we are introducing a new blog series focused on the impact of successful and strategic Enterprise Architecture.

Being successful in the current business landscape demands agility, a deep focus on customer value, and the ability to build and deliver adaptive strategies. 

If you haven’t considered the way these trends are affecting enterprise architecture (EA), you’re already behind. 

In this article, we’ll explore a new paradigm: agile enterprise architecture. But before we explain the value of this approach, it’s critical to get on the same page about a few core concepts. 

What is enterprise architecture?

Essentially, enterprise architecture is the practice of understanding and documenting components of an enterprise — and the relationships between these components — in order to improve strategic planning and decision making. 

The practice of enterprise architecture encompasses discovery (what does the enterprise have now and what will they need in the future?), design (what’s the best way for the enterprise to achieve its goals?), implementation (how do we put this plan into action?), and documentation (how do we synthesize this information in a useful way?). 

Enterprise architecture is usually focused on information technology and the relationship between IT and business goals. One major goal of EA is to reduce technology debt, a term used to describe the ongoing costs associated with hastily chosen IT solutions (as opposed to those considered in the context of a long-term plan). 

What is agile?

The agile methodology is an approach to the development of products or systems that emphasizes adaptation, evolution, and flexibility. 

The first use of the agile methodology was in software development. However, the spirit of agile — as described in The Agile Manifesto — can be applied to many different practice areas, including enterprise architecture. Frameworks like SAFe® provide guidance for applying these principles to different parts of the business. 

To boil it down to one key element, an agile approach values responding to change over following a plan, delivering incremental value throughout the entire improvement process. In other words, it is an iterative, ride-along approach rather than a prescriptive, point-in-time approach. Value is created along the journey, instead of being solely located at some distant destination. 

The trouble with traditional enterprise architecture

What does EA look like in reality?

Most often, enterprise architecture is the responsibility of one individual or a small team within an organization, or an additional role added to the many on an already overburdened leader. They conduct point-in-time exercises and apply EA “best practices,” which are typically academic in nature rather than drawn from contextualized real-world experience. 

The outcome of these exercises is usually a monolithic document that’s difficult to apply to day-to-day decision making. This document purports to “solve” the enterprise’s technology problems, but too often ignores the fact that every solution has a lifecycle, and that the usefulness of solutions changes over time. 

Because traditional enterprise architecture plans don’t flex and adapt, the technology solutions proposed by the EA team tend to become disconnected from the strategic pulse of the business. These legacy approaches structurally ignore the fact that what you know now is almost invariably going to be significantly different than what you’ll know later on. 

As a result, despite being expected to own the long-term technology strategy for the enterprise, EA teams often slide down the slippery slope towards being perennial meeting floaters, sitting on the sidelines of decisions rather than contributing real value.

What is agile enterprise architecture?

Agile enterprise architecture is a new approach to EA developed by The Gunter Group. Agile EA applies the principles of the agile methodology to enterprise architecture in order to improve business outcomes.

Agile EA focuses on iteration and continuous improvement. In this approach, the job of an enterprise architect is not just to deliver a roadmap — it’s to ride along with the roadmap, continuously closing the gap between the plan and reality as it unfolds. 

In addition, a major goal of agile EA is to create a set of architectural patterns that help define business problems and orchestrate their solutions. Agile EA decenters specific technology recommendations in favor of methods and frameworks for finding the right solution in any situation. 

To put it another way, an agile enterprise architect understands that “owning” the long-term technology plan for an organization is not a sustainable responsibility. Instead, agile EA focuses on enabling internal teams to generate their own solutions to complex problems in alignment with broader strategic goals. 

Agile EA dispenses with outdated and ineffective elements of traditional enterprise architecture practices. Whereas traditional EA is academic, agile EA is pragmatic. Whereas traditional EA is prescriptive, agile EA is adaptive. Whereas traditional EA often becomes decoupled from business strategy, agile EA is solely focused on the ways technology enables business outcomes. 

Ultimately, successfully practicing agile enterprise architecture ensures the organization has the technology runway it needs to achieve its strategic goals. 

Enterprise architecture as a service (EAaaS)

One manifestation of agile enterprise architecture is enterprise architecture as a service (EAaaS). As opposed to project-based consultants who are rarely around long enough to see the execution of their proposed roadmaps, EAaaS provides ongoing support in a scalable subscription format. 

EAaaS can augment or transform in-house EA teams. There are several advantages to this approach, including:

Through enterprise architecture as a service, The Gunter Group has the ability to transform an ineffective, impractical enterprise architecture function into an agile driver of positive change. 

A new era in enterprise architecture

We believe that agile enterprise architecture — which is best realized through EAaaS — represents a dramatic improvement over the status quo. 

More than that, however, we view the shift to this approach as a necessary component of a successful enterprise. 

The old models and best practices of enterprise architecture were developed in a different era. They were not built to handle the strain of the rapid growth and change made necessary by the pace of and competition in the modern landscape.

However, by treating your EA capability as a strategic enabler rather than a tactical function, you will unlock business agility, customer value, and long-term success. 

Agility is the hallmark of today’s most successful businesses — and you simply cannot have an agile enterprise without agile enterprise architecture. 

More about Matt Jamison:
Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

AGILE & THE BATTLE FOR BETTER BUSINESS

Agile is a solved problem, in the tech world. In software development environments, it’s now a staple. You would struggle to find a single development team or technology project that isn’t using an agile framework to plan and execute their work. The idea has long passed from experimental to adoption; it has saturated the market.

Little proof is needed for this claim of complete saturation. Just look at the list of certification-ready agile methods: SAFe, Scrum, Crystal, DSDM, Feature-Driven Dev, ASD, Lean Software Dev, Disciplined Agile, RAD. Beyond the certifications you’ll find (often decades old) schools of thought around Wagile, eXtreme Programming, and others. When you can certify yourself in a handful of different frameworks around the same concept, then it’s safe to say that the school of thought is here to stay.

Outside of tech, though, the potential of agile is still largely unrealized. Waterfall methodology is still the dominant approach to project and product management. At the Gunter Group, we feel this is a missed opportunity. The practice and benefits of agile should no longer be the sole domain of nerds. 

The Coming Revolution

Agile has revolutionized development, or rather, agile is the response to development’s demand for revolution. Waterfall was the child of the uniquely meandering progress of early software projects. Early development borrowed from manufacturing, aerospace, and defense methodologies of the time, and depended on long runways for delivery (and even occasionally relied on physical manufacturing processes).

However, as software leapt forward, the waterfall methods of old failed to serve the split-second pivots required by the go-to-market environment of modern technology. Software development demanded a new kind of organization, one as iterative and quickly-changing as the 1’s and 0’s upon which it was built. From this need, agile was born.

It is a mistake, however, to limit agile to the tech environs of its birth. There is nothing about agile that is necessarily specific to software development. We repeat: there is nothing about agile that is specific to software development. It is a framework that has application well beyond its homeland.

A renaissance is before us. Agile has yet to have as meteoric an effect on the broader business world as it has in all-things-tech, but this change is on the horizon. In this article, we will explore several simple means for the application of agile in non-tech environments.

This article is for agile practitioners. It is also for anyone else who works in a world of projects and output-oriented teams. That means everyone. Yes, you read that right: everyone. (Even construction has room for agile. There are certainly limits to the application, as failing fast in that landscape could be catastrophic. Construction is a mature industry with many unique frameworks for success, but the concepts of agile are still applicable in creative ways. Design iteration, proposing and awarding subcontractors, and daily standups with subs might be areas for immediate agile-inspired growth).

Tried and true in the tech-focused backbone of our ever-changing world, the revolution of iterative, cross-functional, self-forming teams will ripple through organizations and markets of all kinds. The thoughts below are intended to give you a leg-up in this revolution, to find yourself ahead of the curve in the battle for better business.

The Business Cycle & Agile: An On-Again, Off-Again Relationship

Agile has a place in the business cycle, but only one place. The picture below illustrates this (a notable exception to this limitation can be found in the SAFe framework, which has made progress in utilizing agile in a broader business context). Agile is often embraced by a development team or manufacturing process, but everything upstream and downstream from these teams still think of their work in terms of waterfall. As the landmark book The Lean Startup explains in detail, this often results in products reaching the market after months or years of investment without validation that the product is even needed.

This can be fixed. At TGG, we have seen successes and failures with clients attempting to embrace agile methods. There is no one right or wrong way to embrace agile, but we have seen some general activities or mindsets prevail over others.

Below is a list of high-level considerations you should keep in mind if you are interested in adopting agile in your non-tech team:

Don’t Do Agile for Agile’s Sake: It can be easy for a leader to say, “It works for the Unicorns so it should work for us.” As a result, agile or lean Centers of Excellence sprout up in organizations that are not ready or willing to embrace these methods. Agile only works when a team understands why they are doing it and are engaged in the method in a way that adds value. It is all about developing business agility and driving value to the customer—not just about “doing” agile.  

Find the WHY (Value Added): People are more willing to change when they understand why a particular change will benefit them. This is universally true, and is a fundamental concept that drives all successful change efforts. When accompanying a team that is new to agile, break the component parts down into WHYs that demonstrate the value added by an agile element. More on this below.

Use a Light Touch: For teams that have been thinking in terms of waterfall timelines and years-long delivery plans, agile is not intuitive. This is even harder for teams that don’t operate in a project environment, such as operations, finance, or HR. It is uncomfortable for someone new to agile to imagine releasing their work before it is “completely done.” For these people, adopting agile represents a culture change. Use a light touch, and embrace change management best practices. Educate on the value of embracing agile ceremonies and artifacts (see Point #2), and give them time to adjust to a new work culture.

Think About Slicing Small: You might think that the key difference between waterfall and agile is the speed of the work. However, this doesn’t quite capture the power of agile methods. Agile teams don’t work faster—they work smaller. Sprints are only successful when a team can break their work into smaller chunks that can be accomplished, reviewed, and delivered to customers in a matter of weeks. When looking to adopt agile in your non-tech team, this can be one of the hardest yet most rewarding mindsets to shift. Ask yourself the question: “What can we complete this month and deliver to our consumers?” 

Start with Standups and Retrospectives: When in doubt, the easiest place to start with agile adoption is with standups and retrospectives. Gather your team together so everyone can give a 30 second status update and share any blockers. Encourage recognitions, because they actually do boost engagement. Periodically bring everyone together to reflect on the way they work, and encourage them to think creatively about small changes they can make to boost productivity or morale. These rituals are baked into agile systems but are often overlooked in the recipes of other structures. They are ceremonies that are simple to implement (their WHYs are easy to understand), and they immediately add value to your team.

Find the WHY: Representing the Value Added by Elements of Agile

In tech, it is easy to take agile for granted. There is little need to investigate why that is the case. Dev teams embrace the frameworks without the need to justify why. Tech simply trusts the efficacy of the model.

Non-tech environments are more skeptical, however. Business units accept the place of agile in their organization’s tech division, because the quality and turnaround of their tech solutions are desirable outcomes. But a chasm exists, an us versus them void between tech and business, in which each realm agrees to the ways of the other without cross-pollination. “Agile works for IT,” says the non-IT department, “but we will carry on as we always have.” 

When making the crossover from tech to non-tech, asking WHY is essential. When making the case for an agile adoption in a non-tech environment, it is not enough to know THAT agile works; you also have to understand WHY it works. 

The core concept of this article is this: by breaking down the framework into a series of WHYs, you are able to build a business case for its adoption.

In Search of WHY

Before diving into case studies, we’ll pause to give a couple brief examples of how to find WHYs. First, we’ll give an example of finding a WHY, and then we’ll observe an organization that has used this WHY thinking approach to maximize the benefit of agile enterprise-wide.

We’ll start with an example of a WHY. Any agilist knows of two basic roles that tend to show up in any agile framework: the Scrum Master and the Product Owner. But why are these roles so valuable? In short, they capture a tension that exists in every project: throughput versus quality. 

The Product Owner represents the customer. He or she is ultimately accountable for the product that hits the market. They massage the backlog, prioritize features, and vouch for the throughput and objectives of the customer. The Scrum Master, on the other hand, is a servant to the team. He or she is responsible for maximizing the value of the team’s work by removing impediments and maintaining focus. 

In every project, there is a tension between speed and quality, and often these elements are at odds. Teams have to choose between the speed or quality of their throughput. The roles of the Product Owner and Scrum Master capture this tension, striking a balance that delivers a timely, quality product. 

Here’s the WHY: agile purposefully creates this tension. The Product Owner advocates for the deliverable; the Scrum Master advocates for the team. There is no consensus without dissent, and the dissent built into the agile framework ensures a consensus between the competing demands of immediacy and quality. 

You’ll notice, in this example, that the WHY is subtle. It simply looks at two roles and understands the purpose for each of them, both individually and together. But their purpose, the WHY, is powerful. Maintaining the tension between throughput and quality ensures that an agile team continuously delivers a product that is valuable. 

There are many examples of organizations finding the WHYs, but a fantastic example can be found in the way Spotify approaches an agile culture. Spotify, a tech company, started from the assumption that agile adds value. But they also embraced a key mindset: rules are a good start, but let’s break them when needed. This led Spotify to match its needs (autonomous squads, short term goals, and an enterprise-wide holistic product strategy) to the WHYs of agile (throughput vs quality, flexibility, consistency, autonomy, alignment) to create a truly unique structure of tribes, squads, chapters, and guilds.

These unique, overlapping structures don’t conform to any particular agile method, but point to the WHYs of agile as necessary predecessors. The result: a nimble organization and healthy culture that keeps pace with the ruthless, fast-paced competition of streaming music solutions.

Agile in Business: Case Studies

So far, we have discussed the concept of embracing agile elements in non-tech teams. Let’s look at a few examples of this concept in action.

The Lean Startup – Laundry Services in India

A current popular expression of these concepts can be found in the book, The Lean Startup by Eric Ries. Over the course of 300 pages, Ries walks the reader through a home-grown approach to agile adoption grounded in decades of direct and indirect (consulting) experience with entrepreneurs and startups.

Core principles of The Lean Startup include small slicing vision into minimum prototypes, testing those prototypes early and often, validating assumptions, and promoting a culture of constant adaptation and growth. These agile-adjacent methods are all implemented without any of the typical agile ceremonies or artifacts.

There are dozens of case studies in the book that demonstrate the WHYs in action. One example comes from a laundry service launched in India: Village Laundry Service (VLS). In 2009, VLS was poised to launch a low-cost modest-return laundry service in a virtually untapped market in India.

The company, however, paused to create small-scale experiments to validate product assumptions and zero-in on specific customer needs. They embraced a model of iterative testing and adaptation that allowed them to target a rollout that was specifically tailored to customer needs. This meant that, once scaled, VLS was sure that they were mass-producing a product that customers would actually buy.

National Insurance Provider – Accounting Team “Scrum”

An insurance provider engaged us to assist with an ERP implementation that would replace the general ledger that accounted for tens of billions of dollars in managed assets and revenues. In the organization, there was a Lean Center of Excellence that had been advocating for agile ceremonies across the organization for several years. However, the accounting department had not yet adopted any of these elements. Early in the project, the team decided to organize themselves into a scrum team, with all the usual ceremonies and artifacts.

Initially, the transition was difficult. The team consisted of financial analysts and operations managers, and no one had project experience (let alone a knowledge of scrum). The “scrum team” was also larger than recommended, with more than 15 people.

Over time, the team used the ceremonies to break down their activities into a series of WHYs. Daily standups helped illuminate blockers and inefficiencies, and sprint retrospectives allowed the team to reflect on what was working and what wasn’t. Before long, the team developed a rhythm to their work and were able to break out the scope into smaller slices that more efficiently made use of their resources. Additionally, they were able to quickly track and validate decisions made about the product, which allowed for quicker pivots that better met the needs of their internal stakeholders.

HR Job Posting – Introducing Small-Slicing to Recruiting

On November 20, 2019, TGG’s Tech Services Lead Matt Jamison presented to AgilePDX on the topic of adopting agile elements in non-development teams. To illustrate his ideas, he shared an example of applying agile to talent acquisition in an HR department, with regard to staffing practices. 

The Problem Statement: the struggle to find and hire talented resources presents a series of constant hurdles. Even without complications, it is difficult to sort through the tides of resumes to find individuals who have the professional and cultural acumen needed for a particular situation. 

But hiring does not occur in a vacuum, and complicating factors abound. Hiring teams struggle to match job postings to the continuously changing needs of their organization. Market factors like shifting regulations, emerging fields, and competitive innovation require constant adaptation to who or what an organization needs on their teams. On top of this, the company mission is regularly transitioning due to adaptations from corporate strategy and new products. 

When hiring for a team, there is a need for agility. Despite this, overworked recruiters are often incapable of the continuous change that would empower them to hire better, faster, and smarter. Poll HR professionals and you will likely hear the same thing, “I’m not getting the right talent. It takes too long to get talent. How do I assess the growth of employees and allow for advancement? I don’t respond quickly enough to changes in my organization and market.”

Enter the Agile WHYs: how would an HR team look to agile to address some of their struggles? Start with the problems: 

– There is too much to change and not enough time to adapt
– Changes in job descriptions require a lengthy approval process

Looking at these problems, several agile WHYs start to jump out in response:

– Vertical slicing deliverables into bite-sized stories
– Sprint structure allows for near-term pivots on vertical slices
– Empowering team members to problem solve allows for quicker creative solutions
– Iteration on pain points or strengths allows for continuous improvement

An HR team embracing these WHYs wouldn’t have to embrace a full scrum adoption to realize their benefit. They could small-slice a job description, looking at components of a specific description instead of the whole thing. They could explore ways that recruiters could update parts of job descriptions in a quicker manner without needing full bureaucratic and legal review involved with a new job post. They could collect user stories from teams with upcoming resourcing needs instead of a list of qualifications and specific experience, empowering recruiters to be more creative in finding the right fit. 

By embracing the WHYs of agile, teams can borrow the best parts of the methods and ceremonies to foster agility. And by doing so, they are living up to the core principles of agile, putting individuals and interactions before processes and tools.

We want to close this paper by reiterating a key point that is foundational to adopting agile in new environments: don’t do agile for agile’s sake. If either managers or direct reports fail to understand the reason why they are making a change, then that change is destined to fail. Do not embrace agile just because it’s trending in high-dollar markets. 

There are good reasons for the successful outcomes of agile—a successful adoption requires an understanding of these reasons first. After witnessing successes and failures in the market around us, we firmly believe that a team must understand the WHYs of embracing agile methods before jumping in. 

More about Matt Jamison:
Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

More about Josh Bathon:
Josh is a creative problem solver with experience in project management and process improvement. Josh thrives in situations that challenge him to learn quickly and adapt to new environments. Leveraging his unique background in seminary formation, Josh brings emotional intelligence and self-knowledge to his interactions to build lasting, goal-oriented relationships. Josh has experience in healthcare IT, primary education administration, and non-profit service, environments in which he has developed a team-oriented leadership style geared toward high-performance outcomes. Josh holds a Bachelors in Philosophy and History from the University of Notre Dame. When he’s not working, Josh loves to read fiction and philosophy, as well as explore the cuisine and quirks of the Portland Area with his wife.

TGG FACILITATED APPLIED AGILE PANEL DISCUSSION

A few weeks ago, The Gunter Group facilitated a panel discussion at one of our clients (a global footwear and apparel company), which focused on Agile methodology application within their organization.

We would like to share a few key topics from the discussion.

1 — Implementing an Admin Week for Scrum Team Efficiency

One panel participant shared the story of her team iterating on ways to improve development velocity. They were having the common issue of missing sprint target dates and discussed the problem during a retrospective. Together, the team realized that between meeting schedules and “shoulder taps” for side work, they just didn’t have enough focused development time. 

Initially the team implemented a block of time from morning until 1pm for dedicated development. While that did increase velocity, they still weren’t where they wanted to be. 

Finally, they landed on a concept to implement an “Admin Week”. They decreased their sprints from 3 weeks to 2 and added in 1 week for admin time. This gave the team 2 weeks of uninterrupted development and 1 week to sprinkle in all of their administrative work such as meetings, ceremonies, idea brainstorming, internal documentation, mentoring, and training. 

This shift resulted in a 36% increase in velocity and 36% decrease in duration of stories from “ready” to “complete”. 

2 — Mitigating Discomfort Around Uncertainty

Another panel participant, an Agile Coach within our client’s organization, shared his thoughts around building comfort with uncertainty. 

With the timely example of COVID-19’s highly impactful effects on businesses’ roadmaps, we discussed how important it is–now more than ever–to strengthen the ability to navigate uncertainty, with an agile mindset. 

Participants agreed that we are seeing executives embrace agile thinking in their ability to pivot quickly and react as efficiently as possible. Work is being prioritized more clearly and decisions are being made at the “last responsible moment.” 

3 — Servant Leadership in an Agile Framework

Lastly, our third panel speaker shared his perspective on leading in a Scrum Master role with a servant leadership approach. 

This perspective emphasized the importance of maintaining a people focus in agile environments. Rather than just focusing on scope, schedule, budget–the servant leadership approach enables and promotes leadership in others. 

He shared his experience about working with Scrum teams in this manner and how it has built relationships, garnered trust, and fostered growth within the team.

It also sets up the team for a safe environment during sprint retrospectives so that they are able to share thoughts and feedback more openly and from a place of assuming positive intent.

At The Gunter Group, we thrive on helping our clients by facilitating conversations such as this one and invite you to reach out if you are interested in TGG hosting something similar within your organization. Please contact us if you’d like to learn more. 

To those who attended the panel discussion outlined above, thank you so much for your participation and we look forward to seeing you at the next one on June 24th! 

UPCOMING PORTLAND EVENT: APPLYING AGILE TO THE NON-IT PARTS OF YOUR BUSINESS

You love agile. You love the iterative approach to problem-solving. You love the way it empowers your IT teams to find solutions. You wish that you could see the same benefits in other parts of your business, but the problem is that agile seems stuck in the world of developers and technical teams. 

Matt Jamison, Tech Services Lead at The Gunter Group, has been thinking about this problem for a few years. In conversations with clients and peers in various industries, Matt has started to break down the principles, roles, ceremonies, and functions of agile into a series of “Whys” that add value in a broader business context. By deconstructing the structures of agile into their purposes, Matt is able to apply aspects of agile to lines of business that fall outside of tech. 

Excited to hear more? Join Matt as he explores how these agile concepts offer a fresh approach to building bridges between strategy, processes, and the realization of business goals. Matt provides examples that illustrate how agile can spill over the boundaries of tech into non-IT parts of the business, providing use cases from HR.

Come join the conversation! The event will take place at Puppet on Wednesday, November 20th from 6:30pm to 8:30pm. Click here for more details, and to register for the event! 

Matt Jamison is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

TGG LEVELS-UP TECH PRACTICE

Gunter Group consultants converged on the Portland area last weekend to attend a 16-hour 2-day training on agile. The course, provided by industry leader Rod Claar, included a deep dive into agile best practices and featured hands-on learning experiences. 

Participants learned the fundamentals of agile project management, especially with regard to the rules and roles of Scrum. This course positions TGG to continue providing the best possible service to our clients, by helping us to integrate proven best-practices with the experience many of us already have in agile environments. 

What did you do with your weekend?

Part of a Larger Growth:

Half of TGG consultants in the field are trained or experienced in agile, as of last weekend’s course. This class was one of many steps made by TGG to grow its expertise in technology. 

Over the past several years, we have seen technology become an important part of every aspect of business. More than 90% of employees in the US use the internet to do their job in some way, which means that IT isn’t just a single department in your business. Technology permeates every aspect of your business, from your customer-facing sales tech to your enterprise resource planning solution. 

Tech Practice Lead Matt Jamison spoke about this just last month in a thought article about the transformation that agile is undergoing in the business world. Modern agile methodologies, now more than 3 decades old in American business practice, are starting to see widespread adoption by organizations of every size. 

Jamison believes that agile will begin to change as more and more non-software teams embrace iterative project systems. TGG consultants are committed to integrating their consulting experience with industry-tested methods for proper tech strategy and methods. 

Included in this commitment is our new service: Agile Methods in Business. We blend our experience in agile environments with quality training and development (like last weekend), all with the goal of helping our clients select the aspects of small-team structure and iterative planning that best fit their situation. 

TGG offers these services in the Portland, Bend, Reno, and Sacramento areas. If you could benefit from consulting services in your agile practice, or need help implementing agile best-practices in your team, reach out today to start a conversation! 

THE FUTURE OF AGILE: LOSE YOUR MANIFESTO

Matt Jamison is no stranger to agile. As the Service Lead for technology at The Gunter Group, Jamison is putting his twenty years of tech experience to good use. He has kept his finger on the pulse of all-things-IT for quite some time.

Jamison’s latest reflections on tech would surprise you. Lately he has been talking agile, but not in the way you might expect. He believes that business is on the threshold of change. 

First, Jamison likes to point out that the idea behind agile is not new. “The Agile Manifesto and the Scrum Guide aren’t revolutionary. Extreme Programming was a thing back in the 90’s. It’s essentially agile. Sit with another person who knows what you’re doing and then iterate. Iterative problem-solving is not new, even if organizations are getting more intentional lately about building agile methods into their structure.”

That being said, Jamison does understand why people go for the rigid approach of particular agile methods. “Someone wrote out a manifesto and it was picked up by Silicon Valley IPO’s that made a ton of money. Now people assume it’s what they have to do to make money.”

There’s nothing wrong with the rigor of a guide or manifesto; it can often be a good entry point into an iterative way of thinking. But Jamison thinks that this can also be an excuse to stop thinking critically.” 15 years ago another developer told me something that still sticks with me. He said, ‘Every problem can be solved with one additional layer of abstraction.’ In an agile environment, you often come to a pain point between a problem and the guide’s method for solving it. That’s when I blur the boundaries outlined by a manifesto and see if I can bring in something new that adds value.”

Jamison has a question that he loves to ask: Does this work for us? “The key is to understand the reason you’re doing something. If you challenge a rule from a manifesto, you need to understand both the reason for the rule and the reason for breaking it. Are you iteratively getting better at something? Then you’re doing agile.” 

“Agile has become a thing,” says Jamison. “The experiment worked! The terminology won’t stick around, but the philosophy is a good way to solve problems. In that way, I think agile will continue to move businesses after the marketing engine stalls.” 

Jamison believes that agile is on the threshold of a new era. Agile was once a firm framework that provided structure to tech developers. As the hype fades, agile is transforming into a set of best practices that will enjoy wide-spread adoption in a variety of organizations. 

Organizations are already putting agile’s successful components to practice. Tech heavyweights like Spotify have experimented with non-traditional loose agile structures. Non-IT companies like banks (Barclays) and manufacturers (GE) have jumped on the wagon as well, experimenting with enterprise-scale structures that promote iterative growth and continuous feedback with less of the rigor. In the end, businesses want what works–and they are finding that in agile. 

This is a slow transformation. It is not hard to see the benefit of iteration, feedback, and innovation found in agile methods; it is much harder to make an enterprise-scale transition. Each organization is unique, and the incorporation of agile requires thoughtful planning and customized implementation. Jamison is helping the consultants at The Gunter Group to combine agile best practices with their business experience in order to meet the unique needs of our clients. 

Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 18 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

TGG SPONSORED AGILE PDX EVENT – FROM MINDSET TO CONSCIOUSNESS: PLAYING THE INFINITE GAME OF HUMAN DEVELOPMENT

We hope you will join us for June’s event to learn about how to spot developmental as opposed to lower level learning experiences in the context of an agile consciousness.

RSVP here: From Mindset to Consciousness: Playing the Infinite Game of Human Development

Wednesday, June 19, 2019
6:30PM – 8:00PM
Puppet Labs, 5th Floor
308 SW 2nd Ave
Portland, OR 97204

Details about the event:

Agile is part of an evolution in consciousness–in the nature of our awareness and noticing skills and our knowledge of self and other. When agile emerges in an organization, it does so within a consciousness unlike its own. Yet, our approaches to agility often impede its ability to stick where it emerges.

Agilists have used the frames of mindset and learning. But, we need to use the frames of consciousness and development in order to truly transform. In doing so, we see agile transformations are actually personal transformations. Organizations don’t change, people change and then the organization adapts.

This deep dive session discusses the agile mindset and puts “mindset” in the context of “consciousness.” It speaks to advancing agilists who are trying to understand why adoptions go wrong when they have done everything “right.” You are more likely to receive full value in this session if you have been pursuing agility within organisations for at least three years.

This session provides pointers on how to spot developmental as opposed to lower level learning experiences. It is based on my own practice, on research I did for my master’s thesis, and on my book The Preservation of the Agile Heart: From Mindset to Consciousness.

Learning Outcomes:

Speaker Bio:

Jean Richardson is a consultant and coach with nearly 30 years of experience in software development, with half of that time spent in learning about agile and participating in the agile movement. For the last six years she has coached individuals and teams in agile-aspiring organizations. A former AgilePDX Coordinating Committee member, Jean is actively involved in helping, guiding, and coaching the agile community at the local and national levels toward a collective agile consciousness!

In case you missed our previous posts, Agile PDX is a large organization of Agile practitioners among the greater Portland metropolitan area. Their vision is to see Portland as a world-class leader in software development. Their vision is to see Portland as a world-class leader in software development, defining “world-class” as profitable, sustainable, and joyful. Their mission is to work together to create a vibrant, successful Agile community of practice in Portland, sharing experiences, distilled wisdom, and innovative ideas for Agile done well.

Their regularly held meetings are as follows and more information can be found on their Meetup page:

Downtown Pub Lunch: 12:00PM – 1:00PM on the first Friday of the month.

Westside Cafe Lunch: 12:00PM – 1:00PM on the fourth Friday of the month.

Downtown Evening Events: Third Wednesday of the month at Puppet Labs: Doors open at 6:30PM, main event starts at 7:00PM and usually runs to 8:00PM, out of the building by 8:30PM.

We will announce each TGG sponsored event as they are posted, so please check back for updates! Mark your calendars now for June 19th and we hope to see you there!

TGG SPONSORED AGILE PDX EVENT – JOHARI WINDOW, WHAT’S THAT? DO I NEED ONE?

We hope you will join us for May’s event to learn about how to use the Johari window to help teams connect on a deeper level without oversharing.

RSVP here: Johari Window, what’s that? Do I need one?

Wednesday, May 15, 2019
6:30PM – 8:00PM
Puppet Labs, 5th Floor
308 SW 2nd Ave
Portland, OR 97204

Details about the event:

One of the keys to effectiveness is to know yourself and show yourself the Goldilocks amount. How do you avoid TMI (Too Much Information)? And, at the other end of the spectrum, how do you keep from being too reserved to share much of anything with other people?

If you know yourself well enough, you can share relevant information to improve communication and connect with others. And the more expert communicators you have on your team, the more potential you have to build trust in a professional way.

One tool to help you on this journey is the Johari Window. Created by psychologists Joseph Luft (1916–2014) and Harrington Ingham (1916–1995) in 1955, the Johari Window helps people understand what they show and what they hide from the world; what they don’t see and what they don’t even know about themselves.

Neal first learned about the Johari Window in one of his leadership training sessions, and it piqued his interest as a facilitation tool. We are excited to have Neal share his insights about how to use the Johari window to help teams connect on a deeper level without oversharing. And for those interested, we’ll have an opportunity for hands-on exercises.

Speaker Bio:

Neal Peterson is a business consultant who helps businesses utilize the full capacity of their systems and processes. His goal is to enable businesses and people to do more with less, more efficiently and effectively. As a certified Project Management Professional (PMP), Six Sigma Lean Black Belt Professional (LBBP), and self taught agile coach, he collaborates across the functional departments of an organization to enable continuous measurable improvement of end to end value chain processes. He has done this for companies in the healthcare, financial services, retail, government, software, semi-conductor, transportation, shipping, and manufacturing industries. He seeks to share the agile mindset with others in the community via conversations and facilitated sessions that enable learning in a collaborative environment.

In case you missed our previous posts, Agile PDX is a large organization of Agile practitioners among the greater Portland metropolitan area. Their vision is to see Portland as a world-class leader in software development. Their vision is to see Portland as a world-class leader in software development, defining “world-class” as profitable, sustainable, and joyful. Their mission is to work together to create a vibrant, successful Agile community of practice in Portland, sharing experiences, distilled wisdom, and innovative ideas for Agile done well.

Their regularly held meetings are as follows and more information can be found on their Meetup page:

Downtown Pub Lunch: 12:00PM – 1:00PM on the first Friday of the month.

Westside Cafe Lunch: 12:00PM – 1:00PM on the fourth Friday of the month.

Downtown Evening Events: Third Wednesday of the month at Puppet Labs: Doors open at 6:30PM, main event starts at 7:00PM and usually runs to 8:00PM, out of the building by 8:30PM.

We will announce each TGG sponsored event as they are posted, so please check back for updates! Mark your calendars now for May 15th and we hope to see you there!