Author: Elizabeth Walsh

Upon its release early in 2023, SAFe® 6.0 brought about several changes to the framework, one of which may be the most important and impactful to you if you are a current SPC (SAFe Program Consultant).

The role of the SPC is key to any SAFe adoption because SPCs provide the foundation on which we build the change initiative. Because we need SPCs to provide the training, coaching, and mentoring that most organizations lack, having a keen understanding of the new SPC (SAFe Practice Consultant) is essential.

So what has changed other than the title? Let’s take a closer look.

What’s changed about the SPC role?

While the core responsibilities of the SPC remain largely the same, many subtle changes add up to a meaningful revision that is worth noting and studying, especially if you already have SPCs supporting your Agile Release Train (ART). While some changes may seem minor, others may alter how you perceive and leverage your SPC skill set.

In the following table, I have summarized the primary responsibilities of the SPC for both version 5.X and 6.0. You may notice that several items have either been merged or enhanced. Next, we’ll dive deeper into the importance of these changes.

Key Differences

Why were the changes made?

No, Scaled Agile Inc. isn’t just trying to keep you on your toes, or necessitate new business cards. These changes—some subtle, some not so much—were made for a few important reasons.

Emphasis on business agility, not just engineering or product development

Previous versions of SAFe emphasized Lean-Agile systems development, which focused primarily on defining, building, testing, and deploying of technology-centric products and services.

While this theme has been important, and will continue to be valuable for most business organizations, SAFe 6.0 recognizes the need to expand beyond IT functions because large organizations are very complex, encompassing much more than just IT. By placing focus on the overall business as a system, they have widened the realm of possibility for SAFe to other functions, such as Finance, Human Resources, Business Development/Marketing, and more.

This also redefines the Value Stream to expand beyond the boundaries of IT. For organizations that may have begun their SAFe journey within the technology world, this enhancement enables further application of SAFe to other parts of the company.

Focus on values and behavior; modeling over telling/teaching

Scaled Agile Inc. modeled the SAFe Program Consultant after an advisor, trainer, consultant role—someone who provides guidance and advice, and primarily tells an organization what they are doing right or wrong as they attempt to induce change where needed.

The new SPC places more emphasis on a different approach, which is akin to professional coaching. With new terminology such as “coaching” and “embodying”, SAFe 6.0 emphasizes a softer, more people-centric approach to the “consulting” responsibility. This is exemplified in the new prioritization of the Continuous Learning Culture within SAFe 6.0.

Which changes should you care about?

If you are still reading, chances are you’re an SPC yourself, or you already have SPCs within your organization who are doing great work. Also, there’s a high probability that your SPCs are trying to understand how this change will affect them.

There are several ways to explore the new SPC responsibilities and determine if/when you may wish to adopt them.

One method is to establish a community of practice for SPCs and encourage the members to exchange their ideas on what this change means to them and your organization. By allowing the SPCs to develop their own vision for the future state, they are much more likely to take ownership of this change and follow through on the execution.

To complement this approach, it may also be helpful to build a high-level change roadmap to help structure the application of the new responsibilities defined for the Practice Consultant.

Closing thoughts

The SPC role is the cornerstone to any SAFe-enabled initiative, so taking the time to make sense of these new and changed responsibilities is an important investment, especially if you have already made a commitment to apply SAFe within your company.

As with all changes, adopting the new role does not have to be a onetime project; if you can incrementally apply small changes that make sense for your SPC community, you may realize the benefits faster than expected.

Dive deeper into the new SPC role and how your organization can best adopt the changes to the role by exploring our learning course, Implementing SAFe – Certified SAFe Practice Consultant.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

When does a relatively obscure coding language become important to the C-suite of an international, multi-billion dollar enterprise?

When we’re talking about the only means you have to translate your existing custom scripted workflows from Jira on Server or Data Center to Jira Cloud.

For users in Jira Server or Data Center environments, the most commonly used applications to handle these kinds of custom scripts are:

• Scriptrunner
• Jira Miscellaneous Workflow Extensions
• PowerScripts

The trouble is, when users of these popular scripting platforms migrate to Atlassian Cloud, their scripted workflows break.

Why?

Because the scripting format in Atlassian Cloud is completely different. On Cloud, you must use Jira Expressions.

What is Jira Expressions?

Jira Expressions is a domain-specific language designed for Jira Cloud that allows developers and Jira admins to set up workflow transition customizations using conditions and validators.

In other words, every piece of custom automation a Jira Cloud user wants in place to streamline and optimize the flow of data, approvals, and workflow progress, gets created using Jira Expressions.

