You are hereFeed aggregator

Feed aggregator


Scrum Alone Is Not Enough – InfoQ and Agile 2015 Interviews

All About Agile - Thu, 08/13/2015 - 14:32

Mark attended Agile2015 in Washington and, as part of his conference commitments, he sat down with ​SolutionsIQ for an Agile Amped podcast about High-Performance Teams, as well as with InfoQ for an on-camera interview to discuss his Scrum Alone Is Not Enough blog series. InfoQ recently interviewed Mark regarding the motivation behind the blog series and how his experience as an Agile expert has formed his viewpoints. You can read the full interview at http://www.infoq.com/articles/scrum-not-enough. And you can view the video from the Agile Amped podcast here. We will post links to the InfoQ video interview as it becomes available.

Teams and their proximity to the final user

All About Agile - Wed, 08/12/2015 - 21:12

Learn more about our Scrum and Agile training sessions on WorldMindware.comA great, simple post from Mike Bowler… Time: Teams that are writing code today that will be used by their customers tomorrow are very focused on what the customers actually need. Teams that are writing code today that won’t be seen by a customer for … Continue reading Teams and their proximity to the final user →

The post Teams and their proximity to the final user appeared first on Agile Advice.

Three Things You Need to Know to Transform Any Sized Organization Into an Agile Enterprise #agile2015

All About Agile - Tue, 08/04/2015 - 13:46

Here is my talk from this AM at the #Agile2015 conference. Enjoy! The Three Things You Need to Know to Transform Any Size Organization Into an Agile Enterprise from Mike Cottmeyer The post Three Things You Need to Know to Transform Any Sized Organi...

‘Agile Executive’ – workshop with Kelly Waters on 28 Sep 2015

All About Agile - Wed, 07/29/2015 - 21:27

Hi everyone, I recently ran my first ever public workshop – a 1 day workshop called ‘Agile Executive’ which focuses on topics to help managers and executives that are embarking on or part of an agile transformation. I am running another session on 28th September – details below… ‘Agile Executive’ Creating an organisation that is […]

Transparency – Two Way Visibility

All About Agile - Mon, 07/27/2015 - 14:44

What does the value of Transparency really mean?Nextgov: How do you define transparency?Fung: My definition is quite a bit different from the conventional wisdom about transparency. A transparency system is designed to allow people to improve the quali...

Is It Ready?

All About Agile - Mon, 07/27/2015 - 10:16

In an agile transformation, one of the first things we work towards is to create an ability to deliver in a predictable manner. As described in our compass and our journey, there is a clear path for organizations that embark on an agile transformation. By becoming predictable, an organization can make and keep promises. In […]

The post Is It Ready? appeared first on LeadingAgile.

Microservice Trade Offs

All About Agile - Wed, 07/01/2015 - 08:36

Many development teams have found the microservices architectural style to be a superior approach to a monolithic architecture. But other teams have found them to be a productivity-sapping burden. Like any architectural style, ...

Story Splitting: Where Do I Start?

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 […]

The post Story Splitting: Where Do I Start? appeared first on LeadingAgile.

‘Agile Executive’ – 1 day workshop with Kelly Waters

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, […]

Fear is Waterfall

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 […]

Agile Transformation … Learning What Doesn’t Work Is The Key To Success

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.

An Introduction to Cost of Delay

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 […]

The post An Introduction to Cost of Delay appeared first on LeadingAgile.

Is Predictability Really What We Want?

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

Failure Modes of an Agile Transformation: Workflow

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.
5. Failure to Decentralize Control

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:

  1. Hire a coach who’s well-steeped in distributed team success.
  2. Ensure all team members receive the same Agile training; for maximum effectiveness, get everyone in the same room for the training.
  3. 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.
  4. Have a facilitator in each location when teams plan their dependent delivery commitments.
  5. 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.)
  6. Invest in technologies that support transparent workflow communication — for example, Flowdock.
  7. Maintain a regular cadence of visits across all geographies and all roles.
  8. Build working agreements that support core hours for availability, or alternative solutions for quick turn-around feedback.
  9. Trade or share the burden of dealing with broad time zone differences.
  10. 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

What’s the Hurry? Building a Digital Enterprise

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, […]

The post What’s the Hurry? Building a Digital Enterprise appeared first on Jim Highsmith.