Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban

Please checkout out this exciting interview with author of Essential Scrum, Ken Rubin. Ken is a distinguished author, speaker, and Agile instructor. He has worked with many of the nation's top companies, and he joins us in this episode to tackle some of the tough questions facing teams as they adopt Agile.

If you haven't already read Ken's great book, please pick up a copy of Essential Scrum on Amazon today!  You can also read Ken's blog and learn more about his services through his website innolution.com.

I hope you enjoy this episode and please remember to subscribe in iTunes. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: [email protected].

All Things Agile - Episode 011 - Ken Rubin Interview

Welcome to the All Things Agile Podcast – your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast in iTunes, and please check out our sponsor:

TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Hello everyone and welcome to All Things Agile. I’m

very excited to announce that Ken Rubin is our guest today on the show. Ken is a

noted author of Essential Scrum as well as being a public speaker and Agile instructor. Before we begin, a quick reminder that this podcast is for

informational purposes only and we accept no legal liability. So let’s get

started! 

First off, Ken, thank you so much for joining us on this episode.  I am really glad to have you on this show. I’ve given the audience just a quick

introduction, but can you please take a few minutes and explain a little bit

more about yourself, both personally and professionally? We really want to get

a chance to know you.

Ken: Sure! So my background is software engineering. My

degrees are all in computer science and I’ve had a typical path through most

software companies. I’ve been a developer, project manager, VP of Engineering

at a number of companies both large and small. I’ve done 10 startup companies

in my career, and I’ve taken two of those public on the NASDAQ. I did my 2 year

stint with IBM in the mid-1990s. I’ve helped companies and I worked with 130

people; we ran around North America building large distributed object systems

and if anybody’s old enough to remember, I came out of the Small Talk world.

Back in the late-1980s, I helped bring Small Talk out of the research labs at

Xerox PARC, and I worked with a startup company that was a spin-off of Xerox

PARC called Barclay System. We were the early market object technology folks.  So we brought Small Talk and object technology to the market.

I’ve been doing Agile since the early-1990s. Scrum,

formally, since 2000. In those days, I worked for a startup company in Colorado

called Genomica. It was a 90 person engineering team, and they let the VP of

engineering go. I ended up inheriting the engineering team which wasn’t

functioning all that well and we transitioned everybody over to Scrum. And that

ended up working out much better for us. And I’ve been using Scrum ever since,

about 14 years. These days, I spend my time out either doing Scrum training

classes and Kanban training classes or doing coaching. And, I hope that in our discussion today I can go over a number of

examples that I had the benefit of seeing a lot of different companies and

what’s working and what isn’t working.

Ronnie: Thank you for the introduction Ken. I’m really

looking forward to the insights you can provide us based on your considerable

experience. The first question I’d liked to ask you, regarding your book

Essential Scrum, is in regards to the dedication and introduction. It really got

me thinking about the importance of relationships and software. I also started

thinking about how relationships or soft-skills play into the success of Scrum.

What is your insight or your advice on how relationships affect Agile teams?

Ken: It’s a good question to start with. To me, the unit of

capacity in Agile is the team. Even the Agile Manifesto calls that out –

individuals and interactions over processes and tools. It really is about the

team. So how they interact with each other, how they perform is of outmost

importance. The relationships among the members of the teams is critical. If

you’re going to have self-organizing teams, they have to have trust in one

another. That’s one of the characteristics that, for me, distinguishes a group

from a team. Group, simply being a bunch of people that I threw together with a

common label. And honestly, the only thing they have in common are the T-shirts

they printed out that have the name of the group on it.

A team is a group that’s gone through the stages. Sort of the top most stages: forming, storming, norming and performing. And if

you can make a real investment to turn a group into a team, first, they had to

figure out these soft skills issues: how to work well together? Otherwise, they

would never become a high performing team, and they would constantly be at odds

with one another. So one of management’s responsibility is to help put the

right people on the team, but once they’re there, it’s the soft skills that

help bring these members together, that help them work well and function well.

In most Scrum classes, there’s an exercise: the Yes – And, vs the Yes – But

exercise. And the intent behind that – it’s actually an exercise that borrowed

from improvisational comedy training and the idea is to try and help teams

understand how to work well together, how to form those relationships, how to

take one person’s idea, build on top of it and not be in a Yes – But style

passive-aggressive cutting things down: ‘Yeah, I heard what you said; it seems

like a good idea but let me now tell you why it sucks.’ That’s not a foundation

for building a high performance team. If the soft skills are not addressed,

then likely you won’t have a style of organizing teams which are the unit of

capacity in doing Agile and for that reason, you’ll likely fail.

Ronnie: I definitely agree. What came to my mind is the book

‘Speed of Trust’ by Stephen Covey. It describes how trust is a major factor and

how people fill in the gaps in communication and that with a high trust

environment, the team is able to move more quickly.

Ken: I think it’s really important. How we disagree is as important

as how we do agree. At no point would I ever suggest that team members

shouldn’t disagree, or shouldn’t have a vigorous debate. They should do it though

in a very proactive way; in a way that’s reinforcing their ability to come up

with an innovative solution, not inhibiting that ability. So if they don’t have

the skills to work with each other and challenge each other, then very likely

that the best achieved is mediocrity.

Ronnie: Excellent point! And I think that leads into our

next question: There is a quote in your book that I love, which is that one of

the benefits of Scrum is that it really exposes existing issues. I couldn’t

agree more. It’s been my experience that Scrum really sheds light on underlying

problems or processes that are actually bottlenecks. One of the challenges that

I’ve seen is that sometimes the personalities and procedures that were in place

before adopting Agile may be discovered to be part of the concerns. Some of the

potential personalities involved may even be in leadership roles. So one

question I would like to ask you is, how does an organization work on improving

their adoption of Agile when much of the legacy culture, leadership style and

procedures are still in place?

Ken: This is actually a critical question and how people

respond in this situation, to me is one of the tell-tell signs as to whether

they’ll be successful – let me give you a specific example. Some years ago, I

was giving a management presentation during lunchtime in front of my boss. So

we budgeted 90 minutes, brought in food, the management team. So senior

management and director level people and some VPs are in the room and I made

the following comment; I said – by the end of your Sprint, you should get the

work done and you should have zero known defects on what you just built. And I

also mentioned that people that have historically been members of the testing

team should be fully integrated in with developers in a single team. They

should work together collaboratively with zero defects to get things done.

Immediately this lady in the back of the room raised her

hand. She said ‘This won’t work here’. I said ‘Why not? What part of that?’ She

said ‘I manage the QA team’. She goes ‘You just told me that I should assign my

people on to the Scrum team.’ Yes, right – we work collaboratively that way.

She said ‘Yeah, well here’s the problem. You also said that at the end of every

Scrum we should have zero known defects and the reason that won’t work is

because we compensate our testers based on the number of defects they find.’ So

she’s saying basically that’s not very motivating if you’re one of my testers

because you’re going to make less money if you do that.

Now, what she says next is the tell-tell sign for me as to

whether a company has a hope of being successful with Agile. Here’s what she

didn’t say. She did not say ‘Well, in that case, I’m just not going to assign

my people out on to the Scrum teams. I’m not going to do that, I’ll just keep

them together’. Meaning, I see the impediment. Agile has shone a bright light

on where we have an impediment. And rather than address the impediment head on,

instead what I’ll do is I’ll alter the definition of Agile so that that

impediment doesn’t exist. Now, companies that are bolted to that approach will

probably fail and fail quickly with Agile.

Instead, what she actually said was ‘I think I’m going to

have a conversation with the VP of HR and the VP of Engineering so that we can

discuss how we’re going to change the compensation plan for our testers’. Now,

we have in place people that understand that the current process, the current

compensation system is at odds with them being successful with Agile. And

rather than run away from the problem, hide when the impediment gets exposed,

we’re willing to address it head on. So my advice – if you don’t have the

executives trained or understanding these key points, you’re likely to have a

problem. By the way, her next comment – I mentioned other things; I don’t pull

people off of Scrum teams to work on your pet projects. Another person raised

her hand and said ‘I do that all the time – what else shouldn’t I do?’

At least in an environment like that, they’re willing to

entertain it. So my approach to trying to address the problem is the leadership

requires the proper kind of training and coaching principally on core Agile

principles. That’s where I try to focus with them. So if I can get 60-90

minutes with them over lunchtime, that’s a good start. Not as good as having

them in a multi-day class, but they’re not willing to make that commitment

usually. So get 60-90 minutes, help them to understand that core Agile

principles and hopefully they can align their behavior with how we’re going to

do agility downstream, cause if they don’t, we will have a serious disconnect

and companies with a better experience at that will likely fail in their

attempt to use Agile, because of that disconnect. It’s a critical question and

either they’re going to understand what we’re trying to do and embrace it, or

they’re not and these companies are going to have a hard time.

Ronnie: I love that example! One of the approaches that I’ve

seen previously is that the director VPs and executive teams actually complete

certified Scrum Master training. I believe that really helped them understand

the vision and what Agile teams actually need.

Ken: I find it beneficial when people like that, people with

high level titles actually attend the classes. Part of the benefit is not just

their understanding, which is profound, but a second benefit as well. You know,

for example – in one class, I was talking about how teams should give range

answers to questions as a way of communicating uncertainty. Range answers to

planning questions, like ‘When will you be done?’ Give a range answer: between

X number of sprints and Y number of sprints. And in this one class, an engineer

stood up and said ‘Yeah, but my management is never going to accept a range

answer’. And there’s only one person in this class – it was a large class – and

the only person in this class wearing a suit was the general manager of the

whole division. He then stood up, turned around and said ‘Well, I’m the guy

asking the questions and I’m telling you I’m willing to accept a range answer

and I’d like to talk to you about how we can keep range answers within one

calendar quarter – but yes, a range answer will be acceptable’.

That pretty much addresses the whole point right there.

People are looking at each other, are like ‘Okay – he is the guy who’s asking

questions and he just said he’s willing to do it and I guess we can actually

move on here under the assumption we can provide range answers’. So getting the

senior execs in a classroom, I think it’s a high priority – but it doesn’t

happen nearly as frequently as it should. Occasionally, I’ll get the luxury of

having a one day – and rarely, but it does happen – a two day class with

leadership. I would say one of every four classes I do, we have that hour to 90

minutes lunchtime conversation. Which is precisely an hour to 90 minutes good,

not as good as a half a day or a day or two would.

Ronnie: Great answer! Leading to my third question which is

adaptive vs. predictive, which is referenced in your book. One of the examples

that came to my mind was release planning. Could you please take a moment to

explain to our listeners adaptive vs. predictive and perhaps how it might apply

to release planning?

Ken: Be happy to. A lot of folks, when they think of

Waterfall, they think predictive. Predictive up front water. In Waterfall, we

have to put together the full requirements document on the first day, when we

have the worst possible knowledge we’ll ever have about that project. So to a

certain stage, you have to predict. If you’re being rude, you’d say you’d have

to guess what all the requirements are. A lot of people didn’t think of Agile

as adaptive – more just in time. So if you imagine like these two being on

either sides of a teeter totter or a see-saw, what I’d like to suggest is that

if you’re overly aggressive in either dimension, overly predictive or overly

adaptive, you’re probably going to be unhappy.

If you’re overly predictive, you’re probably just going to

dip down into the guessing pool. There’s a part of you who might say ‘You

couldn’t possible know that – not on the first day, not when you have the worst

possible knowledge you’ll ever have!’ At this point, you’re just guessing, and

that seems dangerous. On the other hand, if you’re fully adapted and you’ll do

everything just in time, which in the context of release planning would mean no

upfront planning whatsoever, my guess is that’s going to feel chaotic. Agile

isn’t about everything done and adapted just in time. It’s about finding

balance; balance between up-front work, predictive work and downstream adaptive

work. And where you set that balance point will be different for different

types of projects or products, different companies.

So let’s buy into the fact that it’s a misperception to

believe that Agile is anti-upfront planning. Because, of course, that’s simply

not true. Agile is anti-waste. And if you do too much planning upfront, then

you’re going to inject too much unnecessary planning inventory into the system

that’ll have to be reworked or thrown out when something goes wrong. So the

principle here is upfront planning should be helpful, just not excessive. In

the spirit of just enough, just in time. But there’s nothing in there that says

‘avoid upfront planning’ so release planning – if you very specifically look at

that, if you define what it means, in today’s world release planning is

becoming a harder term to use because in the past, a release typically was

performed after multiple sprints of work were completed. So in that scenario, a

release was larger than a sprint. But what about the teams that release every

sprint?

You can argue ‘Well, isn’t sprint planning the same as release

planning?’ Or what about teams that do continuous delivery or

continuous deployment. They can release every feature as it become available

during this sprint. You can even argue that in that context, a release smaller

than the sprint. So let’s change the term just for a moment. Let’s call it

longer term planning. And people might say ‘Well, longer than what?’ Well,

longer than a sprint. Even if you release every sprint, or even if you release

multiple times during the sprint, there’s still a benefit to looking out at a

horizon that’s larger than a single sprint. We might be using milestone

releases along the path to a bigger goal. And so release planning, is really

trying to plan to that large goal.

Okay, that presents certain issues. Here you are at on the

first day of the project – what if that longer goal is 6 months out? Or even

longer? Can you actually give any kind of accurate answer that early on? And the

answer is that you’re going to get asked the questions. And we all know what

the questions are. Questions like ‘When will you be done?’ or ‘How many of

those features do you think will be available 6 months or 9 months from now?’

And ‘What’s all this going to cost?’

Now, these seem like fair questions to ask. And for us,

trying to be in a position to answer them, we need to figure out what

realistically we can do. And the good news is we can do some things. And the

way we’ll address it is, much like I was suggesting earlier, we give range

answers. In release planning, the smart approach is always give a range answer

to questions. If they ask, ‘When will you be done?’ – stating a specific date

is likely going to be overly precise. On the first day of the project you

cannot be that precise, you don’t have good enough information. But I can

always be accurate by giving a range. You just have to give a sensible range.

If I tell you it’s going to take 4-7 sprints to get this done; that expresses

one level of uncertainty. If I said it’s going to take 4-29 sprints; that would

express a completely different level of uncertainty.

At a certain point, I know I can always be accurate, but it

could be ridiculous. Yeah, it’s going to take between now and 3 years from now

– yeah, but that’s not very helpful. So we try to give range answers that are

accurate, that are reasonably actionable by the people who hear them. They can

make a business decision – ‘Should I do this, should I not do it?’ So we have

to do some amount of upfront planning to be in a position to answer those

questions. Typically, at the release planning level, we try to work with

medium-sized stories. Not epics that tend to be too big, but use more portfolio

level planning, but with some people might call features or even themes so we

try to generate a first pass at those, input high level size estimates on them

and then based on a team’s history velocity, or a forecasted velocity, we try

to give a rough estimate. And we try to simplify the problem. If someone says

‘Well, my release is going to be 2 years out’, I don’t think that’s a

reasonable timeframe to be planning. Especially because there’s likely very

important increments along that path that we can plan first. Rule number one is always try to turn a big problem into a

small one in planning. And always give range answers. So I do think by

balancing upfront, predictive work, sort of adjusted time adaptive work, we can

do reasonable release planning. With a very important caveat. We update the

release plan every sprint. Release planning is not a one time at the very beginning

activity. Yes, I did do it early on because I probably got asked some questions

I had to address. But I update my release with every single sprint as I acquire

better knowledge. That’s how I tend to approach it.

Ronnie: Perfect answer. Our next question is also from

Essential Scrum which is in regards to idle work vs. idle workers. I’ve seen

this come up countless times and it can be very frustrating on me. I often see

management focused on idle workers. For example ‘Why is this person only at X

percentage of utilization and rather than a team mindset of why is there work being idle?’ Could you please take a few minutes and explain idle work vs.

idle workers for the audience?

Ken: I will. To me, this is a critical topic, and I cover it

in all of my classes because it lays a foundational principle that I need. The