The basic function of Jira Expressions is to read Jira information very quickly so Admins can customize conditions and validators. For example, let’s say a particular type of Jira issue needs to be approved by a member of the HR team before it can move from “In Progress” to “Done” in its workflow. The code telling Jira Cloud to check this when the issue is transitioned must be written in Jira Expressions.

Why does it matter?

This seems straightforward, and really, it is.

The trouble we’ve run into, though, is that most organizations who are migrating to the Cloud don’t see the need to act on this early enough in the migration process. The depth and complexity this introduces into the migration took us by surprise early on as well. But now, after hundreds of successful migrations, we see the problem for what it is.

Here’s why you need to consider dealing with Jira Expressions long before your migration occurs:

• It’s not an easy language. Jira Expressions is JavaScript-based, but it’s not pure JavaScript, or any other commonly-used language. Translating your current scripts into Jira Expressions is not straightforward. Your IT team is going to have to take the time to learn how to use it. And it’s not easy.
• You probably have more custom workflows than you realize. Large organizations who have been using Jira Server or Data Center for a long time may have hundreds, even thousands, of custom workflow transition scripts running in their current instance. Few even have them documented. So, going through to prioritize and update them all will be a huge job.
• Atlassian’s documentation is limited. For such a relatively obscure and difficult scripting language, the available documentation is thin. And, thus far, there are no in-depth training programs available.

What happens if you don’t factor in Jira Expressions?

Unfortunately, we’ve seen this happen a number of times. While concentrating on a host of other migration-related concerns, the idea of making tiny tweaks to custom workflows feels unimportant.

But it’s not.

Here’s what could happen if you fail to factor Jira Expressions into your plans before the migration occurs:

• The cost of the migration could go up. A large-scale Cloud migration is a significant investment. Whether you’re doing it yourself or working with a migration partner, you want to plan and execute it as efficiently as possible. Dealing with Jira Expressions after the fact will add time and cost to the equation.
• It could be detrimental to your business. The saying goes, “you don’t know what you have until it’s gone.” Post-migration, your teams’ productivity depends on Jira working seamlessly. If some or all of your standard Jira functionality grinds to a halt because of broken scripts, it may take a long time to get back to pre-migration levels.

Cprime is an Atlassian Platinum Solutions Partner with a certified Cloud specialization. We’ve performed hundreds of Atlassian migrations, seen what does and doesn’t work, and developed a tried and true framework for moving you seamlessly from Server or Data Center to Atlassian Cloud.

That includes evaluating, streamlining, and executing your move from your current custom workflow scripting language to Jira Expressions. Contact a specialist today to make sure your migration goes smoothly.

Throughout the past few years, the Velocity metric seems to have become a polarizing element among Agile teams due to how this data point is being used. Several years ago, the Scrum Guide mentioned Velocity as a recommended metric for Scrum teams. Because of the way this information has been used and misused, it has since been removed as a recommended practice. Similar to Sprint burndown charts and the use of Story Points, metrics from Scrum teams seems to have become de-standardized, as teams are now free to choose how they track and measure their work.

Now that teams have more freedom, you may wonder whether this is good or bad for the teams. While it is positive that the team has more perceived autonomy, they also are at greater risk of being directed to track and report specific metrics to management because of the absence of an industry standard rule on Agile metrics.

Why Do Teams Measure Velocity in Scrum?

Within the Scrum/Agile world, there is no single equivalent of the PMBOK (Project Management Book Of Knowledge) which provides a formal, official standard organizations and teams can point to as “the guide”. Hence, Scrum teams are potentially under a higher level of influence by senior leadership that expects to see a specific measure of project progress, and Velocity is often the metric of choice.

So is the use of Velocity in Scrum necessarily a bad practice? Let’s look at both sides of the argument and see what makes sense to you.

Pros of the Velocity Metric

Velocity is typically a measurement of productivity by an Agile/Scrum team that usually estimates work using Story Points. The measure Velocity can follow units of Story Points or a simple count of total Product Backlog Items (PBIs). Teams usually track this data point on a per-sprint basis. For example, a team may have planned 12 PBIs (with an aggregate of 70 points) and completed 10 of them (totaling 50 points) within a single sprint. The Velocity is “50”.

The data is typically used to measure team performance trends over a period of time; an average Velocity can assist a team to forecast future output and allow the team to plan what business value they can deliver over the next several sprints.

All this may sound fairly benign so far, correct? When used properly, Velocity trends can be a great tool for a self-organizing, self-managing team. The problem arises when this data point is used in unintended ways.

Why Might Teams Want to Consider NOT Using the Velocity Metric?

