You are hereFeed aggregator
All About Agile - Tue, 06/30/2015 - 07:16
I don’t always follow the same story splitting approach when I need to split a story. It has become intuitive for me so I might not be able to write about everything I do or what goes through my mind or how I know. But I can put here what comes to mind at the […]
All About Agile - Tue, 06/23/2015 - 13:11
Hi everyone, Until now, I have only offered training & workshops as part of my consulting service to clients. Now, for the first time, I am offering an open workshop for managers and executives that are embarking on or part of an agile transformation. Details below… ‘Agile Executive’ Creating an organisation that is fast moving, […]
All About Agile - Tue, 06/23/2015 - 03:05
This article was written by Haran Rasalingam and was first published on thetrainline engineering blog The big selling point of Agile is the fast return on investment it promises. But what excites me most about Agile is its emphasis on people – agility done well injects humanity back into activities which Waterfall has made bureaucratic and devoid of […]
All About Agile - Tue, 06/16/2015 - 06:55
I was teaching a private class a few weeks ago and a student in the class mentioned that his company had “already failed at Agile three different times.” The way the statement was phrased really struck me. It made me very aware of my own opinions about Agile adoption and taught me a little about how […]
The post Agile Transformation … Learning What Doesn’t Work Is The Key To Success appeared first on LeadingAgile.
All About Agile - Wed, 06/10/2015 - 15:20
I was recently watching an episode of Shark Tank. I loved the unfiltered statement from Kevin O’Leary (Mr. Wonderful) toward an entrepreneur seeking an investor in his company. I’m here to make money! If you’re a fan of Shark Tank, you’ll notice something about Mr. Wonderful. He keeps the conversation focused on the money. When will he […]
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, […]