You are hereFeed aggregator
All About Agile - Mon, 05/18/2015 - 05:00
Predictability in software system delivery is as close to a Holy Grail as it comes in the IT industry. I’ve heard many people stress being able to have a predictable delivery cadence as something valuable to them. As recently as today I saw a reference to “predictability over commitment” on Twitter! But why is predictability so important to so many people? The people who pay for the
All About Agile - Fri, 05/15/2015 - 07:00
In my previous post on the first three Agile transformation failure modes, I focused on the LEADERSHIP aspects of failure: lack of real executive sponsorship, failure to transform leader behaviors, and refusal to change organizational structures.
These next three fail modes are failures in WORKFLOW: effectively making work decisions flow, setting work boundaries, and factoring in the costs associated with work across distributed teams.4. No Business View of the Value Stream
photos via Flickr Commons
Several years ago, I had the good fortune to work with Hendrik Esser in a weekend workshop. Hendrik and I converged on the value stream: What does it look like in traditional organizations? What might we want to be different? And how does an Agile transformation support or impede this new perspective? What we’d seen in our respective careers was frighteningly similar. Most organizations embraced silos, to the degree that even as they were adopting Agile practices, they did so in “agile silos.”There was no view across the value stream. That is, these organizations weren’t tracking the “concept-to-cash” flow of value through a system.
Successful Agile transformations ask us to accept a few basic truths and practices about value streams:
- You’ve got one; go find it.
- Map your system at whatever level of detail best articulates your sense of handoffs and bottlenecks.
- Start where you are in the value stream; taking on an entire system will exhaust you and your teams, which will lead to abandonment of the Agile transformation effort.
- Every system has one primary constraint; find yours, crush it, and then look for the next primary constraint that emerges. Rinse and repeat.
- Be ruthless in your vision to expand the boundaries of your value stream: upstream from the neighbor processes that feed your work, and downstream where you feed your work into your neighbor process.
- Include everyone in identifying the value stream, its bottlenecks, and its potential flow.
- Broaden commitment up and down the stream, not in localized silos.
In my previous post about leadership-themed failure modes, I mentioned the work of Robert Greenleaf. Among his 10 attributes of a servant leader, two of my favorites are acceptance and withdrawal. What do these mean to you and how to do they impact the success or failure of an Agile transformation? To me, these make me think of the experience as a manager or being managed. Here’s a little story about managing me.
Across my tech career I’ve worked for a variety of managers. In one job, I worked in a small group analyzing various methodology approaches for software development. This was exciting: it was my first foray into a break-up with waterfall approaches. Though rather shy (yes, me!) I was a sponge, passionate to contribute and engage. In one meeting, a particular issue was raised that related to the work I’d been doing and I offered up what I thought was a relevant solution. At a break in the meeting, my manager pulled me aside into a separate room. “Why did you disagree with me in there?” he inquired. “Don’t you trust that whenever I make a decision I’ve thought of all other possibilities? You’re disrespecting me.”Huh?
I’d like to say that was the only manager who has ever needed to have complete control over decisions, but you know better. In most cases, there are a few dynamics at work here:
- The manager’s sense of significance is somehow wrapped up in the decision-making control.
- Due to this strict, centralized control, decisions are not as informed as they could be.
- Waiting for a decision because of centralized control wastes time and human potential.
- This control style ultimately lowers morale and fosters cynicism.
Agile transformations fail when we don’t pay attention to our whether we centralize or decentralize control. Greenleaf would characterize this as an inability to recognize when to accept the decisions of the team and when to withdraw your control so that the team owns decisions that impact their way of working. Servant leaders don’t relinquish all control; rather, they recognize the value in releasing control when all concerned are better served. They maintain centralized control when they see that this is in the best service to their teams.
Don Reinertsen talks and writes well about this (see The Principles of Product Development Flow.) You can use some simple guidelines to steer you towards appropriate control modes. Long-term decisions with extended impact that include dependencies across many constituents warrant a centralized mode of control. Short-term and low-impact decisions merit decentralized control. In Don’s words, think of these two principles:
- The Scale Principle: “Centralize control for problems that are infrequent, large, or that have significant economies of scale.”
- The Perishability Principle: “Decentralize control for problems and opportunities that age poorly.”
Agile transformations require continuous learning, and servant leadership is no exception. When Don talks about these domains of control, one thing is certain: this is not about controlling the worker. As he says,
“Watch the work, not the worker.”
Decentralize to move decisions closer to the worker, the one who best knows the work. Centralize control as a service to the flow of value. A bias toward decentralization helps leaders and teams better converge.6. Unwillingness to Address Illusions Around Distributed Teams
More and more I’m seeing organizations with distributed teams: wide dispersement of teams across many time zones, and even 80/20 rules that guide projects to employ 80% offshore teams with only 20% of teams located in the same building (or the same city.)
Want to fail at your Agile transformation? It’s easy. Follow these simple rules for distributed teams: set up a complex geographic maze based on the economics of resource utilization; ensure a time zone difference between 7-11 hours; rely heavily on emails and large documents (especially detailed test plans) for your communication; and definitely don’t invest in bringing people together to collaborate or train.
Organizations in this distributed bind have essentially made deals with the devil, trading off fundamental Agile success principles like face-to-face collaboration for the promise of speed and lower costs (but don’t worry, it’s still Agile!)Really?
How do you monitor the value stream and the flow of work? What working agreements and communication approaches have you implemented that work across cultures? How fast is the feedback? Where is the cost-of-delay calculation in your ROI equation? And perhaps most importantly, who’s representing the challenges of the distributed teams to the rest of the organization? Who listens to them when the constraints become overwhelming?
Here are some changes you can embrace to deal with the distress introduced by the distributed model:
- Hire a coach who’s well-steeped in distributed team success.
- Ensure all team members receive the same Agile training; for maximum effectiveness, get everyone in the same room for the training.
- Invest in high-definition, large-screen video technologies. Accompany these with a top-notch sound system that figuratively brings all the voices into the room.
- Have a facilitator in each location when teams plan their dependent delivery commitments.
- Whether using audio-only or adding video, use facilitation techniques that ensure all insights are welcome (small-group brainstorming, round robin check-ins, frequent breaks.)
- Invest in technologies that support transparent workflow communication — for example, Flowdock.
- Maintain a regular cadence of visits across all geographies and all roles.
- Build working agreements that support core hours for availability, or alternative solutions for quick turn-around feedback.
- Trade or share the burden of dealing with broad time zone differences.
- Engage the executive sponsor in regular visits to all locations.
Finally, here’s the one, most important practice I believe is critical to a distributed team delivery model:Eliminate distributed teams.
That’s it. This yields the biggest success stories I’ve seen with distributed teams. Nearly everyone I talk to says this isn’t a choice for them; yet if they knew the amount of waste built into the distributed delivery model, they’d realize the irony of thinking it’s saving them value.
Stay tuned for the next in the series on the 12 Agile Transformation Failure Modes!Jean Tabaka
All About Agile - Mon, 05/11/2015 - 11:27
By Jim Highsmith and David Robinson Are the forces behind digital business, just one more wave of technology fueled change or is today’s business environment fundamentally different? If different, what are the critical capabilities required to survive and thrive? Examples of the differences assault us in the media. Doug Stephens, author of The Retail Revival, says, […]
All About Agile - Thu, 03/26/2015 - 11:00
You're driving down the highway trying to reach a distant destination. You've had delays such as traffic along the way, and you know that you're going to have to "push it" in order to have any hope at all of arriving on time. You start to feel ...
All About Agile - Thu, 03/26/2015 - 07:58
While there are many books and much research on organizational development, this system view combined with some validated learning over time, is a powerful way to look at organizational challenges as a coach/consultant. Let’s take a closer look to define these areas then apply some validated learning from my own experience. Business Outcomes – the outcomes […]
The post Operationalizing Strategy with a Systems Perspective appeared first on LeadingAgile.
All About Agile - Tue, 03/03/2015 - 04:00
In my post about how to form teams, I talk about products… not in their monolithic, holistic state… but as a subsystem within a larger integrated solutions architecture. In other words, big products are just series of small products that work together in an integrated fashion. Each of these smaller products have a backlog, a […]
The post 3 Thinking Tools for Minimizing Dependencies Between Products appeared first on LeadingAgile.
All About Agile - Tue, 03/03/2015 - 00:19
My other workshop submission for the Agile 2015 Conference is titled “The Evolution of Teams” and examines one team that stopped doing the traditional agile practices is more agile than ever. Agile practices such as daily stand up meetings, sprint...
All About Agile - Mon, 03/02/2015 - 04:00
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 […]
All About Agile - Fri, 02/27/2015 - 13:52
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 […]
All About Agile - Fri, 02/13/2015 - 20:16
My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on ProjectManagement.com (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.
All About Agile - Fri, 02/13/2015 - 02:00
Well… it depends. If you view agile as a system of beliefs, or a way of looking at the world, or as a culture your company is expected to adopt…I’d suggest that it’s impossible to mandate an agile transformation. There is no way to force people to believe in something they don’t believe in or to […]
All About Agile - Wed, 02/11/2015 - 21:27
For many years one example of process thinking, resource gathering, requirements, implementation and acceptance criteria has been the exercise - make PB&J sandwiches. I've done this with groups to discuss the simple task that we typically ove...
All About Agile - Tue, 02/10/2015 - 18:29
Learn more about our Scrum and Agile training sessions on WorldMindware.comRetrospectives are a key part of continuous improvement in Agile teams. The retrospective techniques that a team uses should be adjusted to the needs of the team. In a Scrum … Continue reading →