In my experience coaching Agile teams, I have observed several practices that lead to undesirable behavior by the team, producing degraded morale and performance. Here are a few examples of such practices.

Cons of Measuring Velocity in Scrum

Comparison of Velocity between teams

Because the Story Point measure is a relative scale that is unique to each team, comparing two teams based purely on the total number of points they deliver is basically comparing apples to oranges; it makes no sense and provides no value. No two teams are identical in terms of their skills, experience, knowledge of the problem domain, interpersonal dynamics, or how they approach their work. So it makes no sense to measure their performance using a single, relative metric like Velocity. Doing so can damage the morale of the teams and motivate negative behavior such as Story Point inflation.

Requiring a Team to “Complete More Points Each Sprint”

One common aftermath of comparing team productivity using the Story Point measure alone is that someone in a leadership role will often mandate an increase in team productivity by directing or requiring a percent increase in output; for example, “Team A must complete 10% more points each sprint.” This will often cause unintended behavior such as teams artificially inflating their estimates just to achieve the directed goal; a PBI that used to be five points is now eight points, etc. This type of behavior puts the focus on meaningless increases in the Velocity metric, eliminating its value.

How to Mitigate the Use of Velocity in Scrum

So how should we try to inspire the proper team behavior towards delivering meaningful business value instead of making the metric look good? There are a few variations of the Velocity metric that can help focus the team on improving their predictability and performance.

Percent Complete Versus Planned

The metric I typically recommend over pure Velocity is percent complete versus planned. We can calculate this metric using points or just a total count of the number of work items. For example, if a team completes 10 out of 12 PBIs (or 50 points out of 70 planned), that is equivalent to 83 percent of stories completed, or 71 percent of points completed. The two numbers will probably vary because of the stories having different sizes.

If the team can track this over time—usually at least three sprints—the team will know the average trend, and that will help answer one important question: Is the team performing consistently? If the graph is showing extreme highs and lows, that shows that they need to stabilize the team. The root cause may be variations in team membership, abrupt changes in team capacity, or changes in priorities during the sprint. All of these potential causes provide opportunities for the team to improve. Generally, as a team matures and learns to work together, the Percent Complete Versus Planned should increase since they should know how to plan and execute work more effectively.

In conclusion, measuring Velocity in Scrum can be a powerful tool that can be used for good and for evil. The key is to pay attention to how you are using the metric, as well as the impact it has on your team. If a metric is helping your team do better work and achieve higher quality, chances are you are using the right one. If not, focus on improving by experimenting with alternative metrics that better achieve the goals you’re after.

The engineering industry is constantly evolving. Staying ahead of the curve requires a deep understanding of emerging trends and technologies. In the recently launched The 2023 State of Engineering Management Report, Jellyfish uncovered several key findings in regards to where engineering teams are investing their time, what challenges teams are facing on an operational level, and notable differences between underperforming and overachieving teams. The report underscores the importance of efficiency, engineering leadership, business alignment, and data-driven decision-making. Here’s our take on the results.

Efficiency, a key theme of the report, characterizes a business’s ability to optimize processes and reduce waste. In a manner unseen before, businesses are working to streamline workflows and minimize the number of steps required to complete a task to achieve faster turnaround times, reduce costs, and improve overall productivity. Businesses must embrace efficiency to deliver products and services to market more quickly, to create a major competitive advantage in today’s fast-paced business environment.

Pillar 1: Prioritization and Delivery Management

The Trend

Engineering leadership is another key area of focus highlighted in the report. Effective leadership can drive innovation, inspire collaboration, and help teams to achieve their full potential. By providing clear direction, setting goals, and empowering teams, engineering leaders can create a culture of excellence that drives business outcomes.

The Problem

Engineering leaders commonly question the value they are driving from investments or aren’t satisfied with their delivery organization. Leaders must be proactive about aligning work around value and business outcomes. In some cases, this may require implementing a new operating model or reorganization of the teams to plan, prioritize and implement work.

45% of Engineering leadership cited that their biggest challenge is making sure everyone is focused on the highest priority work

Key Strategies to Employ

While visibility has improved in recent years, it continues to be a key challenge for engineering leaders. There is still much work to be done to ensure leadership is continually aware of certain types of work that are taking time away from established priorities. Here are 3 rules for every engineering leader to increase transparency and build trust and confidence in their teams:

