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…

Sep 18, 2019

As any experienced coach will tell you, a SAFe Transformation that’s stuck in IT can lead to communication problems with other departments that are stuck in waterfall. To increase flow and understanding, areas like Finance, Compliance, HR, and Audit also need to transform and become more nimble. In other words, enterprise agility becomes necessary, and leadership commitment is crucial to making this happen.

So what happens when your client is in an IT Transformation and requires organizational understanding to optimize flow, but leadership isn’t involved? What can you do as a coach to improve that situation?

I encountered this very problem with a previous client, and my suggestion is to start by widening your net and begin building personal relationships with people (especially leaders) outside of IT. Don’t simply be an agile coach—be an active agile coach and engage anyone who will listen. Once other parts of the company start paying attention and getting involved in SAFe, it sows the seeds for the executive leadership to really pay attention.

In this article, I will share my own experiences with a former client, whose Audit department was actively engaged by me to become part of the SAFe Transformation, in turn causing other departments and leadership to follow.

Introducing Audit to SAFe

Building personal relationships with people outside of IT goes a long way towards creating company-wide understanding of agile and lean concepts. But it requires us coaches to be curious and a little adventurous, to drink some of our own Kool-Aid and go on Gemba Walks.

My previous client was a mid-sized gas utility company in the Midwest. While coaching their IT Transformation, I introduced myself to an audit manager over a proverbial watercooler and engaged him in a discussion about SAFe. After explaining why it was so valuable for the entire company, I asked if his department would be interested in learning more in an hour brown-bag lunch presentation. The hook was, “As auditors, you’ll be working with new agile teams. What if you could adjust your processes and expectations to their new way of working? Wouldn’t it be interesting if Audit could also become more lean and agile?”

It took some time before we scheduled the brown-bag lunch. I had to keep communicating and gently nudge him, but nine months after our initial conversation, I took the entire Audit department through a Leading SAFe class. We discussed how we could adjust existing audit and compliance-related processes into something more nimble, while still ensuring laws and regs were faithfully followed. We talked about how auditors (who are typically stretched thin) could iterate with teams and use acceptance criteria as a means to measure not just “done,” but also compliance (and to do so iteratively). With the right lean-agile attitude, the answer was, “Of course you can!”

The Leader Enables Agility

The VP who led Audit and Compliance voluntarily reached a tipping point; she saw the writing on the wall. Despite putting personal and emotional investment into a particular skill set for years, she was willing to forego her reliance on traditionally cumbersome, outdated specifications and was receptive to new thinking. She committed to investing in something she could have easily resisted. Many of her peers would have supported her in not changing (“Agile Auditing”…isn’t that an oxymoron?). Instead, this VP wanted to spend resources—people, time, money—on retooling her entire Audit department.

So how did this VP come around? Her own people—excited to get going—convinced her that transitioning to a Lean-Agile paradigm would increase both efficiences and effectiveness. If the organization could iterate as one large team, then everyone would be working on the same cadence with full alignment. Work would be delivered in small increments so knowledge transfer and learning kept up with the need for it in real time. In this case, while capabilities, features, and stories were delivered, Audit could concurrently verify compliance. They could contribute to stories and acceptance criteria to reflect the greater organizational need, not just a narrow definition of operational functionality. Additionally, they could learn while doing and do while learning. We anticipated a 90% reduction in wasted time by eliminating obsolete, serialized processes. How’s that for eliminating waste and optimizing flow, Taiichi Ohno?

Getting Audit “on the Train”

Building personal relationships with the Audit department, especially the leadership, and then educating them was ultimately how we got them on board with the transformation. They became part of the PI planning process as integral players and members of the ARTs. Admittedly, resources were scarce. With two trains, over 20 teams, and only 10-12 people available to perform audits at any given time, it was out of the question to have single resources dedicated to one or two teams. It simply wouldn’t scale. Yet, we had enough connective tissue to ensure auditors truly iterated and participated while doing so. How else were we going to unlock the benefits of training and auditing while doing? We brainstormed what a good definition of that looked like. Furthermore, the Audit department committed to stop using their own calendars and instead synchronized their planned work with PI and sprint planning.

