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

Transcript:

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

Transcript:

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

Transcript:

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

Transcript:

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

Transcript:

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

Transcript:

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

Transcript:

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

Transcript:

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

Transcript:

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

Transcript:

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!

I am still getting everything setup, but I took another small step. I created a Facebook page for the blog. You can find it and Like it using:  https://www.facebook.com/AgileInstructor

I hope to see you there  :)