1. Set clear priorities and goals: Make sure that your team knows what they are working towards and what success looks like.
2. Foster collaboration and traceability: Consider uniting, consolidating or integrating your tech stack for the traceability to identify problem areas.
3. Empower team with learning: Forget failing fast, learn fast instead, and encourage teams to do the same by continually leveraging performance metrics and providing learning and enablement opportunities where necessary. Teams can benchmark themselves against performance metrics, and the introduction of performance metrics, when done correctly, can be a helpful way to identify areas of opportunity and growth. Teams mustn’t fixate on one metric, instead employing a balanced approach to metrics, where metrics play checks and balances against each other (ex: speed vs quality).

Pillar 2: Business Alignment

The Trend

Business alignment is another critical component of engineering success. Aligning engineering goals with broader business objectives can help ensure that all efforts are focused on achieving key outcomes. This alignment can help businesses to optimize investments, allocate resources effectively, and ultimately drive better business results.

The Problem

We commonly see that business and engineering teams are out of sync and teams across the board are riddled with issues related to governance and/or gaps in maturity of practice. Misalignment among teams and departments often results in misunderstanding of work, conflicting goals, lack of productivity, and wasted time and effort. If you can achieve better alignment, you can tune business impact, increase operational efficiency, and drive the right outcomes faster.

Key Strategies to Employ

Software development is complex, but it’s important to build towards a holistic view of how engineering drives value. Build toward a solution that increases operational efficiency, team effectiveness, alignment, and transparency of work. Aligning the business around value helps teams collaborate more effectively and change to the needs of the business.

Pillar 3: Data-driven Decision Making

The Trend

Data-driven decision-making is essential to both engineering leadership and business alignment. It is truly the glue that binds them for business impact. By collecting and analyzing data, businesses can gain deep insights into customer behavior, market trends, and detailed business performance. These insights can be used to make informed decisions, optimize processes, and drive better business outcomes.

The Problem

It’s hard to fix what you can’t see, so that leaves organizations hyper-focused on trying to move faster, plan faster, develop faster, release faster and at scale. But, as you move faster, people, process, and technology break down. We see incomplete or missing estimates, missing context, and teams working on things not deemed a priority. This kind of breakdown points directly to data hygiene and governance issues.

Data-driven teams who leveraged Engineering Management Platforms (EMPs) saw significant improvements across the board, including a 15% increase in throughput, 17% decrease in cycle time, and a 9% increase in collaboration.

Key Strategies to Employ

For better or worse, every organization has a process and technology flow that brings them from an idea to customer value. This is called a value stream. When it is optimized through process refinement, integration, and waste reduction, value flows faster. A key component in doing so is applying data to the value stream. Cprime’s analytics and data management services allow businesses to collect, analyze, and use data to make informed decisions. By leveraging data to drive decision-making, businesses can identify areas for improvement and ultimately achieve better outcomes.

Engineering Leadership in 2023

Ultimately, the key findings from the report all point towards a singular goal: driving better business outcomes through effective engineering management practices. As businesses continue to navigate an ever-evolving landscape of technology modernization and digital transformation, the need for reliable solutions integrators has become increasingly important. A solutions integrator like Cprime can help streamline operations, optimize processes, and achieve more lofty business goals.

About Jellyfish

Jellyfish is the leading Engineering Management Platform that enables engineering teams to align their work with strategic business objectives. By analyzing engineering signals and contextual business data, Jellyfish provides complete visibility into engineering organizations, the work they do, and how they operate. Companies like Mastercard, Priceline, Zoominfo, and Pagerduty use Jellyfish to maximize the business impact of engineering.

For more information about us, visit jellyfish.co

At the time of this writing, which is early-2023, Scaled Agile Framework® (SAFe) remains the most popular framework in use around the world for scaling Agile teams. Despite its popularity, SAFe is not perfect by any means—no framework is perfect for every situation.

One of the missing components of SAFe is a prescribed approach to handling unplanned work, which is likely a common occurrence for any organization attempting to adapt to an increasingly dynamic business environment. While SAFe does not provide specific guidance on how to manage unexpected surprises, there are a few elements within the framework that you can leverage to reduce the negative effects of such situations.

What is “Unplanned Work”?

Before we explore options to manage unplanned work using SAFe, it’s important to first clarify what “unplanned work” means.

For this discussion, let’s assume that “unplanned work” is equivalent to new requirements that have arisen during execution of a Program Increment (PI) that was identified by stakeholders and/or driven by unforeseen business conditions. In this context, “unplanned work” does not include “discovered” work—specific tasks that the team identifies throughout the PI that needs to be done to fulfill a previously planned Feature or Capability. While the techniques used to address either scenario may be similar, for simplicity, we’ll focus on the former definition.

What Does Success Look Like?

