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…

Nov 18, 2019

It is often stated that while agility works for software, it is not as easily applied to hardware. In this presentation, you will learn how SAFe’s Core Values and Principles apply to Agile Hardware Development. Duane discusses real world considerations when executing within a Portfolio configuration, including:

1. How is Hardware different?
2. Horizon Planning and Hardware Phases
3. Roles and the ART
4. Team Composition
5. PI Planning and “incremental delivery”
6. What about testing and system integration?

Key Takeaways and Objectives

• Understand how SAFe’s Core Value apply to hardware
• Describe the various roles that make up the “Development Team”
• Describe hardware testing considerations as related to environments, system integration and the system team

Presented at the SAFe® Summit in San Diego on Oct 2, 2019.

Video shared with permission from Scaled Agile, Inc. View original link.

Written by Duane Bushman , SPCT

 

Duane Bushman is a Consultant, Trainer, and Agile Transformation Coach with a genuine passion for helping organizations to understand and realize the business value of Lean and Agile principles. His pragmatic approach to applying principles and proven practices to develop a culture of continuous improvement has been cultivated from 10+ years of practicing and coaching Agile in IT and product development environments. Duane’s journey in life-long learning includes being certified as a SAFe Program Consultant (SPC) in 2014 and an SPC Trainer (SPCT) in 2016.

 

More…

Apr 17, 2019

Now that we are on the same page (or at least my page) concerning coaching, I want to focus on Organizational Healing. In the book Organizational Trauma and Healing by authors Shana L. Hormann and Pat Vivian, they state that “organizational trauma and traumatization may result from a single devastating event, from the effects of many deleterious events, or from the impact of cumulative trauma over time.” I sense that every agile coach is participating in the organizational effects of many deleterious events AND the impact of cumulative trauma over time. For me, this trauma becomes apparent when aspects of a company’s culture are in tension with the disruption I, as a coach, cause by fermenting change in the organization. Just my presence as an agile coach in a meeting can cause trauma which will require healing. The healing is required to sustain my relationships. Due to these coaching impacts, I feel that organizational healing needs to be incorporated into our daily work lives to help our client fully embrace change.

As agile coaches, we are helping the client carve new pathways through their brain. I think it’s fair to say this may be traumatic for most. When the client gets a full body knowledge of “what got you here, won’t get you there,” the reaction can be the equivalent of being chased down the street by a tyrannosaurus rex. We’ve set the stage for how impactful an agile coach may be. Now let’s review a few questions about how the coach might promote healing.

1. When we train clients, there are a number of statements and exercises in our training materials that may be the equivalent of tossing a bucket of ice water on our audience. Shocking the client out of their current mindset is certainly one way to change their world view. It is also possible that we will be building in the resistance that shows up as we guide them into execution. When training, what can we do to promote the concepts and support the client as they gain awareness?

2. Attendance at any team/train ceremony or PI event is an opportunity to experience the impact of change, to address trauma and help support healing. What can we do at each stage of our developing relationship with the client to reduce new trauma and support healing any past impacts?

3. As an agile coach, what are the opportunities to lead with your heart as well as your arsenal of techniques, facts, principles, toys and tools?

In 2000, the Hopi Elders gave the world a prophecy that warned us to embrace change and find the courage required to do so. Those of us firmly in the middle of the river of change have an opportunity to help others enter it and celebrate. As agile coaches, we have the option to support organizations as they heal. Take action as a coach if you can. If you can’t act, continue to develop your awareness. Consider the impacts of coaching in your situation and be compassionate, be well.

Written by Charles Osburn

 

Charles started working with XP teams in 2006.  Since that introduction to Agile practices, he has held the positions of Scrum Master, RTE, Product Owner, and Agile Coach working with teams, Release Trains, Product Teams, and Enterprise Transformations. In the past several years he has focused on supporting Scaled Agile adoption in the Financial, Health Care, Pharmaceutical, and Power Generation industries. Currently, Charles has added Gestalt coaching to his practice and is working on an ICF certification.

 

More…