The whole endeavor required a bit of chutzpah, a sense of humor, and some relationship building skills, but the result was way cool. We had a non-technical component of a complex, regulated gas utility directly involved in the SAFe Transformation. For the first time in my experience, we actually began truly scaling lean and agile across an entire company, and not just in IT. It caused people from other parts of the company to pay attention, especially the leadership. The seeds were sown.

Scaling Outward

Once the Audit Department found success with their new agile practices, HR leadership noticed and got involved too. We started working with HR to help determine how traditional roles could be recast as agile ones. It’s unreasonable and unfair to ask people to take risks and change behaviors if you don’t match career incentives to expected behaviors and outcomes—the so-called Organizational Paradox.

The HR department began to change the definition of traditional roles and added definitions of new ones so that career progression was clearly mapped out. They blazed new trails outside of the technology organization and operational community. They helped allay a real fear some members on the ARTs had: what happens if SAFe disappears and my original job has been filled? Having career tracks for scrum masters, product owners, etc. meant people could feel confident that their employment was secure.

As different business departments of the company became interested, leadership took notice and began taking steps to expand agility beyond the IT department. We were beginning to see critical mass accumulating. The CIO hired a new Managing Director of Innovation, and after I introduced myself to her and explained what was happening with our SAFe Transformation, she expressed interest in enterprise agility. This is where the company currently stands—with leadership primed to move forward, they are slowly but surely taking the steps to become a truly Scaled Agile organization.

How do you begin? Be more than a Coach.

Another coach and I spent almost a year socializing and proselytizing. You cannot simply focus on engaging whomever hired you and stay in your silo. We invested significant time going around the company to speak with whomever wanted to listen. This is what’s possible if you engage. You won’t always get traction, but we were pleasantly surprised at the excitement and willingness by almost everyone we spent time with.

The key is transforming yourself from a passive role (“just coaching”) to an active one. You coach, yes, but you also spend time educating an entire company, not just IT, about the transformation. You speak of possibilities. Eventually, you will meet people who have the right attitude and motivation to begin thinking about their own journey. Then it’s a matter of watching the dominos fall and witnessing a transformation that touches an entire organization. It’s a fundamental paradigm shift that truly affects culture change. In other words, real enterprise agility.

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…

Dec 4, 2019

It’s true, management can be a pain sometimes…so what have you done about it?

Often, there is little to no pushback from the ones doing the work. You and your team expect leadership to actually lead the change, and often this becomes a justification for inaction or paralysis. While it’s important for leadership to step up, it’s also only half the story.

Instead of waiting around for management, consider taking personal responsibility. Sure, it’s easier to go along and blame others for what you perceive as unfairness. However, if you are brave enough to be self-directed and speak your mind, then you will ultimately be more accountable, engaged, and happier in your work. Furthermore, most people welcome respectful, but assertive behavior. So if you’re on an agile team, feel blocked, and aren’t sure what to do, this article offers three strategies that have led me to success. I hope they work for you, too!

1. Practice Empathy

Whether you choose to remain quiet or assert yourself, empathizing with others can be an incredibly powerful tool. Try walking in the shoes of those you think of as unfairly demanding. When you have empathy, you can better understand what a person is feeling and why their actions make sense.

Having trouble mastering the empathy thing for your boss? Think about it like this: he or she likely feels a lot of responsibility, and fear of failure often inhibits a more agile, adaptive frame of mind. Agile requires handing power over to the ones doing the work, to allow them to experiment and have a voice. For most people, this lack of control is scary and can lead to feelings of uncertainty and incompetence.

If you want to have a productive conversation, keep your boss’s vulnerability in mind. In general, people just want to be listened to, so start your end of the conversation by validating his or her logic: “I get it—you think we should have this done by next week, which makes sense, because the goal is to get the product to market quickly.”

By clearly validating his or her opinion, your boss will immediately feel heard, accepted, and favorable toward you. Then it’s time to establish your own experience and perspective: “However, last time we ratcheted the teams and worked mucho hours, the results were less than stellar and customers suffered. Moreover, several customers told us they’d rather wait a little longer to get a predictable, quality product rather than something unreliable. I think the key could be good customer communication instead of early delivery. What do you think? Can we try baking this into this next effort?”