way I try to explain it to folks is this way: the largest cost in software

product development is the people. Once we buy hardware and whatever software

people need to do their job, the real cost of any software organization is the

cost of the people that are hired, which is why budget almost always equals

headcount. Everybody is

interested in eliminating waste, but the issue of course, is that within

organizations there are multiple forms of waste. And these types of waste

typically trade off, meaning it’s usually impossible to simultaneously

eliminate all forms of waste. So what people tend to do is they go after the

waste they can see. And since we said the largest cost in software product

development is people, then a visible obvious form of waste would be underutilization

of people. Meaning, if I hire someone to do testing and I pay them 100% salary,

there’s an expectation that that person is going to test 100% of the time. And by the way, my management probably measures me on how

busy I keep that tester, so they assume that the tester reports to me. If I

hire that individual in, pay them 100% salary and assign them to a project, and

that project requires 60% of their time, if I were to stop there, it would give

the appearance of a 40% underutilization of my tester. And I’ll look bad to my

management because I’m paying this person 100% salary, but the individual’s

only working 60% of the time. Okay, that won’t do.

So to solve the problem, I’m going to do the obvious. I’m

probably going to assign that person to a second project, which will lead them

up 30%. Okay, I now have them at 90% utilization – but there’s still a 10%

underutilization – well, it worked so well for 2 projects, let’s try 3. Okay,

clever me. I’ve now eliminated idle tester waste. I’ve driven underutilization

of my tester to 0. They’re 100% utilized. So I have eliminated that form of

waste. The question, of course, is what just went the other way? Meaning, we

said sometimes waste trades off – as one goes down, the other goes up. Well,

here’s the problem. The idle workers weren’t waste that was causing the most

economic advantage. Here’s the problem: as we keep people that busy, chances

are they’re going to need to start blocking work. As an obvious example, I’ve

assigned that person to work on 3 separate teams. It’s very likely, at any

point in time, that person’s blocking two teams. They’re working on one of the

projects and the other two are waiting. That means, the work is now idle.

So what you end up seeing is this inventory that’s building

up all over product development. Inventory being blocked work sitting in

queues, waiting to get done. And the problem is that blocked work, that inventory, is causing huge economic damage. And people don’t focus on it because that’s an

invisible form of waste, hard to see in our inventory and product development

because typically, it’s bits out on the disk, code out on a server in best

cases. Whereas inventory in other cases tends to be more visible. So they go

after the visible ways which is idle workers and they ignore the kind of

invisible ways. The people are still 100% busy, so it

looks like the system is working at capacity. The problem is that if you

examine what happens in large companies, at scale, if you look at how work

flows across their organization, across the system, the collection of teams

they put together to get the job done, what you often find is up to 90% of the

time, the work is blocked.

Imagine you took a stopwatch out of your pocket when a

customer asks you to work on a feature and you agree to do it. If you click the

stopwatch at that point and time starts running, you don’t get to click the

stopwatch again until you’ve actually delivered the features to the customer.

And so, what I’m saying, from click to click on that stopwatch, in a lot of

organizations that I visit, up to 90% of the time or more the work isn’t

moving. And that’s causing severe economic damage and the reason I say that is

it’s injecting a cost of delay. The work could have been done faster and

delivered to customers faster and delivering work faster generates revenue

today; revenue today is worth more than revenue tomorrow because revenue today

generates money and money is a time battle. When you compare the cost of delay,

of idle work, against maybe a little bit of underutilization of the workers you

realize that you’re working on the wrong thing.

In organization, it’s all about the idle work, but that’s

exactly the opposite of what most companies do. Most organizations attempt to

optimize the utilization of their people, and by doing so, they inject a lot of

delay into how long it takes to get the work done and that delay has a real

cost. And they don’t quantify it, so they don’t really see the impact of that.

So you focus on the idle work, you don’t worry about the idle workers. You’re

trying to achieve what I call ‘fast, flexible flow’. To very quickly flow the

work across to your teams in a fast and flexible way. You subordinate other

decisions to that, which means ‘I don’t really care how idle or how occupied or

how utilized your workers are, but I do care about is how quickly you can pull

the work across your organization in a high quality way.’ Though in a sense, most organizations are focused in the

wrong place. They’re watching the workers when they should be watching the

work. That’s the concept here.

Ronnie: Well, unfortunately I’ve seen that happen many

times, and especially with the example regarding QA. It is such a common

practice to do just what you described – when one person is placed on multiple

teams to boost utilization numbers. That practice actually injects more project

risk because if the person is working on team A, B and C – if team A hits a

major bump in the road, there’s no margin to absorb it. Work simply becomes

blocked in the other teams, it can really cause havoc. I love your answer which

forces the organization to ask better questions.

Ken: It’s a good example. I’ll leave you with one analogy

for the listeners. And I know it’s the extreme analogy, so don’t get upset

because it’s just extreme, but it’ll illustrate the point. Isn’t it true we pay

firefighters to be idle most of the time? If you think about it, you really

don’t want to keep your firefighters 100% utilized, because if you do, then the

next fire that breaks out, very likely structures will burn and people might

die. And as citizens, we deem that to be unacceptable. So we actually pay

firefighters to be idle most of the time. Why? Because when you need them, you

need them. And you need them now and any cost of delay associated with that

work is unacceptable because the ramifications are too great. But I’m not

saying you should pay people to sit around and be idle on your software

project. But I’m suggesting the fallout – if there’s a certain skillset that

when you need it, you need it; and any delay in it becoming available blocks

your work and there is significant cost of delay in the blockage, you might

want to seriously rethink the strategy of trying to keep everybody at 100%.

Ronnie: Very true, I love that example. There are tons of

questions that I would love to ask you, but I definitely want to respect your

time. With that said, my final question is in reference to Validated Learning,

which is mentioned in your book, Essential Scrum. I’m a huge fan of Validated

Learning and the Lean Startup by Eric Ries, which I highly recommend. We may

have some audience members that are not yet familiar with the concept and how

it might apply to their team. Can you please take a few minutes and explain to

our listeners Validated Learning?

Ken: Sure. Lean Startup is a very good book and does

leverage core Agile principles and a lot of the terminology, which is why I’ve used it

in the Essential Scrum book, because it very nicely captures a category of

principles that are fundamental to Agile. And the way to think about Validated

Learning is you should validate important assumptions fast. It’s dangerous to

make an important assumption and have it live long in an invalidated state.

Because if I make an assumption and I don’t go out and get it validated, I

start building things or making other decisions on top of that assumption and if

a long time later I finally validate or attempt to validate the original

assumption, what if I determine the original assumption was wrong?

Now, I’m likely sitting on a problem that is much, much

larger than it needs to be. So most people are familiar with the techniques of

performing validated learning, prototype, concept study, experiment – meaning

that validated learning is the act of buying information when you’re

presented with a high degree of uncertainty, and therefore you made an

assumption, if you were certain about something – you wouldn’t have to make an

assumption, you’d just make the correct decision. But in the presence of a high

degree of uncertainty, you have to make these assumptions and then what you

have to do is go buy knowledge, buy information to validate your learning,

meaning to be able to confirm or refute the hypothesis that you stated, the assumption

that you made is correct or it isn’t.

You just have to do that fast. So, in Agile, if you think

about a learning block – you make an assumption, then we build something, then

we get feedback on what we built, then we inspect and adapt, the goal is to go

through that loop very very quickly. So in Agile the third part of this

Validate Learning is that you have to organize the flow of your work to get

fast feedback. In a sense, you say ‘What is the next most important thing I can

learn?’ and then go learn it. And then validate your learning. And if you learn

that you’re going the wrong way, take what you learn, plant your foot and alter

your direction. Take the learning that you have and maybe go to a better place

based on that.

So Validated Learning has two superior economic

characteristics. One – it prunes a bad path quickly. If you’re going down the

wrong path, which you don’t want to do, is keep running down that path very

fast. You’d like to determine you’re on the wrong path quicker so that you can

then pivot over to a new path. That’s economically valuable. The second

economic characteristic – it helps your exploit an emergent opportunity faster.

What you don’t want to do is learn late in a project: ‘Wow – there’s a much

better way we could’ve done this’. When it’s likely to do anything about it in

this release and maybe in the future. Maybe we’re so far down committed on the

path we’re on that even though we all now agree there’s a much better way of

doing it, we actually can’t exploit it. By validating your learning sooner,

you’re able to them exploit those opportunities sooner and end up in a much

better place.

So this is a critical concept. It applies in startup

companies, it applies in well-established companies; they’re building the next

generation product that’s been there for 10 years. You have to validate your

learning, validate the important assumptions fast and you organize the flow of

your work to get that fast effect.

Ronnie: Thank you so much, Ken, for being such a great guest

on our show. I’d love to give the listeners an opportunity to learn more about

your services and how they may be able to contact you. Can you please take a

few minutes to expound upon that?

Ken: I appreciate that. I have a website, it’s

innolution.com and on there I have a blog that I talk about a lot of these

topics and I also have a lot of my presentations that I give at conferences so,

if anybody’s interested feel free – you can go down and look at presentations

on portfolio management, on what I call Essential Scrum and a variety of other

topics, the most recent being risk management. So by all means, feel free to

have a look at that. Mike Cohen and I also have developed a tool called

Comparative Agility. It’s a free survey that you can take which at the end tells

you how Agile your team is by comparing you with close to 13,000 other people

who have already taken the survey – so there’s a number of resources out there.

Also, I do offer training and coaching, so if your company might have an

interest, feel free to contact me. All my information is on my website.

Ronnie: Thank you so much for joining us today Ken and for

your great insight and advice.

Ken: I appreciate you hosting me and I wish everybody the

best of luck with their application of Agile!

Thank you for listening to

All Things Agile! We look forward to you subscribing to the podcast on iTunes

and leaving a kind review. Thanks and God bless!

Welcome to another episode of All Things Agile. In this episode, we discuss the tough subject of team conflict. Whether your Agile or not, every organization is bound to encounter team conflict. We'll discuss how to resolve existing conflict as well as preventing it from even occurring.

I am also very excited to announce that the next episode will feature an interview with notable Agile author, Ken Rubin.  Ken is the great mind behind Essential Scrum. I hope you enjoy this episode and make sure you subscribe to catch the upcoming interview using this link: iTunes. Reviews on iTunes are also always appreciated. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: [email protected].

All Things Agile - Episode 010 - Resolving Team Conflict

Welcome to the All Things Agile Podcast! Your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast on iTunes, and please check out our sponsor:

TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Hello everyone and welcome to the All Things Agile

Podcast! First off, I want to get started by issuing an apology for the delay

in getting a new episode out. The reason why is because I have an upcoming

guest and unfortunately, we are not able to get the scheduling worked out in

time for this episode. But, I am pleased to announce that Ken Ruben, author of

Essential Scrum, will be the honored guest in our next episode.

That said, I want to go ahead and issue another episode. I

don’t want to keep you waiting too long – and with that, I hope you accept my

apologies for the delay in getting this episode out to you. Now, before we

begin, a quick reminder that this podcast is for informational purposes only

and accepts no legal liability. So the topic for today will be ‘Resolving Team

Conflict’. Virtually any team you will be working on is going to have some

degree of conflict. It’s just part of human nature. You can’t all agree 100%

of the time, even though Agile encourages more of a democratic approach to what

the team is working on and the approaches that they use, there’s bound to be

some degree of conflict on any team that you work on.

Now, before we dive into solutions to resolving team

conflict, let’s first identify the different types of conflict. One type I

think is just general healthy conflict and what really we’re referring to is debate. Using the word ‘conflict’ is probably inappropriate in this

particular case. An example of debate, you may have people that share different

ideas and solutions and what type of technologies should be used, or different

coding practices, whatever. That’s fine. Having those healthy debates,

discussing ideas, is actually a good thing. In this case, it allows you to have

differing points of opinion which can be discussed, evaluated and reach an

ultimate decision on. And that’s fine. That’s a healthy form of debate or

conflict, if you will. And, if you have a little bit of that on your team,

that’s fine and I wouldn’t worry about it.

What we’re really going to be focusing on in this

particular episode, is unhealthy debate. And I would describe unhealthy

conflict or debate as a case where it’s really impacting the team. Where it’s

creating what I like to call a toxic environment. You can definitely tell it

when you’re part of a team that’s having this because it just brings

everybody down. It brings the morale down, and it just feels like the team has been

poisoned, if you will. And you’re going to see evidence of that not only in the

morale, but the conversation, the level of communication and collaboration are

going to go down. You are going to see people that are going to be engaging in

using a lot of inappropriate language. You’re going to have a lot of people

getting into some sort of personal battles with each other or one-upmanship, and

it just really destroys the overall team morale and ultimately, the

productivity. And you’ll actually begin to see this long-term in the metrics where you’ll start to see a team that was doing really well, and then they

start to perhaps have their velocity dip down and more and more of

their stories are being accepted late, etc. So that definitely has an impact. I

would definitely classify unhealthy conflict as conflict which is really

bringing down the team. It may be disrespectful, and it’s simply just not in the

long-term viability of the team. So that’s kind of how I would probably

classify the two main types of conflict that I see, either healthy, just

discussion of topics and technologies versus some things more personal and

toxic. And so we’re going to talk about the latter and how do you resolve it?

Now, I have personally seen these cases come up numerous

times in my career, and if you are particularly in a situation – your team or teams

that you’re coaching or another team in your company that you’ve seen this kind

of just not quite right environment, just a little bit toxic, that’s not

uncommon. First off, it’s bound to occur on average. So that said, even

though it’s a common experience within a company, you certainly don’t want to

maintain that toxic environment. Because here is an interesting point that I

have seen personally which is if one team is currently experiencing a level of

poison, if you will – not only does that team’s morale drop and their

productivity drop – it can spread to the other teams. It’s true.

You can have a team that is doing really well, but if their

neighboring team is engaging in disrespectful behavior and yelling at each

other, cursing at each other, it’s going to impact the neighboring team. They

are not going to want to come in to work that day. Their morale starts to drop

and then their performance starts to drop. So another reason why you want to

deal with unhealthy teams head-on is because not only do you want to help that

team, but you also want to ensure that the degree of poison really doesn’t

spread to the other teams and disrupt them as well.

Alright, so let’s talk about some practical tips that I’ve

personally implemented in the past and found beneficial. Again, every company’s

unique, every team’s unique – you’re responsible for your own actions, but something that has worked well for me is to focus on the present and the future.

Often times when you’re trying to resolve team conflict or coaching the teams

through conflict situations, the team members may get too focused

on the past and the things that happened. And, what I mean by this is that I’ve

certainly seen cases where people get into paper trail battles. You know what I’m

talking about? Where you have someone who has an email that they sent 6 months

ago, and they bring it out. ‘Six months ago you said blah blah and now you’re

saying this!’

So you have these people that hold on to every little piece of

communication, every little email and their real honest reason why they do so

is so that they can spit it back out later. And candidly, that’s not healthy.

And when you really analyze it, those persons, those individuals are focusing

their attention on things that occurred in the past, right? ‘Two weeks ago you

said this; last year you did that’ and so they can get into a lot of negative

debate, a lot of disrespectful behavior sometimes because they’re so focused on

past hurt. And they’re not really learning to forgive and let it be water under

the bridge. And they’re just holding on to that pain, and they’re then letting

that disagreement, anger, and pain, poison the waters in the present and then going

forward towards the future. And you don’t want that.

One of the first things I like to focus on when trying to

coach a team is to – sort of phrase of the idea is: keep the water under the

bridge and keep it there. Okay? Don’t say ‘Oh well, yeah, okay we can move

forward’ and then the next week later ‘Again, I told you 4 months ago that this

is the way we’re supposed to do it’, etc. And again, that leads to that

negative behavior if you’re always bringing up the past. And so whenever I’m

sort of involved in trying to coach a team, I try to think about staying

present, right? Think about: never mind the past, whatever happened in the past

has already happened – we can’t get back into the DeLorean and go back in time