The ability to manage change effectively is key to any Agile initiative. Whether you are adopting SAFe or not, your team must be able to handle unexpected events gracefully  to deliver on your commitments. So, what does “success” mean in this context?

Successful management of unplanned events typically translates to effective delivery of value despite changes in the business environment, which could originate from customer or competitor behavior. Hence, if your team is effective in handling changes in their backlog, you will be able to maximize your chances of successfully meeting the PI Objectives and business goals.

Techniques for Dealing With Change

If your team is applying SAFe, there is limited guidance to assist you in managing changes in requirements. However, if you explore some of the guidance more closely, you will fine some hidden tips that can help you.

Keep an Eye on the Amount of Change With Requirements Volatility

One of the keys to managing changing requirements is to establish and maintain a metric that you may not have heard of: Requirements Volatility. This metric is similar to predictability, but is a leading indicator that enables your Agile Release Train (ART) to keep an eye on the amount of change that occurs within your requirements.

SAFe has several backlogs for maintaining and managing work at various levels, with the Portfolio Backlog at the top of the hierarchy. Most teams that are operating Portfolio-level SAFe will leverage this backlog to manage the high-level business requirements, usually stated in the form of business cases or initiatives. Since this backlog, as with all the other backlogs, is intended to be organic and continuously evolving, it is often difficult to understand the amount of change that is occurring, since there is no “baseline” or “freeze period” that takes place. This means that in order to deploy a metric like Requirements Volatility, you have to take a snapshot in time at regular intervals in order to assess the level of change.

Measuring Volatility

When might be the right intervals to take snapshots? As I mentioned previously, SAFe does not provide any guidance on this, but one approach that I have observed to be effective is to take a measurement at PI boundaries (at minimum) in order to evaluate how much change has occurred within the backlog. This will enable you to determine how many new requirements/epics have been introduced within that period of time.

If you are experiencing significant shifts in priorities within your PI, you may want to take the same measurement at the Program level (within the Program backlog). You could also do the same for the Team-level backlog as well if you observe massive changes in requirements, which is both undesirable and potentially destructive to your ART.

While there will likely be a cost associated with measuring and tracking volatility of requirements, you may observe trends that could alter how work is introduced and/or prioritized, which is an important factor that could dictate the effectiveness of the ART.

Applying Capacity Allocation to Handle Unexpected Change

Another technique that you may consider for managing requirements is Capacity Allocation of your backlogs. Within the backlog at each level of SAFe, you can determine how to organize and plan your work to ensure an optimal balance between Enablers, Features, and Technical Debt. This helps you deliver short-term value and foundational infrastructure to prepare for longer-term functionality that you will need in the future.

One method you could explore is to encourage your teams to only plan up to 80 percent of maximum capacity in order to provide a buffer for expected changes in requirements; if your stakeholders have a tendency to change priorities frequently or unexpectedly, having the extra capacity to address these situations can improve your teams’ ability to continue delivering valuable system capabilities.

One recommendation in this situation is to continue educating your customers and stakeholders about requirements management; help them understand that constant change is not ideal and potentially damaging. Even if your team can deal with this effectively, it is ‌not sustainable and not good for morale.

Closing Thoughts

While we all know that change is inevitable and should be embraced, there is no perfect system for dealing with unplanned work. A significant contributor to how we experience change is our relationships—our level of collaboration with the customers, stakeholders, and our teams is ultimately what will determine the outcomes of any project.

So, if you are in a situation where things aren’t going as expected, try to experiment with some techniques I shared and encourage the team to come up with new ideas as well.

And, if you need more advice or guidance from an Agile expert, download our white paper, Using Lean-Agile Principles to Execute Organizational Transformations, or explore our SAFe coaching and consulting solutions.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

It is painful to watch how some enterprises treat the Scrum Master role like a commodity: Scrum Masters are all the same and easily exchangeable. A generic input and an expense to be reduced. They are often treated more as administrators and scribes than as critical enablers for delivering superior economic outcomes. As a result, the Scrum Master role is often viewed as a dead-end with no growth opportunity.

The Commodity Attitude and Agility

This commodity attitude is tragic for the individual laboring under this mindset and economically limiting for the enterprise. This mindset robs the enterprise of the Scrum Master’s and one of Agile’s fundamental value propositions: superior economic outcomes through our way of working.

The Agile Manifesto’s first declaration, “Individuals and interactions over processes and tools”, calls out the dramatic influence our ways of working together have on outcomes.

From study after study—from Scottish coal miners in the 1950s to NUMMI, the joint Toyota-GM venture in the 1980s, and even on nuclear submarines—we have learned that a key determinant to successful outcomes is how people work together.

