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

Please checkout out this exciting interview with author of Essential Scrum, Ken Rubin. Ken is a distinguished author, speaker, and Agile instructor. He has worked with many of the nation's top companies, and he joins us in this episode to tackle some of the tough questions facing teams as they adopt Agile. If you haven't already read Ken's great book, please pick up a copy of Essential Scrum on Amazon today!  You can also read Ken's blog and learn more about his services through his website innolution.com. I hope you enjoy this episode and please remember to subscribe in iTunes. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: coach@agileinstructor.com. 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

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: coach@agileinstructor.com. 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 anothe

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: coach@agileinstructor.com. 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 t

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 coach@agileinstructor.com. 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

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 coach@agileinstructor.com. 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

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 t

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 coach@agileinstructor.com. 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 coach@agileinstructor.com 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 coach@agileinstructor.com. 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 coach@agileinstructor.com 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 coach@agileinstructor.com. 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 coach@agileinstructor.com 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!

In this episode, I will start the podcast discussion by providing tips to help you select a good Agile instructor or coach for your organization. It's a tough decision facing all organizations when the begin their journey with Agile. 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 coach@agileinstructor.com. Also, please take a moment to subscribe to this podcast in iTunes using the icon provided on the right. All Things Agile - Episode 001 - Selecting a Good Agile Coach 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 one. Today’s topic will be ‘How do you select a good Agile instructor or coach?’ 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 – large and even small companies may want to hire a coach or instructor to help them start their Agile journey. In my opinion, key aspects to look for are: experience, knowledge and communication skills. So let’s start with experience. You really need to take a good look at someone’s background. It’s more than just the number of years. I recommend instructors with experience at different companies and different types of teams. That provides a more varied and useful background which can provide additional insight and experience. Let me elaborate. Say you have someone who has been at one company for say, 5 years, and that’s the only company that they worked at regarding Agile. In that case, that person realistically probably just knows how that company does things, okay? Therefore, their experience is a lot more limited. And now compare that with a coach or instructor who’s been at literally dozens of companies. They’ve seen all kinds of things work and not work – and also across different industries; that provides them with additional insight that they can leverage at your organization. Please keep that in mind. Moving on. Experience in larger companies requires scaling. A company with billions in revenue and thousands of employees is a totally different ball game than a start-up. An instructor with only experience in teaching Agile in a young company may have difficulty with a corporate giant. Quite frankly, the larger the company is, the more any mistakes or errors or ineffectiveness in their processes or their practices – it only becomes magnified as the company rose and is larger and larger. So if you had a smaller company, let’s say 10 people, and the practices you’re putting in place don’t work out as well, it’s probably more recoverable. You know, maybe they lose a couple hundred dollars or thousands of dollars – maybe. But at a larger company, if there’s things that go awry, it can cost the company billions. And instead of a few people perhaps – if things really went south – they may lose a few people a few jobs; at a larger corporation, if things really go awry, thousands of people could potentially lose their jobs. That’s a huge responsibility! And so, when you’re working at a larger company, it has more integration points and many, many more people and larger scale teams – you really have to be at the top of your game. And also, in terms of working with those larger companies, in order to get things done, you really have to automate. You have to automate as much as you can – things like minute gathering and metrics, etc. It forces you to really take a good look at what you’re spending your time in, time on, and be able to automate that as much as possible. However, those same principles that apply at trying to streamline larger organizations also apply to smaller companies as well. Being able to leverage some of those automation principles, even at a smaller company, can certainly produce huge benefits. But let’s move on. If you have a coach or instructor who is perhaps familiar with younger companies, they can provide additional insight regarding how to achieve Agile with fewer resources. Because if you’re in a company who doesn’t have a bigger budget, they may not be able to spend as much funds on training and other types of programs. So when you’re looking to bringing in a coach or instructor, see if you can find someone who again has experience at different companies, different types of teams and also including experience at different sizes of companies – that’s how you’re making sure they have experience with a company that’s of your nature. Next up, I’d like to talk about knowledge. The instructor or coach should definitely be certified. And I’d definitely prefer a strong alliance or similar organization. The effectiveness of an instructor is often based on who taught them. So the source of the coach’s knowledge is critical. The quality of an instructor can make or break a training course, or significantly impact the success of an Agile adoption. I definitely recommend knowledge across implementations such as ‘Scrum’ as well as ‘Kanban’. If you have someone who only knows one way of doing things, that may or may not translate well to your organization or your team, based on your company’s industry. So being able to have someone with background in multiple different Agile implementations, allows them to configure and approach as a better fit for you. Again, that’s also where knowledge and experience combine to help provide a better fit for you. Let’s also talk about, again the quality of the training that the instructor, the coach themselves received. I definitely like to know that, because we can only impart what we possess. And how the person was trained or taught is going to be a direct reflection on how they will teach. And so, by finding out the quality of the person’s original trainer, that will help you better gauge on how this coaching instructor will work with you or your organization, or your team. Let’s move on to communication. Communication is of course also very critical and your coach or instructor needs to be a good teacher or a good mentor. The coach should have an open personality and be warm and invite all questions. Soft skills make the instructor more effective. If you have someone who is very unapproachable, then the team members may be intimidated or just not comfortable asking questions. And that can then lead to bitterness and passive-aggressive behavior. I’ve certainly seen it in organizations before, so I definitely recommend someone with that open and warm personality, because then people will feel comfortable asking questions and what that provides you with is buy-in. It’s when people are able to ask their questions, they feel good about it, they have buy-in regarding the adoptions of Agile or maybe you’re already using Agile but you’re bringing in a coach or instructor to help you get to that next level: again, if they’re able to participate, it increases their motivation and the likelihood of success for the adoption or for the further improvement in Agile. So those are some quick tips regarding selecting a coach or instructor. I certainly help you found them useful. Remember, you can check out my blog using the website: agileinstructor.com. Feel free to contact me using coach@agileinstructor.com. Also, don’t forget to visit our sponsor: teamaccelerator.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 2 where we’ll discuss ‘Ideal Scrum Team Sizes’ – it’s a popular topic. People always ask what’s too small, what’s too large – so we’ll definitely address that and 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 in iTunes and leaving a kind review. Thanks and God bless!