and try to fix it. So in that case, what can we do right here, right now? Stay focused and present. And if you’re speaking with them and

they start going ‘Well, what about that 3 months…?’ just say Stop! Stop. That

was in the past, we can’t change it – what we can change is the present, let’s

focus on that. And it’s not easy to do, but try to hold a hard line on that.

Just say ‘That’s in the past, let’s learn to forgive and put that behind us and

carry on for the present and the future.’

Now, if you can work on that and allow the team to avoid

getting into those negative conversations about the past, then I’d say the next

step is to focus on what actions or changes they can make here in the present

to avoid future pains. So, for example, if part of the past pain was say, for

example, some of the defect procedures were not being followed, as an example,

and people were complaining about it with each other about whose fault it was –

this person didn’t follow procedure and they should have, and someone has a

paper trail from 6 months ago. To avoid that situation, I would say: Identify

what changes could prevent that problem from happening again. So, for example,

you might do six sigma root cause analysis, if you will and say ‘Okay, what

really happened? Why was the process really not being followed?’ Well, maybe

one reason is because the tool being involved wasn’t adequate enough. Maybe you

just need to upgrade your toolset, maybe there’s some other procedures that can

be added. Maybe someone needs to go through some additional training or maybe

involvement with another team can be changed or improved. Or another team

member’s schedules can be altered to allow them greater flexibility in the work

schedule. Whatever the case may be, but the point is this: don’t dwell in the

past, it’s already happened, okay? And then, for being able to resolve the team

conflict, identify actions or steps that can be processed right here, right now

and able to prevent that future pain.

In terms of where it’s a little bit more

personal – that does happen sometimes, where you have teams that for whatever

reason, people harbor personal grudges towards each other, and even if all of

your policies and tools and procedures are all well and good, some people may,

simply put, just not like each other. It certainly can happen. Again, most of

the time, teams will be okay with just changes in their practices. But, there

will be cases where people just simply have personality clashes and where I’ve

seen that in the past – if it’s really that strong, I would say it can be

sometimes worthwhile to go ahead and switch some team members around. There can

be cases where, for whatever reason, those overlapping personalities just bump

up against each other just a little too strong, but you can take that

individual and perhaps shift him to another team, and he’ll work perfectly well

there! Because at the end of the day, all team members are not equal. We each

bring our own level of skill and personality and really, you don’t want

everybody on the team to have an exact mirror copy of each other, in terms of

skillset and personality. You need that diversity because it helps produce a

more well-rounded and ultimately balanced team.

If one person, for example, is a little bit more thorough

and another person is a little bit more sort of quick to act, actually having

them on a team together can sometimes help because the person who’s more

thorough will help balance the other individual out and ultimately, you can end

up with a sort of a middle ground which is actually pretty well and functional.

However, if you have those personality clashes where perhaps you have two

individuals that are for example overly thorough and they may be bumping heads

with each other, maybe that person belongs on another team and maybe there’s

another team out there who needs that type of personality and skillset and they

may actually be a welcome addition.

Now, it is kind of like a last resort to implement team

member changes to shift the morale, but it is certainly better to do that than

to let the team continue in unresolved conflict. And I know it takes a little

bit of guts to go ahead and to talk to people and say ‘You know, I think we

need to move you to another team' but you got to think about the overall team

and the overall organization with the other teams. And again, if you let this

team remain unhealthy or toxic, it’s going to spread to the other teams and you

certainly don’t want to do that and that’s not fair to the other teams, to have

that happen. So, again – I always start first by avoiding getting into the past

trauma state, focus on the present, evaluate what options can occur in the present,

changes and practices, etc; they can be implemented to prevent future pain and

if it is a situation where it’s kind of a deep personality clash more so than

the practices, there need to be team member changes. And that’s okay, and that

does happen – I have certainly seen it happen in other teams as well as my own

teams before. And that’s okay – in a larger organization, it’s bound to happen

sometime.

I would say, kind of like an ultra-last resort, I really

hate to see situations where a team member is removed from the company. That

has happened, I have seen it happen, but that is such a last resort action and

I would certainly encourage any Agile professional that’s trying to help a team

experiencing conflict, that they truly keep that as an absolute last effort

action. And the reason why it’s because it’s my belief that it’s easier to

coach and maintain than it is to replace. Whenever you replace a person in your

organization, you’re incurring cost not only with recruitment, but also with

the interview process – people have to take time out of their days just to

interview the guy or girl – but you also have to consume time with training and

getting them up to speed and having them learn the culture and the ins and outs

of the team, team practices or they may be new to Agile and you have to train

them with that. So all that process can easily take a couple of months. And in

doing so, the team’s velocity is already impacted. So I personally recommend,

whenever possible, try to coach through the situation and reach a solution,

rather than simply just throwing in new bodies. That’s my experience and that’s

my belief. So, again – this is sort of a fourth option there, kind of last

resort.

But those are the strategies that I’ve employed to try and

resolve team conflict and that’s a conflict once it’s already occurred. And I’d

actually like to take a moment and cover a different topic which I honestly

think many Agile professionals don't even consider, and I haven’t seen it mentioned

too much in articles or books, and that is preventing team conflicts. The

material I just covered a second ago is in relation to resolving team conflict once it’s already occurred. But, the old adage is that an ounce prevention is

worth a pound of cure. So you might ask yourself: how can we prevent team

conflict from ever even occurring?

I’ll offer, I’d say about 4 suggestions that I believe, if

you can implement them, they may help you. I’ve certainly seen them help teams

in the past. The first is co-location. When you’re able to bring the team

together physically, like they’re actually physically sitting next to each

other, it often times helps prevent team conflict. If you have teams that are

composed of a lot of full-time remote members, it can be difficult to maintain

a healthy team. And the reason why is because of the bandwidth of

communication. And the highest bandwidth of communication is face to face,

where the person can see the other person’s gestures, the tone of voice, etc.

And if they’re remote too much, then you’re doing a lot of email, a lot of IM

chats, etc. and it’s so easy for the words to get misinterpreted, to get lost

in translation. And so, in that case, it’s just bound to result in team

conflict eventually. So if you can co-locate the teams, and I mean physically co-locate, like in the same office area, that really helps with being able to reduce

the chances of team conflict ever occurring.

Second way I’d highly suggest is in how you treat the team

members. And what I mean by that is this: if you have a team of let’s say 7

members or whatever, and one or two of those members are always favored upon by management or leadership and always listens to those individuals and nobody else,

or those individuals get included in all the important discussions and meetings

and nobody else does; they’re the ones that always get promoted, that receive a

healthy salary and everyone else doesn't– that’s bound to create team conflict,

right? But if you can really look at the team as a team, and comprised of many

different people, each bringing their own value and contribution to the team,

that will significantly reduce the chances of team conflict from ever occurring.

Because you’re reducing the likelihood of people feeling disenfranchised or

left out. Or disrespected. So if you can prevent that – again, it’s a lot

easier to prevent team conflict than it is to fix it once it’s occurred,

right?

I would say that another way to help resolve team conflict

is through training. I’ve seen so many times where Agile teams are just thrown

together and the training aspects is never really fully delivered on. Even

though it costs a couple of thousand dollars, it’s far worth it to ensure that

your team gets off to the right start. You want to ensure that, for example,

all the Scrum Masters become, in my opinion, Certified Scrum Masters, Product

Owners become Certified Product Owners – again, these are my experiences; your

actions are your actions. But that’s my personal opinion – when you’re able to

have those individuals be formally trained, it really does help because they

learn the right practices, not just the way that the companies or organizations

are currently operating. And that’s important!

I also recommend having all of the team members receive some

sort of Agile training. Again, it enables them to have buy-in, and enables them

to better understand the changes being implemented and why, for them to really

see the benefits. If you simply throw people on an Agile team without adequate

training, I think you’re setting yourself and the team up for failure. Don’t do

it. Even though there may be some costs involved in training, it is absolutely

worth it to do so because the longer term cost of not giving them adequate

training and education will be ten times worse or even more than the cost that

could’ve just been handled up front through adequate training. So I definitely

recommend doing that. Don’t skimp on training and coaching and that’s not some

ad or something for my own benefit. I mean this sincerely that I have seen

teams and organizations that did not train adequately and I’ve seen others that

did. And it’s a night and day difference. And again, by doing that, you’ll help

prevent the team conflict from ever even occurring, and that’s certainly

something you want to do.

The fourth thing that I would like to throw out there, a

suggestion again to prevent the team conflict in the beginning, is how you form

the teams. Who’s on the teams and in what roles or capacity? So many times I have

seen team conflict occur because the team members are just thrown together.

Look at a spreadsheet, get some names, throw them on a team. That’s simply just not wise. You need to really examine the skillsets and the personalities.

Who’s got a strong personality? Who’s going to be the person who’s going to

challenge the status quo? Who’s the person who’s going to be a negotiator?

Who’s the person who’s going to help bridge different people together and help

people come to a consensus?

Finding out those personalities and the skillsets, including

development and maybe testing skillsets, finding out those individuals and then

seeing how to craft them into a functional and balanced team really pays

dividends because they are far less likely to have conflict. They are going to

be able to work with each other and compliment each other. If you just simply

throw people together in a team, you’re just asking for conflict. And not only

that – but if they’re not balanced properly, if you look at for example the

work each member’s contributing during a particular sprint or iteration, you’re

more likely to find that the workload isn’t very balanced and that’s

usually because the team’s not balanced. They’re not properly structured. So

prevent the conflict in the first place by investing time to ensure that from

all the people you have across the organization, that you’re really analyzing

their skillset and personalities and putting them together and positioning them

to win, right? If you’re just throwing the bodies together into a team, you’re

just asking for failure and conflict. If you invest the time – and really, how much time does it

take, folks? A couple of days, maybe, to really take a deep look at the team

members and really consider who would be great to partner up with who and if

you can spend that time to partner the team members up correctly, it really

will pay dividends. If you can do that, you’ll prevent a ton of team conflict

down the road. So that’s four suggestions for you, in relation to preventing

team conflict, on top of the other suggestions on resolving if it’s already

occurred.

Alright, well I think that wraps it up, regarding for how I

have personally tried to resolve and prevent team conflict. I certainly am open

to hearing your suggestions. If you have any, feel free to send me an email at [email protected]. And

don’t forget to check out the AgileInstructor.com website and

TeamXcelerator.com website. And as mentioned earlier, I do have a special guest

coming up in the next show, which is Ken Ruben, author of Essential Scrum and

I’m really looking forward to asking him some really great questions I think

you’ll enjoy and find insightful. Well, I think that wraps it up for this show

– thank you so much for your patience in waiting for a new episode, I apologize

for the delay and looking forward to releasing a new episode with that great

interview with Ken Ruben. Thank you very much! Goodbye!

Thank you for listening to All Things Agile. We look forward

to you subscribing to the podcast on iTunes and leaving a kind review. Thanks

and God bless!

Welcome to another great episode of All Things Agile. This blog and podcast is dedicated not only to interviews with Agile leaders but also to actionable and practical advice. In this episode, we tackle Scrum of Scrums. Well cover what it is, mechanics, benefits, and things to watch out for. If you have multiple Agile teams, this is an episode you must checkout.

As always, please take a moment to subscribe using this link: iTunes. Reviews on iTunes are also always appreciated. Do you have a question that you would like answered in an upcoming podcast, please send your question to: [email protected].

All Things Agile - Episode 009 - Scrum of Scrums

Welcome to the All Things Agile Podcast! Your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast on iTunes, and please check out our sponsor:

TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Hello everyone and welcome to the All Things Agile

Podcast. Today’s topic will be: Scrum of Scrums. What are they and how do you

implement them successfully? But before we begin – a quick reminder that this

podcast is for informational purposes only and accepts no legal liability. So

let’s get started. As part of the AgileInstructor.com blog and this podcast,

All Things Agile, I like to alternate between interviews and informational

content. I think it’s important to help listeners with direct, actionable

advice based on hands-on experience. Interviews are great and I certainly look

forward to conducting more interviews, including in the next episode – however,

I definitely want to include direct content. Things that I’ve learned from my

experience that I hope can help you.

One of those topics that is often overlooked is Scrum of

Scrums. Now, many people have heard of this, but are not really quite sure how

to pull it off or perhaps they’re kind of winging it right now and perhaps

haven’t seen what has worked at other organizations and are maybe looking for

some additional advice. So I’d like to focus today on, again, Scrum of Scrums.

So in this case, let’s start with ‘What is it?’

For those who haven’t heard that term – Scrum of Scrums –

basically, when you have the individual Scrum teams, maybe in a smaller company

or at a team that’s focused on a product –that team might work well and be able

to take care of all the needs and that’s great. However, you may have cases

when one team is just not enough to fulfill the needs of a product. Or perhaps

there are multiple products being worked on and perhaps each team is working on

one particular product or component, but those teams then have dependencies on

each other. So just to recap: you may have cases where you have to have

multiple teams working in order to get the job done on a particular product

because there’s just so much work to do; or perhaps you still have multiple

teams, not because multiple teams are required for a particular product or

component, but just because maybe there is a dependency between the teams. You

may have a product A and a product B, and you may have a case where the

products are supposed to act like a suite. For example, a lot of Apple and

Microsoft products are designed to work together with each other. And so, in

that case, even though the teams may be working on separate products, they

still may have dependencies on each other in which case there are pieces of the

puzzle that still need to align with each other.

With any of our project managers in the listening audience,

they’ll immediately start to think ‘Well, you got to keep these teams in sync’

because if the teams are working on the same product or multiple products with

dependencies, then there’s definitely the risk that the teams can end up

stepping on each other. And, you run into other issues where you need to be able

to release code at the same time together, right? Because if you have, say 3 teams working on the same product, that product is going to get

released at one time or is going to get delivered to production. And you can’t

have those teams so disconnected that they’re causing havoc for each other and

making it difficult to release the product at one time.

And then you also have quality concerns. You have multiple

teams working on products together in parallel – there’s always a risk that one

team can make a change for something and then inadvertently break another team

and introduce unaccounted for defects. And naturally speaking, that’s not a

good thing. So, how to overcome it? Well, there are many different practices

and I’m not going to say there’s any particular right and wrong answer for

this, but one of the more commonly applied principles, or practices I should

say, is the Scrum of Scrums.

So there’s a need for it when you have multiple teams and you

have to keep them in sync, help them ensure they’re not stepping on each other

– what does the Scrum of Scrums actually look like? It can certainly vary by

organization, so I’m going to focus on what do I commonly see in the field?

Again – I’m not talking about a theory or a book, but what I actually see

taking place in many other companies and industries.

Scrum of

Scrums is a ceremonial meeting involving representation from

multiple Scrum teams in which those representatives get together and help

synchronize each other. For example, as I’ve mentioned – usually, what I see in the

field is that it tends to be representation from the contributing or participating

teams. Every organization is different – technically speaking, they could

involve all the team members, but what I often see used in the field is

representation. Meaning, you have a team of 7 people or so – each team

has many different team members and if you start to get everybody together, it

can get unwieldy sometimes. So typically, I’ve seen 1-2 representatives per

team.

Again, there’s no hard and fast rule regarding who those

individuals are, but what I commonly see is that it tends to be a ScrumMaster

and or Product Owner. Now, there can also be cases where another rotating team

member is involved – maybe it’s just a senior technical person or a senior

person regarding testing, so maybe they rotate on some kind of schedule – but generally

speaking, I tend to see the ScrumMaster and the Product Owner as being the

ones that are the most frequent participants.

And if you stop and think about it, that makes a lot of

sense. One of the roles or responsibilities, if you will, that I commonly

associate with the ScrumMaster is they need to know what the deal is. They

need to know how the team is doing. What are the team’s obstacles? What’s the

overall progress on where they’re at? As I like to call it: the ScrumMaster always knows the pulse of the team at all times. If someone

were to stop the ScrumMaster in the hall and ask how his or her team is doing,

they should be able to answer that question. Conversely, the Product Owner is