This is Why I Am in This Crazy Agile Coaching/Mentoring Business

Years ago, I believed that to deliver great products, you just assembled raw engineering talent and then got out of the way. My eyes would roll up whenever our leadership talked about methodology and practices.

I could not have been more wrong.

After quite a few hard lessons and some mentoring from the CEO of an amazing startup—Ken Spencer of Creo Products—I learned firsthand how people work together is an outsized driver of economic outcomes. Alistair Cockburn succinctly summed this up in his quip “People trump process.”

Agile as a Competitive Advantage

In most Agile frameworks, the Scrum Master role is primarily concerned with the team’s way of working. When we treat our Scrum Masters as commodities—interchangeable and as a cost to be reduced—we are demonstrating that we do not regard our way of working as a competitive advantage.

Unfortunately, commodity cultures struggle with sensing and responding to opportunities and threats in a volatile, uncertain, complex, and ambiguous (VUCA) world. Commodity cultures find it hard to exploit change for economic benefit.

So, if we believe our way of working is a competitive advantage, then how do we de-commodify the Scrum Master role and acknowledge the value this role brings?

Six Guidelines for De-Commodifying the Scrum Master

Here are six guidelines for de-commodifying the Scrum Master role and turning it into a contributor to Agile success:

1. Understanding What the Scrum Master’s Role IS NOT

First, let’s be perfectly clear, the Scrum Master is not an administrator putting meetings on people’s calendars. They are not a scribe taking notes from those meetings to present to a project manager. And most certainly, they are not a project manager assigning and dictating tasks to the team.

2. Understanding What the Scrum Master’s Role IS

Their job is helping the team be a team and not a group of people who happen to work together. Their job is to help them discover their greatness as a team. Yes, I know this sounds fuzzy, but after being in this industry for nearly 40 years, I have discovered one truth: the fuzzy stuff drives economic outcomes.

Orgs must acknowledge that the Scrum Master role is primarily a coaching role. In fact, I like to say their job is to put me (an Agile coach) out of a job. Coaching is an intimate relationship with a team and is very much influenced by personality types. An individual who is a rock star with one team could fall flat with another. A team should be able to interview their Scrum Master, even if it is a team member who is being considered for the role.

3. Position the Scrum Master Role as an Opportunity for Advancement

Third, the Scrum master role must be seen as an opportunity to advance one’s career by developing strong facilitation and coaching skills. These are essential skills for anyone seeking a leadership role in an enterprise regardless of whether they see themselves as a manager or a senior engineer. Leaders must learn it’s not about making themselves appear great but about making others great.

The Scrum Master role is an excellent gateway to developing those skills. Contract Scrum Masters bring valuable new skills into the enterprise and can help start an organization on their Agile journey by mentoring and coaching internal Scrum Masters. However, to truly grow an agile organization, the Scrum Master role should be performed by someone who desires to grow their career with the enterprise.

4. Acknowledge That the Scrum Master is Not Always a Full-Time Role

Fourth, the Scrum Master role should not be a full-time job description.

A newly formed team may need full-time coaching to help them speed up their journey through the Tuckman curve (forming, storming, norming, and performing). However, as the team begins to function as a team, the direct coaching demands of the Scrum Master will diminish.

Personally, I prefer an appropriate team member who has leadership aspirations to receive 50% release time from their regular responsibilities to fulfill this role. Other enterprises may have a Scrum Master facilitate multiple teams.

5. Delegate the Running of the Team to the Scrum Master and Their Team

Fifth, delegate ownership of the team’s way of working to the Scrum Masters and their team.

Far too many enterprises are obsessed with “maturity,” which is often code for rigid compliance to some centrally defined framework or methodology. This compliance mindset impedes relentless improvement. Agile is about sensing and responding to change, and the way of working must also sense and respond to change. Practices introduced by Agile frameworks are a good starting point but were never intended to be a methodological straight jacket. After all, why do we have retrospectives if not to improve our way of working?

A discipline of “improvement experiments” can serve as an important guardrail on the evolution of the teams’ way of working. Most importantly, when the team owns their way of working, they will need time and space to focus collectively on improving their way of working. It’s not going to happen “after hours”.

6. Set Up a Support System for the Scrum Master

Finally, don’t let the Scrum Masters stand alone. Set up a supporting ecosystem for the Scrum Masters to share, learn, and improve together.

