July 24, 2014

All Posts Tagged With: Agile Coach

Agile Coaching Blog

The Great Wall: Scaling Agile on a Multi-Team Project

If you are launching a large-scale agile project (e.g. one that requires more than a couple of Scrum teams) then careful consideration should be given to how you scale the management of the project. Starting off by applying standard scaled agile management solutions (i.e. Scrum of Scrums or SAFe) may help you feel like you are getting off to a good start. However, with those solutions comes the danger of creating a management structure that focuses on optimizing the project structure primarily for management’s benefit rather optimizing the project’s structure for the delivery of a valuable, usable and feasible solution.

This paper describes a lightweight yet powerful approach to scaling agile management for a multi-team project. ‘The Great Wall’ is an approach that enables the emergence of a scaled management solution that focuses first on promoting the delivery of the solution but also satisfies the needs of management.

Get the full article!

Scaling Scrum – BigVisible


Planning and Flexibility

Responding to Change over Following a Plan

Planes Trains and Buses

If you read the Agile Manifesto, it is right there as the 4th, and final value of Agile Software Development. Normally when I think about this value, or explain it to others, I usually talk about it meaning that we should make sure we respect reality, and be more focused on responding to empirical feedback over adhering to a plan. This is all true, but I’d like to pose that it could be interpreted in another entirely different way. By increasing a project team’s flexibility, we can reduce the amount of planning required. Let me offer you an analogy. Imagine you are going on vacation tomorrow and need to catch a flight in the morning. Chances are, you have carefully selected your flight time. By the time you reach the day before your flight, chances are that you have made travel arrangements to get to the airport such as scheduling a taxi or shuttle. Of course I need to arrive two hours early, so chances are I am planning to get up extra early to get to the airport with enough time that I don’t risk missing the flight because of lines for bag check or security. All of these plans must be carefully laid out and choreographed because the stakes for missing my flight are quite high. Chances are I will face a steep financial penalty, possibly missed connections, long delays and stress. If I miss that plane, it’s a big deal with serious consequences. Now compare that experience to taking a subway or bus somewhere. I may review a schedule, but chances are I will simply go to the stop and wait. I don’t need to precisely plan timings, rather I have a general heuristic of how much time I should set aside to get from one place to the next. Even if I come around the corner to the station in order to see my train departing, chances are this will not delay me more than 10 minutes. That is a frustration, but by no means the stakes of missing a plane.

This contract between the pressure of making a plane and the pressure to catch a subway train represent the two poles on a spectrum representing a team’s capability to deliver. Teams that have very limited capacity to do given tasks – a team that has several specialized skills only one person can do, for example – are very fragile, one unplanned absence, resource contention, or other problem and the team will be unable to complete their work in a timely manner. Like in the case of making a plane, being just a little late can carry a steep penalty. We can compensate for this fragility by robust planning and time buffers, but these carry their own costs. If I were to fly from my home airport in Boston to Florida, that flight would take about 3 hours, but current travel guidelines would recommend I get to the airport 2 hours early. Assuming transportation to the airport is not a factor, this buffer represents 40% of my travel time, all because of the uncertainty of airport lines and the high stakes of missing a flight. This is not to mention the actual cost of planning as well.

Capabilities are an Asset to Avoid the Expense of Planning

Rather than teams investing more energy in planning to manage their limitations, they should look to improve their resiliency. We do this by building up cross training in team members so that they can work in multiple capacities, engineering our products to be modular, and using a common shared language for requirements, allowing people to swarm around a problem with a common context. These sort of techniques at first blush may sound sound like waste, until we take into account the high cost of making plans. This cost is more than just the effort of a project manager to put together a complex gantt chart. Sophisticated plans  increase dependency and risk, people may not realize that obscure items are on the critical path and could impact the schedule. The increased risk may also make team members more risk adverse and less willing to experiment, which is precisely the opposite of what we want when working in a complex adaptive system. Let me offer some real examples.

A team that is dependent upon one person shared across teams, faces a dual risk. If they are not ready for the specialist on the agreed upon date, they may face a delay until the next scheduled window they have with that person. Even if they meet their deliverables on time, there is a risk that another group using that specialist may be running late and end up overriding the agreed upon schedule.

A team which is limited in its ability to deploy code across environments must carefully plan deployments. The longer time lag between these, then the more interdependencies are introduced, increasing the sophistication of the deployment and ironically slowing it down further.

A team that must execute a carefully choreographed set of activities to have any chance of completing its work according to the planned time horizon will never experiment or take risks to learn new things, as they can’t risk breaking their plan.