also usually in the loop and should be. The Product Owner should also be a

person who’s actively engaged with the team and knows not only generally how

the team is doing, but also how they’re doing in relation to the scope for the

items that are being worked on for that particular effort or release.

So in this case, having either one or both of those

individuals attend on a regular basis is usually what I see in practice. And I

also see value in having other rotating team members and I think if the Scrum

Master / Product Owner are the only ones to ever attend, then that can

sometimes stifle some of the other team members, or maybe sometimes the morale.

It is good to have some occasional participation from other team members – it

gives them insight into what the other teams are doing and also to ensure greater

participation and injection of different viewpoints and ideas.

But again, common things being common, I usually see ScrumMasters and Product Owners as typical representation. So if you had 3 teams

working on the same product and let’s say each one of those teams provided two

representing members – say for example a ScrumMaster and Product Owner – with

each of those teams and members, they’ll usually formed together in some sort

of a meeting or, if you prefer the term – ceremony. Basically, a quick meeting.

And again, every organization is different, everybody conducts Scrum of Scrums

a little bit differently, but what I tend to see happen in many organizations

is that Scrum of Scrums tends to form a modified daily Scrum or daily Standup.

Meaning that in your daily Scrum, you might usually have the typical ‘What did

you work on yesterday? What are you working on today? What’s in your way? What

are your impediments?’ Usually, I’ve seen Scrum of Scrums take a little bit of

variant to that.

So for example, the group members may get together for a Scrum

of Scrums and ask questions like ‘What have you worked on since the last time

we met?’ And the reason I mention that ‘since last time we met’ is

because the frequency for the Scrum of Scrums varies a lot. Some organizations

will have Scrum of Scrums weekly, maybe every two weeks – maybe once a sprint.

And some organizations will even have the Scrum of Scrums daily. And I think

there’s no hard and fast, right or wrong answer on the frequency. I think it

really depends also on the nature of the project being worked on and the teams,

and their maturity and the risk level involved. If there’s high risk and the

product pieces being worked on are very complex and there’s lots of teams

participating in this, then having a higher frequency is usually a good thing.

But if it’s a very mature product and the teams are very mature and there’s not

too much risk on what’s being worked on at that time, then a less frequent

Scrum of Scrums meeting makes perfect sense.

Again – I think that’s totally dependent on your

organization and your unique situation, but typically what I see is that

members get together and they’ll ask ‘What have you worked on since the last

time we met?’, whatever period that’s been; ‘What are you going to work on

before the next time we meet again?’ So for example if your Scrum of Scrums is,

say, weekly – What did you work on in last week and what are you going to work

on this week? As an example. And that helps clue in the other members on ‘Did

this team fulfill the items that they said they were going to work on? Did they

accomplish them; yes or no? And what are they going to work on next, what’s

coming up?’ That’s important information to know if you’re trying to

synchronize the teams.

Thirdly, what’s in my way? Or what impediments does my team

have? Again – just another way of saying ‘these are potential things that can

block us’ or ‘are blocking us’. And part of that reason is to one: see if

someone else can help. You may have a case where team A is very blocked at the

moment and running into issues, but perhaps someone on team B has had prior

exposure to this type of problem and they can answer that question like ‘Hey –

I’ve seen that before! Here’s what you need to do!’ and they can give you the

solution right there and avoid further pain. So it’s a way of not only helping

synchronize the teams, but also helping the teams help each other. So it’s

definitely an encouraging aspect of the Scrum of Scrums.

Another facet is by discussing the challenges faced by a

team is that it allows other teams to know that information and account for it.

For example, if they know that one of the other teams – say team A

hypothetically – is running into issues, then maybe one or two of those stories

that have originally been targeted may or may not complete on time and they can

sort of mentally put that in their list; if there’s concerns or if there’s

dependencies where if team A starts to slip behind the schedule, then team B,

which may have a dependency on team A, can then account for it. Like ‘Okay,

well, maybe we need to push off some of our items into a future sprint for example.

I would say the fourth question that can be asked in a Scrum

of Scrums is: What will you put in another team’s way? In this case, I’ve told

you what has our team worked on since the last time we met? What are we going

to work on or are we working on currently and I have discussed with you are

challenges and impediments, things that are concerning us or blocking us – and

forth, here are some items to be aware of, here are some heads-up things. Let

me give you some examples of how this can be applied to you. Let’s say you have

3 teams working on, as an example, the same product and for example team B is

about to make some risky changes. And they’re going to do it this week and they

may want to ensure that they give the other teams a heads up. Hey – as part of

what we’re going to be doing, I just want to make sure you are fully aware that

we are going to be making these changes, and when we do, it may break some of

the existing APIs and the other teams present may need to make some adjustments

on their side, so that they can account for the API changes, for example.

It’s a great way to ensure that you are letting the other

teams know of your potential impact on them, so they’re not caught off by

surprise and that really helps build trust and you’re not surprising other

teams with problems; you’re letting them know in advance ‘Hey – we’re about to

put something in your way, perhaps’. And maybe it doesn’t turn out that way,

maybe it’s just a potential risk – but you just want to ensure that the other

teams have that curtesy heads-up.

So again, just to recap: every organization is different,

every unique industry has its risk tolerance and things like that, so the

frequency may vary depending on your circumstances, the representation for the

Scrum of Scrums can definitely vary – depending on what you organization needs,

but as I’ve mentioned, typically I see in the field one to two representatives,

typically a ScrumMaster and Product Owner, maybe a rotating team member;

typically I see the modified form of daily Scrum or standup. Usually I see,

especially the first 3 ‘What have I worked on since the last time we met? What

have I worked on or going to work on between now and the next time we meet and

what’s in the way, what’s blocking me, what’s concerning me?’ And forth ‘What

do you need to be worried about? What potential risks can our team inject that

you need to be aware of?’

In terms of how much time it takes, what I typically see –

similar to a standup, the process should not take long. The point of Scrum of

Scrums is not to have a giant, fancy PowerPoint presentation and really sleek

graphics or anything like that. It’s a very, very informal meeting and, in this

case, I would say 15 minutes. Similar to a normal, Daily Scrum. It’s, to me,

what a well-oiled Scrum of Scrums should be like. Very quick, very informal,

very direct, to the point. In terms of how to help do that, one of the ways is

again going back to the audience. If you have everybody from all the teams, it

can be very difficult to have those sessions in a quick timeframe. That’s why

having representation tends to work out better in my opinion.

Also, the people participating – in this case, the representation

is from the teams themselves. It’s not really trying to loop end on the project

managers and resource managers and the directors and the VPs and everybody and

their brother. Because the more, honestly, those people get involved in the

situation, the longer the meetings are going to be and the more off-topic they

will be. And that goes back to ‘What’s the benefit to even doing all the Scrum

of Scrums stuff?’ Why should you care?

Well, one is, it helps reduce risk, but more importantly, it

helps the teams help each other. Like I’ve mentioned before, teams can offer

advice to each other. It’ll keep them synchronized as well and it’s really to

benefit the teams themselves. It’s not meant to make project managers happy or

to make VPs happy. And so, in that case, by keeping the audience to the

actionable members of the team, you’re able to operate more informally, more

efficient and sort of get in there, and talk together and be adjourned and move

on with your day. No need to inject a lot of long-winded discussions or

politics involved. Some of the other key aspects of the Scrum of Scrums is that

when you do have the sessions, I think it’s important for someone to maybe take

a few notes sometimes. I’m not saying big, detailed meeting minutes, but it can

be helpful if someone is at least taking some notes regarding that. Typically,

what I see, is that the ScrumsMasters, if they’re participating, they’ll

sometimes take down a little bit of notes – again, nothing formal, on the

conversation that was had. And the reason that I mention that is because when

the representatives leave that Scrum of Scrums, I personally found that it’s

very beneficial for them to relate important notes back to their teams.

So for example, let’s say during the Scrum of Scrums meeting

and let’s say there are 3 teams participating in the product release. They may,

for example, one team A may say ‘Hey, by the way, I just want to let you know

we’re about to make some API changes and the other two participating teams will

need to make some adjustments for that.’ Great point to let people know about

it – that’s very awesome. And so when the other ScrumMasters go back to their

teams, maybe for example in their next daily standup, daily Scrum, that ScrumMaster is going to mention ‘Hey, by the way, I just finished participating in

our Scrum of Scrums and I want to let you know that team A mentioned in the

Scrum of Scrums that they’re about to make some API changes and it may break

us, and we may need to make a few changes to adapt to that’.

In this case, the ScrumMaster or the representative, or

whoever it is – they have at least some rough idea, notes or ideas of what was

discussed in the Scrum of Scrums. They can relay pertinent information back to

their own teams, so that not only is the representation sort of in the loop

with what’s going on, the whole teams are in the loop. In that case, the teams

themselves, all the team members are aware of the relevant information for

them. And that way, it’s not just a few people that know what’s going on there

and everybody else is in the dark.

If you have representation in a meeting, as part of that

representation’s responsibility is to ensure that the other team members that

did not attend are aware of important information. And so, I think that’s sort

of the general gist of the ‘how’, if you will, the mechanics of the Scrum of

Scrums. Again, there’s no particular right or wrong answer to doing that. Every

organization is different, you have to find out what works for you – that’s

kind of the beauty of Agile, to adapt.

Now, in terms of what my experience has been – I think that

one piece of advice I’d issue to you as caution. Do make sure that the Scrum of

Scrums does not become a status meeting. Your goal is not to just read off some

random set of status updates. One of your goals, again, is to help each other.

And to keep each other informed. And so, when you engage in just a pure status

roll call meeting, then the helping each other and the transparencies can break

down. And so, I would definitely warn or encourage you that when you conduct

your Scrum of Scrums, try to keep it focused on ‘Hey, the teams themselves are

the audience. This meeting is for us, this meeting is to help us help each

other, so that we can deliver the products together or within the same

product.’

So if you keep that mentality or focus, then I think it

helps the tone and the attitude of the meeting. Cause if it turns into just a

giant project management status meeting, then I think the morale tends to go

south and helping each other tends to go down as well. Because people are

trying to ensure that they are publicly postured well, that their team is not

looked upon in a negative light. So they may even play down information, they

may even withhold information. They may not want to admit that ‘hey, we just

dropped the ball!’ But if it’s very informal and kept to the participating

teams and focused on helping each other, the teams will have that confidence

and have more candor and transparency, where they can say: Hey, look – this is

really in our way right now and this is causing us major problems. And by being

able to communicate in an open manner, that helps the teams that are

participating feel connected and willing to reach out to each other and help

one another.

The purpose of the Scrum of Scrums is to help the teams

themselves. I know I kind of beat a dead horse on this one a little bit, but

it’s a complicated topic. Many books don’t go into it very much, many websites

don’t go into it very much either. And there’s not a whole lot of guidance into

the Scrum of Scrums and I just wanted to take a moment and sort of discuss what

is it, who’s the audience, what are the mechanics, and what are the benefits –

we talked about that, in terms of the improved synchronization, communication,

helping each other, letting people know about risk, etc. And so, with that

said, if you are involved with multiple Scrum teams or product or suite of

products, I would certainly encourage you to take a look at the Scrum of Scrums

practice if you’re already using it. And if you are using it, I may want to

encourage you to take a look at how it’s currently functioning and what the

drivers are, if you will, behind your current meetings. And maybe just take a

look at it, kind of like a retrospective. Take a look at how well your Scrum of

Scrums meetings are taking place and, you now, as you go, you can always make

improvements to it.

Alright, I hope you enjoyed this episode! As always, I’m

honored to get a chance to speak to you and stay tuned for our next episode

where we’ll be having a special guest interview – I’m really excited! Alright,

well thank you very much and if you have any questions or would like to offer

suggestions for future topics, please email me. You can reach me at [email protected] and I’ll

be happy to include your questions in the next episode. Thank you very much!

Thank you for listening to

All Things Agile. We look forward to you subscribing to the podcast on iTunes

and leaving a kind review. Thanks and God bless!

I am thrilled to bring you a true business leader to the show. This episode features an interview with HealthPort CTO, Nupura Kolwalkar. Learn how she championed the transition to Agile in her organization. We will discuss challenges, tips, and most importantly, results.

I hope you are enjoying the great targeted content on this podcast. Please take a moment to subscribe in iTunes using this link: iTunes. Also, please send me your thoughts and questions using [email protected].

All Things Agile - Episode 008 - Nupura Kolwalkar Interview

Welcome to the All Things Agile Podcast - your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast on iTunes and please check out our sponsor:

TeamXcelerator.com. And now, here’s your host – Ronnie Andrews Jr.

Ronnie: Hello

everyone and thank you for joining me for another exciting episode of All

Things Agile. Today I’m joined by a special guest: Nupura Kolwalkar. She’s a

long-time friend and former colleague of mine. Nupura is a business leader who

is utilizing Agile to accelerate her organization. So first off, thank you Nupura for joining us today – it is definitely an honor.

Nupura: Thank you

for having me on the show.

Ronnie: Can you

please take a moment to tell our audience more about your background, maybe

both personally and professionally?

Nupura: Sure! So

I have been in the healthcare IT space for about 9 years now. I have been exposed to all

aspects or most aspects to approach IT from a revenue cycle, clinical, HR and

analytics perspective. So a good, broad understanding of this day’s American

healthcare industry. It’s been an interesting journey – as much as everybody

focuses on the actual industry and the domain expertise, through 9 years, more

of my learning has been on the talent management and process simplification

side, although the domain expertise is always a great plus.

What I enjoy most about my role, where I’m at now, is that I get to see folks learn something from simple processes and

direct conversation that helps them to be better professionals at their

workplace and find joy in working with their teammates.

Currently, I am working at HealthPort Technologies as the Chief Technology Officer. I have worked in the past with companies like

McKesson, Pfizer, NextGen – so I have a wide variety or background, but I’ve

definitely found my groove where I am.

That’s professionally. Personally, I have two young kids, a

husband, a house, a typical family with a dog as well. So, standard young

family, mom role at home. So my goal always is, if I take on a new challenge,

how do I rely on the talent that I hire and work with to achieve my personal

work-life balance; which is usually measured by how many times in a week do I

have to take my laptop back home. And currently I take my laptop home only in

the weekends, which I think speaks to my theories and my co-workers and the

folks that work in our organization.

So that’s probably more on the personal side. I love to travel, love to interact and learn these things; I love change, so

change is probably the most constant thing in my life.

Ronnie: That’s a great introduction – thank you so much! First off, I really wanted to

thank you for coming on the show because you’re really our first guest that’s

coming on as a business leader. We’ve had some other guests before that were

sort of with the Agile gurus and more like instructors and so forth; but I’m

really excited to have an actual person who is putting this in place in the

field as a business leader and implementing Agile in their organization and

being able to testify to the impact. So with that, I’d probably like to dive

into our first question which is: As a business leader, how has the use of

Agile impacted your teams?

Nupura: When I think about the question, there are so many

little impacts that make a big impact; but at the end of the day, to really

pinpoint a couple, I would say my biggest satisfaction from bringing Agile to

our organization is it’s allowed the organization to scale fast and work

correctly really early on.

We do two weeks test, so in a couple of weeks we usually

know if something’s going to work through the organization, because we’re able

to demo to the business. And if it doesn’t, then we’re able to course

correct early on in the process. My next key point is showing business value. This is

probable where I feel that Agile has come true in the most significant way and

close to the idea Agile principles. But showing business value: when I walked

in we had internal tenth day quarters because we had a good evaluation aspect

to work with, as well as products and we had to wait 6-7-9 months to see what

came out, but as we moved to Scrum and we installed the demo process, the stakeholders

got absolutely addicted to it. They wait for every Tuesday to get the demo for

their operation goal and objective.

The business value, it helps us, it helps them, it helps the

organization and save a lot of money. As a business leader, between the two of

them, what is ultimately impacted is the cost and efficiency that we’re able to

achieve and through our organization because of fail fast, course correct early

