Jun 3, 2019

A colleague suggested I write this article, and I quickly agreed, thinking to myself, “No sweat! There are so many little things that can make a big difference. I can type this out in no time.”

Now pause. Go back and review that last thought. Do you see a flaw in my logic here? “There are so many little things…I can type this out in no time.” Did I really think a long list of things would make this task any easier? That it would make the writing process fly by?

It took me three weeks to write this article. The fact that there are so many small changes that can have a huge impact on a SAFe® Transformation made my heart beat a little faster every time I thought about it. I kept putting my thoughts down and picking them up again, and the list kept growing and growing.

Fortunately, the solution to my problem and the organizational transformation problem above are the same: put on your Product Thinking Cap and prioritize ruthlessly, coming up with a short, doable list of the most important things that can make the greatest impact. Your list doesn’t have to be perfect or comprehensive, but as you focus on small efforts with the biggest impact, you will begin to move forward in the right direction.

Below are my Top 5 suggestions for little changes that will make a big difference in your SAFe Transformation. It’s my belief that these practices go a long way to energize all Agile Transformations at any level, from team adoption to global enterprise transformation. There are nuances, but the principles remain the same.

1. Emphasize Mindset over Toolset

There’s a reason why the Scaled Agile Framework^® (SAFe) training classes emphasize Values and Principles at the very beginning. They describe a mindset that is essential to scaling agility within an enterprise environment. Without the right Lean-Agile Mindset, a SAFe Transformation is often ineffective, despite all the great tools included. As I often say, “The mindset fuels the toolset!”

What is the difference between a toolset and a mindset? A toolset is a toolbox of practices that can be used to implement a solution. Scrum, Kanban, XP, and SAFe are all frameworks and/or collections of practices that can be pulled out of an Agile toolbox. A mindset is your understanding; the key to knowing which is the right tool for the job. I can use a screwdriver to beat a nail into a piece of wood, but it takes understanding to know I’d be better off using a hammer.

Just like carpenters who apprentice under a master gain an accelerated understanding of woodworking, SAFe Teams and Senior Leaders who train with a deeply experienced coach gain an accelerated understanding of SAFe. As a SAFe Program Consultant (SPC) and Agile coach, I train people on how to use various toolsets, but more importantly, I help others to develop the Lean-Agile Mindset, which isn’t immediately intuitive and often doesn’t become real until several iterations into the application of a new framework. As teachable moments materialize, I look for opportunities to tie values or principles to the problem being solved, reinforcing Lean-Agile thinking.

So often, people want to do Agile without being Agile. In essence, they want to implement the practices without changing the way they think. Someone will ask how to do something (usually in an email, text, or IM) without context for the problem being solved. Typically, a quick response without a conversation can create more harm than good. Context and understanding are critical when using any of the tools in the Agile toolbox.

If your organization can’t embrace the Lean-Agile Mindset, then you will not have a sustainable SAFe Transformation. Remember—the mindset fuels the toolset! There’s a saying in the martial arts: Learn the way, then make your own way. Once the new way of working transforms how you think and becomes part of you, only then can you truly start to walk down the path of Agility.

2. Model Agility – Be Agile as You Do Agile

When leading a SAFe Transformation, it’s so important that your behavior models the values and principles found in the Agile Manifesto and SAFe. Start by leading yourself first. For example, if you want to encourage others to be fearless, then act fearless, choosing to be motivated by joy and enduring hardship without losing your cool. If you want to encourage collaboration, then collaborate rather than dictate.

Try not to fall into Command and Control Management, the traditional “do as I say and not as I do” style of leadership that creates fear, confusion and inhibits transparency. This approach discourages the self-organization necessary for SAFe and other Agile frameworks.

