Or… do you know someone who is saying (OK… maybe THINKING) this?
This posting is for you (or send it to someone who you see freaking out about having to DO this).If this is NOT you… please move along (or read this and be happy you are not here today).
First things first.
Scrum is nothing new. Neither are the concepts around “Agile.”
Scrum does NOT solve your problems. Sorry.
Scrum is not THE solution. Sorry.
Scrum is a framework that actually EXPOSES all the dysfunctions in your organization; this could be a team, division, company, NGO, government, non-profit, or ????.
What does this mean if you have been told that you MUST move to an Scrum and Agile?
Some naysayers will tell you to bend over and kiss your ass good-bye. It’s not THAT bad.
Many people have been “burned” by attempting to try Scrum and Agile in an environment that was not ready. Read more in this blog about some of the stories of people who have AND what people have done to avoid that situation.What can you DO?
1) Learn from others. This requires conversations with people. Some of them may be tough. You are not re-inventing the wheel here. Get a mentor or coach (inside or outside your organization).
2) Get some training for yourself, your team, and your stake holders. Get buzzword compliant at a minimum. Buzzword compliance does not mean you will be successful. This takes time and training can show you what’s coming.
3) Is your first “pilot” project in RED already? Identify someone with enough political capital to take fire cover for you.
5) Get ready to Focus and #deliver. Remember this is not an “IT” thing — it involves people in your organization working together.That’s IT? You’ve GOT to be kidding….
This five step list above seems pretty simple.
Start with simple.
It’s not as bad as it may look at the moment. It requires a change and if you are not ready to change, please STOP and just keep doing whatever you are doing today (it’s gotten you this far, right?!?).Questions?
Free. No sales-pressure.
Here is the thing… I am not a mind reader. I DO have experience being where you are today and I help people navigate this daily (and, I also use these techniques in running my own business).
It starts with a conversation between two people.
I am available for that conversation (or find someone who is open to doing this with you!).Let’s Talk
NOTE: This comic strip was originally published on July 23, 2007 under the topic of: “ScrumMaster = Snake Oil Salesman?“.
Try learning some new techniques too (see my last posting on NVC and Scrum).
Since I agreed to a four city tour in November of Scrum Trainings, I thought this would be an excellent opportunity to explore what yes really means, and why it remains such a stumbling block. What did I find out about 'yes' and other aspects of Indian culture?
Raising the questionMy Scrum courses devote substantial attention to working agreements. At the start of each course, I facilitate a discussion among the participants. “What agreements do we need among ourselves so that we can work together effectively between now and the end of the course?” The participants propose their topics, and then agree to concrete actionable proposals. I might add a topic or two. Sometimes we have to modify the proposal before we can come to an agreement that everyone can really support.
Agreements among the participants make for an effective course and agreements among colleagues are an excellent tool for transforming corporate culture. You can't change corporate culture directly, but you can influence your meeting culture quite strongly, simply by making working agreements with your colleagues. This in turn influences and changes your corporate culture.
Nicolas Jene, one of my participants last October was retaking the CSPO course he had taken a year ago. Back then, we had made a number of working agreements, including being on time and ready to go after breaks, devices off or on silent, no crosstalk, the attention protocol, how to deal with questions, etc.
People are the same everywhere...Nicolas noticed that the working agreements this time around were essentially the same as the agreements as in his last course, so he asked, 'Are the working agreements always the same? Even in different cultures?” I thought back to my the last year of courses in Switzerland, in Russia, in Portugal, in Italy, and in Texas, and replied, 'yes, pretty much. But I am not sure how that will be when I get to India, because the culture there is quite different compared to where I have been before.
So in all of my India courses, I facilitated the same discussion. What do we need to work together effectively?
All of my participants in India asked for and agreed to more or less the same the agreements, just like at every other place else I have been to. They did have some novel suggestions, but the topics and actual agreement were essentially the same.
My conclusion? People are the same everywhere. They want the same things from each other. They need the same things to work effectively: Focus, Commitment, Courage, Openness and Respect. Sound familiar? These are the Scrum values. You find all of them reflected in people's working agreements.
But cultures are differentIf people are the same everywhere, does that mean everyone thinks alike? Of course not! Case in point: during my last product owner class, I showed Henrik Kniberg's fantastic video “Agile Project Ownership in a Nutshell” (watch it here). One highlight of this video is the importance of saying 'No.' “Pat [the product owner] practices [saying No] every day in front of a mirror.” After watching the video, the class wrote down their “Eureka!” moments of what they would take home from the video. Most of the participants found that 'No!' was a highlight of the film. “We are allowed to say no!?” “We're expected to say no!?” “Wow!”
One person, of Indian origin, had a completely different lesson from the video: “Sometimes it is better to say yes and prioritize down.” What?! That was exactly the opposite of what Henrik's video was trying to say, or so I thought. I even asked him about it. Yes, that was his a-ha! moment. After getting past my disbelief, I reflected on why his answer might have been different from mine and the others.
If the inputs seem the same, but the outputs are different, then there must be some other inputs I don't know about. I call these inputs 'culture' and I decided I wanted to explore that further during my trip to India.
Why is 'no' so difficult to say?At each course in India, during the section on working agreements, I introduced the topic of yes and no, and explained why I thought there was an issue. My participants agreed that this misunderstanding occurs quite regularly when working with western companies. So I invited the participants to discuss in pairs why saying no is so difficult, then report back on to the group.
To my surprise, there was no hesitation to discuss the issue (though I had done a lot to lower the social risks in the room before asking question). The opinions of all four classes – over 100 people – centered on three issues:
- Our upbringing discourages us from saying no. It is impolite to say no.
- If I say no (to the customer), my company might lose the business.
- If I say no (to a manager), I might lose reputation and risk losing my job.
In short, it's about fear. It's about the challenges of living in a developing nation. It's about the fear of becoming part of the 60% of the population that lives on $2/day or less. Saying yes is an accommodation. You may lose the business or your job later, but you do have it today, and that is perceived as much lower risk than saying no right away. Given that upbringing appeared so often in the list of reasons, it looks like the accommodation is deeply ingrained in the society.
What does 'yes' really mean?What does 'yes' really mean in India? It depends. It might really mean yes. It might also mean “I'm saying yes to satisfy your expectation” (but without committing to actually deliver on the expectation). More likely, it means, “I'm going to do my best, but there may be outside forces that I cannot control which will prevent me from succeeding.”
How to bridge cultural differences?I don't pretend to have the definitive answer to this question. I found being in India, talking face to face with people and learning to recognize their body language were both very helpful. I found it easier to work with people while I was there than over the phone from Switzerland.
Is there really a conflict between being polite and setting realistic expectations? I think this is a false dilemma. Henrik Kniberg pointed out that Autonomy and Alignment are not opposites, but independent of one another. People can be aligned and autonomous. Steve Biddulph wrote that parents can be both firm and loving with their children. How can you set realistic expectations and be polite? I think that is a fair question for any team to ask of itself.
Conflict avoidance is not evilMany facilitation techniques avoid using the word No. In a retrospective, we first identify possible topics for improvement. Then we identify the most important items, and say yes to a few of them. We don't actually say no to anything. Just yes. Dot-voting is classic consensus-building tool. Identify the most important, start there. And Rod Collins' Work-Thru also focus on identifying where we agree, so we can start here, and deferring points of conflict until later, when trust is higher and the situation is clearer. (Read more about Work-Thru's...)
Are there patterns here which could be applied for other kinds of collaboration? I have seen evidence that working agreements can be extremely effective at transforming corporate culture. Can working agreements be the basis for bridging cultural differences within a project? I believe so. You create your own culture through your working agreements (among other things – good stories are vital!) within your project so that you and your on-shore and off-shore collaborators can work together effectively.
Finally I believe that one day, people in India will let go of their fear. It is not weakness that makes people afraid, it is fear that makes them weak. India has strong abilities and great prices. There will always be a demand for that combination. If this customer gets away, there is always the next one. Once people realize they don't need to be afraid, they will have the courage to say no and to say a yes that really means, Yes!
Bend the spoon is a phrase we use quite a bit here at LeadingAgile. I don’t want to hear what’s happening, I want to hear what we need to make happen… and what we are doing to make it happen. I don’t want to hear why we can’t do something, I want to talk about what we are doing to make reality conform to our will.
If it’s impossible… bend the spoon.
Some people are wired to bend the spoon, some are not. When I walk down a busy sidewalk, I kinda expect traffic to flow around me. When my wife walks down the same sidewalk, she dodges the oncoming traffic. My wife sees the world as a set of rules that have to be followed. I think that rules are made to be broken.
If you believe you can bend the spoon in your organization, you are going to have a much greater chance of actually making change. If you see your organization as a set of immutable laws, laws set in motion by powers that are beyond your control, it’s going to be much more difficult.
Bending the spoon isn’t about imposing your will on the organization… it’s about believing that change is possible. That somehow, someway… all the crap that is getting in the way of really adopting agile can be changed. If you don’t believe you can change your organization and decide to change agile to accommodate dysfunction… you are going to fail.
Bend the spoon.
I’ve started using an analogy to illustrate the importance of product owner teams in larger organizations. When working with organizations to do an agile transformation, almost always, a tiered model is used for scaling across the organization. The model looks something like this:
The top tier is portfolio management which is responsible for investment decisions and what initiatives continue to move forward. The middle tier is representative of the Product Owner role in Scrum and is where we often create program teams, sometimes called product owner teams. The bottom tier is where stable cross-functional teams reside that are delivering increments of value in some cadence such as every two weeks.Let me describe this engine analogy to see if it resonates with you. Stable Engines
I think of the delivery tier as the engine of the organization. Each delivery team is designed to operate at a sustainable pace in a very predictable manner. If we think of each team as an engine then we may find some operate at 2500 RPM, others 3500 RPM, regardless, they each operate at a RPM that is sustainable. If we can operate with little variance then we can start to become predictable and make promises on what can be delivered over time. If a team is running at 2500 RPM then I can determine how far that team will travel if that engine powers a car.
But, if we push the engine past a sustainable pace, or have them operate past the redline, then the engine becomes stressed, will wear out more quickly, and likely fail to deliver as expected and certainly become unpredictable.Fuel for the Engines
Product owner teams represent refineries responsible for providing good fuel. They must understand the business goals and problems to be solved, collaborate with delivery teams to define capabilities to build, and further decompose those into clear backlog items that provide clean burning fuel needed by the engines.
Provide bad fuel – the teams sputter and are unable to run at a consistent RPM. Bad fuel will not allow us to make promises to the market or our customers.Drilling Locations
I haven’t completely vetted this out in my mind, but when thinking about portfolio management I believe this is where we are making investments on where to drill for crude oil. We increasingly learn more about the potential initiatives, collaborate with the product owner teams, and possibly delivery teams to progressively gain more knowledge so we can make funding or cut decisions about where we will invest.Wrapping Up
This analogy seems to resonate when I’ve used it over the last few months to describe the responsibilities of delivery teams and product owner teams. Turning crude into clean burning fuel is a big job and really highlights the challenge most organizations have in providing clarity to their delivery teams.
I would love to get your thoughts on how I’m thinking about this.
The tech industry has long used conferences to share ideas, products, practices, and news. In this era of TED talks, YouTube, SlideShare, and livestreaming, it's easier than ever to be in the audience when thought leaders take the stage.
The best conference talks -- even if they’re virtual -- elicit a reaction that’s visceral: they make you think and act differently. Whether it’s a jarring statistic, or a humorous anecdote, or a charismatic speaking style, something about the best talks stays with you long after the talk has ended.
Ring a bell? That’s the kind of talk we’re after for RallyON 2015. Here are some talks from last year’s RallyON that people still talk about today.
What’s the most intractable, inefficient, and slow-moving organization you can think of? If you said the US government, you’re probably not alone. As we learned in this talk by former Assistant Secretary and CIO of the Department of Veterans Affairs, Roger W. Baker, implementing Agile at the VA had powerful and mind-changing consequences.
- The department’s success rate for IT programs went from 30% to 83%.
- The VA returned $373 million to the US Treasury budget.
- It deployed the Veterans Benefits Management System—a $700 million program that completely replaced a paper-based system—six months ahead of schedule.
It’s rare to get a peek at how large, publicly traded enterprises do things under the hood; it’s even rarer to hear them talk about both what’s working and what’s not. So when Wendi Nagy, Program Director at Comcast, assembled a team (PMO Director Paul McGregor and Agile Coach Janelle Brunke) to share the lessons learned in the company’s Agile transformation, people listened.
- What they did right: standardizing iteration length and using common user story formats in a single Rally workspace.
- What they did wrong: a “never say no” culture that resulted in too much WiP.
- What’s working: instead of delivering in silos, teams demo features to internal and external clients at the end of iterations -- earning them a great reputation for delivering.
You’ve probably heard or seen a conference talk that made you think twice, made you want to share it with everyone you know, or made you change how you do things. What’s the best one in your book? What would you like to hear at RallyON 2015? Submit to our Call for Content and tell us more in the comments below.Rally Software
An agile team is not just any random group of people. An agile team is not a group of business analysts doing a daily standup to coordinate their work. It’s not a group of developers that meet every other week to do sprint planning. It’s not a project team with folks matrixed across two or more other agile teams.
An agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product. These people are dedicated to the team, and as a rule, do not move between or across teams as demand ebbs and flows.
I’m going to suggest that the very definition of an agile team… a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product… is getting in the way of forming agile teams, mostly because we misunderstand what a product actually is.
In the small, this guidance is clear… it’s the system all the way from user interaction to data and back and all the abilities to deploy and install said product into production. In the large, forming a team like this isn’t usually possible, and often if possible, not advisable.
In the large, a product is actually a sub-system of a larger systems integration.
When you look at a product this way, it is often very possible to create a small cross-functional group of people that has everything, and everyone, necessary to produce a working, tested increment of product.
The idea is that you organize around products or features where you can, and you organize around subsystems where you have shared functionality. We call these collectively business capabilities. Once you have the business capabilities understood, you align the business capabilities with the technical architecture and ultimately the organizational architecture.
The intersection and alignment of business architecture, technical architecture, and organizational architecture is where you form a complete cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of their part of the product.
Because your business architecture, technical architecture, and organizational architecture are probably broken, you are going to have dependencies between these teams that are going to have to be managed. For now.
Over time, the job of the transformation initiative is to break these dependencies.
Dependencies are evil and they need to be broken.
The more you manage dependencies the less agile you will be, period.
Over time, as you break these dependencies, you will be able to treat each of these teams as pure play agile teams.
Until you start forming teams that align business capabilities with technical architecture and organizational architecture, and begin the hard work of breaking dependencies… all you can do is go through the motions of Scrum. You will never get the value you are working towards.
I’m telling you guys… the reason you’re doing agile and not feeling very agile is because you don’t have these kinds of teams and you have way too many dependencies.
No amount of daily standup meetings is going to fix this problem.
An agile culture won’t do the hard work for you.
Bobtuse can be wildly informative
I have three non-negotiables when it comes to running an agile transformation. If we are unwilling to create clear, well-articulated backlogs… if we are unwilling to form complete cross-functional teams… and if we are unwilling to produce working, tested software on regular intervals… we probably shouldn’t even get started. Without these three pre-conditions it is unlikely that adopting agile practices (or even an agile culture) will make much of a dent in terms of how you put product into market.
That said, the number one thing that gets in the way of creating clear, well-artciulated backlogs, forming complete cross-functional teams, and producing working tested software on regular intervals is dependencies. Let’s just say it… dependencies are evil. Dependencies break agile. You have two choices when faced with a dependency… you can either break it or you can manage it. The more dependencies you choose to manage instead of breaking, the less agile you will be over time.
This might just be the one immutable law of adopting agile.
We are working on more video for the site to tell our story. This is the first stab.
There are a bunch of us out there that are super passionate about this notion of agile as a cultural framework… or a value system… or a mindset. If you’ve been following this blog for any length of time, I suspect you’ll know where I stand on this. I think that culture, values, and mindset are important… but they aren’t why we adopt agile. We adopt agile to build better software, software that our customers want to use, and to get better economic outcomes for our companies.
To the extent that culture, values, and mindset lead to those outcomes… great… but culture, values, and mindset are not why we adopt agile. They are a byproduct.
If we allow for a moment that culture, values, and mindset are a necessary precondition for adopting agile… let’s think through what that actually means. Let’s say we have a traditional organization… functionally soloed… tightly coupled legacy architecture… matrixed, project based delivery system… overlapping, intertwined value streams… power struggles between executives… compensation models that reinforce and incentivize around the existing system… and all the cultural toxicity that you might expect comes along with this… what do you do?
Do you come in and give everyone a pep talk on the value of agile? Do you invite them to participate and hope that they all agree and self-organize into a new, rational delivery model? Do you run them through ScrumMaster training and have them bring back a bunch of practices that are incongruent with their existing culture and delivery framework? How do you create safety for people to step out and try new things? What if the team level folks all see the value, but those in power with the most to loose don’t?
I’d suggest that you can’t attack culture by attacking culture. You have to meet the organization where it is today and use it’s own weight against it.
Most people in these kinds of organizations recognize that something is broken and that something needs to be fixed… they just don’t trust everyone around them to necessarily work in their best interest to fix it. Our approach is to use the organizations need for predictability and control to actually create the conditions where agile practices and culture can take hold. We know that agile creates more visibility, more insight into what’s going on, better ability to make and meet commitments than any sequential process.
We have to use agile to get the organization what it needs and to create the conditions for change. We create the conditions for agile by creating the org patterns that enable agility.
When you are promising the organization what it wants now… predictability, quality, early return on investment… and can make the case that all this agile stuff gets them there faster… you can begin the change without even mentioning culture, values, or mindset. Instead, you talk about backlogs, teams, and working tested software delivered on regular intervals. You talk about metrics and planning. You talk about the ability to realize revenue earlier, you talk about creating clean breakpoints where we can change direction, you talk about having greater ability to make and meet commitments.
None of this is incongruent with where we want to go… none of this is incongruent with evolving a healthier culture, living agile values, or adopting an agile mindset… those things just aren’t where we start. We start by adopting an agile system of delivery, a system that delivers the business results your company so desperately needs, while creating the conditions for more agile practices to take root… and a more agile culture to emerge over time. You are never going to change culture by telling everyone they are doing it wrong and need to change.
My belief is that to effectively change culture, you have to create safety… you have to create alignment… you have to create congruence between your desired outcomes and rewards. You have to have a rational system of delivery that allows people to show up for work, to be able to do what they are being asked to do, and really see and feel what it is like to be successful in that new model. In an organization with a highly toxic culture, you have to lead with a point of view and a plan and push the organization to change… I don’t believe pull will work.
I think culture, values, and mindset are important, but I tend to see them as a byproduct of a rational system of delivery… a system of delivery that creates safety for everyone involved… a system of delivery that allows those cultural norms, applied values, and mindset to emerge over time. People ask me all the time how to sell agile to your executives… the answer is to simply stop talking about what we want to accomplish with agile and start aligning agile to the business drivers that are most important to your executives.
Use the organizations weight against it. Sell the organization a way to solve it’s business problems… you’ll get the culture change for free.
The post Cultural Judo – How to Change Culture Without Changing Culture appeared first on LeadingAgile.
Have you heard about the fortune cookie meme where you read your fortune cookie and then add the phrase “in bed” to the end of it? For example:
You will learn a lot today … in bed.
A dream you have will come true … in bed.
Funny ... and maybe a little immature.
Well in the business world, the same thing works for the phrase “at scale.”
Maintain quality … at scale.
Coordinate work across development teams … at scale.
All things are difficult before they are easy … at scale.
The fact is, “at scale” can mean 100 different things based on your context. Are we talking about scaling one database up to thousands of databases? Are we talking about a system working with 10 users, as opposed to 10 million? Is it one team vs. 100 teams? A recent Huffington Post article described 10 things you can do to appear smarter during meetings; tip #6 is, “Ask ‘Will this scale?’ no matter what it is.”
“At scale” can mean so many different things that it can become meaningless.
Here at Rally, “at scale” means distributing Agile techniques across locations, across departments, and across business units. It means solving the problem of coordinating the work of hundreds of teams to get the top business initiatives completed, driving value across the enterprise. Companies do this in many different ways. Some practice SAFe®, some use LESS, and others have created a blend of both or invented their own. No matter what framework these companies are using, the problem they're solving is the same. How do you deliver high-quality value to your customers in an efficient and predictable manner?
Here, we try to drink our own champagne. We continuously seek to find ways to improve, and at times we will bring in our own transformation consulting to evaluate how to take the next step in our Agile journey. We’ve done this just in the last year, and as a result we’ve solved some internal problems and substantially increased our feature velocity.
At Rally, we challenge ourselves not to hide behind the vague problem of “at scale.” We think about how we can help you deliver business value faster, whether you've got a single team or hundreds of teams, and we think about the problems we can help you solve. Are you struggling to get your first Agile team up and running? Are you trying to convince executives that an Agile transformation is the only way you can stay ahead of the market? Are you looking for a way to plan and collaborate remotely across your seven development locations? Rally can help by connecting you to world-class coaches, products, partners, and other customers.
Talk to us about the problems you face in getting business done ... at scale. We probably have a solution for you.
If you read least week’s post about agile misconceptions, There is One Right Approach, you will like this one. This week’s article is Agile Misconceptions: Agile is Just a Project Management Framework.
If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. We’re leading it in San Francisco and London this year. We offer discounts for multiple people from your organization. Sign up now.
What’s the difference between a user story and a task?
Well that’s an easy question, I thought, the first time it was asked of me in a Certified ScrumMaster class. “The difference is …,” I began to reply and realized it wasn’t actually such an easy difference after all.
I’d been using the two terms, “user story” and “task” in my classes for years, and they seemed pretty distinct in my head. User stories were on the product backlog and tasks were identified during sprint planning and became part of the sprint backlog.
That was fine but wasn’t very helpful—it was like saying “salt is what goes in a salt shaker and pepper is what goes in a pepper grinder.” Sure, stories go on the product backlog and tasks go on a sprint backlog. But what is the essential difference between the two?
I paused for a second the first time I was asked that question, and realized I did know what the difference was. A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person.
Let’s see if that works …
A user story is typically functionality that will be visible to end users. Developing it will usually involve a programmer and tester, perhaps a user interface designer or analyst, perhaps a database designer, or others.
It would be very rare for a user story to be fully developed by a single person. (And when that did happen, the person would be filling multiple of those roles.)
A task, on the other hand, is typically something like code this, design that, create test data for such-and-such, automate that, and so on. These tend to be things done by one person.
You could argue that some of them are or should be done via pairing, but I think that’s just a nuance to my distinction between user story and task. Pairing is really two brains sharing a single pair of hands while doing one type of work. That’s still different from the multiple types of work that occur on a typical story.
I have, however, used a couple of wiggly terms like saying tasks are typically done by one person. Here’s why I wiggled: Some tasks are meetings—for example, have a design review between three team members—and I will still consider that a task rather than a user story.
So, perhaps the better distinction is that stories contain multiple types of work (e.g., programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work.
LeadingAgile is proud to announce that Jim Cundiff has agreed to join our team as President and co-owner effective March 2nd. Jim has been a visionary leader in the agile community for the past 10 years, both as the Managing Director of the Scrum Alliance, and most recently as Principal and co-owner of Big Visible. We look forward to collaborating with Jim as we work to take LeadingAgile to the next level. Please join us in welcoming Jim to his new role.
I coach for a living. I coach companies through the journey of their agile transformation. I love what I do, and I love seeing the joy people experience when their transformation journey yields meaningful results. However, people’s joy can be lost when their expectations, e.g. I thought it would happen easily or more quickly, don’t align with reality. Often the “WHY?” for the transformation is lost, or is never really understood in the first place.
Agile transformations can feel very uneasy; there are incremental and fundamental, daily changes that must take place, and occasional frustration and discomfort are expected and felt along the journey toward a meaningful, sustainable success. Change is hard and it’s just not reasonable to implement and address processes and skill gaps, into a short time span. Realistic expectations, a shared understanding of and remembering the “WHY?” you want to “Go Agile”, is necessary to keep going when moving forward gets hard.
We create great products because we have a desire to solve real problems, and all that one believes will be gained by solving those problems. Similarly, we should set out on an agile transformation journey with the willingness to change, and the clear understanding of how that Journey will enable and support our company’s core beliefs. Unfortunately, I’ve noticed that companies that haven’t clearly aligned the “ WHY?” of the agile transformation with the Why they exist as a company, have the most trouble with succeeding at, and sustaining, their transformation.
In those cases, the types of responses I typically hear when I survey people around a company about why the agile transformation is taking place a) Because our competitors/everyone is doing it, b) Management decided or c) If we don’t do it our business will fail, and my favorite d) I don’t know man, I just do what I’m told. While those may be “valid” reasons for transformation, they are not very compelling because they don’t give us a good foundation and understanding to look to when things get challenging.
Why then would a company not spend the time discovering and articulating “WHY?” they’ve decided to make this drastic, difficult change, and start with a shared common understanding across the organization, to set the stage for a successful adoption?
True to the traditional form of management planning and execution, many hope that by just discovering the “perfect” path forward everything will just work out, or that once the transformation fails they’ll be able to just go back to doing what they did before. That’s too simplistic a view for something that is very expensive and disruptive.
Your journey into an Agile Transformation begins with changing how you approach your decision to make that transformation. Agile is about collaboration, transparency and response to change, and relies heavily on people trusting people and working together. It requires selflessness in how our jobs change, and how we support others taking on new responsibilities. It requires honest communication from the top on down, and requires the company to really understand “Why” an agile strategy makes sense, while making use of agile principles, before they engage on the path to transform.
I believe “Why is this transformation important to you” should yield an answer closer to: Because we believe in giving our customer the best experience possible, and because of that, we want to adopt a new process that will allow us to respond to their needs, enable our employees to enjoy their work and grow, and help us strengthen our core beliefs that have made us successful for so many years. To do that, we believe and understand that the agile principles closely align with our core beliefs, that the change will be difficult, but we have a clear understanding of those challenges, and are going to go through that journey and learn together as one company.
Why are you adopting agile as a company? Perhaps you should find out.