principle in Agile. So those are the two biggest ones. There are quite a few

little ones like the morale of the team. Once we

settled down with Scrum – it was definitely difficult to get there – but once

we settled down the morale, the motivation, the commitment and ownership

are definitely very high on the radar. Sounds like little things, but

ultimately the team puts the show together so they are highly motivated, and

you get better results. So those are probably my key 3 points that I would point

out.

Ronnie: Sure. I

love that answer and I really like the phrase you used that the stakeholders

were addicted to the demos – that’s awesome. And I would definitely agree with

your experience that when you are able to provide those demos and be able to

course correct early, it keeps you from making costly mistakes later. You don’t

want to be 6 months later at the end of the release and realize that what

you’ve developed wasn’t what the stakeholders really wanted.

Nupura: Right,

absolutely. And one the things that I would like to point out is that it takes

time for the teams and the stakeholders to get to where we are. In the process,

many times the stakeholders won’t show up for a demo. And they’ll show up for

the next and skip one and they would start complaining ‘Well, that’s not what I

really asked for’ – but the demo is our way to hold our stakeholders and

customers accountable for what they asked us to do. So our response would be:

If you don’t show up to validate what you need, then you get what you signed up

for because we’re not going to go back and invest in correcting the mistakes.

So it’s a bi-directional accountability as well.

The demo holds the team accountable to the stakeholders, but what I have found

very interesting is that’s my only forum to hold the stakeholders accountable to

the team.

Ronnie: Excellent

point, excellent point. I totally agree. That’s a really key factor there;

being able to hold each other accountable. Well, I think that

probably really dove-tails well into our second question, which is: What are

some steps that you are currently using or in the past have used to help adopt

Agile practices?

Nupura: Good

question, Ronnie. And I think we did really good at McKesson. I changed the

direction of how I wanted to go about doing this at our business. The theme of this implementation has always been: let’s have a grass-roots level movement, not a top-down level movement, but have a  grass-roots level movement with top support to it.

People ask me what I have learned; I’ve done this in a couple of top

organizations – if I had too many external folks involved who did not

understand the impact of a good or a bad process, or the lack of a process, it

added a lot of noise to the organization. Why go through this change?

And one of the things I have definitely seen as we implement

Scrum is that we do see attrition. I have seen close to 25-30% attrition in all the

last three cases that I’ve implemented this process. So a couple of things we

did. My functional management team and I sat down and planned for what happens

if we have attrition? What is it that we need in our organization to ensure

that we can take on the attrition? Which is mainly knowledge redundancy – do we have knowledge redundancy in the organization? If there are people who are going to leave because of change, will the

organization, the stakeholders and ultimately the customers suffer?

So that was one question. The second was: what will it do to

our morale organizationally, and what would it be as a reflection of the

management team? That was relatively new to HealthPort.

So those were the three answers that we wanted to answer so that we can

deliver to the business; we wouldn’t have a revenue impact to the business, but

we’d be able to take this organization through the change at our own pace

instead of someone else’s pace.

Once we set goals for those, the rest of the time was getting the knowledge documented because when I walked in there was

nothing documented. And when I say documented, it’s not pages and pages of

requirements. It’s really about change. For example, this particular area is a little bit

difficult to understand. Let’s put it into our knowledge pack that we give to

our new hires. So the first thing we do in getting ready for Agile was a new

hire packet because we knew we were going

to go through attrition and we wanted a good, stable base to hand over to our

new hires as they came in. So we implemented a new hire packet. We planned for attrition by getting the

knowledge into visual workflows and these workflows were located on the walls, they were in the team environment. They weren't living in a tool; they were out there in everyone’s

face so people could just walk over and look at them. So that was the trick to

even think about Scrum.

But once we started to actually think about Scrum, one of

the ideas that I’ve used back in my McKesson days was to put together

a team of the teams to build it in a way that the teams hold themselves

accountable to this change and they wanted to go through this chance. So we

called our team Matrix, because it truly was a matrix of different roles.

Now, one of the things we did do differently here than what I have seen done –

there’s a big focus on no functional management or leadership should be in any

of these meetings. Now, we haven’t released functional managers but there is no stress between the contributors and the

management teams. We work well, so they asked us to help out so that we could

use some of our time and save them some project time in order to take this

through change.

So our Matrix team consisted of some functional

leaders, but not all of them, and contributors from each

function area and a couple of stakeholders outside of my direct organization to help

them see how they’re going through this change, and how is it going to impact

them. And the team pretty much put their agenda together; they worked through our town-hall meetings, and monthly staff meetings to get buy-in from

directors in the organization, next steps,

morale boosters, coaching – which is the biggest thing in my opinion. We

trained a team so that a team can start to train at the peer level to other

teams. We had, of course, formal coaching which can never be replaced in my

opinion.

It was a 6 month effort

to transition the whole organization to Scrum. We did it based on the revenue

impacts that we could forecast. Cause, you know, when you plan for attrition,

you have to make sure that key knowledge is not lost; and if it’s going to get

lost, what’s the impact that it would make. So all in all, it was a gradual

movement reported completely by the management teams and implemented by the individual contributors through the individual contributors. I believe it took us to

stabilize, maybe about 6 to 9 months, just to stabilize. We saw a very high

level of attrition, but we were able to plan to bring new people in and have

them absorbed into the organization without an impact. It did, in fact, impact morale, and I want business leaders to recognize

that when they sign up for these things, we have to do morale boosters for the

organizations because it’s hard to see your colleagues leave because they don’t

agree with the culture that’s coming into play.

So that was my biggest struggle – to keep the motivation and

morale level high through this change. And we also discovered that there were a

couple of things in Scrum that don't even apply to those teams because of the

turnaround times that we required on those teams. So all in all, in 6 months

the team did it – all I had to really do as a business leader was to have their

back and be supportive. We did all of this internally with none of the

businesses stakeholders really knowing what we were doing because they were

still getting their projects delivered and introduced the concepts very slowly

to them,  the demo being the first thing

that we introduced. So there was the transition period, we allowed people to transition

at their pace, not our pace. And I believe we came out really good out of the

transition and I do believe having the individual contributors drive it really helped that process significantly.

Ronnie: I would agree, and I like your insight. Again, as a business leader regarding,

for example attrition because that’s really something that most of us wouldn’t

have even considered, right? And it is true that in any organization, doesn’t

matter what it is, you’re going to have some individuals that are going to

embrace change and you’re going to have some individuals that are just very

resistant and they just don’t want to change and when you’re trying to

implement any type of process change, there’s also going to be a degree of

friction and it’s important to be cognizant of that. So I’m glad you…

Nupura: And plan

for it. As a business leader responsible for $400 million – in my case, if I

haven’t planned for it behind the scenes that would’ve been a huge impact that

the organization couldn’t absorb because of their size. Another thing I would

like to point out on that is that it’s not just that people don’t want to

change. What I saw was – sometimes the pace is too fast for some people. We

have lost some really extremely talented people who had great business knowledge

because they couldn’t deal with the pace of this sprint. So trying to find that

balance and letting the teams come there was definitely another big challenge

that we had to face.

Ronnie: That’s a

good point. Well, Nupura, why don’t we transition into our next question; it’s

a little bit more of a tougher one, it’s definitely more of a challenge and

definitely someone looking for an answer from a business leader, which is: how

are you currently, or perhaps in the future, look into tie in the HR component

to the use of Agile? For example, what do you recommend to other business

leaders to provide performance reviews, rewards, to encourage successful Agile

adoption and use?

Nupura: I have

been asked this question a couple of times before. From my personal

perspective, given our context and culture, it’s a little bit different to

perform mixed measurement and management. And myself have gone through a lot of

performance metrics, being a leader, I’m

doing it a little outside the box. So what we do, and I can only speak about

what I do and it is working pretty well in our organizations: two things.

There’s a team level performance which is directly tied to the outcome of the

Agile aspects of the process. I don’t really say it has to be tied to a date,

although dates are important, don’t get me wrong – but I don’t really tie

directly to their run-rate – it’s about what

outcome did you achieve at the end of two weeks, at the end of four sprints is how we measure it. And we have data that

we use to measure it internally. We do surveys with our stakeholders, we do after-demo surveys for the big

projects. But it’s very outcome-based, not necessarily estimates vs. actuals based. Which is a little bit of a different way to look

at Agile. And I’m sure not all business leaders would agree with me, but it

worked well for the team, it helps with the morale and motivation.

Now, with personal performance management, we focus on in

the individual and team, and on the individual side, where I say that Scrum helps

the most, is in more than the management itself. It was the individual found it easy to break down some of the

barriers that they need to find like communication. Like let me cover my basis

constantly via email. Those things, I think, Scrum really challenges you to

open up, break the barriers and get into an uncomfortable zone of direct

communication.

So through this, while we were transitioning a few things we

did was measure our folks. Not necessarily whether they’re performing well or

not, but measuring our folks to see if they’re able to get over that barrier

and help them with a lot of personal coaching, outside coaching, to get over

the barrier of direct communication and conflict management. So those are the

two things where I have found value in implementing Scrum and the fact that implemented Scrum has brought out our

talented folks to be direct, respectful and ready to deal with conflict. I

haven’t really thought of tying any direct Agile results to individual

performance and I don’t know if I will get there, because from all different

perspectives – I do feel like artificial data like dates and boundaries

ultimately don’t measure a talented person. It’s the creativity and it’s the

outcome that they provided to the organization, along with their commitment,

that measures the individual. It’s maybe a little bit of a different answer,

maybe not expected.

Ronnie: Sure –

it’s great! I definitely appreciate you opening up and explaining what you have

seen and I hope that that benefits other members of our audience, so thank you

so much. With that, I’d like to transition into our final question which is:

What advice would you like to give to other organizations that are considering

adopting Agile?

Nupura: Agile and Scrum works for any organization. Several

times when I’ve been on forums, where I’ve engaged some of my peer

conversation, the first thing people say that even though you had all the right

stars aligned to put Scrum in – that’s why you were successful. Scrum’s not for

me, Agile’s not for me – anything that bases off from my organization. I

really, truly, passionately believe that Agile is for anybody and it is up for

the business leader to find ways to bring such a wonderful bi-directional

accountable process to the organization for the better of your talent. At the

end of the day, your talent is going to be at a better place once you have this

process.

And I hate to call Agile a process as well, because it’s

a principle, it’s a mindset, it’s a culture. It’s not so much just a demo or the retrospective; it’s how people think when they start to practice

Agile. That’s what I love about what this methodology brought to our

organization. So given that, I would say be open-minded and be ready for a

change. If the business leader is not ready for change, then there’s no way you

can transition into something that’s so intrusive to the organization, creates

a lot of noise in the interim, but knowing where you want to get to,

you should be prepared mentally, organizationally, knowledge-wise to cross that

barrier as a leader.

Now, one of the lessons learned from my past is, in the

first round, we all read books, we all were trying to implement Agile in a

very waterfall organization. We all read books and we said we are going to

follow Agile to the end nth principles.

So we started with the expectation to have an ideal implementation. What I’ve

learned through taking two or three organizations through this is the core

would be to get to an ideal implementation, not to start at ideal

implementation. And it allows for people to absorb change, leave, come back and

embrace the growth of this methodology, instead of the brute force of the

methodology. So we, having been in product management and strategy for a long time, I always tell the product

managements: the thing about minimal value products instead of the perfect

product – I have applied that principle to the implementation of Agile. Minimal

viable that shows the value of the change itself. If you’re able to provide the

value to the business and to our own organizations, then take the next step. So

don’t use the Agile principles to implement Agile. That would probably be my

biggest take-away.

Ronnie: That’s a

great point. Love that answer! Well, thank you so much Nupura for that great

advice and insight and thank you once again for joining us here on All Things

Agile. It’s been a real pleasure.

Nupura: Thank you

for having me on the show again and I’m glad to be here with you, Ronnie. Great

job on what you’ve started here!

Ronnie: Well,

thank you very much to our special guest Nupura Kolwalkar and thank you

everyone for listening to another great podcast. Look forward to seeing you

again! Thank you!

Thank you for listening to

All Things Agile. We look forward to you subscribing to the podcast on iTunes

and leaving a kind review. Thanks and God Bless!

In this episode, I tackle some common challenges faced by young start-ups trying to implement Agile. If you are a solo entrepreneur or have a few cofounders trying to launch a successful tech startup, then I certainly suggest you checkout today's episode.

As mentioned in the episode, I would really appreciate it if you could leave a review on iTunes. Of course, I hope that you will leave a 5-star review. I will try to mention reviewers in upcoming episodes. Here is a link to subscribe and post a review: itms://itunes.apple.com/us/podcast/all-things-agile/id640441739 

All Things Agile - Episode 007 - Tips for Startups

Welcome to the All Things Agile Podcast! Your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast on iTunes, and please check out our sponsor:

TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Hello everyone and welcome to the All Things Agile

Podcast! We have another great show lined up for you today. In this episode,

we’ll be covering tips for startup companies. But before we begin, a friendly

reminder to please submit an iTunes review. The reviews are very helpful and a

way to acknowledge the great free content presented on this show. I also look

forward to giving you a shout out in an upcoming episode. So let’s dive into

today’s topic.

How to implement an Agile solution in a young company? A

quick reminder that this podcast is for informational purposes only and accepts

no legal liability. So, in the case of this episode, I will be defining a young

company as 1-3 co-founders. A company certainly less than 10 members in total.

Agile is often considered the cool thing to do. So many people try to start

using it! A common mistake is to start Agile methodologies before having the

critical mass to do so.

Let me take a moment to better explain. Methodologies such

as Scrum are often designed for larger organizations and not 2 co-founders. For

example, a typical Scrum practice is to have 7, plus or minus 2 team members.

Having many team members provides resiliency. If a team member isn’t feeling

well, goes on vacation or is otherwise unavailable, the team can still

function. There are other team members available to absorb bumps in the road.

Also, don’t forget the roles of Product Owner and Scrum

Master. A fresh startup doesn’t likely have the resources to staff a team this

large. Chances are a startup has 2-3 people, working long hours and performing

virtually every role, including taking out the trash. Literally. So what other

Agile approaches, such as Kanban? What about those?

Well, I definitely believe that Kanban is a bit more sexy

at the moment and it certainly has its advantages. It’s a great tool for teams

that are more queue based in the work, such as product support teams. It’s a

lightweight approach with minimal formalities and that said, based on my

personal experience though, I still believe that Kanban needs at least a

minimal level of critical mass to be successful. I would recommend a team size

of at least 5 to successfully implement Kanban. It can be a daunting

challenge to build a Kanban team with only 2 or 3 founders who are wearing

numerous hats. I’m not saying it’s impossible, but that it simply may not be

wise.

So what can I recommend for a young startup? I would advise

not worrying about trying to follow a structured methodology. If you are in the

early stages of 1-5 company members, it’s great if you can adopt a full

methodology, but you may find yourself focused more on following ceremonies,

rather than the urgent needs of building a company. The key is to not worry

about having an efficient team when you’re just starting. Instead, I challenge

you to become an effective team. Simply put, if you are efficient, but not

effective, it won’t matter because you’ll be out of business. Doing the wrong

thing well, is still doing the wrong thing at the end of the day.

You can still apply Agile principles though. For example,

the Backlog concept is a great way to ensure that you’re always working on the

most important thing first. A young company certainly has limited resources. It

is imperative that it focuses on the most impactful items first. This does not

mean firefighting. Many small and even large organizations join in

firefighting. They spend their day carrying a fire hose, putting out one fire

after another. Does that sound familiar to, you know, perhaps your own company?

A significant danger in this approach is that the leaders

rarely examine what is truly important to their business and customers.

Successful companies must take the time to lay out their priorities and

determine really what is impactful and focus on one thing at a time. The goal

is to not do everything perfect. Striving for pure perfection is a fallacy and

will just slow you down. A second suggestion is that you can leverage someone

else’s expertise. If your company only has a handful of people, it can be hard