There are times in a transformation where it is appropriate to take a prescriptive approach (see SAFe Principle #9), but the goal is to move toward a facilitator role and become a Servant-Leader. Maximize the capabilities of your team by empowering them. Ask thought-provoking questions and provide goals without giving directions. By allowing your teams to think and act for themselves, they will develop their own leadership skills.

An impactful SAFe transformation leader understands that Agility is a journey and not a destination. You and your team may find yourself slipping into the comfortable old ways of Command and Control and order-taking. Rather than becoming discouraged, reinvigorate your Lean-Agile Mindset by acknowledging what happened, and then demonstrate relentless self-improvement by retrospecting how you will act in the future. As you do, you will be able to respectfully pull others back onto the path of Agility. Doesn’t this sound like a healthier approach than the fruitless criticism of a person’s inability to transform?

3. Define the Minimum Viable Transformation (MVT)

In some cases, launching a train and walking through a Program Increment (PI) might be enough. In other instances, mentoring over a longer period may be necessary to achieve the desired goal. First you have to ask yourself, “What are the goals or desired outcomes of this transformation?” Doing without understanding is NOT the behavior of a Lean-Agilist, so defining an MVP and hypothesizing benefits should be part of your transformation. The decision to persevere or pivot should be evaluated throughout the transformation and as understanding grows, a new MVT may be established.

4. Engage Leadership; Don’t Just Inform Them

As you move the down path of transformation, having described an MVT and hypothesized benefits, who can validate that you are going down the right path? And if the MVT changes or your hypotheses produce unexpected results, then who can make the decision to either persevere or pivot?

Business leaders often expect they can step out of the way once they’ve engaged someone to lead an organizational change, but expectations for their role need to be made early and repeatedly in a SAFe Transformation. They can’t simply be informed of the progress; they need to understand how their role plays a critical part in the organizational change.

Leadership requests and behaviors can either reinforce or weaken transformation efforts. For example, holding individuals accountable rather than teams will lead to command and control behaviors and other anti-patterns. This is especially true when holding individuals accountable for metrics.

Metrics are neither goals, nor accomplishments. As the Agile Manifesto eloquently states, working software is our primary measure of success. Metrics can be gamed and used to cloud the real issues, or they can shed light on how to help and improve teams. Encourage your leaders to find the context for those metrics. If leadership places an emphasis on metrics themselves, their well-intentioned workers will put in the effort to have the best possible metrics. But if leaders emphasize delivery of quality software in their participation at System Demos and PI Planning events, then guess where people will focus their efforts?

The importance of good leadership in a SAFe Transformation can’t be emphasized enough. If leaders model Agility by participating and collaborating across functional areas, then their behavior will be a powerful force for the change they want to see. If they fail to model Agility and don’t motivate their teams, then the Transformation is likely to stagnate.

5. Organize for Success

So much can be said about how to organize for success, and yet the specifics are unique for every transformation. How do you know where to start? For many companies, this means bringing in an experienced external coach who will walk through the transition with you, helping you define what success looks like and how to measure it along the way. He or she will know what questions to ask, such as:

• To what extent can teams be collocated?
• Do you have the right people in the right roles?
• As the team and program ceremonies are implemented, can other redundant meetings be removed?
• Do the budgeting and portfolio management support the new way of working, or are they set up to create tension?
• Are Agile Release Trains (ARTs) aligned along Value Streams or are they siloed along technology stacks?
• Do teams and Trains know how they will respond to unplanned work requests?
• Have expectations been set with Business Partners so they know how to interact with the new working model?

An external coach (or two) can help you find answers to these questions and navigate the change. And while external coaches are certainly an enabling factor to any successful SAFe transformation, at some point, they need to remove themselves from the client’s site. The goal of any good coach is not to become a permanent fixture, but to make necessary adjustments and get out of the way. An experienced consultant energizes both internal coaches and senior leaders to renew the Lean-Agile Mindset and model agility, thereby creating a sustainable transformation that lasts long after that coach leaves the client site. In other words, they help with these 5 little activities that make a big difference in your SAFe Transformation.

How well are you doing the little things that make a big difference in your SAFe Transformation? Check in with this 10 Question Survey, which shows you how well you’re doing and offers solutions based on how you score.

Written by Mitch Malloy

 

Mitchell “Mitch” Malloy has 25+ years in the software industry. As a Coach and Mentor for 10+ years, he keeps a focus on value, an eye for excellence, and a passion for people. Since the 1990s, Mitch practiced Agile techniques while growing in his own Agile journey. He has led and participated in numerous Agile Transformations for companies of all sizes, where he has mentored others in Agile values, principles, and techniques.

 

More…

Nov 3, 2020

In this short, interactive Lean Coffee with Dean Leffingwell, the creator and co-founder of the Scaled Agile Framework^® (SAFe), Dean presents his excellent musings and chalk-talk answers on the following topics:

• Critical Success Factors for a Lean-Agile Center of Excellence and Roadmap for Organizational Agility
• Roadmap for SAFe 6.0
• The Do’s and Don’ts when implementing Lean Portfolio Management

This conversation was facilitated by Kathy Marshak, Principal Transformation Consultant, SAFe Fellow and SPCT for ICON.

Nov 4, 2020

You may be thinking, “There are companies out there with pretty poor and absent leadership. How the heck are they still around?” That’s a great question. These companies may be around for a little while, but ultimately will run into an unforgiving brick wall. Don’t take it from me. Even a casual review of authoritative writing will quickly establish that great leadership is key for organizations to succeed and thrive.

As I help companies in their agile transformations, I get to see leadership (or the lack thereof) up close. There is a significant difference between leadership being present vs. absent. Organizations with involved servant leaders are the ones who successfully transform themselves into Lean-Agile organizations. As leaders put the needs of their employees first, people start to love their work and in turn drive tons of value for customers.

An example of great servant leadership

I’m going to share the story of the first time I experienced great servant leadership. It happened around 2 in the morning. I was a young Air Force airman in the middle of a stressful Operational Readiness (“OR”) exercise, in which our entire Air Force air wing had to prove it was able to perform its primary mission in the event of war. We had flunked our previous OR, and it sucked. Full colonels had been fired, and the new leadership had ratcheted up our work hours, the intensity, and anything else that stressed us out.

Everyone up and down the rank structure was on edge. We were cautious, risk-averse, and did everything by the book because inspectors were evaluating us. We were always under pressure to perform, not to mention we were in a situation where several colonels could mess up and all of us would pay the price.

Anyway, it was 2 AM in the Life Support shop where I was working, and we were having a heck of a time getting our trucks to deliver survival equipment to airplanes about to launch. Security personnel on the flight line were understandably nervous about having even a minor security incident, so they checked and double-checked everything. They got so backed up that it became impossible for people to access the flight line, including people who were well-known and normally had easy access.

Personal recognition is a valid way to identify someone as being authorized. Even though the security personnel knew some of us well, they ignored this fact and still went by the book, checking our credentials and each truck up and down. What should have been quick deliveries turned into late ones. There was a lot of unnecessary waste in this process. Security still could’ve been highly secure by smartly applying when to be precise and when to be somewhat accommodating.

Everyone became stressed and angry. Even though we busted our butts, we would likely end up with a poor rating because we couldn’t get the equipment to the airplanes. We were in the shop lamenting our woes, when Colonel B, our Director of Operations, strolled in. After the wing commander, Colonel B was the most important decision maker in our wing. He was intimidating, with a reputation of being impatient with people who didn’t know their stuff. All of us nervously stood at attention. (You may not know this, but for a low ranking enlisted guy like me, a “full colonel” was a big deal, someone only a few degrees removed from God. So us low ranking peons were really nervous.)

Colonel B, however, was jovial and curious. He looked at us and said, “You know who I am and what I can do. So tell me right now—what I can do to make your lives easier? How can I help you do better on this exercise?”

We were flabbergasted and didn’t know what to say. Thankfully, one of our NCOs mustered the courage to speak up about the trouble we’d been having with security on the flight line. Colonel B pulled out his brick (radio), talked to his counterpart in charge of security, exchanged some pleasantries and then quickly got down to business. “We have some issues with your guys on the flight line. Can you help me fix them?”

And just like that, an intractable impediment instantly dissolved. The number two guy in our wing drove around all night, using his rank and stature to quickly resolve issues none of us had the power to solve. He did not bark out orders. Instead, he listened to what his people had to say and used their knowledge to make informed decisions.

What can we learn from a great servant leader?

This may seem like a simplistic example, but it was servant leadership at its finest. Rather than asking for updates and status reports, Colonel B was present and with us “in the trenches.” He removed obstacles to empower low ranking people like me to do our jobs. His actions became the stuff of legends. “Remember when Colonel B showed up at 2 AM? We should have asked for so much more!”

A great servant leader is there through all the BS so you can remain focused on what you’re good at. Furthermore, they trust you to do your job to the best of your ability. This trust, in turn, motivates you to be your best and excel. When a hard-charging leader has your back, it’s easier to take risks, to step out of your comfort zone and try new things. It’s how innovation happens.

A great servant leader isn’t necessarily your buddy, just ask the people who worked for Steve Jobs. But they show up when it counts and work with you. They have high standards and may expect you to work hard, but they’re also fair and realistic. A great leader practices Gemba, walking around and meeting people where they work.

A leader who says things like “I don’t care, just get it done,” leaves you with a bad taste in your mouth because they’re unfair and unhelpful. When I became an officer, I wanted to prepare myself to surpass mediocrity and grow into a great servant leader. The lesson I learned from Colonel B at 2 AM left an indelible impression on me; I try to emulate his behavior. That’s the other thing about great leaders—they leave a lasting impression; one you want to emulate so that you might also become a great leader, not for the people you lead, but for the people who choose to follow you and that you, in turn, serve to the best of your abilities.

Written by Rodger Koopman

 

With over 30 years in technology, Rodger started his career as an Air Force officer developing weapons guidance systems and global terrestrial & satellite networks, working strategically in counter-terrorism at the joint DoD level. After retiring from the Air Force, Rodger was an early employee in two successful start-ups and a key participant in five mergers & acquisitions. When Itron acquired Rodger’s first startup, he was tasked by Itron’s CEO to move to Raleigh, NC to lead and re-organize Itron’s R&D office. Rodger has led numerous successful implementations of highly effective Agile practices and automated DevOps pipelines in both startups and multiple Fortune 100 companies. Now an Enterprise Coach, Rodger is a certified SAFe 4.6 Program & DevOps Consultant (SPC, SPD) and certified AgilityHealth Facilitator.

 

More…

Feb 17, 2020

As your organization begins its DevOps transformation, you may become preoccupied with automation, forgetting that there are other DevOps concepts to address in your environment. The Scaled Agile Framework® references CALMR (Culture, Automation, Lean Flow, Metrics, Risk & Recovery) to highlight the importance of more than automation in DevOps. In this article, we’ll address the other concepts to keep in mind while on the DevOps journey.

Culture

The evolution to a shared responsibility for delivering value fast across the entire Value Stream is different for every company. The journey each company makes is specific to them and their own challenges. Their mindset change is unique. The development and operations teams need to design a better approach together; however, all need to acknowledge that the process must continuously change and improve. The silos must come down and responsibilities must be shared.

The importance of resource investment can’t be overstated. Adding Operations team-members to agile teams will encourage sharing of knowledge and insight. Training on the new automation tools will accelerate adoption and success.

Acknowledgement that new tools are required along with identical test and production environments is critical. The cost of having identical environments prohibits many companies from achieving successful automation; however, the cost of unstable environments and/or the cost of the time to troubleshoot bugs due to different configurations far outweighs the cost of the identical environments. Stop the fight and just provision identical environments. This step alone is crucial to changing the perception of DevOps in your organization. If features are successfully demonstrated at the end of sprints but result in bugs in production, then the culprit is probably a difference in the environments.

Also, partnerships with InfoSec will result with all deploys going through the security checks regardless of batch size (or batch criticality), which may not have been the case in the past.

Effort is required to mature the organization to embrace and champion DevOps.

Lean Flow

In the past, prior to agile, we’ve seen application developers write hundreds or thousands of lines of code over multiple months before passing the code to the Operations team to deploy. Even agile teams, without DevOps, could have complex and intrusive deploys. The focus for a successful DevOps environment is to have small deploys. Smaller deploys ensures less intrusive changes. A shorter batch window results in more frequent deploys. DevOps encourages smaller batches and more frequent deploys to ensure a lean flow. Teams need to rethink what they include in their deploy packages; the smaller, the better.

Metrics

DevOps is not a one-and-done proposition. Constant evaluation and improvement is foundational within agile; DevOps is not an exception. From the inception of your DevOps journey, it’s important to have metrics and measures in place so improvements can be recognized, evaluated, and celebrated.

In one company I worked with, we were able to shorten a 6-week environment-provisioning process to less than 5 minutes. Without gathering the base metrics upfront, we would not have been able to measure our progress. It took time, and the culture was greatly impacted, but it wasn’t the end of the journey. We continued to look for further improvements. We continued to ask ourselves what else we could automate. DevOps, as with agile, is about constant change and improvement. Monitoring and optimization is almost real-time.

As with all parts of Agile, transparency is paramount to success. DevOps will require many test-and-learn iterations; sharing the successes and failures will communicate progress and ensure buy-in. Showing the metrics will help demonstrate the maturity of DevOps in the organization.

Risk and Recovery

To succeed with DevOps, your organization will need to develop a tolerance of failure and rapid recovery. Since DevOps is designed to deploy small pieces of code quickly and automatically, it also automates backing out those changes. Instead of multi-hour downtime to implement a huge package of code and then multi-hour recovery time if the code doesn’t work, DevOps quickly deploys smaller packages, automatically validates the code, and—if necessary—has a small, quick backout procedure.

In Conclusion …

To fully recognize the benefits of agile, every company needs to begin the DevOps journey…and every company will uncover challenges along the way. These challenges come from many different parts of the company and may show themselves in different ways. It may be an agile team not embracing the new tools, or the business not approving the funding for a robust test environment, or InfoSec not approving the automated solution. However these challenges present themselves, it’s important to spend time upfront uncovering areas of resistance and the root causes. DevOps takes time, effort, and persistence—automation is the easy part.

You need the DevOps benefits: to innovate faster, to be more responsive to the business needs, to see better collaboration, to experience better quality, and to have more frequent releases. The effort needed to adopt DevOps is worth the journey.

Written by Cathy McGraw

 

Cathy has 25+ years of experience in Application Development as a Software Engineer, Director of Application Development, and Scaled Agile Coach. As her career progressed, Cathy recognized her passion to help people and organizations mature in their careers and Agile journeys, and so for the last 10 years, she has been practicing and coaching Agile. As a SAFe-certified SPC, POPM, and SDP (DevOps) professional, Cathy has helped multiple companies initiate and deploy their Agile and DevOps practices. She has worked in numerous industries, including manufacturing, logistics, insurance, software development, broadcasting, utilities, and retail, where she has provided coaching and training for teams and executives.

 

More…

Dec 5, 2019

As a coach who helps implement Agile and the Scaled Agile Framework® (SAFe), I’ve encountered many organizations where the product development teams (software and otherwise) are not immediately sold on Agile change. Agile tends to appeal more to the business side, less so to the ones doing the work. Why is this?

The first two principles of the Agile Manifesto offer clarity. The first principle states, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Both management and development teams can agree that this is a good goal. So what’s the problem—what makes teams wary?

It’s the second principle that draws their skepticism. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

While everyone can get on board with satisfying customers, the second principle goes against everything that teams have ever learned in traditional software development, or any work being done, for that matter. Welcome changes late in development? “A sure-fire way to cause delays,” rationalizes the traditional mindset. “Late changes mean long hours and working weekends. Cancelling vacations and not being with the family. Forget leisure time!”

In the beginning, it’s typical for teams to conclude that Agile is not their friend. So what can you do to change their minds? How do you convince teams that Agile is not just another way of squeezing the last drop of work out of the staff?

In this article, I will reference Agile Principle #5 as the key to fostering healthy, productive Agile teams. I’ll walk you through it step by step while offering suggestions based on the practical application of this principle. The goal is to create a win-win for everyone, including business leaders, the organization, the coaches, the customers, and—most importantly—the teams.

How do you get Agile Teams to care? See Principle #5.

Agile Principle #5 states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Let’s unpack this. The first sentence refers to “motivated individuals.” You may be wondering where you are going to find these “motivated individuals” so you can replace all the disgruntled malcontents that are currently on the team.

Remember, these people were interviewed and hired by leadership based on their background and experience. They must have held at least a sliver of promise, because out of all other candidates, they were the ones chosen. If they weren’t competent, then they would’ve been dealt with before now. All they need is for someone or something to unlock their intrinsic motivation. You could be the one to help with this.

Now that we assume that no new staffing is required, let’s look at the next sentence. “Give [teams] the environment and support they need, and trust them to get the job done.”

This sentence contains the three areas that you must address to get the teams to care:

1. Environment
2. Support
3. Trust

The more you focus on improving these areas, the more excited your teams will be to work, not to mention more willing to make changes late in development. Let’s dive into each area—what can you do to get the teams to care?

1. Provide an Environment of Experimentation and Continuous Learning

The team has the experience and background to best serve your needs. You can’t find a group of people more ready to do the work. So how do you provide an environment that is innovative but fun?

Start by creating an environment where experimentation is encouraged and praised. Remember that the team you have is the most qualified to determine how they should approach the work—not management, not the business owners. After all, the team is the closest to the work and the problems. If you allow them the freedom to experiment with new ideas and new solutions, then they will likely increase product value.

The team might get discouraged when a new idea does not turn out to be an improvement. Compliment them for trying. Point out that they’ve learned something to enhance their judgement going forward, even if that idea was a bust. An environment of learning and experimenting is the key to innovation. The team will occasionally get it wrong, but more often they will get it right, because they are the experts closest to the work.

When something does go wrong, please don’t fire them! Once, at a former client, I was attending a team’s morning standup when the Product Owner solemnly said, “Bob will no longer be part of the team. He made a terrible mistake yesterday while rehosting a virtual server. His mistake lost some customer data.”

The team fell silent, and the PO said, “Let that be a lesson to us all.”

I am positive that each team member took away a lesson from that standup, but was it the right one? Death of experimentation and therefore innovation? Fear became the first consideration for every team member. You do not want to support this kind of environment.

General George S. Patton said, “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.” Quite a sentiment coming from one of the most successful generals in World War II!

2. Offer Support Using Empathy, Encouragement, and Feedback

Next, provide the team with support. Listening to them is first and foremost. Ask them:

• What struggles are you facing?
• Can I help by removing impediments?
• Can I support you in your dealings with other parts of the organization?

When you give them your undivided attention and then act on what they’re telling you, they become much more willing to go out on a limb for you.

The other way to support the team is to provide them with prioritized work and quick feedback. This enables the team to do work that is truly valuable to their stakeholders and customers. Attention from stakeholders fires up the team and inspires them like nothing else. They feel that their work is valuable to the organization, because they hear it directly from the company leaders.

3. Trust the Team to Get the Job Done

Trust is the glue that holds everything together. The team needs to feel the organization’s confidence in their capability to do the work. This goes back to environment. Do you have a strong command and control culture where no one is trusted, and everyone is micromanaged? If so, then the team will be uneager to try something new and innovative. They will stick to the tried and true, what is expected and nothing more. They will minimize any risk of being punished, or worse. On the other hand, if teams are trusted and given freedom, then they become active employees who are motivated to create incredible products.

I coached an insurance company for almost a year. The teams had to upgrade the entire organization’s personal computers (65,000+ PCs) from Windows 7 to Windows 10. In the past, a similar task had taken a year to complete. Major problems had occurred, causing outages for users. This time around, with new Agile management, the team felt the freedom to do things better. They explored different possible solutions, came up with a plan, and completed the entire upgrade in three months with no hiccups. I started hearing from senior leadership. They asked, “How was this possible? What happened to the teams?”

Do you know what happened? Leadership started displaying trust in their teams.

Conclusion

If you’re a leader struggling to gain a more successful approach to helping your team be successful beyond your wildest expectations, please understand that the price you pay for changing in these three areas is well worth the business results. As you develop into a lean-agile leader, your team, your customers, and you will be happier for it.

Written by Jim Camden

 

Jim has over 35 years helping large and small companies solve painful problems in technical and organizational areas. His early career was in software for large and complex mission-critical systems. He was a developer, designer, architect, and business analyst. Jim has been intrigued by the human side of technology success for the last 20 years, which led him to Agile and SAFe. He is motivated by observing successful SAFe Transformations in organizations that benefit in tangible ways from their efforts. As a coach, he has seen the organizations he works with gain clarity in what matters and what doesn’t, and then concentrate on the former. These principles are so powerful that they work when adopted in any organization—in every sub-group, in any industry, at every level, whether co-located or distributed—despite the current level of Agile maturity within the organization and regardless of the current structure. The key is to have a coach that can make them real to you and your people.

 

More…