Planning is Still Invaluable

None of this is to say that our goal should be to eliminate plans entirely, or even that planning is always unnecessary expense. Indeed,my view has generally aligned with Dwight Eisenhower when he famously said, “Plans are useless, but planning is essential.”
The key thing we need to remember when we are doing that planning is that when we are faced with a situation requiring quite a bit of sophisticated planning to manage, that perhaps we should look closer at the system and see if we need to change the nature of how our team is working so that we can succeed with a simpler plan.



Will Agile Process Work For My Project? Defined vs. Empirical

As an Agile Coach I often get a question about when Agile frameworks should or should not be used. One of these is whether or not an Agile framework is suitable for a particular project or product. This question is not easy to answer, especially since the one asking the question has more knowledge of the proposed work than I do!

One thinking tool to help make such a decision is to contrast “defined process control” with “empirical process control.” This video explains what I mean.

Is your project or product definable before you start working or do you need empirical data to help build the solution? Looking for more clarification on this topic or anything else agile? Just ask, we will do our best to get you started in the right direction!

It’s kinda nice having a coach in your corner, right?


Agile Delivery: From ScrumMaster to Team Coach

Several weeks ago, one of my colleagues at BigVisible brought up an interesting concern around agile delivery and the ScrumMaster. How is, he asked, that there are so many ScrumMasters out there who are unprepared for their role on a team?

Agile Delivery Team Coach ScrumMaster

As I thought about it, I realized that the two-day CSM course basically introduces new ScrumMasters, team members, and other interested parties to how Scrum works and how to move teams through the ceremonies and artifacts associated with Scrum. What it doesn’t do—and likely cannot do in just two days—is also focus on all of the things ScrumMasters have to do to foster truly high-performing teams. The ScrumMaster role, done right, is much more than just scheduling meetings and updating a burndown chart. That leads me to conclude that the name ScrumMaster should (or will) die and be replaced with one that reflects the truly comprehensive nature of the role: team coach. Here’s why: [Read more...]


Extreme Stand-ups: The Cocktail Minute

a black-and-white, from the 50s, of folks dressed in business attire, apparently at a cocktail partyI’ve been lucky enough to be coaching a rather open-minded team who’s getting on in their journey of “going Agile.”  By most accounts, the team has been thriving: self-selecting prioritized work, organizing around it, taking pride in improved flow and reduced waste.  For the most part, they have been genuinely experiencing the joy of working in an iterative, collaborative and open way… except for one glaring exception: their daily stand-ups.

“Painful.”  “Boring.”  “A waste of time.”  What should be the frosting on their morning flakes was leaving the team feeling soggy and needing another cup of coffee.  A 15-minute jazz of collective focus had become a dreary 30 minute-long plodding through the task board.  No good.

Part of their challenge is that this agile team tackles a variety of flavors of work.  Many the work items are pure analysis: another team in the enterprise wanting to make a change and asking for a spot-check on the impact to this central system.  A good number are enhancements: a new column on a report for this line of business; a new field on that form for another…  There’s a real dispersion to the work.  It’s clear that some percentage of the work being done in this group does not need the undivided attention of the entire crew.  Discuss this mix of work in the traditional stand-up format, there’s a lot of noise to the signal and people begin to tune-out.

In these kinds of situations, I sometimes suggest I like to call “The Cocktail Minute.”  Here’s a typical scene (names have been changed to respect the privacy of the talented):
[Read more...]


Four Pillars of Agile Coaching

The Agile Super Coach

Of all the abused words in the Agile domain, none seems to be more abused than the simple word “coaching”. There are numerous people out there professing to be “agile coaches”, and while I don’t mean to denigrate what any of these people do, there is a very broad latitude in the types of things that they do. This can further confound our ability to work with organizations as there may be a disconnect between coaches and clients about what exactly they are doing.

Unfortunately, in the absence of a clear understanding, I have seen people begin to expect that the “Agile Coach” is nothing short of a super human being. The can swoop into any project, turn around the results, and simultaneously coach that group into effectively preventing all those problems from ever occurring again. Or they may have an unnecessarily narrow view of the role and try to put an Agile Coach in a box by insisting they only do training, for example. To be fair, when I encounter these missed expectations, they are usually my own fault. I did not do a good enough job of articulating what the role is I, or anyone else, would potentially be playing in that organization as an Agile Coach.

I can’t profess to be the keeper of truth on this topic, but here’s a model I’ve used to help organize my own activities and to make sure I’m articulating clearly what role I see myself playing.

[Read more...]