to take advantage of traditional methodologies such as Scrum.

An ultimate approach is delegation. If your company needs a payment processing system. Rather than trying to spin up a large

development team to implement it, why not leverage an existing payment service?

In other words, learn to delegate and let other best of breed vendors do what

they do best. If you are not able to directly afford to do so, you may want to

consider joint venture agreements. You may be able to structure win-win deals

that can expand your company without requiring large up-front capital.

Most entrepreneurs make the mistake of trying to do

everything themselves and they also try to have total control. As a result,

they fail to delegate. And, they do so to their own demise. Learn to play to

your strengths and delegate the rest. A third suggestion is flexibility. Many

Agile newcomers try to follow everything by the book. The truth is you must

know when to follow, when to bend and when to break the rules. Every

organization is different. You must look at your company and determine what

practices are truly practical for you. It’s not that the best practices are not

valuable – they are! They are best practices for a reason.

However, not every practice will align well with your

company or with your current size and maturity, especially as a young startup.

Learn to adapt practices during your Agile journey. If you adopt some of these

suggestions, your company can hopefully gain some momentum and start to implement

the more full software methodologies later. When your organization has

developed the critical mass of size, maturity and revenue – you’ll find these

approaches to provide structure and sanity. Again, there’s definitely a benefit

to some of the more structured Agile implementations. But I’ll say once again

in summary though: depending on your unique situation, please consider

different Agile implementations to better suit your needs. Focus on being

effective before worrying about becoming efficient. In other words, learn to

meet your customer’s needs and then learn how to do that efficiently through

process and tools.

Play to your strengths and delegate to others so that your

company can grow faster and avoid large, unnecessary development costs. Learn

to be flexible and when to follow, bend and break the rules. Lastly, remember

that Agile adoption is a journey, not an event. It doesn’t happen overnight and

it really never ends. It’s a continuous refinement process to take your company

to the next level.

With that said, I love startups! And I hope that you found

this information very useful. If you’d like to find out more, please consider

our email newsletter, by following the link on our AgileInstructor.com website.

You can even send me an email using [email protected].

I certainly look forward to hearing from each of you soon! And thank you very

much for your support!

Thank you for listening to

All Things Agile. We look forward to you subscribing to the podcast on iTunes

and leaving a kind review. Thanks and God bless!

I am pleased to share an interview with Agile pioneer, Jeff Sutherland.  Jeff is a founding father of Scrum and Agile.  He is a noted author and speaker.  Jeff provides insight to many of the largest organizations in the world.  In this episode, Jeff addresses some of the tough issues facing today's organizations.  Please take a moment to listen using the link below or subscribe to the podcast using this link.

Please visit Jeff's website: scruminc.com to learn more and check out available courses. During the episode, Jeff mentioned several great books which are linked below for your convenience.  Please take a moment to pick up a few copies for your Agile teams.

Scrum: The Art of Doing Twice the Work in Half the Time

All Things Agile - Episode 006 - Jeff Sutherland Interview

Welcome to the All Things Agile Podcast – your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast on iTunes and please check out our sponsor:

TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Hello

everyone and welcome to the All Things Agile Podcast. I’m very excited to

announce that today’s guest is Jeff Sutherland. He’s a true legend in the world

of Agile, especially Scrum. He’s a founding father of Scrum and also an

original participant in the Agile Manifesto. I’m very excited to have him on

today’s show and I’m hoping that he can shed some insight into how implement

Agile teams in larger organizations. So let’s go ahead and get started. First

off, thank you Jeff for joining us today! Regarding my first question, I’d like

to know what is your input or advice on how to implement Agile successfully in

today’s global workforce where we often have teams that are spread across the

globe: India, China, etc. How can we implement Agile successfully even if our

teams are globally distributed?

Jeff: Well, first

of all, Scrum simplifies their already complex Waterfall implementations. So

Scrum is easier to implement globally than traditional approaches. I’ve worked

with many skilled firms over many years – the first one was actually IDX, now

GE Healthcare, which was a competitor to McKesson and in fact, the head of

marketing – Pam, at IDX who worked with me, implementing Agile there, went on

to become the CEO of McKesson; she might still be there, I don’t know, I

haven’t checked recently. But she was probably there when you were doing your

Agile transformation.

But IDX, at the time, had 8 business units. Each business

unit had a minimum of 3 products. Many of them were acquired technologies,

acquired companies, mainly in the United States, but some teams that I’ve

worked with were in Europe; but scattered all over the place. So we scaled

Scrum in a big way. One of the best teams was actually in 3 locations across

the continent. So I’ve written about at least a half a dozen papers on good

distributed implementations of Scrum, and Scrum is the only way of doing

software that allows you to actually scale up without losing productivity per

developer. As soon as you start to scale Waterfall, the productivity per

developer goes down. It starts to drop radically once you get more than 6

people, which is why we keep Scrum teams small. But by keeping Scrum teams

small and then using the scalability mechanism that we do, we actually have

several case studies now which are the only ones every published showing that

you can scale globally and when you scale, you can get linear scalability by

adding teams.

Of course, you have to do Scrum well. Now, one of the

problems with any kind of distribution – Microsoft did a study on this a few

years ago in a process group – and they found that in every case, in 10 years

of doing Microsoft distributed development, in every case, it delayed the project,

it increased the project risk and it increased the dysfunction on the teams.

And so, any time you distribute, those are the 3 things that you have to deal

with. And as I’ve said, Scrum can effectively deal with all of them, but only

if you run a very good Scrum locally. Then you can distribute it. If you

distribute a bad Scrum, then you magnify the dysfunction when you distribute.

But that’s also true with Waterfall. So, in the worst case, Scrum is better

than Waterfall.

Ronnie: Okay –

and maybe just a follow-up question to that: In your opinion, when an

organization is looking to adopt Scrum and globally distribute, have you found

that it’s easier to sort of treat the teams all as equals, if you will? Each

one’s equally able to grab work from a bigger picture from the product backlog,

or do you think that it’s easier to delegate certain either component areas or

certain pieces of functionality to particular teams; or do you think that

creates too much of a siloed pigeonhole?

Jeff: You always

want to maximize the feature teams. You always want to have cross-functional

teams and have every capability on the team that’s needed to get to a ‘done’

state. One of the most interesting models today in scaling is Spotify because

they elegantly did what I try to do at GE Healthcare. And what they’ve done is

they have almost all features-driven teams. They do have some component teams,

but almost all features-driven teams and all features-driven teams have a

visible piece of the Spotify user interface. And every team can upgrade their

piece of the product, every sprint, without disrupting any other piece of the

product. And so, by making things visible for every team, and really managing

the architecture and the dependencies properly, it gives them a very powerful

way to implement a really cool product. And they really have to be fast and

they really have to be Agile because their competitors are Amazon, Google and

Apple. And any one of them will crush them if they don’t run fast enough.

Google, Apple and Amazon are like a big tsunami, all coming at them at once and

they have to run fast enough so that the wave doesn’t crash on them. Basically,

they use Agile globally to do it. So I’d recommend that your people really

study the way Spotify has done this.

Ronnie: Excellent.

If we look at that, it does make a lot of sense. I guess the next question I

have is in relation to more of the program or release level type planning and

the question is really regarding: when you have teams kind of more in the

trenches that are in the process of adopting Agile, however you may still have

parts that work large organizations at the program level or they’re trying to

work through what’s going to be in a particular release and they’re still in

Waterfall mode. Do you have any advice for organizations that – the trenches

may be adopting Agile, but maybe at the top level, they’re still kind of left

in Waterfall?

Jeff: Well,

basically that’s the way Scrum always started. We started in the middle of a

big Waterfall implementation. So it’s not only common, it’s the usually problem

when companies are starting off. And what we find, if we look at the success

rate of traditional projects vs. Agile projects, even though there’s a lot of

bad Agile out there, we publish data this Danish group gave up in our book on

software in 30 days last year and the data showed clearly that about 10 years’

worth of Agile vs. traditional projects and over 50,000 projects showed that

the success rate for traditional projects was 14%. 86% were either late, over budget,

with unhappy customers or complete failures, nothing ever delivered. Whereas on

the Agile side, and this is global data, worldwide averages, the success rate

for the Agile projects was 42%. About 3 times the success rate of traditional

projects. And many, of course, of these Agile projects are embedded within

Waterfall. So what that means is that when you’re doing Scrum inside a company

that’s doing Waterfall, you’re going to be 3 times as effective at delivering

your piece at the right time and 86% of the time, the Waterfall part of the

company is going to be late.

So that means that every Scrum team working inside that

environment needs to get a very clear commitment from Waterfall on dates and

they have project managers that are supposed to do that. In fact, that’s the

big role of the project manager that’s left since Scrum doesn’t need them. So

the Waterfall project managers have to commit to a date; the Scrum teams with

their product owner will commit to the date and most of the times, the Scrum teams

will hit it and then traditional implementations will fail. So the Scrum teams

always have to have a Plan B so they need to clearly articulate to the

management that when the Waterfall teams have missed their date and that

they’re going on to Plan B and they should be called when the Waterfall team

fixes their problems.

One of the things that we sometimes see is that when the

Waterfall teams are late, which they mostly are, then they say ‘Well, the Scrum

teams – you guys are faster so we’ll just put you on the Waterfall teams’ which

is a really bad idea, because it just slows the Scrum guys down to Waterfall

speed. A better idea is for the Scrum guys to say ‘Look, we’re faster than you

are – give us functionality, we will Scrum it – we may need some of your people

to do that, but we can produce it much faster’. If you do that, Scrum will

gradually grow in the organization and start to drain the swamp of failed

Waterfall projects.

Ronnie: Okay,

excellent. I guess, my next question would be again in relation to large

organizations, is on the subject of documentation. Obviously one of the

challenges that a large organization gets is bureaucracy. That there are

typically already in place a lot of gatekeeping documentation and they often

times have so many different departments and one department hands off another’s

keys to another – and in your experience, when implementing Agile or in

particular Scrum at a large organization, what advice do you have on the

subject of documentation? Ensuring that you have enough, but at the same time,

that you’re still able to move quickly?

Jeff: Okay, when

Scrum launches just enough documentation and every time I ask anyone: do you

have just enough documentation? They say: No! And I say: Well, take a look at

what you got and get just enough. When I’ve actually looked with them, we find

that about 68% of their documentation is totally useless and they’re actually

missing a little bit – about 10%. That’s what we seen at some big companies.

And companies that are doing medical devices that have to be FDA compliant, FDA

certified we find that – one of my partners recently went into a German medical

device company, they had 12,000 pages of documentation for an implant medical

device. So he actually took that documentation to the FDA and said: Is this

just enough? And the FDA said: Are you kidding? We won’t even read 12,000

pages. What are those people thinking?

So he worked with the FDA and after 6 months, he got it down

to 800 pages. So this is what we typically see on these high documentation

traceability projects. Companies are generating 95% of what they’re generating

is totally useless. The FDA doesn’t want it. And when you get it down to just

enough documentation, only 5% is needed. So what Scrum will do in any company

is ask the question: Do you have just enough documentation? If the answer is

no, then they’ll look at what is just enough and when they determine that,

they’ll make that really clear to the management and the rest of the company.

If the management insists on producing 95% junk as in the

case of the FDA compliant people, then nobody can help them. They’re just going

to waste a lot of money. But what Scrum will make it clear is what is that’s

just enough, what do we really need and we’ll get that on the table.

Ronnie: Okay,

perfect. I guess the final question I’d like to ask you about is in sort of the

executive buy-in and dealing with some of the political aspects. When you often

have large organizations, you may have some well-entrenched executives that

maybe they don’t quite get Agile or they may be stuck in their ways, so can you

give some suggestions if you had some people that are working on their Scrum

teams and running into some roadblock with their upper executives? Do you have

maybe some book recommendations on anything you’ve worked on or a colleague

worked on that may be beneficial to recommend to an executive?

Jeff: In many

companies – my company, Scrum Inc. does a lot of management workshops. Mostly

with the senior management. With the middle management, you want get them all

in the certified Scrum Master training so they really understand how it works

and what they need to do from a management point of view. Without that training

and education, it’s pretty hopeless because management – if management doesn’t

know what Agile is, then they tend to do things that actually disrupt it and

cause it to either go slow or fail outright. Just out of being clueless. So

education and training is really critical.

At the end of the day, there may be people that are more

interested in maintaining their empire than they are in furthering the

organization. And senior management has to deal with that. I remember one

global telecom company went completely, 100% Scrum all at once and the Scrum

trainer that was leading the effort was communicating with me, he said: Yeah,

is this going to work? And I said I’ve already written a paper on this, it’s

called ‘Hitting the Wall’. What happens when you take a global organizations,

take them to Scrum all at once.

What happens is they run into their biggest impediment

really fast, and depending on what the management does at that time, that will

tell you whether it’s going to be successful. And the Scrum coach and trainer

said they’ve already hit the wall. I said: What was it? He says there were 30

managers that were getting in the way and the CEO just fired all of them. So at

the end of the day, there may be some housecleaning needed.

Ronnie: Yeah –

but that’s one of the greatest advantages to Scrum, it’s that it really exposes

what was already there. Well, I think that’s an excellent suggestion. If it

comes to organizations that I’ve personally worked at, have provided

certification, training to some of their middle and directorial-level positions

and I do think that was really helpful. And it is very interesting that you

mention that you do have workshops for some senior management and that’s really

great to point.

If someone wanted to find out more about yourself and about

your company and the services that you provide, where do you recommend that

people take a look?

Jeff: Well, they

can certainly go to our website: ScrumINC.com. They can send me an email:

[email protected] and I’ll get back to them.

Ronnie:

Excellent. And do you have any particular books or works that you’ve written or

your colleagues written that you’d definitely recommend?

Jeff: Yeah, there

are two books that were written last year. One of them is actually really good

for managers – it’s written as a novel. It’s the story of a company that was in

big trouble; how they brought in Scrum and how they turned a disaster into a

success. And it’s not a long work, you can read it in a few hours and you

really get the basic ideas. The other more IT-focused book that I did last year

with  Ken Schwaber ‘Scrum in 30 Days’ and

both of these books are on Amazon. An even more interesting book is up on

Amazon but will not be released for a few months; it’s called ‘Scrum: The Art

of Doing Twice the Work in Half the Time’. And it is a book for the general

business reader and Randomhouse founded this in their business book ‘Division’

and they wanted it at least 80% of the examples outside of IT. And so this is a

really good book for the general business guy to get a handle on what is Agile,

what is Scrum all about? What are its benefits, what are the key principles?

How can it help my company? So, ‘Scrum: The Art of Doing Twice the Work in Half

the Time’ – you can go to Amazon and preorder it.

Ronnie: Okay,

excellent. I’ll definitely provide links to those. That concludes all my

questions. Jeff, I’d like to thank you for your time, I really appreciate it!

Jeff: Okay, thank

you! I enjoyed talking with you!

Thank you for listening to All Things Agile. We look forward

to you subscribing to the podcast on iTunes and leaving a kind review. Thanks

and God bless!

I am thrilled to present a wonderful interview with Mary and Tom Poppendieck.  They are true legends in the Agile and Lean Software Development movement.  Checkout today's episode where we discuss challenges facing many organizations such as: product vs. project mindset, globally distributed teams, and equipping teams for success. We also discuss their latest book, The Lean Mindset.  Please consider picking up the book to learn more about these topics in greater detail.

Please check out their website: poppendieck.com to learn more about Mary & Tom and their insightful work.  Many thanks to Mary and Tom for investing their time for this podcast and for their contribution to our industry.

All Things Agile - Episode 005 - Mary and Tom Poppendieck Interview

Welcome to the All Things Agile Podcast. Your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast on iTunes, and please check out our sponsor:

TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Hello

everyone and welcome to the All Things Agile Podcast, Episode 5. I’m

very excited to present to you a wonderful interview with lead software legends

Mary and Tom Poppendieck. Before I begin, a quick reminder that this podcast is

