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…

March 15, 2021

Move 1: Get Crisp on the Idea

Often, a stakeholder comes up with their next great idea in the shower and just has to get it out of their head. Nothing wrong with having a great idea, but we need to know what it looks like. I’m a fan of hypotheses. Get this person to come up with a hypothesis for their NSO. Sometimes this activity alone stops the person in their tracks. If nothing else, it helps them get crisp on the idea. If you’re not sure how to form the hypothesis, try this hypothesis-driven development template.

Move 2: Put it in Context

You will need to check the NSO against the strategy, which your stakeholder quite possibly set. It’s your first filter on whether you should take up the work. If it’s not in your strategy, then you will need a strong justification to do it, especially if it’s a big-ticket item.

If the NSO aligns with the strategy or if there is a strong justification for it, then it’s time to check the roadmap. Why? Your roadmap should give the stakeholder context for where this NSO would fit in versus the other work. Sometimes this context is enough to shift their idea right or even drop it altogether. Funny story: I had one stakeholder who discovered their NSO was already in the roadmap in the right spot. For more information on how to create an effective roadmap, I recommend Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty by C. Todd Lombardo.

Move 3: Reveal the Sacrifice

You have a hypothesis, the NSO is in context on the roadmap, and the NSO still has to be done ASAP! Next, show them what outcomes are currently being worked on. Ask: “Are you willing to sacrifice today’s outcomes for this new thing?” Notice that I said “outcomes” and not “features”. You should be driving for value and outcomes, not just cranking out features. Where do you find your outcomes? PI Objectives and/or Sprint Goals are a good place to start. If you don’t have those, then you will have to do a little interpretation (and create an improvement backlog item to become more outcome-driven!)

Move 4: Talk about the Cost of Change

So now they’re willing to make that sacrifice? I admire that level of dedication. Maybe this NSO is a thing, but there’s still work to do. So far, your stakeholder is willing to sacrifice some current and future work items. Time for a wallet check—are you willing to sacrifice the cost to wrap up the current work?

They may ask “What cost?” Let them know that there’s an Interrupt Tax. Unless your team(s) are practicing technical excellence, it’s going to take some time to unravel all the code and stuff they’ve been working on. My experience is it can take a week or two, but it may take longer.

Time is money and a little financial literacy certainly helps. You need to know the cost of your team’s (or teams’) time for a week; if you don’t know, then their manager should. If you want to ballpark it, here’s a reasonable formula: Assume a developer salary is $70k/year (no benefits) and that a team is 7 people. Assume the whole team will be involved in backing out of the current work. The cost per week is about $9,500, but you can round it up to $10k. And that’s just the cost of getting ready. So is your stakeholder willing to pay $10k+ to get ready to start the NSO? The team(s) SHOULD be creating a POTENTIALLY Shippable Increment of the product every Sprint, so closing the current work up neatly shouldn’t be a huge problem at a Sprint or PI Boundary. Can it wait until then? After all, we should do more than just a quick hypothesis. The rest of the stakeholders need to be consulted and okay with these changes.

Wrap-Up

So what happens if your stakeholder has a great idea, has put it into context, knows what they’ll have to give up, and understands the Interrupt Tax and is willing to pay it? Go back to the Agile Manifesto Principles: “Welcome changing requirements, even late in development. Agile Processes harness change for the customer’s competitive advantage.” While making such a big change may seem overwhelming, you have already proved to yourselves that the NSO is worthwhile and valuable. So go for it!

Looking for guidance in your Agile Transformation? For nearly 3 decades, our experienced coaches have mentored clients in their digital transformations.

Written by Randy Smith , SPCT

Randy is a Consultant, Trainer, Agile Transformation Coach, and SPCT. He believes that a transformation is about more than adopting a framework—it’s also about meeting people where they’re at to help them create an optimal human system that can happily and effectively deliver value to customers. Randy has more than 2 decades of experience in the industry and has worked in several sectors, including tech, manufacturing, shipping, financial, and medical firms, and he has served many roles like developer, test management, release management, support, etc. He started using Agile principles and values with a team in 1999, got his SPC in 2014, and completed his SPCT in May 2019.

 

More…