Robert Galen (40)
One of my favorite movies of all time is A Few Good Men with Jack Nicholson and Tom Cruise. I can picture that highly charged confrontation at the end clearly in my mind. You know the one.
Tom Cruise says—I want the Truth…
And Jack Nicholson leans forward, with that classic look, and says—
You Can’t Handle the Truth!
What a climax to the film. I get chills every time I watch that scene.
I’ve been thinking more and more in my coaching about why leaders and managers often wait too long to ask for agile coaching help. I think it’s a general phenomenon in agile (and non-Agile) teams and organizations, but for the purposes of this article, I want to focus upward—on “them”.
The THEM in this case includes:
- C-level leadership
- Vice Presidents
- And even Project Managers
So, I hear you asking. What does the movie A Few Good Men have to do with leadership recognizing their weaknesses when it comes to agile transformation and asking for help? Well, I’m glad you asked. That’s where we’re going next.
I’ve been sharing about agile methods for over ten years at conferences and workshops. One of the top three questions I always receive from attendees is:
Does agile work with distributed teams?
And sometimes the question is phrased another way:
The notion of co-located teams is nice in theory, but in real life we have team members all over the world. We need to cobble together teams based on our business needs from wherever they are. Does agile support that level of high distribution?
I often smile at the repetitiveness of the question. It indicates clearly that enterprise level software development is often distributed. It also indicates that outsourcing is still alive and well. I’ll try to provide some answers to these questions by sharing two stories of distributed teams I have experienced.
A Tale of Two Distributed Teams
I was lucky enough to be invited to do an agile jump-start for a new client. They are a rather large firm that builds hardware and software devices supporting mechanical control systems. They were kicking off several projects that encompassed many teams, some of them offshore and many distributed. They were looking to leverage Scrum as the method for starting these projects, and they invited me in to do some training and get the teams sprinting in this new style of product development.
I once was leading / coaching a team that struggled mightily to work together as a team. I was the Director of R&D at an eCommerce SaaS product company. We had been leveraging Scrum for a number of years with reasonably good success and had approximately 10 Scrum teams focusing on the various aspects of our online product.
But there were a couple of teams that were really struggling, which often seems to be the nature of things. Out of ten teams, we had about three that were high performing, three that were moderately performing, and three that struggled along. Don’t get me wrong, the team members were solid people and good employees. It was just that this whole “agile collaboration thing” was hard for some of them to grasp and embrace.
IntroductionThis article has been floating around my head for quite a while. It will encompass several themes. First is, how do we “account for” the time and focus within our teams? Second is, how granular do we plan for and monitor the focus of our teams? And finally, when planning and forecasting, should we plan at the individual level?
The “we” in these is a bit broad. I would include managers, directors, VP’s, C-level folks, the PMO and Project Managers. Virtually anyone who is tasked with “caring about” a technical team and what, how, and when they do what they do.
The Dinosaur AgeWell in this case, it’s not that long ago, but the analogy feels right to me. In this Dinosaur Age, project managers and “all management” for that matter, cared about people and their time. What are some of the aspects of that?
- The world of time-sheets and project level tracking, relatively fine grained in nature. Usually captured “after the fact” so the data was error prone, but it served the accounting requirements of the organization.
- Managers worry about keeping individuals “busy” in their project planning. Developers need to be coding and testers need to be testing. Nothing else matters as long as we’re optimizing at a functional (silo) level. We will “collaborate” when we “integrate”.
- People are fungible resources in this model. You care less about skill and capability, instead simply assigning tasks to people to the point of “100% utilization or more” is the goal.
- Multi-tasking is the norm—especially for developers with specialized skills. In fact, it’s quite common to see a specialized person spread across 5-10-15 teams, with their “actual or realistic” capacity being ignored.
- Quite often we try and predict projects (sourcing, utilization, needs) out for very long periods of time. We leverage people, capacity & utilization percentages, filling in endless boxes on spreadsheets for this. Truly it’s an exercise of arithmetic!
At the risk of sounding a bit self-serving, I thought I’d share some thoughts around how to select an agile coach. Since the Agile Methods nearly always require a seasoned guiding hand to help you accelerate your adoption and transformation, this is one of the more important decisions you’ll make. Here is the continuation of a list of critical areas (click here for part #1) I consider when hiring a coach and in sharpening my own experiences as an agile coach.
Independent vs. Group Affiliations
One of the more difficult decisions you have to make is who to approach. Coaches essentially come from the following affiliations:
|Independent coach||Either a sole proprietor or a small collection of like-minded coaches; usually have training as a service||Usually quite experienced, vertical areas of skill, well known & established, strong consistency||Bandwidth and availability - scheduling. Rarely want long term engagements, costs|
|Agile Coaching firm||A company/group that specializes in agile coaching. Often training is part of their services portfolio.||Consistent coaching model, bench strength and collaboration||Varied coaching skills, typically want to embed coaches, costs|
|Agile Tooling firm||A company whose primary business model is tooling, but they’ve also provided training and coaching services||If you’re ‘leading’ your adoption w/tooling, bundled services.||Tooling can get in the way – conflicted goals, inconsistent coaching|
|Search firm||A search & recruiting firm that has ‘discovered’ agile methods and coaching services. Dual priority of coaching & staffing / staff augmentation||Aggressive pricing, bundled services, ability to find coaches – scale themselves||Inconsistent coaching quality, coach retention, it’s not their primary business model|
You’ll want to consider WHY you’re looking for a coach. What challenges are you facing? What sorts of skills are you expecting them to bring? If you’re just starting up, then finding a coach that has experience “jump starting” agile teams will be your initial goal. If you’ve been agile for a while and looking for a “tune up” and assessment, then that might take you in a slightly different direction. Most coaches can handle both sides of that spectrum, but it’s useful to be clear on where you are on the adoption curve.
Realize that there’s a special relationship established between the agile coach and the organization they’re coaching. First of all, you need to be prepared to establish a partnership with your coach. Be ready to share your “dirty laundry” and your personal challenges. Be ready to trust the coaches you select; not only their experience, but their character and integrity.
Be open to learning from them, but be also open to challenging them to “raise the bar” in your agile adoption efforts.
And important part of any coaching relationship is measurement. How will you measure the results they provide? A typical measurement scenario is to focus on the teams and their productivity—measuring before, during and after coaching. But it’s not as simple as that. Agile measures are quite different than traditional measures, so you’ll want to do some research. You’ll also want to include your team and measure their personal reactions to the coaches.
One of the things I hear most often in my public speaking engagements and workshops goes something like this:
I’ll spend time speaking about an agile principal, or practice, or technique, or even a mindset. Someone in the audience politely raises their hand and asks a question. I’m paraphrasing a bit, but it usually goes something like this—
Bob, that sounds really nice as an academic scenario or generic advice, but in the real world, something like that will never fly. We have too many constraints. It just won’t work in our organization. It sounds nice, but…
And then there’s the inevitable follow-up question—
Can we still do agile if we don’t do that ____________?
Which often gets repeated over and over again as we explore additional principles and practices…
I often feel a wide variety of emotions as a result of these dialogues—from frustration to sadness to a smile at the repetition. Depending on the point being made, it’s usually an early indicator that I’m in for a tough go in the class. It often indicates that folks are being ‘told’ to attend and to “go Agile”, but who really don’t buy into the whole change thing.
Where am I from?
I’ve started doing the following as part of my introduction in classes; heading them off at the pass so to speak. I’ll talk about my background. How yes, I’m an agile coach and trainer, so I’ve done some academic-oriented work: studying, reading, and the like. However, I’ve also spent 6 of the last 8 years as an internal Software Development organizational leader and agile coach. So, I’ve been living in the real world, with real world dynamics, challenges, and constraints. Given that, I’ve been able to generally make agile work in those contexts. Every idea or technique or practice or principle that I bring up, I’ve seen work in practice…in the real world.
My friend Lee Copeland asked me the following question:
I'm putting together a keynote talk and need some examples --
projects that were successful in the sense that they implemented the requirements, within budget and time BUT didn't return any actual value to the business.
Got anything you can share?
And it made me think about my past projects. My initial reaction was no, I don’t think I’ve ever worked on a project that met the projects time and scope commitments, yet delivered NO business value. The keywords here are the “no business value”. But I have worked on some squirrely projects that did disappoint on business value. Let me describe a few of them as a means of sharing some things to avoid in your own projects.
In addition, I hope the stories hone in on some of the aspects of customer/business value, why achieving it might be a challenge, and how it can be a variable but worthy target.
Beware heavyweight software development frameworks that kowtow to status quo leadership practices
I remember my first introduction to the Rational Unified Process (RUP) as if it was yesterday. I had a tremendous amount of experience with a wide variety of traditional Waterfall methods. Each promised to solve nearly every challenge associated with software projects and each failed to do so. So I was eager to try something new with RUP and was hopeful that it would help improve my software project success.
And as part of RUP I’m including the Unified Modeling Language (UML) and Use Cases as the defacto requirement artifact. There were a lot of new approaches within the RUP. It was sold as a ‘framework’; one with lots and lots of expert guidance. I think one of the overwhelming or inherent assumptions in RUP was that we (the customer of the process) lacked the ability to define an effective process.
So, RUP solved that problem. It provided templates, guidelines, phases, techniques, iterations, gates, hand-offs, planning guidance, testing guidance, models, workflow advice, etc. Literally thousands of pages of guidance for how to define requirements, plan, construct, test, manage, and deploy a software project. It was an amazing amount of “stuff”.
The five Core Scrum Values have been defined as:
Tobias Mayer wrote a counterpoint blog post on these values and suggested a different set and focus all on his own. Here’s what Tobias had to say:
I believe there are some core values, that can help establish a way of being that offers a foundation for success in moving from a left-brain, logical, commanding culture, to a right-brain, intuitive, creative one. Each of these values begins within self, and can be lived independently of the reactions of others.