for informational purposes only and accepts no legal liability. So let’s get

started!

One of the goals for this podcast is to interview and

feature influential leaders in the Agile space. Today’s guests are just that –

Mary and Tom pioneered the Lean Software development movement, with their

groundbreaking book Lean Software Development and Agile Toolkit. It’s a classic

among Agile literature. In 2013 they also released ‘The Lean Mindset – Ask the

Right Questions’. Mary and Tom travel the globe, speaking at conferences and

consulting with many of the world’s top companies. It’s an honor and a pleasure

to have them on the All Things Agile Podcast. Without further ado, let’s

welcome Mary and Tom!

Well, thank you for joining me today Mary and Tom, I really

appreciate it. Why don’t we go ahead and get started with a few questions.

During my own career, I have worked at several Fortune 500 companies. And I’ve

often found that large organizations tend to be project-focused, rather than

product focused. For example, I have seen environments where software

development is treated as a black box, and it can sometimes have a

throw-it-over-the-fence mentality. I would love to hear your thoughts on

integrating software development as part as a holistic product chain.

Mary: If you look

back to the early 90’s, I was a manager in the early 90’s and there were very

few of my colleagues that could even type. Typing wasn’t something that you

learned, unless you were going to be a secretary. The idea of doing email and

stuff was so difficult that when the internet first came, many managers sat

down their secretaries to do their email typing. Eventually that went away. But

if you look at industries that were formed before technology was widespread,

like banks and insurance companies and those kinds of industries, you’ll find

that this technology area was separated out from the mainstream for two

reasons: one reason is because the managers of the line businesses simply were

not comfortable with technology; and another was that computer technology was

considered something that was expensive and should be centralized in order to

reduce costs.

Well, today, computer technology is not the same. It is the

fundamental basis for competition for almost every company that uses it. Thanks

to the kinds of products that they offer, or the things that help them be

competitive – if you take a look at the new companies like Google and Facebook

and Amazon and those companies, computer technology is a fundamental

competitive advantage. And if that’s true, then it needs to be manage, at least

what’s done, in the line organization, rather than in some side-organization

that is in side to the line organization. So if you look at the companies I’ve

just mentioned, they don’t have a central IT department. They have the line

organizations responsible. That doesn’t mean that they don’t think about IT

costs, but they think about them as product development costs.

So now, the things that people develop that are helping the

company become more competitive and distinguish it from other companies, are

things that need to happen with people who sit in the line organization and

truly understand customers and are close to them and secondly, software

technology today is much more thought of not as a black box, but as a constant

feedback mechanism. So you do something, you see the results on customers and

on the line business, you adapt to the results and you continue on.

With those two things said, first of all it provides the

competitive or strategic advantage to be thinking in line organization about

technology. And secondly, technology is by and large best developed as a short

feedback loop kind of a business; it makes very little sense to continue on

with this black box concept that used to be a sensible idea. Tom, you have

something to say?

Tom: Yes,

definitely. I’d like to address this from a little more abstract level and put

projects in their proper place. The motivating aspects as identified by Simon

Sinek is ‘always a purpose’, a reason for doing things, a difference that an

organization is attempting to make in the world. It’s the reason why people

come to work, why they think about a problem, why they devote a lot of energy

to solving a problem. Now, ‘Why?’ is primary – nothing great happens without a

great ‘Why?’ ‘How?’ is where the project sits; it’s one of the techniques for

containing risk, for containing how much resources you’re going to devote to

achieving your ‘Why?’. Agile is another collection of techniques that are

‘How?’s – ways of working strategies, tools.

Engineering disciplines are another set of ‘How?’s.

Automated testing and many others. But they’re all ways of working, ways of

thinking to achieve a purpose. And neither of those are your product. Your

product is ‘What?’ that’s Simon’s third level. Why, How and What? Now, whether

you are successful is not so much a matter of did you sail this in the

constraints, that your project imposes? It is ‘did you do the very best that

you could in terms of achieving your purpose within the constraints of your

available tools and skills, and risk management strategies?’

I read a fascinating article in Harvard’s Business Review

yesterday. And it was saying that the most important, the most powerful way of

managing risk is to measure and analyze time to recover the something going

wrong in any individual component of what you’re doing. This translates easily

at least in my initial impression, into how fast is your feedback loop?

If you try and do a ‘What?’ that doesn’t really contribute

to achieving the purpose and find out about it until very much after it has

been done, and after many things have been built on top of it, you have wasted

all of the good skills, all of the good techniques and you have triggered away

your ‘Why?’ But if you find out about it very quickly, and you haven’t placed

practices and approaches that you can recover very quickly, then you have the

very best that you can; you’ve delivered the best ‘What?’ that you can using

your constraints to achieve your purpose. And I think that’s the framework for

thinking about projects – it’s just a tool; they’re not the ‘What?’, they are

not the ‘Why?’ – they’re just a way of containing risk.

Ronnie: Right,

that makes sense. I agree. Sometimes, people place more emphasis, if you will,

on the success of the project rather than the success of the product. And for

the customers, I agree. Excellent answers. The next question I was wanting to

ask, kind in a similar note, I also worked on projects where everything was

kind of guided by arbitrary dates if you will. And sometimes, the end customer

and the product features were really not in focus. Have you seen this behavior

before and if so, what advice do you have for our listeners on how to tackle

this issue?

Mary: Well, it’s

interesting where the arbitrary dates come from, because I think that a

business organization wants them to help them move forward with customers. They

have some frame in mind about how much it’s worth to them to do that, how much

money they can spend and what kind of deadlines are important, and those

deadlines and those budget constraints should be honored as far as what are our

constraints for meeting our overall objective? But then those get translated

into somebody’s version of minor objectives and minor deadlines and if we don’t

do this by this time, we can’t get to there by that time. Then those become

completely arbitrary and basically unattached to the overall purpose. And those

kinds of deadlines that are fake, are pretty easy to detect and what is the

reason for them? That’s what you got to ask. Why do we have these strange

deadlines? Why don’t we have, instead, a very tight feedback loop and a

visibility of the progress we’re making towards the overall objective of what

we’re trying to do and understand what part of the progress needs to happen at

different times.

Now, if the way that you do a project is you first do all of

the design and then you do all of the next step and it isn’t until the end that

you actually do the work, write the code, write the test, integrate the

software, then those days are truly artificial. But if you strategy is to say

‘I am going to have a complete system in two months – it’s going to be a

minimal system, but it will be workable and we can get feedback on it – and

that two months is going to give us another 8 months to finish the whole thing

and the feedback necessary to do that’ – that’s a much more viable deadline. So

you have to say are the high level constraints appropriately applied as

low-level constraints to get stuff done or are they artificial? Because if

they’re artificial, smart people can figure that out and they will ignore them.

Tom?

Tom: Not all

deadlines are arbitrary. Some are legal, some are annual rhythms of shows.

There are some very legitimate deadlines. And a competent team with a competent

manager that understands what it takes to do work will be able to achieve a

real deadline. However, if a deadline is used as motivation, as a goad, as a

way of avoiding waste, then it can be very ineffective and very destructive. It

can lead to bad behavior. The use of a deadline that is not legitimate, that is

not related to the ‘Why?’, to the work being done, is probably a symptom of

lack of competence to measure what really matters about the progress of the

work.

Mary: I want to

throw in one last little thing here, and that is that projects should have

things called: cost, schedule and scope. And the thing that really should be

flexible is neither, in most business’ cases cost, nor schedule. The thing that

should be flexible is scope, because cost and schedule deadlines are typically

driven by business constraints. But the scope should be the thing that is

negotiable almost always and the reason for that is that, especially in a

software environment, the thing that we’re putting together is a complex

system. The more junk, features, capabilities or whatever that we throw into

that massive software, the more complex it is, the more difficult it is and by

and large, over time, the more stuff you have in software, the more crud you get

in there, the more complexity you get in there, the harder it is to change, to

manage and so on.

So in software, you want to think of ‘stuff’ as bad. You

don’t want to measure a team on how much junk can I put in, in a window of

time? You want to say: How much business purpose can I achieve within as little

code as possible? So you are looking for reduced feature set, reduced

capabilities that get the job done. And so the thing you really want to reduce

is not the budget or the schedule; it’s the amount of stuff that you try to

squeeze into a business-driven budget and schedule. So typically in all

projects – and this is not the way most project managers look at it – but a

software project almost always bend on scope, rather than bend on deadline or

on cost.

Tom: It is

impact. Did you achieve the impact that your work aimed to achieve? Did it

achieve its purpose? If the impact can’t be measured, you have no guidance

about what to include and what to leave out. You have no measure about when

you’re done. If you have as much impact as your tools and skills and techniques

permit, as the team was capable of and the project was a success…

Ronnie: I

definitely like that impact thing – that kind of really sums it up really well,

thank you. If you don’t mind, I’ll ask the next questions which is: in my

experience, I’ve seen senior exectutives get very excited about Agile and they

decide to roll it out across the organization. However, sometimes the teams can

be lacking in technical skills or tools to ensure success. For example, great

Agile teams place a high value on quality and that usually will translate in

frequent and rigorous testing. And if a team has, for example, automated tests

in place that will result in the product being in good shape. However, there may

be teams which have never worked, for example, with test automation and it can

then be a real challenge. What are your thoughts regarding skills and technical

preparation in relation to methodology adoption?

Mary: Methodology

is the result – it’s not the driving factor in a good Agile implementation.

What you’re trying to do is create an environment with rapid feedback, so that

you can do a better job of satisfying customers. And you should not be

measuring ‘did I do this or that Agile practice’? You should be measuring ‘do I

have greater impact in delivering what my customers really want?’ And that’s

where you get to the quality, the test automation and that sort of thing.

So let’s talk about a different objective for that

executive, so that the executive have stuff that they can measure and put hands

around. And that is, instead of working about a methodology called Agile, why

not worry about what I’m going to call ‘The Software Development Process of the

Future’ which is continuous delivery. So instead of saying that we have these

meetings and we have these things, you should be saying ‘How fast, from the

time I decide to do something, until the time I get it in production – how long

does that take?’ And when you start looking at how far along am I on the path

to continuous delivery - that is my executive goal. Those companies that do

that have far more effective Agile implementations because it’s that one thing

that you’re focusing on that continues delivery, that drives all the good

technical behavior by the way of good practice behavior.

Let me give you an example in Alcoa – once upon a time when

he became CEO, decided that he wanted to focus on one single thing and it was

going to be safety. And every single issue around any kind of safety incident

was what the entire company focused on. And that became a lever to cause all

kinds of additional good behavior and the company really took off, because you

can’t have safety without quality, alert workers, really good, well-run

equipment, all of that sorts of things. And similarly in Lean, the concept of

flow is sort of that driving principle. So you try and just focus on flow,

everything falls in place. All the technical things, all the quality things and

so on. Similarly in software. Let’s not focus on process; let’s focus on

continuous delivery. How far are we towards being able to deploy immediately?

And if we make that the one principle of how we perceive, then what we have is

a driving principle that will drive all the rest of the good behavior and

certainly, all of the technical behavior.

Ronnie: Excellent

answer. A final question, if you will. There are many great sources of

information on implementing Agile, but most are geared towards smaller

organizations often. And for larger companies, it can be a hurdle if you will

to implement new methodologies in a global workforce. For example, I’ve

recently worked with teams that are split across India, Brazil, China, Mexico

and of course here in the US. What insight can you provide on how to tackle

teams that are globally distributed?

Mary: There

certainly are many big companies – we wrote in our new book about Ericson as an

example – very large companies that are very effective in implementing Lean and

Agile concepts. But they don’t hold a lot of stake in having ‘teams’ that are

geographically distributed. Yes, organizations are geographically distributed –

but why do teams need to be? So what I see large, effective organizations do

when they think about distribution is to say what are the things that need to

be communicated? And how can we effectively, at a single site, have

communication among colleagues and think about communication across teams on a

different scale? So the effective ones don’t try too hard to make individuals

have to communicate across large distances. And if they do, they have people

travel.

However, there can definitely be reasons why people should –

and really valid purpose-drive, business-driven reasons why people need to

communicate across geographic boundaries. And there certainly are plenty of

examples on how this is done effectively. If you look at the open source

movement, none of the open source projects have people co-located. These ones

work very well with the communications issues across countries and if you look

at them for models on how to do it. So if teams do need to be distributed, then

you want to think ‘Why?’ Okay? You do not want to have class A people figure

out what to do and class B people are in another continent that actually implement

it, because that gets us back to the first question. The people that are doing

the implementation are divorced from the purpose.

But if the teams are geographically distributed, you have to

think hard about how can they all share a common purpose that they understand

and believe in and commit to, and if they do that the communication issues will

be solved. And if you can’t imagine teams across countries dedicated to a

common purpose, then you should say: Why are our teams structured this way? So

every company that has solved this problem, has solved it in a different way,

depending upon their market and their structure and all of that sorts of

things. But they do have a few things in common. One is, they think for

themselves. They don’t take rule books. They try to make sure they honor the

intelligence of every person on the team and make sure that they can

participate fully their thoughts in thinking about it, and they don’t have

these wall handover mechanisms because that’s not the right way to deal with

this.

Tom: All the

teams we have seen around the world, and we’ve seen many, have one shared

characteristic. And it’s not tools or techniques or methodologies – it’s they

think for themselves. There are many examples, case studies about groups that

have thought about their problem and their context and their challenges and

they think for themselves and come up with a unique combination of tools and

techniques and disciplines that make them highly effective in achieving their

purpose. A team which is distributed and is simply doing what it’s told to do

is not going to be very effective. A team which is distributed for a good

reason who all believe in a purpose that they are trying to achieve and have

adequate tools, handles and the like, that make it possible to communicate

effectively, will figure out how to do it. They will think for themselves, if

they have sufficient feedback about how they are doing, how things are working

for them; they will figure out how to do it. And there are many, many ways that

different teams figure out how to do this. But it’s not a recipe. It’s not a

product that you buy; it’s how people think about what they are doing together.

If they can’t think together, they can’t be very effective at working together.

They can’t learn together. The product will reflect that lack of learning.

Ronnie: I

definitely agree. I definitely agree with you that having those teams be able

to really understand it and what they’re trying to achieve and have those goals

and have that thought in control is very key – it’s as you mentioned, if you

kind of have a class A, class B type situation, then it can often result in

micromanaging and diminish morale and sometimes poor quality – I’ve seen in the

past the results in code. Great points, great points! And a lot of them are

actually referencing some of your more recent work – if you don’t mind, I’d

love to mention that briefly. You guys have put together a great book last year

‘The Lean Mindset’. Would you like to maybe highlight that a little bit more?

Mary: Sure! I was

just reading in an article that it used to be ‘share all their value’ was the

thing that businesses thought they were in business for. But today, in today’s

economy and today’s high-tech environment, what you really want to do in order

to have a successful business is you need to have great people that use their

minds for accomplishing the common purpose. And that purpose has to be

something that these people believe in and you need to have an intense focus on

delighting customers. And those three things: customers that you’re trying to

delight, employees that are deeply engaged at trying to make something happen

for those customers and an overriding purpose are the three sort of company

drivers of the future.

Our book has 5 chapters. One is on purpose and then the next

one is on engaged workers and energized workers; the third one is about

delighted customers. And then we talk about efficiency and what efficiency

means in this context. Efficiency means, in the Lean context, flow efficiency

rather than resource efficiency. Which is a whole other topic that we can talk

about sometime. And lastly, we talked about innovation because today’s economy,

today’s technology moves too fast to be comfortable that what worked 3 years

ago is going to work 3 years from now, so constant innovation is another thing

that companies need to have. That’s sort of, in a nutshell, what the book is

about, those 5 chapters. And to sum it all up we have lots of case studies in

there, as Tom said, and each case study shows how thinking for yourself in your

context is important; which means it’s important to have people who care to

think for themselves and who are allowed to think for themselves and who are

inspired to help make the company successful.

Ronnie:

