You are hereFeed aggregator
All About Agile - Mon, 01/18/2016 - 15:46
Over the last 30 years at work, I have observed many re-structures. Some I was part of. Some I created. Some worked. Some didn’t. And some created only marginal benefits. Others – in more recent years – were truly transformational and catapulted team performance to a whole new level. I have always been fascinated by […]
All About Agile - Fri, 01/15/2016 - 12:45
Enterprise tipping is NOT the corporate version of cow tipping, although it is fun to play with the analogy. ;)
Consider rewriting the following description of cow tipping (Wikipedia) replacing “cattle” and “cows” with “business units.”
"The urban legend of cow tipping relies upon the presumption that cattle are slow-moving, dim-witted, and weak-legged, thus easily pushed over without much force. Some versions of the legend suggest that because cows sleep standing up, it is possible to approach them and push them over without the animals reacting. However, cows only sleep lightly while standing up, and they are easily awoken from this state. Furthermore, numerous sources have questioned the practice's feasibility, since most cows weigh over half a ton, and easily resist any lesser force."
We often approach agile adoptions in large enterprises as if it’s possible to “approach them and push them over without the animals reacting.” For example, I often run into an enterprise agile adoption objective of transitioning 90 percent of the enterprise to agile development in 12 months. The reality is more involved; more like a sports or dance team getting great at what they do, as described by Peter Senge1:
“At some time or another, most of us have been a member of a ‘great team.’ It might have been in sports, or the performing arts, or perhaps in our work. Regardless of the setting, we probably remember the trust, the relationships, the acceptance, the synergy—and the results that we achieved. But we often forget that great teams rarely start off as great. Usually, they start as a group of individuals. It takes time to develop the knowledge of working as a whole, just as it takes time to develop knowledge of walking or riding a bicycle. In other words, great teams are learning organizations—groups of people who, over time, enhance their capacity to create what they truly desire to create.”
As an agile transformation consultant, I’ve developed two rules of three to remind myself and my clients about the challenging, yet rewarding work of tipping the enterprise toward a new way of working.Muscle Memory Rule of Three
Scrum coaches are well aware of the muscle memory rule of three. It takes at least three iterations for a team to get comfortable with the rhythm of Scrum and its ceremonies, and develop a sustainable practice and velocity that allows it to plan and execute longer range. Think of Scrum as square dancing. It’s not enough to go through the dance moves just once; it takes multiple repetitions for the rhythm and coordination of the dance to sink in—the dancers need to develop muscle memory.
When scaling this iterative, incremental approach to a team of teams in frameworks such as the Scaled Agile Framework® (SAFe®), this same muscle memory rule of three applies. The team of teams needs to experience the rhythm and coordination of SAFe at the program level to get familiar with it.
Think of SAFe at the program level as a troupe of square dance teams that needs to dance together with moves between the teams (e.g., passing bandanas or cowboy hats). The planning event is where the dance of the upcoming program increment and the moves between teams are discussed. Like square dancing at the team level, it takes multiple passes at dancing at the team of teams level for the troupe to develop good coordination. In other words, it takes multiple program increments for the team of teams to get good at coordinated development and at handling dependencies between teams.
Here at CA, Agility Services has developed an approach to launching a program (a team of teams) called Ready > Sync > Go. During the Sync phase, each team gets good at dancing as a team while the program-level folks plan the coordinated dance of the team of teams. Once the teams and the coordinated dance plan are ready, the program holds its first planning event to launch the coordinated development of the team of teams. CA Agile consultants make sure the client organization builds its muscle memory for this coordinated dance by applying the rule of three.
Before moving on, I want to make a caveat. The muscle memory rule of three is not sufficient for a team or a team of teams to get great at the dance; merely good enough to improve on their own. I do believe in Malcolm Gladwell’s assertion (from his book “Outliers”) that it takes roughly 10,000 hours of practice to achieve mastery in a field. Finally, mastering agile development involves more than the iterative, incremental process pattern of Scrum and SAFe.Organizational Learning Rule of Three
Personal change is hard; changing how we work as an organization is harder. As a transformation consultant, I frequently hear comments like, “We’ve been doing development this way all of my career, what’s wrong with it?” I’ve learned through experience that this reaction is not a request for the rationale behind a new way of developing, it’s a request for empathy. Organizational change is threatening. No amount of rational argument on my part, as an external consultant, is going to ease that discomfort.
I developed the organizational rule of three while addressing this resistance to organizational change. There’s a progression to overcoming this resistance even in the face of successfully launching programs, and here’s what it often looks like:
With the successful launch of the first program, I hear, “Well, we got lucky, we picked a good set of teams and an application area that is well-suited to agile development.”
The second successful program launch helps dispel the “we got lucky” rationale.
With the third successful program launch, the organization starts to own the process and make it part of its DNA.
Only when we reach this point has the organization reached the tipping point, that is, the point of no return. In his book “Tipping Point,” Malcom Gladwell describes it as:
“The tipping point is that magic moment when an idea, trend, or social behavior crosses a threshold, tips, and spreads like wildfire.”
When I work with an organization’s Agile Center of Excellence (COE), I describe this tipping point as the moment when the center stops pushing agile development and the organization starts pulling the center’s coaching services.
I don’t believe in big-bang transformations. In an enterprise with multiple business units, tipping the enterprise entails tipping individual business units. And like the progression of overcoming organizational resistance with respect to successful program launches, you have to tip multiple business units to tip the enterprise as a whole.
In this figure, the red down arrow represents the tipping point for that organizational unit and reaching that tipping point entails the rule of three with respect to the subunits.Implications of the Rules of Three
The principal implication is that the urban legend of cow tipping is a bad mental model for enterprise tipping. We should dispel the myth that this is a simple, quick methodology change.
Enterprise tipping (truly changing the way an organization works) requires patience, focused effort and leadership.
It’s why John Kotter’s 8-Step Process for leading such a change starts with:
1. Create a sense of urgency
2. Build a guiding coalition
3. Form strategic vision and initiative
And ends with:
6. Generate short term wins
7. Sustain acceleration
8. Institute change
An Agile COE can help focus an enterprise’s agile adoption tipping initiative. I’ll talk more about them in the next blog post in this series. Stay tuned.
1. Senge, Peter M., The Fifth Discipline Fieldbook: Strategies and Tools for Building a Learning Organization, The Crown Publishing Group, 2014.Jim Tremlett
All About Agile - Thu, 01/14/2016 - 06:00
I did a post last week called ‘Are People Really Afraid To Change’. If you have a minute, go check it out before you read on… we’ll wait… I’ve never been skydiving. Almost went in my early 20’s, but when the time came to go, I didn’t have any money so I had to stay […]
All About Agile - Mon, 01/11/2016 - 06:00
Thought Exercise One Let’s say for the moment that I am the CIO of a mid-sized company. I have a team of 100 or so people building software. Let’s also say that those 100 people are largely dedicated to 10-15 smaller products, there are few dependencies between those products, and we are currently using traditional […]
All About Agile - Wed, 12/02/2015 - 10:00
Up to this point in this series on the 12 failure modes in agile transformation, I’ve covered topics around failure in leadership , failure in workflow and failure in congruency. These last three failure modes concern the overall sense of “transition”: How are we tending to our sense of change—not just as steps in a process, but as humans and teams in transition?
When we leave the human context behind—when we ignore the time, safety, and direct experience required to shepherd us through change—we have failures in transition.10. Ineffective Plan for Transforming Beyond IT
So often, when I speak with executives about their agile transformation, they’re looking at how to build products faster: getting to market faster, with more innovation, by making their engineering teams more efficient. They bring this “work order” to their product or IT group and declare that an agile transformation is in play. Teams align along some scaling approach and metrics are gathered around overall productivity. But speeding up value delivery by concentrating your transformation on product development is sub-optimal.
Concentrating agile transformation in the development organization looks slick. It’s something we can grab onto. Its practices have a sense of speedy efficiency around them, and that’s enticing. It can grab the hearts of people who thrive on heroics. Testers, developers and UX are “transformed” into a new way of working across the product teams. Through their work, the product engine begins to attain the purr of feature delivery. But is this truly transformative?The essence of a great agile transformation is having a vision that goes far beyond how engineering teams align their practices in delivery cadences. A real transformation takes in the whole system.
With brutal honesty, we must look in a mirror that reflects our entire system of value creation and delivery and ask, “This being so … so what?”
In other words, given the state of our business—our whole machine—how we can be transformative in an enduring way?
- Declaring the transformation from the executive level is insufficient.
- Rolling out all teams at once is insufficient.
- Starting up teams randomly is insufficient.
- Training everyone at once is insufficient.
Each of these is a useful but ultimately ineffective action, leaving the transformation sputtering toward a “GEFN” (Good Enough For Now) end state.
At a recent conference, I was talking with a gentleman about agile at its most basic level. He had no idea what it was and why people would want it for their engineering teams. As I talked about small teams in cadences of delivery that are bounded by planning and reflection, he asked about scaling. What can possibly be useful about agile in really complex situations? To confirm the agile approach specifically in complex environments, I referred to some of the “probe / sense / respond” language from the Cynefin view of complex thinking. That is, agile groups in complex domains recognize the need to create innovation through practices that emerge from action and reflection.
We took our discussion out to the corporate level as I explained how our organization had been applying agile practices at a corporate level for years. I also brought in some of the lean principles that guide software agility but also can guide businesses. In the end he asked me why people were just talking about agile in the product development space; why weren’t we thinking larger and broader into the business overall? Indeed.
We can turn this around. An agile transformation is far bigger than the efficiency of delivery teams; it goes beyond IT. Imagine your transformation looking like this:
- Led by a visionary leadership team that wants to transform the way the entire company does business
- Guided by lean principles of value flow, pulling work in a smooth flow, and continuously improving your work so that you continuously set yourself up to innovate
- Encouraged to reduce organizational friction in processes and interactions
- Informed by recurring value stream mapping that invites teams to push the boundaries of the stream up and out
- Invigorated by increasing employee respect and admiration for the tribal work
- Engaged in a bias toward learning through transparency and collaboration
- Coordinated across the value stream in a synchronized cadence of action, learning and planning
- Set in an orbit around customers as your sun with the entire organizational trajectory spirited by the pull of customer value
My sister Claire doesn’t own an ATM card. This is not because there are no ATMs where she lives; her metropolitan area is surrounded by them. When I asked her, “Why no card?” she said, “Jean, I like to go to the bank. It’s all about the people.”
How we get our money is a conscious choice. For Claire, that means creating and maintaining a relationship with the people at her local bank. That bank earns her business through how they “show up” for her; they’ve created an unspoken bond of loyalty.
When we define our agile transformations, what are we doing to create “Claires”? Do we seek to inspire loyalty to the transformation effort? How does the transformation lead teams to engage with their colleagues in defining success beyond practices and metrics? What would loyalty look like?
To be clear, process and structure are necessary. But they are insufficient. And worse, they can lead to a false sense of success in the transformation. We’ve checked off the boxes, but we haven’t checked in with the people.
When I think about this agile transformation approach I fear the adoption of a something akin to a cargo cult science: “cargo cult agile.” That is, if we simply apply these practices and measure these things, surely success will come. If people fail in adopting the practices or fail to live up to the metrics, there is something wrong with the team. If you don’t get the results you want just add more process, structure and metrics. If the transformation is considered complex (and what transformation isn’t, when you’re in a large organization) we rely on process and structure all the more. Again, process and structure are necessary—and clearly they must be used as a guide for appropriate synchronization of the transformation effort—but alone, they are not enough.
My colleague Rachel Weston Rowell recently pointed me to a New York Times article about how IBM is changing the way it works. It’s embracing design thinking and aggressively rolling out training to guide how the company reinvents itself. Virginia M. Rometty, IBM’s chief executive, and her executive team were among the first to embrace the new approach. The training varies, with executives getting one-day sessions; product managers, a week; and new designers, three-month programs. In all, about 8,000 IBM employees so far have had some in-person training in design thinking. It’s an impressive number, but it’s also only two percent of the IBM workforce.
Why design training? Because transition must start with empathy: we must invite ideas that depart from our normal mode of creating and executing. As we move through agile transformations, empathy must be the driving force guiding how we engage with individuals. What do they want? what are they willing to let go of? What advice do they have about success? What might it look like to embrace a larger sense of “team” across many teams during the agile transformation? And finally, how can all this great process and structure truly transform how we passionately engage in the work we love?
In this vein, we must consider how people will fit: how their personal values will align with the aspirational values an agile transformations invites us to hold dear. In her TEDxMileHigh talk, Natalie Baumgartner talks about “fit” for people in their work. As she describes it, fit goes far beyond role descriptions and responsibilities. It guides our willingness to engage in a new view of how we work that supports our values, our personalities and our communication styles.
For my part, a great agile transformation feeds off of people’s positive perspective of the change. As Natalie says with regard to fit, “It’s definitely a risk to make a change; it is a much greater risk to stay where you don’t fit.” Agile transformation involves myriad risks. Use these risk situations as an opportunity to reflect on what’s going on beneath the surface of the process and structure.12. Ignoring the Path of Individual, Team and Organizational Transitions
So far I’ve covered 11 failure modes in agile transformations. And yes, there are other modes in different technical and organizational contexts. But I’ve saved this failure mode for last because I believe it’s the least understood, and hence the least addressed.
We ignore the work of true transition not just at the organizational level, or even at the team level. We ignore the work of transition for each individual impacted by the transformation.
Here’s what I’m thinking. In any large transformation effort, even when we just know it’s good and for the right reasons, there’s always someone who has something to lose—whether true or imagined. An entire team can bristle at the “directive” to “go agile.” Directors who’ve attained their stature through their ability to push through adversity are now being asked to find their significance in how they guide and serve, not push. Heroes are losing their motivation as the firefighters as they’re incentivized to work collaboratively in support of the the team. Teams are asked to alter their composition and perhaps their highly guarded bond. All of this in the name of a well-meaning agile transformation.
Often, an agile transformation is driven by a fear of market shifts, of disruptions that can obliterate your customer base. In this tumultuous environment, we recognize the need to change how we work to deliver innovation and value. But perhaps we don’t recognize the underlying organizational unease this sets in motion. The well-meaning goal of creating a better way of working generates the unintended consequence of a big pile of FUD (Fear, Uncertainty and Doubt.)
What to do?
In his books, Transitions and Managing Transitions, William Bridges encourages organizations to engage in transition “rituals” that smooth the way and bring individuals along with the change. A vision with a goal in mind is a great start, but starting with the beginning is not. The small or large set of changes that an agile transformation asks of us needs more scaffolding to truly attain that goal. Our effective transformations acknowledge these three important stages of transition, in this order:
- Endings. People in transition often go through a subtle cognitive shift; they gradually stop thinking of the “we” and move to an “I” in something of a “mourning,” stimulated not by the transition process itself but by their personal reactions to the process. People can find themselves disoriented and disenchanted. In this stage, we guide team members to let go of what they’ve believed or assumed about themselves or about how they see themselves in their work environment and their attitudes towards others.
- The Neutral Zone. To move forward, we accept the reality of the gap between what was and what may be, sort of standing in the middle of the street. You can’t stay here forever, but you know you need to be here to get to the other side. I often talk with teams about “the goo of ambiguity.” You’ll know you’re in the neutral zone when you find yourself smack dab in the middle of that uncomfortable unknowing. In this organizational and process wilderness, you can begin to craft a different reality that can enhance or expand what might not have seemed plausible before.
- The New Beginning. “You finish with a new beginning.” How do we know we are moving out of the Neutral Zone? We begin to gain greater clarity about the path of our transformation. We genuinely reach for the change, seeing in it the possibilities of what can be true. We have the sense of emerging engagement and dedication to the success of the transformation. Our leadership team, having gone through this transition with us, speaks the language of, “What task can we now take on as an organization, a task so monumental it requires all of us?”
David Logan’s TED talk about tribal leadership complements Bridges’ work with regard to how we guide people to a more powerful and devoted transformation. If individuals think, ”My life sucks,” then we start there. Use language that invites people to view the transformation as a way to move from what sucks to a place of feeling great. We move through stages of, “I’m great, and you’re not,” to an organizational sense of “We’re great!” When we pay attention to these important steps in transition, we feed the fire of a great agile transformation: for individuals, for our teams and for our entire organization.
Steve Farber talks about leadership born of love, energy, audacity and proof. Here’s where we show up for successful agile transformations. Out of our love, energy, audacity and proof, we lead agile transformations informed by the necessary work of transition. We do this in service to our teams—the people who, with great anticipation, love what we do.Pulling It All Together: Be Your Kindness
Agile transformations are hard for systems, for organizations, and most importantly, for humans. Acknowledging the potential ways a transformation can fail helps you build awareness of where your best intentions either engender success or perpetuate deflating failures.
Let’s review the 12 failure modes in agile transformation:
- Lack of Executive Sponsorship
- Failure to Transform Leader Behaviors
- No Change to the Organizational Infrastructure
- No Business View of the Value Stream
- Failure to Decentralize Control
- Unwillingness to Address Illusions Around Distributed Teams
- Lack of a Transformational Product Manager
- Failure to Create Fast Feedback
- Short-changing Collaboration and Facilitation
- Ineffective Plan for Transforming Beyond IT
- Viewing Transformation Solely as Process and Structure
- Ignoring the Path of Individual, Team and Organizational Transitions
In outlining these 12 failure modes, I have taken a very personal perspective on what I view as the modes that cause us the most pain. Now, here is my invitation to you:
- Re-read the 12 failure modes.
- Decide on the pain that each mode is causing you, or could be causing you.
- Find out what is the most painful for you personally. Which is the one that catches your breath or brings an immediate sense of exasperation?
This is how you’ll know where to start in creating and sustaining a healthy transformation. Be a kindness to yourself in how you bring this information into your organization, your teams and your life.Jean Tabaka
All About Agile - Tue, 12/01/2015 - 08:28
I’m always looking ahead to the next planning or the next estimating meeting. I teach this behavior to my clients whenever I’m coaching a new ScrumMaster or Product Owner. I start off by involving them in what I’m doing, showing what needs to be done and by explaining my thinking. The teaching is very experiential, yet incomplete in […]
All About Agile - Wed, 11/25/2015 - 11:43
Today, I was faced with the unfortunate task of renewing my driver’s license. It’s been 10 years since the last renewal and I remember the last time I was at the Maryland MVA (Motor Vehicle Administration) office, I waited for what seemed to be an hour. We all know how painful the experience is. You stand […]
All About Agile - Thu, 11/19/2015 - 11:58
The Scrum approach to delivery has produced the greatest team in the world. And the elements behind the team’s success are repeatable, meaning your team could be next in becoming the greatest team in the world. (That sure has a nice ring to it.)
View image | gettyimages.com
The team I’m talking about is the All Blacks, which retained its Rugby World Cup crown recently—the first team to do so since the tournament started almost 30 years ago. If you’re not familiar with the All Blacks, in the past four years, the team has only lost three of its 54 matches and the last time it lost consecutive games was in 2011. In fact, the All Blacks hasn’t lost on its home turf since 1994, before some of the current players were born. Yet their captain is from tiny Kurow, New Zealand (population 339), the coach is a former policeman and none of the players has the letters MBA after their names or got on the team through family connections. The team also comes from a country with a much smaller population and lower GDP than its next few rivals, so they’re not the biggest or the richest.
How does a country with more sheep than people produce a team recognized as the world’s greatest, and what does this have to do with Scrum?
Indeed, why are we referencing a sports team when most of us work in teams in urban offices where we chase paper and deadlines rather than an oval-shaped ball? Because high-performing teams, no matter what their domain, share many commonalities. And it’s a happy coincidence that the All Blacks practice the sport that gave the Scrum approach to product delivery its name. (Very briefly, for those who have just joined us, two Japanese researchers of high-performing teams in 1980s workplaces came up with the term “Scrum” as a good fit for the characteristics associated with high performance, including speed, flexibility and handling uncertainty.)
Let’s examine a few of the characteristics of the greatest team in the world to better understand how our own teams can become ultra high-performing. Given that rugby in New Zealand/Aotearoa is our metaphor here for high performance, I’ll be introducing a few new words into your vocabulary.Principle 1: Be Your Role
People on high-performing teams know their roles inside-out. Knowing your role doesn’t just relate to the bullet points in your job description: It means intrinsically knowing how your skills influence your teammates and how you collectively use these skills to succeed.
View image | gettyimages.com
For All Blacks captain Richie McCaw, who has an impressive win rate of around 90 percent from his 140 caps, this meant sitting down with his uncle when he was a teenager and identifying on a scrap of paper what he needed to do to become a “G.A.B.”—a Great All Black—then taping it to his bathroom mirror so he could see it every day. In other words, visual management. Sound familiar? In your team, what’s the difference between a developer and a great developer, or a product owner and a great product owner? What about for your own role? Probably not characteristics that are bulleted in your job description.
Knowing your role means sticking to the basics, even when things are difficult, and trusting your team to do the same. For example, if you’re leading 8–7 in a tense final against your bogey team (France) you should focus on solidly executing the fundamentals, again and again. Nothing fancy, just K.I.S.S. This is where your 10,000 hours of purposeful practice pays off. Several past and present All Blacks sprint fast enough to compete in the early rounds of the Olympics 100 meters event. They’ve completed years of purposeful practice in order to deliver effectively under pressure. Keep executing the drills you have practiced in training. Don’t skip your planning sessions or retrospectives because “you’re too busy” or “there’s a deadline.”
Once you know your role, the next step is to elevate it, redefine it and be your role. For example, number 10 for the All Blacks, Dan Carter, has arguably redefined the role of first-five eighth (relax, that’s as technical as we’ll get with rugby). In Japanese martial arts, this aligns to the concept of shu-ha-ri. While many of his contemporaries are content to score points through kicking, Carter is sufficiently cross-functional to play well outside his role and carry the ball across the line, rather than pass it to another player. Given that several players oin the All Blacks are similarly cross-functional, that makes for a powerful advantage over mono-functional teams. We’ll cover this more in the next section.Principle 2: Be Cross-functional
Fundamental to Scrum is the cross-functional team, which means there are multiple paths for work to reach the “done” state. This complements, rather than contradicts, the principle of knowing your role. On a rugby team there are 15 players, each with a specific role. However, a player’s role is superseded by the team’s overall goal of delivering the ball across the try line (or goal posts). This means that a player like Dan Carter, whose primary role is to score points through kicking, has also scored 29 tries (similar to a touchdown) in international rugby because he is T-shaped. Unlike many of his rivals, his jersey is just as dirty at the end of the game as the rest of the team.
View image | gettyimages.com
When we talk about “T-shaped people” in agile it means people whose deep technical knowledge is complemented by a breadth of skills. This counters situations where a person becomes a single point of failure or a bottleneck, as is so well demonstrated in the agile cult classic book, The Phoenix Project. Teams in the workplace can incrementally increase their cross-functionality over time by creating a simple skills matrix and allocating a few hours per week to upskilling. After three to six months, the team will be quantifiably stronger and have reduced its dependence on a single individual.
As a team member your versatility makes you more valuable to the organization, and that’s something to bear in mind for challenging times.
Cross-functionality goes hand in hand with diversity and high performance. The All Blacks are arguably the most diverse team at the Rugby World Cup, and it’s no accident that in recent decades, as the team has embraced more diversity, it has won more games. Players come from several different cultural, religious and linguistic backgrounds. Harnessed to a strong vision (discussed in the next section), this diversity creates open-mindedness around trying new ideas and synergies that enable team members to be authentic and bring their whole selves to the team. Research confirms this leads to increased creativity, better decisions and harder-working teams.
Your team may be more diverse than you realize. Many workplaces lose their human touch and it’s easy to get caught up in “doing” our work at the expense of building high-performing teams and getting to know the person behind the job title. A half-day investment in effective team-building activities a couple of times per year (which needn’t involve blindfolds, high wires or singing Kumbaya) will pay dividends, create “ba” and directly improve team performance.Principle 3: Be United Around a Vision
“We are the most dominant team in the history of the world.” Pretty audacious, huh? Perhaps not. The All Blacks created this vision before other teams started calling them “the world’s greatest team.” However audacious it is, it would be much harder to become the world’s most dominant team with a watered-down vision that exudes mediocrity, or with no vision at all. There’s no doubt about what this team wants to achieve. So, back to our teams in the workplace: what’s your team’s vision?
View image | gettyimages.com
We’ve already talked about being your role and being cross-functional. Perhaps it’s no surprise how well the All Blacks embody teamwork and uniting around a collective vision, given the strong influence of Maori and Polynesian cultures on the team. As the cliche goes, “there is no “I” in team.”
Just as Japanese culture embodies Lean principles, Maori and Polynesian cultures elevate the importance of the team (or family, collective or other group of people) over the importance of the individual. Western cultures, by contrast, often elevate the individual over the team (e.g. individual performance targets) which can lead to local optimization at the expense of the overall system’s performance. Focusing on team performance as the unit of success has a dramatic impact on how the team plays.
Scrum and SAFe® require a sprint goal and product vision, respectively. Build on that in your workplace and establish a vision for your team. What are its values, goals and outcomes? This fosters a team that is united, focused and aligned, rather than a group of people who “happen” to work together.Next Steps
Several All Blacks are expected to retire in the coming months. The good news is that there’s now an opportunity for another team to be the world’s greatest. Maybe it will be a team in your organization. How can you elevate your team’s performance so it exhibits the same traits as the world’s greatest team?
- Help your team move from doing their role to being their role
- Make cross-functionality and T-shaped team members the norm through purposeful practice
- Create a compelling vision with your team that encourages high performance
There’s a Maori phrase that concisely sums up these themes:Ko ahau te kapa, ko te kapa ahau – I am the team and the team is me." Suzanne Nottage
All About Agile - Wed, 11/18/2015 - 05:46
I was recently asked to do a short talk and Q&A for an agile project management meetup in London. You can see the full video here: https://skillsmatter.com/skillscasts/7115-agile-project-management-in-a-larger-organisation Lots of great questions, so hope this gives you some useful insight that helps you with your own work. Kelly.
All About Agile - Wed, 11/11/2015 - 00:37
Learn more about transforming people, process and culture with the Real Agility ProgramAfter a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the … Continue reading The Scrum Master and Product Owner as leadership partners →
The post The Scrum Master and Product Owner as leadership partners appeared first on Agile Advice.
All About Agile - Mon, 11/09/2015 - 09:12
(Presented as an accompanying case study to Part 4 in the Scrum Alone is Not Enough series.) In the previous post, we discussed how it’s not enough to practice Scrum at the Team level and expect that it will solve all problems. Senior Management has to get involved for real Agile change to happen and high performance to be achieved. An important aspect of that is Systemic Problem Solving, which we’ll look at closer using the World’s Smallest Online Bookstore as a case study for examples. Systemic Problem Solving Most teams that I encounter are very good at solving specific problems locally (at the team level). What is missing is a bigger picture, holistic view. Systems thinking (pdf) is a tool that helps you take a Systemic – or bigger picture – view of whole systems. Let’s look at a couple of common organization problems as examples – namely “Long Regression Cycles” and “Product Owner can’t seem to stay focused on the big picture”. Long Regression Cycles Hereafter: LongRegressionCycle The Org Team recognizes that it has a problem with the regression cycles as illustrated: When long regression cycles are an issue, without a systemic approach the organization might first try adding more people to do regression testing. As a second step, they might try automated testing through the browser/GUI using a special team who has access to an expensive tool. Unfortunately, as we see below, this will likely lead us down the wrong path: This is a simple causal loop diagram –it’s intended to help us look past the initial problem and see deeper causes. Variables create cause and effect within a system. In a causal loop diagram, you start with a single part of the system that you can already identify and just keep asking “what influences this part?” then draw links between the interconnected parts using arrows pointing in the direction of influence. Once you can no longer think of additional parts or influences to add, you have a closed loop. In this example, we can envision what may happen by playing through the loop, starting at “Features added” and following its influence to the “Regression Cycle Length”. Keep going, and we can see that the often-used simple fix of asking a special team to automate regression tests through the Browser/GUI influences many variables and eventually exacerbates the problem that it was intended to solve. The diagram makes it clear that GUI based automation is fragile, and having all the work done by a special team is creating an island of knowledge. These two problems combine, increasing the time it takes to find bugs and eventually even increases the number of bugs themselves. To solve the underlying initial problem, we would have to also find an approach that doesn’t recreate these same issues! Instead of a special team doing all of the test automation, the work should be done by every team. Instead of doing all the automation through the browser, do most of it through public api’s (or their equivalent) that exist at the boundaries of the system. Before making any change, the team creates a new version of the causal loop diagram to see if their proposed solution is an improvement on the original. Product Owner Can’t Stay Focused on the Big Picture Hereafter: UnfocusedProductOwner In a second example, the Team sees a Product Owner making frequent revisions to the Team’s work in Sprint. We can talk to the PO about this, but we can’t just expect the PO to change unless we also identify and fix the underlying problem. As this image illustrates, we can see that the real problem is that the PO is under daily pressure from stakeholders to solve real and perceived customer problems. The challenge is how to set aside enough time to deal with those issues, while still making progress in the bigger goal. A causal loop diagram like this should help the organization discover the need for Portfolio Management, which would give the Product Owner some boundaries on how much short term work they should accept from the Team. In each case, the key point is that the Org Improvement Team must make sure that they’re solving the systemic – and not just surface – problem. So let’s look at how the World’s Smallest Online Bookstore teams might do that, using a Scrum-like framework to achieve it. Our World’s Smallest Online Bookstore Organizational Improvement Team is working in two-week Sprints to stay in sync with their Development Teams. As we learned in this post, the Org Improvement Team operates in a manner similar to a regular Scrum Team, just with a few slightly relabeled components. Let’s see how the Organizational Improvement Team will tackle these problems. Organizational Improvement Queue (aka Product Backlog) Since the causal loop diagrams above showed us that creating special teams for test automation and simply asking the Product Owner to change weren’t going to solve the problems. The Org Team can avoid wasting time on ineffective, localized solutions and focus the Improvement Queue on finding specific things that will contribute positive systemic results. Such as: LongRegressionCycle – Involve more members of each Development Team in test automation; LongRegressionCycle -Find alternate means to test automation that don’t involve the browser; UnfocusedProductOwner – Support the Product Owners in saying no to more expedited customer requests… Organizational Queue Refinement (aka Product Backlog Refinement) After discussion with the Development Team representatives and the Team level Product Owners, it is agreed that the pressure that the POs feel to respond to all customer issues within two days is getting in the way of the Teams delivering on both quality (which leads to more customer issues) and the big picture. They also identify the need for site license JetBrains IntelliJ and “Reducing Product Build Times from 15 minutes to 5 minutes”. Sprint Planning The Org Improvement Team commit to running several experiments to resolve the UnfocusedProductOwner challenge. Since this problem will need several months to address completely, they decide to do the following: […]
All About Agile - Fri, 10/30/2015 - 09:00
Recently I experienced what was one of the saddest moments of my career when, while re-watching “Return of the Jedi” for the 116th time, I realized I was coaching a company that was basically the Empire.
Surely you remember the movie's very first scene? Darth Vader arrives on the Death Star to help put the long-delayed project back on schedule.
Here’s the conversation that ensues between the commander, our de facto Death Star project manager, and Vader, our business stakeholder. Swap out the titles and you can almost imagine it taking place in a conference room in a company not so far, far away.
Commander: “I assure you Lord Vader, my men are working as fast as they can.”
Vader: “Perhaps I can find new ways to motivate them.”
Commander: “I tell you that this station will be operational as planned.”
Vader: “The Emperor does not share your optimistic appraisal of the situation.”
Commander: “But he asks the impossible … I need more men.”
Vader: “Then perhaps you can tell him when he arrives.”
Commander: “The Emperor’s coming here?”
Vader: "That is correct, Commander. And he is most displeased with your apparent lack of progress.”
Commander: “We shall double our efforts!”
Vader: “I hope so, Commander, for your sake. The Emperor is not as forgiving as I am.”
You know you’re in trouble when Lord Vader suggests he’s the more forgiving of your bosses!
If you’re the commander, then, at this point, you are very worried. Because you already know you don’t have the people to succeed. (You may think throwing “more men” at the problem will make it go away, but Brooks’ Mythical Man Month tells us that adding manpower to a late complex engineering project only makes it later.)
And you know that if you fail, you’ll get force choked.Fail with a Culture of Fear
This is what you call a culture of fear. It pains me to see this in my coaching, because the problem with a culture of fear isn’t just that it doesn’t work. Nothing shuts down innovation, motivation and collaboration faster than a fear-based culture.
Fear can be persuasive in the short term, but with this tactic you’re going to lose a lot of people over the long term. People will make promises they can’t keep and say things are going well, even when they aren't, to avoid punishment. Fear will exacerbate work delays as people obscure the true status of the work, and, more importantly, it will result in a loss of your workers as they get force choked out of the organization.
Dan Pink has pointed out that extrinsic carrot-and-stick motivation was designed for 20th-century work. In the 21st century, people feel trapped by organizations that use this approach: people often know the best thing to do to get the work done, but they don’t feel empowered to do it because they’re stuck in this systematized culture of fear.Empower Your Teams
In a culture of fear, teams don’t feel empowered. Slap their hands a few times and they’ll stop trying. Eventually you’ll end up with a team that waits for directions, that waits for someone else to make decisions for them rather than moving forward. As the president of 3M said,If you put fences around people, you get sheep.
From a manager’s point of view, this can actually seem more frustrating than it does compliant. I’ve heard managers complain that “my team won’t do anything unless I tell them to do it,” without acknowledging (ironically) that they’ve created this culture by not trusting their teams, or by punishing them for straying outside the fences.
We often think of the military as the epitome of command-and-control management, but in reality even the military recognizes the importance of decentralized decision-making. A military commander might radio his troops and tell them to “take the hill,” but he doesn’t need to tell them HOW to take the hill: he lets THEM decide the best way to do it, based on local information and the situation on the ground. In a fear-based culture, if you tell your team to take the hill, they may very well stand still and say, “How?”Adapt to Take Out the Death Star
Think about a boss in your life with whom you worked really well. I bet that person had trust and faith in you to get your job done, and had your back if you needed help.
Now think about the Battle of Endor, toward the end of “Return of the Jedi.” Admiral Ackbar has assembled the entire rebel alliance fleet and they’re approaching the Death Star, intending to take it out and save the galaxy. But as they get closer they realize that the Death Star’s shield hasn’t yet been deactivated by the team on the ground with Han Solo and Princess Leia. Then they see the fleet of imperial star destroyers.
At first Ackbar wants to retreat, but Lando Calrissian lobbies him to change tactics—engage the star destroyers in battle, despite being outnumbered, so that Han and Leia have more time to work on the shield. [SPOILER ALERT] Ackbar assents: the fleet spends a little time picking off tie fighters and star destroyers, Solo and Leia get the shield down, and Lando and Wedge Antilles successfully destroy the Death Star. Yee ha!
To accomplish an epic feat like this you’ve got to collaborate, communicate, respond to feedback and trust your colleagues to do their jobs.
Would Vader have listened to advice, like Ackbar did? Would the Emperor have trusted his team on the ground to pull through, even though they were late? Heck, would you dare to give either one of them feedback on their plan, in the heat of battle? I didn’t think so.
But let’s be honest: not every project is the Death Star. In fact, to act like every project is mission-critical is disingenuous—not to mention demoralizing. And when you do have that project that feels like life or death, everyone already knows: you should all be in alignment already, with everyone on board, eager to work together to get the job done.Mind the Trap
Ackbar was right to call out the trap. Your trap is thinking that you can have control over everything, and thinking that having control would improve your circumstances. In truth, especially at large organizations, you can’t possibly see everything that’s coming—much less control it.
Agile organizations avoid the trap by reflexively responding to change, delegating decision-making closer to the ground, improving their visibility into the work and making adjustments based on feedback.
To become an agile organization, you have to start by changing your leadership style. Managers: you can coach all you want at the team level, but if your executives still go around acting like Emperor Palpatine, you’ll end up with no change to the business and no improvement in your results.
You also have to change your system. Sure, everyone may have a little dark side in them, but most people aren’t genuinely evil—they’re just a product of the system they’re in. In the same way that carrot-and-stick systems aren’t good motivators for today’s style of work, fear-based systems don’t produce positive long-term results. Change the system, however, and you’ll change the behaviors of the people in that system. Take it from a scoundrel like Han Solo, who, adopted into a system of people collaborating for a better universe, turned himself into a hero.
(image: Flickr, CC)Use the Force
We know that fear is the path to the dark side. Yoda tells us that fear leads to anger, anger leads to hate, and hate leads to … suffering. Let’s put an end to cultures of fear and suffering! It’s no way to work, and besides, it’s not going to get your organization where it wants to go. (Unless you want your competition to fly into your core reactor and blow you to smithereens.)
Do not give in to the dark side! You have the power at your disposal to change. Before “The Force Awakens” later this year, I hope you’ll join me on a journey towards greater business agility.Todd Sheridan
All About Agile - Tue, 10/27/2015 - 09:31
I think this is the last post in my series on using metrics to gauge the success of an enterprise transformation. As an enterprise transformation consultant, one of the key challenges I face is ensuring the steps I recommend throughout the transformation will help the organization achieve their goal, or the business drivers that inspired the transformation. In part […]
The post What’s the Pulse of Our Enterprise Transformation? – Part 3 on Transformation Scorecards appeared first on LeadingAgile.
All About Agile - Mon, 10/26/2015 - 14:46
A nice article on HBR - "Why Organizations Don't Learn", byFrancesca Gino and Bradley Staats; take a look.They list these reasons:Fear of failureFixed mindsetOver reliance on past performanceAttribution biasThe authors then give some strategies fo...
All About Agile - Mon, 10/26/2015 - 08:28
What is Red Yellow Green? Red-Yellow-Green (or Red/Amber/Green) is a status reporting mechanism used to help executives understand the current state of a project. Green means everything is good; we’re on track both with time and budget. In some cases, green means within 5% of budget. Yellow means there is some risk that there are scope or time problems, but with sufficient re-planning we can come back to target. Yellow is usually measured by some number crossing a predetermined threshold. Red indicates the project is in serious trouble. Models RYG is just a model of reality (in truth, all reporting simply models reality). All models hide details with the goal of making the situation easier to read and understand. Some are hidden so much that the truth gets lost. A team’s Task Board, Scrum Wall, or the overall Portfolio Kanban Wall are all first-order models of reality. While not perfect mirrors of the current state of the work, they’re fairly close. They help demonstrate qualitative information; i.e. which stories are complete, not just how much. A Release Burndown Chart, Burnup Chart or Cumulative Flow Diagram are all second-order models of reality. In other words, they summarize information contained on the Walls/Task Boards. They’re useful because they help spot trends. The Cumulative Flow Diagram provides the most information on trends, but it still has less information on it than the Portfolio Kanban. Red Yellow Green Reports are models of the charts, in that they summarize the charts, hiding even more informational details. They assume that a plan’s scope, budget, and time are fixed and unchanging. Models might be adequate in a world where these are true, but in a world that accepts change as the norm, colour-coded reports are dangerous. At best, these reports don’t measure truly done so much as whether a team is on track to make a target. In addition, since RYG reports usually have green as a default state, often there are too few questions that are asked until it’s too late. Charts Even burndowns, burnups, and cumulative flow diagrams are imperfect because they focus on output (# of Stories or story points achieved) and not outcomes (the right features delivered to the customer.) Charts of all forms appear to promise certainty, when there isn’t any, which creates a false sense of security. If we’re going to chart at all, we should use forecasts and not precise lines, and make it clear this a forecast. If your chart just shows the average velocity, then you should provide a forecast that says we have a 50% chance of achieving this rate for the foreseeable future. If you want to get more sophisticated, you can track error bars as well. Measure your best and worst three Sprint’s Velocity in the last six months, and use these as your 20% and 80% confidence bars. Then you can say that you’re 80% confident you will do at least as well as your worst three sprints, and 20% confident that you will do as well as your best three sprints. Even this model has a weakness in that it assumes your velocity will follow normal distributions. The reality is likely that it won’t. However, forecasting with error bars (or lines) usually gets the idea across that we’re forecasting a range of possible outcomes. Genchi Genbutsu Finally, all reports discourage people from leaving their offices. They give us the false feeling of safety. The report seems real and so it gives a good model of what is actually happening. Toyota has the practice of Genchi Genbutsu – go and see, literally. Review the charts but then leave your office and go to the place of the work. Watch, listen, ask, and review the Portfolio Kanban wall with the team(s). This will bring you back in contact with the reality of which features have been truly done. This will help you see if all the Story Points in the charts delivered the value that they claimed. Stop/Do So stop using RYG reports. They hide too much information. Do use Burndowns/Burnups/Cumulative Flow diagrams as a tool to help you spot trends, but don’t rely on them alone as the source of truth. And most importantly, review the Portfolio Kanban Wall with the Team(s) on a regular basis, as this is our best measure of reality. http://www.drdobbs.com/dr-dobbs-agile-newsletter/191600661 Other have taken up on it as well: http://www.solutionsiq.com/greenshifting-and-redshifting-within-projects/ http://www.edmundschweppe.com/2013/12/the-green-shifting-anti-pattern/ http://calleam.com/WTPF/?p=1205