Do this by establishing a Scrum Master community of practices (CoP). The CoP becomes the focal point for mutual support and collectively driving improvement. During practice meetings, Scrum Masters can seek advice and share their experiences. A simple mantra we have for the Scrum Master CoP is, “we’ve got your back!” Through the CoP, Scrum Masters can drive improvement by sharing the results of improvement stories and deciding on improvement stories to add to their respective backlogs.

How an enterprise treats its Scrum Masters is a barometer of the value it places on its way of working.

• Are the Scrum Masters seen as valuable drivers and contributors to relentlessly improving outcomes, or are they seen as just another commodity and all the same and interchangeable?
• Do they foster team growth or is their job to perform administrative and reporting tasks for the team?
• Is their role to actively drive process improvement or to enforce compliance with fossilized standard operating procedures and practices?

How we answer these questions is the difference between “doing Agile” and being agile.

This is the third in a three-part series of articles covering the POETIC Leadership approach to Lean-Agile leadership, authored by Alex Gray, a Lean Agile Practice Lead at Cprime. Click below to visit Parts One and Two:

• Part One: Personal and Organizational
• Part Two: Emotional and Team Thinking

In the first article of this series, we discussed why organizations that wish to employ Lean-Agile methods must promote a culture that supports that way of working. And, we began discussing what that culture looks like and how they can develop it—first on a personal level, then organizationally. In the second, we covered why emotional intelligence is vital for Lean-Agile leaders, and the value of instilling team thinking into the organization.

We recommend reviewing both articles first, if you haven’t already, to get some context for what we’ll be discussing in this article: the Intelligent and Curious components of the POETIC Leadership model.

I – Intelligent

Of course, an effective leader must act intelligently. That should go without saying, but it’s not always a primary concern when people are hired or promoted. To be successful in a Lean-Agile environment, POETIC Leaders must have a sufficient IQ to support continuous learning, a solid grasp of Lean-Agile values and principles, strong domain knowledge to support the teams’ efforts, and the ability to utilize this intelligence when making business decisions.

IQ

Intelligent leaders need to have a good general IQ. Importantly, they don’t need to have a high IQ to be effective. It certainly can be helpful in a lot of situations, but there are also many other factors that are equally or more important for leadership success.

The main reason an adequate IQ is beneficial for leaders is because it means they will be able to absorb and retain vital information, and apply what they’ve learned to new situations and necessary decisions as they arise.

Lean-Agile Values and Principles

Intelligent leaders develop a solid understanding of Lean-Agile principles because they recognize these principles will help their organizations become more efficient, responsive, and innovative.

Lean is a philosophy and set of principles that focuses on maximizing value and minimizing waste across the organization. Agile is a framework for managing product, development, and teams. It’s based upon the idea of iterative and incremental development where teams work in short cycles or time boxes to deliver small high quality increments of a product or service together.

Lean-Agile principles can help leaders in many ways. For example, they can:

• Improve efficiency and productivity by reducing waste and streamlining processes
• Increase customer satisfaction by providing higher-quality products and services
• Foster a culture of innovation and continuous improvement by encouraging experimentation and learning
• Enhance team collaboration and communication by promoting transparency and flexibility
• Increase agility and adaptability, allowing organizations to respond quickly to changing market conditions and customer needs.

Overall, understanding Lean-Agile principles is very valuable for leaders who want to help their organizations become more effective and competitive.

Domain and Technological Knowledge

Having domain knowledge means having a deep understanding of the industry or field in which the organization operates, as well as the specific skills needed and functions performed by the teams under the leader’s authority. This can help leaders make informed decisions, anticipate trends and challenges, and stay ahead of the competition.

For example, a leader in the technology industry needs to understand the latest developments in software, hardware, and networking in order to make strategic decisions about the direction of the company.

Having technological knowledge, on the other hand, means having a general understanding of the latest technologies and how they can be applied to improve business operations. This can help leaders identify and implement new technologies that can drive innovation, increase efficiency, and improve customer satisfaction.

For example, a leader in the retail industry may need to understand the potential benefits and challenges of using artificial intelligence, blockchain, or the Internet of Things in order to make informed decisions about the company’s technology strategy.

Overall, having both domain knowledge and technological knowledge is crucial for leaders who want to be effective and successful in today’s dynamic business environment. It allows them to make informed and strategic decisions that can help their organizations stay competitive and achieve their goals.

Business Decision Making

Making effective business decisions is a crucial part of leadership. Leaders are often responsible for analyzing complex information, identifying key issues and challenges, and choosing the best course of action to achieve the organization’s goals.

To make good business decisions, leaders need to have a combination of skills and abilities. For example, they may need to be able to:

• Analyze data and information to identify trends, patterns, and opportunities
• Understand the organization’s mission, vision, and values, and align decision making with these principles
• Consider the potential risks and benefits of different courses of action
• Communicate clearly and effectively with others to gather input, provide information, and build consensus
• Make difficult decisions in a timely and confident manner, even when there is uncertainty or disagreement

In the end, the purpose of all the other aspects of Intelligence is to support making effective business decisions that will benefit the organization.

C – Curious

The final aspect of being a POETIC leader is to be curious. This quality works hand-in-hand with intelligence to support a continuous learning culture in the organization, and an environment that values exploration, experimentation, and innovation. All of these qualities, in turn, support the principle of continuous improvement, which is at the heart of Lean-Agile values.

Exploring

Curious leaders are constantly searching for new information, new experiences, and new perspectives. They are often driven by a strong desire to learn and understand the world around them.

As a result, they will remain on top of industry trends, new advancements or best practices that can be applied to the business decisions they make.

Without this quality, leaders can quickly stagnate, halting their teams’ progress as well.

Experimental

Curious leaders embed an experimental mindset in their organization—a culture of forming hypotheses, designing experiments, and evaluating the data from the experiment. The results of the experiments can inform future design, strategies and products.

Experimentation is another core principle of the Lean-Agile methodology: short, iterative production combined with a strong feedback loop supports continuous improvement in both the quality of the product and the efficiency of the process.

Encouraging experimentation relies heavily on the psychological safety we discussed previously because team members—and the leader themselves—need to feel comfortable with taking calculated risks and potentially making mistakes in the name of improvement.

Innovation

Closely related to experimentation is the idea of innovation, which is vital to organizational success in today’s lightning-fast competitive environment.

Curious leaders are open-minded and receptive to new ideas and feedback; they’re not afraid to ask questions, challenge assumptions, and try new things in order to gain a deeper understanding of the situation or a problem.

This can often help them identify and solve complex challenges and come up with creative and innovative solutions. And it can often allow them to enable their teams to be creative and come up with innovative solutions. Curious leaders often:

• Identify and prioritize opportunities for innovation, based on the organization’s goals and the market environment
• Communicate a clear vision and strategy for innovation, and align the organization’s resources and efforts towards achieving it
• Encourage and support experimentation and risk-taking, and provide the necessary resources and support to enable innovation to flourish
• Foster a culture of collaboration, communication, and continuous learning, and provide opportunities for team members to develop their skills and knowledge
• Monitor and manage the progress of innovation initiatives, and make adjustments as needed to ensure their success

Learning and the Growth Mindset

Curious leaders are lifelong learners who constantly seek new opportunities to learn and grow. They might be interested in a wide range of subjects—from their own industry or field, to the arts, the sciences, and many other disciplines. This allows them to bring diverse and well rounded perspectives to their leadership role. And, it encourages their teams to follow that example, promoting a growth mindset.

Teams permeated by a growth mindset believe that they can improve and develop their skills and abilities through effort and learning. They see challenges as opportunities to grow and learn, rather than as threats or setbacks. This approach helps leaders stay open to new ideas and approaches, and enables them to adapt and respond effectively to changing circumstances.

Having a growth mindset can also help leaders foster a culture of continuous learning and improvement within their team or organization. By modeling a growth mindset themselves, leaders can inspire others to adopt this perspective and approach to their work. This can lead to a more innovative and adaptable team or organization, which can be better equipped to meet the challenges and opportunities of an ever-changing world.

Gemba

Curious leaders often want to go and experience what’s really happening in the world and the workplace for themselves.

A great technique for curious leaders is gemba, a Japanese term that means “the place” where value is created and work is done. For leaders it is the practice of going to the ‘gemba’ to observe and understand the work processes and identify opportunities for improvement.

Gemba is not about getting status updates. By going to the gemba and seeing firsthand how work is being done, leaders can gain valuable insights into the strengths and weaknesses of the current process and identify opportunities for streamlining, efficiency, and continuous improvement.

Additionally, going to the gemba can help Agile leaders build trust and credibility with their teams by showing that they are willing to roll up their sleeves and get involved. Overall, going to the Gemba is an important part of being an effective Agile leader.

Summary

To lead Lean-Agile organizations, the culture leaders create is the most valuable thing they can work on.

In this article, we have summarized some of the key techniques and practices for Lean-Agile leaders to be aware of: POETIC Leadership. Not all leaders will be great at everything. But making sure they have a good balance of all six aspects will build a strong foundation for success.

How POETIC are you?

To better understand these concepts and support your and your organization’s leadership abilities, explore our value-based, experiential learning courses for leadership development.