Excellent! I definitely encourage our listeners to pick up a copy of your

latest book. Once again, it’s ‘The Lean Mindset’ and it’s available at book

stores everywhere. I picked up my copy on Amazon, and I really just want to

thank you both Mary and Tom for joining me today for this podcast episode.

It’s been tremendous help to myself and I’m sure, to all of our listeners. I

really thank you so much for your time Mary and Tom, you’ve been great!

Thank you listening to All Things Agile. We look forward to you

subscribing to the podcast on iTunes and leaving a kind review. Thanks and God

bless!

Today's episode is centered around some exciting news. I am launching a new venture, Team Xcelerator Inc., which will focus on Agile team software. The AgileInstructor.com blog and the All Things Agile podcast will be moved under the Team Xcelerator umbrella. I am very excited about the possibilities. Please checkout the podcast and send me your thoughts and product feature input using [email protected]m. Also, don't forget to please post a kind review in iTunes. We really appreciate your time and support  :)

All Things Agile - Episode 4 - A New Hope

Welcome to the All Things Agile Podcast. Your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast in iTunes and please check out our sponsor: TeamXcelerator.com.

And now, here’s your host: Ronnie Andrews Jr.

Hello everyone and welcome to the All Things Agile

Podcast, Episode 4. Today’s title is ‘A New Hope’. This is paying

homage to the classic Star Wars title, but before we begin, a quick reminder

that this podcast is for informational purposes only and accepts no legal

liability. So let’s get started.

As an Agile coach, I’m frequently searching for tools to

help myself and others utilize Agile methodology successfully. Candidly, I

haven’t found many tools which truly reflect the needs that I have seen over

the years. Rather than let this frustration remain, I decided to start a new

company: Team Xcelerator Inc. to tackle common challenges for Agile teams.

You have undoubtedly heard references to Team Xcelerator a

few times already. I want to take a few moments to talk about it in more

detail. Everything is still very early stages, but I’m hopeful that many Agile

practitioners will come to love it. A goal of mine is to develop a product

which reflects the global nature of today’s workforce. Almost all development

teams are now spread across the world and this trend is only continuing to

rise. The use of Agile itself is also on the rise. However, many organizations

are still struggling with learning and how to adapt Agile, including the fact

that teams or departments may implement Agile differently.

Many of the products that I’ve seen on the market are really

just project management tools. We still have a lot of work remaining, but it is

a goal of mine to develop Team Xcelerator into a cloud-based web tool which

will enable teams to specifically focus on Agile success. I also intend for

Team Xcelerator to be affordable. I want to encourage teams to utilize the tool

and achieve success. It will be targeting organizations of all different sizes,

including young startups to industry veterans.

I can’t release too many specifics at this time, but I did

want to take a moment and let my audience have advance notice of this new

platform. I’m also interested in your input to ensure that it better conforms

to your needs. 

As the episode title alludes to, it is a new hope for me and for

the world of Agile; an opportunity to create a platform for Agile

professionals, by Agile professionals. And I hope that you’re excited about this

recent product news as I am – and remember: you can check out my blog using the

website agileinstructor.com and feel free to contact me using [email protected] and feel

free to include product comments that you may have regarding Agile tools. I

would love to be able to take in your input and ensure that we have product

features that will truly meet the needs of our audience.

Also, don’t forget to visit our previously discussed

sponsor: TeamXcelerator.com which makes this podcast possible. And thank you

once again for joining me for this quick podcast – join me for Episode 5, we’re

having an exciting interview with Mary and Tom Poppendieck who are the

innovators of Lean Software. You don’t want to miss it! Remember – it’s time to

accelerate your team, today!

Thank you for listening to All Things Agile. We look forward

to you subscribing to the podcast on iTunes and leaving a kind review. Thanks

and God bless!

In this episode, I discuss the subject of overtime. I provide my recommendations based on solid experience and explain the reasoning behind it. During the episode, I also reference Rework by Jason Fried. Please take a moment to subscribe now in iTunes. Provide your own feedback or recommendations by writing to me using [email protected].

All Things Agile - Episode 003 - Use of Overtime

Welcome to the All Things Agile Podcast. Your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast in iTunes and please check out our sponsor:

teamxcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Hello everyone and welcome to the All Things Agile

Podcast – Episode 3. Today’s topic will be ‘The Use of Overtime’. But

before we begin, a quick reminder that this podcast is for informational

purposes only and accepts no legal liability. So let’s get started.

As part of the AgileInstructor blog and this podcast, I

like to cover topics that are often overlooked by traditional Agile books or

articles. So in this case, I want to focus on the application of overtime within

Agile teams. It’s a topic which can certainly illicit strong emotions. There

are some that advocate that overtime should never be used. In contrast, many

teams engage in overtime occasionally or perhaps even routinely as part of

their reality.

I would like to take a moment and share some insights from

my hands-on experience which I hope that you will find very helpful. I think

there are 3 general viewpoints: the first opinion is that there should never be

overtime. That we need to build sustainable teams. The use of overtime violates

that principle. The second group often believes that we have to do whatever we

have to do in order to deliver the project on time. If that means overtime,

then that’s what we have to do. Perhaps you’ve heard that language from one of

your project managers before. Lastly, there’s another opinion that lies

somewhere between the two spectrums – that the use of overtime is not sinful,

but should not become a regular habit.

Through my experience, if there’s a need for overtime, it’s

because there are underlying problems that haven’t been addressed. This is an

insight that 99% of businesses simply do not get. They don’t see overtime as a

warning signal to an existing problem. It’s used to overcome issues with estimation, over

commitment, technology, processes, etc. I understand that occasional use of

overtime might be justified for events which are not predictable, such as

national disasters. However, most uses of overtime are related to things which

could have been predicted. Overtime does not fix the core issue which caused

the team to get behind in the first place. It’s treating the symptom, not the

problem. The biggest source of issues related to overtime is expectations.

Simply put, the team is either over-committed or has

impediments which are not properly accounted for. Schedules are defined based

on everything working out perfectly. However, most projects have bumps along

the way. If teams and ‘leadership’ communicate the situation to stakeholders,

the difficulties can often be accounted for by either reducing scope or extend

the expected delivery timeframe, etc.

However, that rarely happens in most organizations. Why?

Well, because most members of leadership are not truly leaders. It’s brutal,

but it’s true. They are individuals focused on their career and their

reputation. They don’t want to lose face and admit that their group is behind

schedule. They think that it will tarnish their reputation among their peers.

That’s the real truth. Most deadlines given to teams are artificial. A project

manager somewhere looked at a calendar and picked a date for their release to be

delivered. Stop and think about it. Will someone be physically harmed if the

release is delivered on a Friday instead of a Monday? No! Will the company go

bankrupt? No!

Those PMs and other managers may treat the projects as life

or death, but it’s not. They’re just dates! Let’s not make the dates more

significant than they truly are. It is often the case that the subject of

overtime comes up due to artificial dates that the team didn’t even influence.

This environment often breeds routine overtime. So why is that so wrong?

Well, first – regular overtime exhausts team members,

leading to burnout. As a result, morale and ultimately, productivity drop

dramatically. This in turn, leads to attrition. I can promise you that your

best team members will be the first to leave. And, that will devastate the team.

A second reason why overtime is a bad idea is margin. If you have someone

already working 12 hour days, there’s little or no margin for them to absorb

future or further work. If you have someone working 8 hours who needs to

temporarily work late, they have the energy and stamina to do so. But, if the

team member is already exhausted, they have no additional energy and reserve to

handle that issue. There’s simply no margin to absorb further bumps in the

road. This adds additional risk to the team and to the project.

Third, the organization is just continuing to treat the

symptom and not the underlying problem, which is just foolish and downright stupid.

It takes guts. But true leaders must take a step back and ask ‘How did we get

in this situation?’ Then, actually solve those issues to prevent future

occurrences. Organizations such as Toyota are famous for this principle and

enjoy the financial success of their wisdom.

If you’re a business leader, I sincerely hope that you will

take this message to heart and implement it

in your organization. If you are a Coach or ScrumMaster, please try to convey

these points. Perhaps you can refer your leadership and team to this podcast

episode. If your ‘leaders’ can’t or won’t change, then you may be forced to

adapt. One way is to take action yourself. Do what you can to tackle the

underlying issues behind overtime. Retrospective improvement items are a great

place to start. If you’re unable to make the changes necessary, perhaps because

you’re not empowered or just don’t have the availability, at least you can

account for it in your initial estimates.

Now, I will say that I will hate adding excessive padding,

but it may be necessary if that’s your reality. I sincerely hope that you’re a

part of an innovative organization or starting one yourself, that you can make

sure to avoid routine overtime by addressing the ‘Why?’ A great book to

underscore this point is Rework by Jason Fried and David Hansson. I highly

recommend picking it up on Kindle or Audible. It’s a quick read, but very

enlightening. I trust that after reading it, you’ll also come to the conclusion

that conventional wisdom is inherently flawed, and there are better ways.

That summarizes a few quick points about the use of

overtime. I sincerely hope you found them useful. Remember, you can check out

my blog using the website agileinstructor.com. Feel free to contact me using

[email protected] and also don’t forget to visit our sponsor:

teamxcelerator.com, which makes this podcast possible. It’s a cloud-based

Agile team software package, designed for small and large companies alike.

Thank you once again for joining me for this podcast, please join me for

Episode 4 for an exciting product announcement. You don’t want to miss it!

Remember, it’s time to Accelerate your team, today!

Thank you for listening to All Things Agile. We look forward

to you subscribing to the podcast on iTunes and leaving a kind review. Thanks

and God bless!

In this episode, I discuss the ideal size for an Agile/Scrum team. It is a frequent question when organizations first begin adopting Agile. I will provide my recommendation based on solid experience and explain the reasoning behind it. I have also added a transcript of the episode below for your convenience. If you have suggestions for future topics, please send an email to [email protected]. Also, please take a moment to subscribe to this podcast in iTunes using the podcast icon provided on the right.

All Things Agile - Episode 002 - Ideal Team Size

Welcome to the All Things Agile Podcast. Your destination

for tips and interviews with the leaders in the world of Agile. Don’t forget to

subscribe to this podcast in iTunes and please check out our sponsor:

teamxcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Hello everyone and welcome to the All Things Agile

Podcast Episode 2 Remix. Today’s topic will be ‘Ideal Agile Team Sizes’. But

before we begin, quick reminder that this podcast is for informational purposes

only and accepts no legal liability. So let’s get started.

For the context of this episode, I’ll focus on Scrum, since

it’s a very popular form of Agile. We’ll cover other implementations, such as

Kanban in separate episodes. That being said, Ideal Team Size is a popular

subject and many newcomers ask about team sizes when they’re first learning

Agile. Corporate leaders also struggle with the topic when they try to roll out

Agile and form team in their organization.

People are curious how big is too big? Or how small is too

small? What are the implications? I’ve often been asked what team sizes do I

personally recommend? For Scrum, the longstanding recommendation is 7 team

members – plus or minus 2; so that’s 5-9 members. However, the product owner

and Scrum Master boost the total count to 9-11. Now, some coaches may or may

not include the product owner and Scrum Master when factoring in the team

sizes. But I certainly do. So what specific size do I recommend?

Well, based on a hands-on experience across numerous teams,

I believe that 10 is a great number to be at. That is 8 team members, plus the

Scrum Master and the product owner for a total team count of 10. That is a

number that’s in-between the recommendation and one that I have found to be a

sweet spot for Scrum teams at many different organizations. If your team,

however is too small, it can certainly cause problems.

The reason is that people are wearing too many hats. For

example, I do not recommend that Scrum Masters and product owners double up on

roles. So for example if you have a product owner or Scrum Master who’s also a

critical path contributor on a story, it can be a disaster. So an example would

be the Scrum Master working on a story and that story gets in deep trouble and

they need to dig deep into it, and then what do they do? So an example would be

the Scrum Master working on a story and that story gets in deep trouble and

they need to dig deep into it, and then what do they do? Maybe let go of some

of their other Scrum Master duties? And then the entire team suffers and other

stories suffer.

People need to be able to concentrate on their given role.

It’s been my personal experience that if you allow the product owner and Scrum

Master to focus on those roles which they should, they’ll be good at them and

the entire team benefits because those roles act as multipliers. Now, I

especially don’t recommend that the same person serve as both the Scrum master

and the product owner. It’s a conflict of interest and I have rarely seen it

work out well. Most of the time, it’s also a disaster. It is a constant

temptation by business leaders, foolishly trying to cut corners by

understaffing the teams. When the team is too small, people may not be able to

focus on their core gifts. They also get burned out quickly.

Please remember that one of the principles of Scrum is to

build a sustainable, well-functioning team. If you undercut your team, don’t be

surprised if you end up with attrition. And I can promise you this: the most

talented people will be the first to go, because they have options and they

will exercise them. Now, there’s also yet another great reason why you should

not shortchange your team size and that’s risk. If you have a small team, it

increases your risk profile. If a single team member departs, goes on vacation,

has a flat tire, whatever – the team can be in deep trouble. There’s no margin

for the team to absorb bumps in the road. If a team is too small, it’s also

more likely to have ‘siloed’ knowledge which is an additional risk for the same

reasons.

Now, I hope these points have made it abundantly clear that

an understaffed team is a bad idea for everyone involved, including the

customers receiving the product. Adversely, a team size that is too large can

also be a challenge. Simply put, the larger the team, the more coordination is

required to provide sanity. In my experience, the effectiveness of a larger

team is directly proportional to the savviness of its Scrum master. A talented

Scrum master may provide more effective, shall we say ‘glue’ to hold the larger

team together.

That said, an extremely large team is still a bad idea. And

not one that I endorse. For example, as the size expands, so does the team’s

Scrum ceremonies. The daily Scrum meetings or standups become a tiresome chore.

It simply takes more time to process so many team members and what they’re working

on, which applies to all the team ceremonies. So with very large teams, there’s

also a greater risk for destructive conflict. A lack of unity, or cohesiveness.

I have seen large teams form factions within the team. That situation breaks

down trust and ultimately, destroys productivity.

So why do I recommend a total team count of 10? On average,

for Scrum, candidly – it’s a middle ground. It mitigates most of the downsize

discussed earlier; there are enough members to reduce risk and prevent burnout.

However, there are not so many members that it becomes unwieldy. It’s also a

great size for conducting team ceremonies and co-location. It’s very doable to

locate the 10 members together, such as a row of cubes or a conference room

they can share. In my experience, proximity really does matter. Wise

organizations understand this point and make the effort to do so. By keeping

people close together, you’ll be amazed at how it improves team communication.

And I’ve heard stories in the past about ‘Oh, well we can’t afford to relocate

people where they’re sitting because it will cost too much’. That’s simply not

true. In fact, it will cost you more money not to, in terms of lost

productivity and software quality. It is absolutely worth it to try to

co-locate your teams as much as possible.

Now, I won’t say that the team size absolutely has to be 10

members. It’s simply a target to aim for. A rule of thumb, derived from my

personal experience, along with the opportunity of watching literally dozens

and dozens of other teams in their Agile journey. Selecting a team size at or

around 10 will enable the teams to succeed, rather than setting them up for

failure. Now, we can’t 100% guarantee success, but we certainly can position

the team to win.

That summarizes a few quick points regarding ideal team

size. I certainly hope you found them useful. Remember, you can check out my

blog using the website agileinstructor.com. Feel free to contact me using [email protected] and also

don’t forget to visit our sponsor: teamxcelerator.com, which makes this

podcast possible. It’s a cloud-based Agile team software package, designed for

small and large companies alike. Thank you once again for joining me for this

podcast, please join me for Episode 3 where we’ll discuss the use of overtime,

such as scrambling to meet those crazy deadlines. You don’t want to miss it!

Remember – it’s time to accelerate your team today!

Thank you for listening to All Things Agile. We look forward

to you subscribing to the podcast on iTunes and leaving a kind review. Thanks

and God bless!