From my coaching experience, I’ve learned that most leaders and teams want the same things: to solve challenges and create positive outcomes. Most leaders are very interested in making people more productive and happier in their work. In order to move from an adversarial “management vs. us” paradigm to a solution-oriented, collaborative one, both you and management need to actively try. Empathy is essential; it helps everyone recognize they’re on the same team, working towards the same goal.

2. Learn to Say No without Saying “No”

Early in my software engineering career, I was working on a complex piece of military weapons guidance code. My boss (an intelligent man) came to me and said, “Rodger, hot item; can you and your team quickly huddle and converge on X?”

Instead of immediately taking this on, I first told my boss, “Sure, be glad to do that. However, this other important thing we’re working on will temporarily be put on the back burner so we can work on X. Is that OK? Because we’ll work on whatever you tell me is your highest priority.”

His response was illuminating and an example for the rest of my career. He didn’t huff and puff. Instead, he said, “No, you’re right; the other item is the higher priority. I’ll let my boss know what’s what.”

So how do you stop yourself from being a passive, resentful “order taker” and learn to say “no” without saying no? Give your boss context and information. Provide options and ask for help prioritizing. The other, more subtle, dynamic in play is mutual trust (but more on that later).

Be courageous and take risks. Maybe you’re in a situation where you work for a lesser person who says insane stuff like, “I don’t care how you do it, just get it done.” That can be really hard, but I suggest that you at least try adding your own relevant information to the conversation in a respectful way.

In management science, there is a concept referred to as “conditioning your audience,” meaning that people tend to behave to the level of your expectations. As you send subtle, subconscious messages, your audience can become “trained” in a certain behavior. For example, if you treat someone like a child, then this person will likely begin acting like one. Without respectful but assertive dialog, you wind up “training” your leadership to walk all over you. They will keep asking you to do things, because you tend to say “Yes.” The better option is to engage and provide context. The results will surprise you.

3. Practice Trust and Live the Agile Mindset

As I mentioned before, you cannot always wait for leadership to make the first move. An organization cannot fundamentally transform unless you, yourself, also put in the hard work. To compete and succeed in a globally networked world, you have to be able to quickly respond, change, pivot and execute. If you don’t change yourself, then you cannot expect to play in the agile sandbox.

People will only trust you if you show trust in them. Your leadership is the same. I understand this is difficult. Our current Western culture is built around a 150-year-old industrial management paradigm—top-down, “command and control,” built on distrust. Distrust is inefficient. When you don’t trust someone, you begin setting up mechanisms and feedback loops to verify and “control” outcomes. When you can’t trust, you always feel you have to go back and check. This is exhausting.

To this end, agile ceremonies are important. They’re the tools that teach you how “to be” Agile and how to trust. When you learn something entirely new, you first have to learn the basics. When you fail, you try again, over and over. It’s a mechanical process. You’re taught fundamentals and then—after much repetition and practice—you begin internalizing instinctive behaviors and muscle memory. What initially is rote and mechanical becomes instinctive and second nature. When you persist, you will soon turn into a nimble, agile, fire-breathing dragon-slayer.

You too must do the hard work and change your mindset. Can you begin to trust more and distrust less? Are you willing to trust, possibly fail and trust again? Can you constructively engage when you feel someone broke your trust? “I trusted you and I feel you disappointed me. Let’s start over. We work much better together when our relationship is built on trust.”

Conclusion

Although leadership has extraordinary power to impact an Agile Transformation, you also have an important part to play. Your boss is interested in making your team more productive and happy, so act assertively and stand up for what you believe is the right way forward. Remember, if you treat your boss like an unsupportive yahoo, then he or she will likely be an unsupportive yahoo!

I’ve been in organizations that do the Lean-Agile thing well, and it’s awesome. The focus is on getting stuff done, but also having some fun. Another lesson learned; be patient and nice to yourself, because all this goodness doesn’t happen overnight. How long it takes depends on the hard work of everyone, both you and your leadership.

Through coaching and training, ICON is experienced in helping both leadership and teams embody the Agile mindset.

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…