Roy van de Water, Clayton Lengel-Zigich, Derek Neighbors, and Gerry Kirk discuss: Kanban in your personal life Kanban in work life as a one-man team Personal kanban can help save your marriage Personal insights from Kanban Personal Scrum? Personal Kanban boards Burnout The post Episode #58 – Personal Kanban with Gerry Kirk appeared first on Integrum.

Roy vandeWater: Hello and welcome to another episode of the “ScrumCast”. I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Kane Mar: And I’m Kane Mar. Performance Review Roy: Today we will be talking about Performance Reviews. Kane, in the past I’ve talked to quite a few managers, who want to figure out who the star performers on their team are. What advice would you give somebody asking that type of question? Measuring Teams Instead of Individuals Kane: That’s a difficult question to start up with. To be honest, working in an agile environment, it’s very difficult. In large profit projects, it’s a different system. My advice, quite honestly, would be to measure team rather than the individual. So, look for star teams rather than star individuals. Derek: What if somebody comes back and says, “Well, wasn’t that a little bit of a communist view? How am I going to motivate the troops, if there’s no incentive for them to perform better than someone else?” Kane: It is up to every [inaudible 01:14] for the individual as well. In our spa, the incentive is intrinsic rather than extrinsic. In other words, it’s self motivating incentive, the ability to create a great product, to have that great product out there on the market place, seeing use of that great product. In large part that’s the big benefit or one of the huge benefits of doing Agile software development rather than a large paycheck at the end of the day. Derek: I’ve seen a couple of teams where they start to question, is it really even worth doing individual performance reviews? If it really is more intrinsic motivation and it really is, you’re trying to measure the performance of the entire team or the entire organization, do you think there might be a time when we’re not even doing individual performance reviews? Kane: I would love to see that. Quite honestly, I think that would be beautiful thing. Unfortunately, I have also realized that this is in large part the real world and many organizations will struggle with that. Many organizations already do struggle with that. Do I think that we will realistically get there? Honestly, I think that would be very doubtful. However, having said that the closer we get, I would push for it myself, but I wouldn’t necessarily expect that to be the case. How Are Promotions Determined Derek: So taking it from a different perspective, instead of having the performance reviews in place as an incentive, what if I have a new position that has opened up, like I have a position for a Scrum Master or I have a position for a product owner or maybe even a C‑level position, how do I decide who to promote and bring up to that position when everybody on the team should be treated as the whole team? Kane: I’m a big fan of actually giving it a shot, trying it and seeing. You may get some good results, you may get some disastrous results, but you’re never going to know unless you actually try that. Derek: You mean to have the entire team have that position or just pick somebody and see what happens? Kane: Speak to the team. Ask the team who they would like to be their CIO, CEO… Derek: Oh, I got you. Kane: …if that’s what you need, and so have the team make that decision, and have a discussion about that, but unless you actually try that, you’re never actually going to exactly know who the best person actually is going to be. I’ve come across instances in the past where someone who I thought might be an ideal CEO turned out to be someone who was not an ideal CEO, and vice versa, and I think that is a major consequence of just being a human being, sometimes what we perceive is not really the reality. Try asking the team, they’ll have a much better idea of who a good…or what they’re looking as part of the CEO, and so ask the team and have them have their feedback, and then go with that and see how that works. Why Is It Hard To Be Human Derek: I absolutely think you’re kind of speaking our love language where we’re very much about “be human.” But why do you think it’s so hard for management in organizations to actually do the human thing, why do you think they revert back to behaviors where they don’t ask the team who they think should be in charge or who should be in a particular position, what do you think inhibits them from doing the thing that would seem to be so natural to do? Kane: Gosh. [laughs] I’m not really sure how to fully answer that one, as you will, to give you an honest answer, I think a lot of it comes down to greed, I think a lot of is tied to “hey, at the end of the day,” and to a certain extent we’re all somewhat selfish. I know this myself. I’ve acted in a selfish way in the past, and I think that provided that we have systems in place that gear towards people’s greed and selfishness then I think it would be very difficult to walk away from that. Derek: It might also potentially be a situation of arrogance. Where if I am the CEO or whatever position, like I should know best, right? I don’t want to defer to my team because I should know better than them because I am in a higher position, so I am going to make the decision to [crosstalk] Derek: Not justifying it, but that may have some part of it. Ego Getting In The Way Kane: Yeah maybe, ego, absolutely. Ego is probably a very big factor in that sort of decision making as well, absolutely. How Does Compensation Determination Work Derek: In an environment in which you rate the team instead of individuals, how do you choose individual pay? How are people’s salaries going to work? Kane: Everyone should have a based on individual pay to be honest, because everyone is different. We all have different skills, and different skills are valued differently in the marketplace. I have no qualm about individual pay, and individual pay being different for every individual on the team. That is a real reflection of the real world. In that regard, I don’t have an issue with that at all. Any incentives on top of that however need to be done on a team basis. In other words, if the team is successful in meeting their accomplishments, whatever those accomplishments shall be, they should be rewarded as a team, rather than on an individual basis. There should be some element of individual compensation, but there should also be some element of team based compensation. Derek: How do you decide which individuals make what? Like if you’re going to have individual compensation, how would I choose to pay one developer or one employee more than another? Transparent Compensation Kane: My favorite way of doing this is to make it totally open. In other words, to have compensation transparent. I admit, that’s a totally radical, for most organizations, that is a totally radical suggestion. However, having said that, if you make it totally transparent, then the notice is on the individual to justify his or her salary. Say if you have a developer that is making twice as much as a tester, unless they can justify that, then maybe they shouldn’t be making twice as much. Derek: I’ve seen that. A couple of instances too, where, as we move into 21st century work, we have to challenge what we consider compensation. I have seen a lot of employees choose potentially more time off, or more flexible schedules, or various other forms of incentive or compensation that they prefer over pay. They actually would take a lower pay to have a more flexible schedule or be able to work on product or projects that are more meaningful to their direction in life, and we are just scratching the surface when we’re talking about preference problems and the sense of incentive, performance, and compensation are all going to be in a pretty serious flux in the next decade or two, as the market heats up for talented, creative, knowledgeable workers, and the supply is not there for the demand. I am curious as to see where it’s going to go I guess…are you seeing some weird things out there in the organizations you are working with? Kane: Absolutely. It’s not only things you have mentioned, and those absolutely will be impacted, but there are also things like people’s titles, career paths, I think all of those things will be impacted. Certainly, with the small to medium companies that I tend to enjoy working with, that does tend to be the direction that they go. In other words, they tend to go towards much flatter structure, with a much more open mechanism for compensation and pay. How Do You Move Towards Radical Transparency Derek: If, for a small company, I could see making this type of transition to such a radical new approach to individual compensation and performance reviews on a whole team basis instead of on a usual team basis . But how would you work on something like that if you are on a smaller agile team within a larger organization and that organization has a strong culture of individual performance, or has a demand of having a certain number of employees promoted out of the small team every so often, or something like that. What would you suggest to those types of teams? Kane: In any situation like that when you’re trying to introduce and agile approach within a large organization, you have to be prepared for the fact that there is going to be some culture change that is necessary to accommodate the agile team. I wouldn’t expect the cultural change to be something that happens overnight. In fact it takes anywhere from two plus years for that to happen effectively within a large organization. However, having said that, you do need to start having that conversation, because unless you start having those conversations with the HR organization, things will never change. Unless you actually sit down with the HR organization and say “look, these are some of the impacts. We would like a team‑based bonus rather than an individual bonus. We would like to have a flattened hierarchical structure, in other words, fewer titles, rather than a very structured team”. Unless you’re willing to have those conversations then nothing within the organization will change. My feeling is that for a team to be truly successful with an agile approach within a large organization, then the large organization has to acknowledge some of those differences and actually start addressing them. Giving Continuous Feedback Derek: Another part of performance reviews is giving people a feedback mechanism on how they can improve as an individual. When it comes to incentive, I don’t think it makes sense to have individual incentive on team based work. There’s probably definitely still room for improvement on an individual level within a team. How are you seeing teams give each other valuable feedback to improve as individuals when there’s not that mechanism of a regular performance review to hand that feedback back to them? Kane: Let’s be clear, traditional performance reviews are almost entirely political, and the feedback that they give is often given back for political reasons. I say this from personal experience. I spent maybe 22 years of my life within large organizations doing exactly those types of performance review. I would say that the feedback given during those performance reviews tends to be very, very negative rather than very positive. I would be cautious about that myself. A better approach is to have people to provide feedback on an ongoing basis. Quite honestly, within an agile team, the best feedback I can get from an agile team is if the team said to me “look, Kane, we want to work with you on an ongoing basis”. That’s fantastic. However the opposite is also true. If the team comes to me and says “Look, Kane, we don’t think you’re working out. We would like for you to leave the team”, for me that’s a clear indication that I need to change my behavior and improve my performance. Real feedback coming from people that I work with on a day‑to‑day basis is far more valuable and more hones too than feedback you might have from a performance review maybe once a year. Derek: Is there anything that you would like to promote or anything that you’re currently working on that you would like to promote? Kane: I do have a newsletter where I talk about these issues, and well as other agile issues. It’s called The Scrum Addendum. You can find it at my website: Scrumology.com. If your listeners would like to hear more about these types of issues feel free to sign up. Derek: Thanks for joining us! Kane: Thanks very much. Bye now.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich… Roy vandeWater: I’m Roy vandeWater. Scott Dunn: I’m Scott Dunn. Strengths Finder For Employee Engagement Clayton: Scott thanks for joining us today. I know that you are interested in the strength finder or the strengths…I don’t know what the generic term for it is, but maybe can you give, I guess, a little bit of a background of what that is and why you find that interesting? Scott: Sure. Back when I was a manager for a web development shared systems team, looking for ways to have my team members be engaged and focused. I was at an event called the leadership summit. There, I heard someone named Marcus Buckingham talk about the level of engagement of employees and how low it was. I was definitely listening. He gave a stat that less than two out of ten of us are engaged, meaning that we care what is happening at work and are doing our best. The company that he worked for at the time was Gallup. They did a survey of a million employees and a hundred thousand men trying to find what makes great management. They boiled it down to twelve questions called the “Q12”. The biggest lever if you were a manager to get the best out of your employees was do they have a good chance each day to do what they do best? IE Do they have the chance to play to their strengths? From there they came up with an assessment that you can walk‑through and get your top five strength which is called the strength spine which has been on the best seller list for four or five years now. Marcus has recently come out with an assessment of the zone, he has recently left Gallop. This is called “The Stand Out” which talks more about your strengths, roles and puts you in several categories of manager, leader and sales. There is a couple of ways you can approach it. From there you are talking to your team and working with them in a way that helps to discover what their strengths are and to find a way to leverage that as a coach, scrum master or manager. How Would You Implement Strengths Finder In An Organization Clayton: Let’s say I am a manager and I have this scrum team or agile team, how do I implement this? Do I make everybody take a questionnaire and then put people in boxes? How do these two roles meet? Scott: That is a great practical question! What I have done before is something that I have detailed on my blog. We can circle back to that later but I do try and make it so people can go to and follow the cheat sheet. But basically what I do is I give everyone a couple weeks’ head up and notice in saying, “I’m going to be putting books on your desk. Don’t worry about reading it right now. Just take the assessment in the back. You’ll find the code. You’ll go to a website and register and use that code to start your assessment.” That gives them details about how the test works and try to lower the level of anxiety. It’s not a pass/fail test. You can’t not have any strengths. You’re not going to have a strength like loser or something like that show up, and you’ll be… Clayton: Roy hasn’t taken the test yet. Roy: That’s right. I’m really strong in the ability of being fired. [laughter] Roy: Sorry. Go ahead. Scott: Is beer drinking a strength? Well… Roy: I think I’ve got that one covered, too. [laughter] How Accurate Is The Assessment Scott: Yeah, you’ll get lots of funny responses, but the amazing thing is the results I’ve had. I’ve done this with at least 200 people so far. On every team that I’ve been on when I was independent we’d always do this because one, it’s a big team‑building thing. It’s very affirming. These people come out like, “Wow.” They’ll routinely say, “That really nailed me.” I promise you, over 99 percent of the time they’re saying, “That was so accurate. They’ve been reading my mail. I can’t believe this.” It’s a very affirming process. Not just for them, but that next step after they’ve taken it I schedule a meeting for all the team to come in. We just walk through their strengths. I just list them up on a grid. I’m writing them up in front of everybody, and I’ll open up the book and read off, or I’ll read off their reports. Everyone’s getting to hear about each other’s strengths, what they’re naturally good at where they’ll find the best of each other. These teams aren’t great teams because everyone’s well‑rounded. They’re great teams precisely because each person’s not, and you find out. You get that insight. I had one manager come up and say when she followed that. That was the most her team had talked to each other in four years. You get these amazing sharing and insights into each other as a team, and that’s part of the team‑building process as well. From there you start talking about coaching, and we can get into that a little bit later. But even if you just did that, you’re talking 12 to 14 bucks for this book, a one‑hour meeting. They spend a half an hour of their own time taking the test, and it’s a huge ROI as far as just the connection that they’re going to make and your insights as their manager or Scrum master as well. It’s very powerful. What Do The Results Look Like Clayton: What do the results look like? I’m trying to think of, I think it’s the Myers‑Briggs Personality Test or something like that. I can’t remember. I think they have these little codes. Is it the same type of idea? Scott: No, and I like the Myers‑Briggs. I took it, and my response is what I think most people think the strengths assessments are going to be, which is, “Oh, that’s interesting. That says that I’m an extrovert.” Well, but what do I do with that? How do I use that at work? Be more extroverty? You don’t know what to do. The strengths by it, it’s going to give you top five strengths, which are really more like action verbs, or the stand‑out will give you your top two roles and list out all nine. But, there are some that are actionable, like a maximizer. It’ll give you action items to take with that. If the stand‑out will say, “Here’s what you’re best at. Here’s what you can do with that. Here’s a great next step.” If you’re a maximizer, look for areas where something’s happening with your team, or the company, or a process. It’s OK, but it can be made great. You’ll naturally be pulled towards making things great. Average bugs you. It opens your eyes to say “Wow, that’s true. We had a deployment processes, and it’s OK, but I know that we could shrink the time down. Or, a build process, we could shrink that.” These people, if they’re on your team, and they’re a maximizer, they’re going to love doing that. They’ll thrive doing that. They’ll learn the most, and grow the most and perform the most. The team can lean on it, and these people will never get tired of doing that stuff. That’s one of the insights. Each one of those will be like that. I had a team member once, and we were at a lull at work as a Web team. I said, “Just take it easy. Surf the Web. No big deal. Enjoy your paid time off here.” It turned out she got frustrated and left for another job, and the reason was one of her strengths was activator. The worst thing I could have done for an activator, or I should say an achiever‑‑ that’s someone who loves to check off everything they’ve done that day. They love coming in that day, and there are 10 things to do. They get to check, check, check. “Look, I’ve been productive. Look…” Scott: …that was driving her nuts. She would rather have me just cook up some work or given her a checklist of things to do and say, “Hey, could you just take a look at some of these areas in the code base, and review it for areas for opportunity”? Anything. I could have made it up. For me, that would have killed me. For her, it bugged her so much that she left for another opportunity where they would have kept her busier. Those are a couple of examples of doing that. Will It Highlight My Weaknesses Too Clayton: I understand that it’s a really good tool for figuring out what kind of jobs the members of the team can do that are personally motivating. Do you find it’s, also, a good tool to use to help team members discover their weaknesses? So that they can try to round out areas they might not necessarily be proficient, or necessarily enjoy as much? Try to find enjoyment in areas where they don’t excel, so that the team can go more for that “Everybody in our team is a well‑rounded individual”? Scott: Right. That’s a great question. That’s a common one, because most of our performance reviews are really spent like, “I see that you’ve done this, and this, and this and this. Thank you for your contribution. Now, let’s spend the rest of our hour talking about these areas where you [laughs] suck. Where you’re not so strong, where you failed, or come up short, or you just don’t perform well.” Those areas where you’re looking at the clock and say, “Is the clock broken? I hate doing this, anything but this. Let me check my email one more time.’” That type of work. For me, it was organization. “Here’s our recommendation. Use the DayRunner, or why don’t you try the PalmPilot?” I’ve tried those things. The truth is, areas where we’re weak, those things that we do that just drain us that we loathe, all the effort we might put in to try to get better at that will be a lot of pain and not much result. If you look back over those areas, and you might know what some of those are. I certainly know some of mine. I look, and I have put a lot of time and effort over the years, and I ain’t much better. I’m about the same, marginal improvement, despite putting a lot of time and effort, and money even, at times. What would be much better for me, especially as a team member, is to invest all that time and energy into my areas of strength, where there will be leaps in growth, much productivity and engagement. I’m better to be around. Look for someone else in those areas where the team might need someone who is detail oriented, who loves to check things off, who loves to tackle the tough nuts. Then, find out where we can shift the work. On these agile teams as a whole, we should be volunteering. We’re self‑organizing. We’re self‑managing. This is the perfect playground to say, “I love doing this.” The whole team wins when you do that. “I’m not so good at doing this, and someone else probably would like that and they would thrive.” Now, you’re not playing in areas where you just won’t ever grow that much, or do that well, and getting not such positive performance reviews, and someone else could. They’re not getting the opportunity to do more of what they would love to do. We actually say, “Play to your strengths. First of all, discover them. Find out what they are, and begin carving out time each week to invest in learning about that‑‑activities that you could do to practice.” That’s how we grow, right? We learn and we practice doing it. Manage around your weaknesses. On the ROI side, it’s just not worth putting time into your weaknesses. Just work around them. Dangers In Everyone Only Playing To Strengths Clayton: It sounds to me, if everybody is playing to their strengths and doing the things that they’re best at, you will naturally have a tendency to form information silos and skill silos. You’ll start to form a team that doesn’t pass the hit by a bus test. Is that something that you’ve seen happened? How do you prevent that from being an issue? Scott: I would separate the difference of technology skill. I’m definitely one who really believes in generalists. I don’t want specialists, and I really love breaking down silos. But there’s a difference between, say, technical knowledge, your abilities and aptitude, and what you actually are doing versus areas where you’re playing your strengths, so several people that might be developers might love development for those different reasons. A lot of us in IT have the strengths around learning and input. We love the process of learning, and we love input. If we hated learning, we probably wouldn’t be IT. We would probably be complaining every time they have a new version of the software out. But outside that, you’ll find people who love to do it because they love the analysis part of it, trying to figure how this works, people that love it because they’re fixing problems. They don’t mind doing process work. They love tackling problems and restoring things back to what they should be working. We have people who love it because they love teaching others as they’re building. “Hey, this is what I have learned. Let me share this with you,” whether it’s business side or IT, so those same strengths, whether they’re all Java developers or not, those strengths will come and play in different ways. They can still be generous and share the technology vine. They all work in the codebase, and I would want that. I want collective ownership of the codebase for sure. But why they do it and how they do it is different, and they can play their strengths differently. I’d look for that, and I still look for ways. You might have to shepherd them all around a little bit and say, “Here’s an opportunity over here. I’ve noticed that only one person is the expert in this.” I’d do that by nature anyways. But I don’t think that strengths will get in the way and shift them up and just all playing together in the sandbox so to speak with the actual technology itself. Has It Ever Gone Bad Clayton: The last question on the strengths topic is there an example you can give us or maybe a situation where you introduced this concept, and you had people to take the test, and it just really went south? Maybe some people are really against it and just really want to participate. Anything like that? Or people usually just willing to give it a shot? Scott: Everything is always going perfect and sweet for me. Roy: I thought that was the case, but I just wanted to make sure. That’s good to know. I Refuse To Be Labeled Scott: [laughs] No, I did have someone who was a bit of a rebel stallion which actually I like about them. I loved it when people don’t just accept what I’m saying. Skepticism’s good. A healthy skepticism is something I like to see. But this person took it to the extremes and just really basically refused to be…He felt he’s going to get labeled. I like to say, “The issue isn’t the issue.” I don’t think that was an issue. I think it was an issue on vulnerability. He was afraid of what the results might say. He knew it would be public. All the other people have their strengths pinned up on their cubes and were talking about it and all that. I think that was the issue. But in the end, I let it slide and just gave him time and said, “I’m not going to make you participate. I wouldn’t want to do that.” Later on, on the side just after all the excitement had die down a bit later, he did take it, and he said, “It really did nail me. It was accurate, and it was insightful.” Then we had a nice quiet conversation about that, and that was good to know. Outside that, people will approach it skeptically, but they’ll usually participate. They’ll understand that there’s a win it for them, and I’ll try to take time for that. More importantly, no one’s ever come up afterwards and said, “That wasn’t a good experience for me.” They might say, “I wasn’t sure about this particular strength or that one.” But overall, they say it’s really good. The conversation will draw insights. But there hasn’t been resistance except for maybe management saying, “What’s happening? Are you doing my job as far as developing my people?” which you need to make sure you’re on the same page with them and talk with them beforehand. Or HR saying, “It should be on our category not yours.” In fact, a very big supporter of this is HR. It’s worth checking with them, and they can share organizationally that they’re on board and that they know where this is going. For me, it’s all about team building and the agile team being self‑managing and self‑organizing. I take it from that route and just make sure everyone’s aware and not over‑communicating, but no significant problems after the fact. Roy: We’re about out of time. But is there anything that you’ve been excited about lately ‑‑ maybe a book, blog, training course, or anything like that ‑‑ that you want to share with anyone? Scott: Yeah, I’m such a person of immediacy, I guess. There’s a movie called “Blue Like Jazz” which is actually based on a book. But that term, “Blue Like Jazz,” is talking about jazz doesn’t resolve, and I’m realizing there’s issues in our agile community, I think, that don’t always resolve around what we believe and hold true and what we actually live out. I’ve been noodling about that. It maybe challenges us maybe to get back to the community a bit more and see what we can do to make a difference beyond just what teams and individuals themselves within the companies and contributing to the greater good. By the end of the day, I would love to have everybody know scrum and agile process. I’m looking in the ways to do that. I’m looking for ways to push out on the other communities outside that. I just finished lean start‑up and was really impressed me with that on top of the way we can partake accountability for evaluation of what we say we’re contributing to the business. If they can’t measure that, and they don’t have metrics upfront of how they’re going to validate that really added value, what are we doing? That closes the loop, the learning loop for scrum, and if they are willing to, I really recommend everyone to take a look at that as well. Roy: Great. Thanks for joining us today. We appreciate it. Scott: My pleasure. Thanks for having me, and thanks for all the great questions.

Derek Neighbors, Roy van de Water, Clayton Lengel-Zigich, David Bland discuss Lean Startup principles in Agile: Lots of companies dealing with unknowns Product teams Release early, release often Validate, Experiment, Iterate Culture preventing engagement? Executives communicate with teams How to get the “C” level to change Eric Ries “Lean Startup” / Steve Blank Is it a panacea? Radical culture problems abound Confusion about what lean startup means Risk adverse culture problems when you have golden egg to protect? Alignment across enterprise Cross functional teams How do you maintain it? Give freedom, be creative Innovation team (I’m a special snowflake) Executive support mandatory The post Episode #55 – Lean Startup Principles and Agile appeared first on Integrum.

Missing Content Clayton Lengel-Zigich, Roy van de Water and Mike Vizdos discuss: Do we estimate defects? How do I get “credit” for doing defects? What counts as a defect? New defect comes in what do we do with it? How should defects effect velocity? Why so defensive? How to deal with predictability? Definition of done factors in. Transparency is what is important. Use the retrospective Luke. Please don’t punish me. Person that writes the check decides. Zero defect mentality. Hardening sprint.  Say What? Developer Hat v Scrum Master Hat Transcript Clayton Lengel‑Zigich:  Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich… Roy van de Water:  I’m Roy van de Water. Scott Dunn:  I’m Scott Dunn. Clayton:  Scott thanks for joining us today. I know that you are interested in the strength finder or the strengths…I don’t know what the generic term for it is, but maybe can you give, I guess, a little bit of a background of what that is and why you find that interesting? Scott:  Sure. Back when I was a manager for a web development shared systems team, looking for ways to have my team members be engaged and focused. I was at an event called the leadership summit. There, I heard someone named Marcus Buckingham talk about the level of engagement of employees and how low it was. I was definitely listening. He gave a stat that less than two out of ten of us are engaged, meaning that we care what is happening at work and are doing our best. The company that he worked for at the time was Gallop. They did a survey of a million employees and a hundred thousand men trying to find what makes great management. They boiled it down to twelve questions called the “Q12”. The biggest lever if you were a manager to get the best out of your employees was do they have a good chance each day to do what they do best? IE Do they have the chance to play to their strengths? From there they came up with an assessment that you can walk‑through and get your top five strength which is called the strength spine which has been on the best seller list for four or five years now. Marcus has recently come out with an assessment of the zone, he has recently left Gallop. This is called “The Stand Out” which talks more about your strengths, roles and puts you in several categories of manager, leader and sales. There is a couple of ways you can approach it. From there you are talking to your team and working with them in a way that helps to discover what their strengths are and to find a way to leverage that as a coach, scrum master or manager. Clayton:  Let’s say I am a manager and I have this scrum team or agile team, how do I implement this? Do I make everybody take a questionnaire and then put people in boxes? How do these two roles meet? Scott:  That is a great practical question! What I have done before is something that I have detailed on my blog. We can circle back to that later but I do try and make it so people can go to and follow the cheat sheet. But basically what I do is I give everyone a couple weeks’ head up and notice in saying, “I’m going to be putting books on your desk. Don’t worry about reading it right now. Just take the assessment in the back. You’ll find the code. You’ll go to a website and register and use that code to start your assessment.” That gives them details about how the test works and try to lower the level of anxiety. It’s not a pass/fail test. You can’t not have any strengths. You’re not going to have a strength like loser or something like that show up, and you’ll be… Clayton:  Roy hasn’t taken the test yet. Roy:  That’s right. I’m really strong in the ability of being fired. [laughter] Roy:  Sorry. Go ahead. Scott:  Is beer drinking a strength? Well… Roy:  I think I’ve got that one covered, too. [laughter] Scott:  Yeah, you’ll get lots of funny responses, but the amazing thing is the results I’ve had. I’ve done this with at least 200 people so far. On every team that I’ve been on when I was independent we’d always do this because one, it’s a big team‑building thing. It’s very affirming. These people come out like, “Wow.” They’ll routinely say, “That really nailed me.” I promise you, over 99 percent of the time they’re saying, “That was so accurate. They’ve been reading my mail. I can’t believe this.” It’s a very affirming process. Not just for them, but that next step after they’ve taken it I schedule a meeting for all the team to come in. We just walk through their strengths. I just list them up on a grid. I’m writing them up in front of everybody, and I’ll open up the book and read off, or I’ll read off their reports. Everyone’s getting to hear about each other’s strengths, what they’re naturally good at where they’ll find the best of each other. These teams aren’t great teams because everyone’s well‑rounded. They’re great teams precisely because each person’s not, and you find out. You get that insight. I had one manager come up and say when she followed that. That was the most her team had talked to each other in four years. You get these amazing sharing and insights into each other as a team, and that’s part of the team‑building process as well. From there you start talking about coaching, and we can get into that a little bit later. But even if you just did that, you’re talking 12 to 14 bucks for this book, a one‑hour meeting. They spend a half an hour of their own time taking the test, and it’s a huge ROI as far as just the connection that they’re going to make and your insights as their manager or Scrum master as well. It’s very powerful. Clayton:  What do the results look like? I’m trying to think of, I think it’s the Myers‑Briggs Personality Test or something like that. I can’t remember. I think they have these little codes. Is it the same type of idea? Scott:  No, and I like the Myers‑Briggs. I took it, and my response is what I think most people think the strengths assessments are going to be, which is, “Oh, that’s interesting. That says that I’m an extrovert.” Well, but what do I do with that? How do I use that at work? Be more extroverty? You don’t know what to do. The strengths by it, it’s going to give you top five strengths, which are really more like action verbs, or the stand‑out will give you your top two roles and list out all nine. But, there are some that are actionable, like a maximizer. It’ll give you action items to take with that. If the stand‑out will say, “Here’s what you’re best at. Here’s what you can do with that. Here’s a great next step.” If you’re a maximizer, look for areas where something’s happening with your team, or the company, or a process. It’s OK, but it can be made great. You’ll naturally be pulled towards making things great. Average bugs you. It opens your eyes to say “Wow, that’s true. We had a deployment processes, and it’s OK, but I know that we could shrink the time down. Or, a build process, we could shrink that.” These people, if they’re on your team, and they’re a maximizer, they’re going to love doing that. They’ll thrive doing that. They’ll learn the most, and grow the most and perform the most. The team can lean on it, and these people will never get tired of doing that stuff. That’s one of the insights. Each one of those will be like that. I had a team member once, and we were at a lull at work as a Web team. I said, “Just take it easy. Surf the Web. No big deal. Enjoy your paid time off here.” It turned out she got frustrated and left for another job, and the reason was one of her strengths was activator. The worst thing I could have done for an activator, or I should say an achiever‑‑ that’s someone who loves to check off everything they’ve done that day. They love coming in that day, and there are 10 things to do. They get to check, check, check. “Look, I’ve been productive. Look…” Scott:  …that was driving her nuts. She would rather have me just cook up some work or given her a checklist of things to do and say, “Hey, could you just take a look at some of these areas in the code base, and review it for areas for opportunity”? Anything. I could have made it up. For me, that would have killed me. For her, it bugged her so much that she left for another opportunity where they would have kept her busier. Those are a couple of examples of doing that. Clayton:  I understand that it’s a really good tool for figuring out what kind of jobs the members of the team can do that are personally motivating. Do you find it’s, also, a good tool to use to help team members discover their weaknesses? So that they can try to round out areas they might not necessarily be proficient, or necessarily enjoy as much? Try to find enjoyment in areas where they don’t excel, so that the team can go more for that “Everybody in our team is a well‑rounded individual”? Scott:  Right. That’s a great question. That’s a common one, because most of our performance reviews are really spent like, “I see that you’ve done this, and this, and this and this. Thank you for your contribution. Now, let’s spend the rest of our hour talking about these areas where you [laughs] suck. Where you’re not so strong, where you failed, or come up short, or you just don’t perform well.” Those areas where you’re looking at the clock and say

Roy: Welcome to another episode of the Scrumcast. My name is Roy van de Water and joining today is Jurgen Appelo. Could you please introduce yourself a little bit Jurgen? Management 3.0 Jurgen Appelo: Yeah. Sure. My name is Jurgen Appelo and I am the writer of a book called “Management 3.0.” I am also the author of a blog called noop.nl and I am interested in the role of the manager in agile organizations, organizations working with scrum or any of the other agile methods. Roy: Cool. I’ve been scanning through “Management 3.0” and I talked to Jade quite a bit who has read the whole thing. What was your motivation to write that book? Jurgen: My original motivation was to write a book about complexity science and Agile… Jurgen: …developments because I like the science that explains why Agile works. I read lots of books about systems theory and thought. With people at conferences, I’ve noticed that their main problems were with management and leadership because Agile and Scrum don’t really define what the role is of managers. People just see managers as impediments to be put on the impediment backlog or something. Managers have to support the teams in order to make Agile really work. When I got that feedback, I thought, “OK, let’s focus my book on that topic because I happen to be a manager for 15 years.” I knew something about the role of the manager in Agile organizations. That’s what I, then, decided to focus on. Managers Reactions To The Book Roy: What do you feel has been the reaction from the managers that have read your book? Jurgen: So far, so good. Interestingly enough, most of the people who read my book are not necessarily managers themselves, but interested in the role of the managers or how to help them. Also, in my courses for example, based on the book, I think about 20 percent of them are middle managers. The other 80 percent are formed by Scrum Masters, product owners, team leaders, sometimes entrepreneurs, sometimes a product manager. A very diverse bunch of people, but they all struggle with the management position. Either they are themselves managers or they want to help managers in order to get them aligned with what Agile expects from them. How Can Agiles Coaches Facilitate Innovation Roy: Many people are saying that they value innovation, but they don’t really allow the environmental conditions for it to thrive to exist. What can we, as Agile coaches, do to help that? Jurgen: That’s a difficult, difficult question. One thing that seems to lack in Agile methods is experimentation. Basically, I learned from system’s science that there are three forms for systems to survive in changing environments. Scrum teams are, also, systems that are trying to survive in a changing environment. Those three approaches are anticipation, adaptation and experimentation. In Scrum, we do a little bit of anticipation because we try to look at the next sprint and predict what the customer wants. At least, that’s what the product owner does. We do a lot of adaptation because we show the results to the product owner. Then, they respond, the back‑log changes and new priorities and things off that. But what about experimentation? There is no real guidance on exploring things, just for the sake of trying things out. I explain that sometimes jokingly, “I ordered a chai tea latte from Starbucks a few weeks ago, just to see what it was and I hated it. It was terrible, so I threw it away.” This was neither anticipation nor adaptation. It was exploration, just trying things out for the sake of trying. We seem to be lacking that in Agile organizations. That is what innovation needs actually. We need a bit of time and space for experiments. How Do I Get My Teams To Be Self-Organizing Roy: From reading your book, I feel that you value self‑organization a lot and getting the team to feel like they have the authority to perform this type of experimentation. I’ve heard managers in the past ask the somewhat ironic question, “How do I make my team be self‑organizing?” What is the right way to ask that question? How do I allow my team to self organize or encourage them to self organize? Have you found a good way to get them to really feel comfortable, to take the authority, to make decisions and experiment? Jurgen: Yeah, because usually managers trouble a bit with delegating stuff to self‑organizing teams because they see as it as a black or white thing. Either I make a decision as a manager or the teams make the decisions as self‑organizing teams. They see it as just two actions. But, actually there are more options in between. There are shades of gray. In my book, I list several levels of delegation. The second level, for example, is trying to convince a team, but you still make a decision as a manager. The third level is a step further where you first ask the teams, “What is it that you would do if you were allowed to make that decision? Just give me your input.” Let them, still I will decide. Step‑by‑step you could go into the direction of delegation without doing a full‑blown sweep from level one to level seven because that for some managers feels dangerous and it is dangerous with some teams. You need a more gradual approach. I try to help them with that. I explain it sometimes as trying to find what is the speed limit. Trying to drive your car as fast as possible, but you don’t want to drive too fast because that will end up in chaos. It’s the same with self‑organizing teams. I’ve seen it myself. Inexperienced and immature are allowed to make any kind of decision, things will blow up. There is too much freedom. You have to constrain it a little bit. Helping Managers That Are Resisting Change Roy: What would you say to a manager that’s resisting allowing their team to self‑organize, perhaps somebody more of the traditional management role where they’ve always been taught that if they’re not in control, then everything is going to go wrong? Jurgen: That’s a well‑known problem. It’s a good question. I can only tell from my own experience that I have noticed quite the opposite. When I introduced Scrum in the Agile organization, things were going better. Things were not blowing up around us as much as they used to before. We have self‑organizing teams. I was able delegate to them. The performance went up. This did not diminish my role as a manager. On the contrary, it elevated me in the eyes of many, including my own CEO, because I was the one who came up with it. I was the one who said, “We have to do this.” The result was that I expanded my span of control from 20 people to 30 people and then, in the end, to 100 people because it made us more scalable and I could manage more teams. I would deny that it makes managers feel powerless. On the contrary, if you do it well, it could make you more powerful. It’s a bit cliche, but it is win/win. You gain from it as a manager because better performing teams reflect on you as a manager because they are your teams. My CEO didn’t want to let go of me anymore after such good decisions. Changing Organizations Roy: Got you. You talked a little bit about introducing Scrum into organizations and starting to form these teams. You just came out with a new protocol of how to change the world. How does that fit into trying to introduce organizational change? Jurgen: The question that I get most often is, “How do I get other people to change their behavior?” Or any form of that question like, “How do I convince team members that they should develop themselves some more?” Or, “How do I convince my customers that they should accept Scrum and its changing back‑log and things like that?” It’s always the same thing that Agile and Agile coaches struggle with it is convincing other people that they have to change. I have basic change management. I have researched that. I have borrowed lots of ideas from many good books and I turned it into a little handbook called, “How to Change the World”. It is an ambitious title, but it’s only 80 or 90 pages. It sort of gives an overview from my perspective as a complexed thinker on how you should approach a social system, which an organization is. It is a social system, and you have to poke it with ideas and experiments, and see what works and what doesn’t and do iteratively and get feedback and basically, you have to be agile as a change agent as well because you never know how the system is going to respond, how the organization is going to respond to your ideas, but just to try things out and also understand that you have to work on not only the rational level, but the emotional level as well because some people are aware of a need for change, but they have to be fed the medicine with lots of sugar. You have to address the people’s intrinsic desires as well and not only the rational part. Why Is Management Slow To Change Roy: In the book too, you talk a little bit about how management is often times really slow to change. Why do you think that is? Jurgen: It’s for many reasons. I’m quite sure some of them will fear their jobs because they see it not unreasonably as a danger for their position because I do think that, in some organizations, there are too many managers. The middle management layer is simply too fat. It can be thinner, but it doesn’t mean that we need no managers. I’m quite sure that for some this is the reason to resist and while for others it is simply not knowing what to do and willing to work with self‑organizing teams, but fearing that things go out of control. These managers would have a positive inclination towards Agile, but they simply don’t know how to handle it in a safe way. There are many different ways, many different reasons I think for managers to be cautious or resisting. We have to figure it out on a person by person basis. Roy: What would be your best change success story where you’ve gone in somewhere and introduced a good change? Jurgen: That would be my own organization because I’m not an Agile coach. I can only talk from my own experience as a manager. I’ve been working in my last organization for 7 years as CIO. There I introduced Scrum and it was a success in terms of the people who were working there, both the team members, top management, and customers. Of course, there were plenty of problems that we had to solve, but that’s what Scrum does. It doesn’t solve the problems itself. It just makes them more visible. We could start working on them, but everyone agreed that we made a good step in the right direction, that’s my personal experience. Of course, I hear plenty of stories from others, but they’re not my own. Roy: Recently you’ve been involved and helped organize something called the Stoos network. Could you please tell us a little bit about that? Jurgen: Yeah, sure. I was in contact with Steve Denning, another author who wrote Radical Management, Franz Roosli, who was part of the Beyond Budgeting Movement, Peter Stevens who was an Agile coach, and the four of us thought wouldn’t it be great to get people together, who are all trying to address the management problem and I’m just one of many. We started inviting people, and this became the Stoos event, the STOLZ, it is actually pronounced in German. In Switzerland, we had 21 people together to discuss things and we tried to figure out how can we accelerate change in the world and it is a very difficult topic. But we were very much inspired by each other and it seems that there’s plenty of spinoff activity now with Stutz satellites and Fearless Change, Fearless Hamburg, Fearless et cetera, lots of cities where events are being scheduled, and we’re already talking about some follow up events that have not been announced or scheduled yet, but at least we want to go on because it is a topic that many people are concerned about, and we’re all trying to figure out how can we help to accelerate change in the world. My another book How to Change the World is my own small contribution, but many people have their own contributions as well and we want to align them and make it dance together, that would be useful I think. Roy: Do you have anything that you’d like to promote or current things that you’re working on that you’d like to talk about? Jurgen: Well, there’re lots of things that I’m working on. I’ve already started writing the next book, which is sort of a real follow up to Management 3.0 in terms of very practical stuff to do. I aim for things you can try the next Monday morning when you get back to your work. That level of practical pragmatic stuff because my first book had lot of theory in it and I thought it was important to have a solid foundation, but now people are asking for more examples of practical things that are happening in other organizations and that they could try out. I’m collecting those. I talk with people at conferences. I have my own idea of what I call roving coffee. I have coffee with people in various places in the world. Wherever I’m traveling, I invite people to have coffee with me and I ask them what are practices that are working for you, I want to hear their stories so anyone who wants to share a story with me, they can do that over email or have coffee with me, I’m collecting them, and hopefully that turns into a very interesting new book that might be out by the end of the year or next year or something. Roy: Awesome. That sounds great. I’m looking forward to it. All right, well, thank you for joining us. Jurgen: Thank you for inviting me.

Missing content

Derek Neighbors: Welcome to another episode of the “Scrumcast”. I’m Derek Neighbors. Corey Haines: And I’m Corey Haines. Getting Kids Involved In Programming Derek: Corey, I wanted to talk a little bit…You’re pretty well known in the community, at least in the software developer side, also a little bit in Agile and the eXtreme Prgramming XP side. I find your story extremely fascinating on a number of levels. One of the things that always intrigued me is that you started programming relatively young for the average programmer, I would say. I’m curious a little bit about how you got started, and I think people can find some of that online. What would you tell parents who had kids that were interested in computers or programming? What would you tell them to encourage them to let their kids get into this kind of craft? Corey: I think nowadays, like I got in by cheating at video games. We had all the source codes so we could go in and change the source to let us get past points that we couldn’t get past. Nowadays it’s a little bit more difficult to do that, with all the games are huge and compiled. Now with the physical computing stuff that’s so pervasive and so easy to get into, like with the Raspberry Pi stuff that’s coming out and Arduinos, really grabbing the attention of the kids via physically doing stuff. I’ve done a little bit of work with teaching kids. I taught a class last summer and we used Scratch for programming. It was just amazing to see kids pick it up. It’s a graphical programming environment so there’s a lot less of the frustration of syntax errors, things like that. I’d say get into, bring those sorts of things. There a lot programs going on now around that are sort of centered around teaching kids to program. Derek: Absolutely, we run one here at our work space, so absolutely. Corey: That’s neat. What Would You Tell Your Younger Self? Derek: What would you tell your younger self if you could go back in time to that 10‑year‑old Corey Haines, what would you tell yourself? Corey: Don’t go into Microsoft technologies. Simply because of the fact that when I started spreading my eyes out a little bit and started looking beyond the .NET space and, even before that, the VB space, that’s when I really found this amazing community of learning and the community of not just one language but most people out there that I meet are some form of polyglots. The open‑source community is very supportive. I got into VB, C#, doing a lot about it in the corporate environment for longer than I wish I had. It was about 2004 when I started looking outward mostly through the XP community. And I wish that I had started sooner. Year Long Pair Programming Tour Derek: I think that segues really well. You talked about being in the corporate community, and certainly, how you came on my radar was when you took your yearlong tour where you said, “You know what, I’m really kind of tired of this corporate thing, and I’m really interested in really becoming a master at what I do and really broadening my horizons and working with different people.” As part of that, you took a yearlong tour so to speak to go work with a wide variety of people, a wide variety of projects, technologies, you name it. What inspired you to do that? Corey: In 2008, I actually left my last corporate job, joined a startup for about seven months, got fired from that startup because it just was not a cultural fit for me. Then a friend of mine and a good mentor of mine, J.B. Rainsberger, he and I for quite a few years had been talking about how great it would be to do something like Paul Erdős who was a mathematician that would basically just go everywhere and do math with people. We always have that idea of, “Man, would it be great to have the opportunity to just go program with people? No overhead. No expectations. Just go program, go code with them. See what they’re doing. Learn from them. Teach them.” When I got fired, I had some money saved up and was just like, “Now is the time to do it.” There’s so much out there to learn. There’re so many people out there to learn from and teach. I set up a three‑week trip. Then it snowballed into that. It was originally only intended to be about three weeks. But during those three weeks, it started to snowball, and I started setting my eyes outward a little bit and realized that there was a whole range of people out there, that I could go code with. It was always anywhere from a day to five days. So there was…I would come in, the only rule was, I was doing it for room and boards. I needed a place to stay and I needed food and I was pairing with somebody the whole time. And that was sort of the only rule that went with it. Self-Awareness Was Found Derek: What was the best part about that experience? Corey: There were a lot of really great parts. One of the big things that came out it that I had started with this idea and actually came to fruition was. I had a much, much, better sense sort of where I was, level‑wise. I had good understanding. I’d worked with people, who’ve been programming longer than I’d been alive. I worked with people who’ve been programming for a few years. It really gave me an opportunity to reflect on just where I stood as a developer. I was about, 11 years into my professional career, may be 12 years in. We often times get caught up in our own community and we have a sense of where we are relative to the other people in our community. But by going out and just working with as many people as I could, I got a better sense of that. I learned something in one place and then the next day, I would be teaching it to the next people. That sort of helped me, really solidify a lot of my understanding of the, a lot of the core fundamental techniques, that I use when I program. Putting Developers On Safari Derek: I think that’s a huge, a huge deficit that this occupation has, is, it’s really hard to have a measuring stick where you are. Sometimes, if you think you are really great at something, may be you kind of pull back and you stop engaging, you stop learning. One of the things that kind of excites me is, what if we get to a point where, companies start to put programmers out on loan, so to speak. What if it was a corporate culture to allow a little bit more polyglot behavior and allow developers to kind of meander between different corporations to help get some of that litmus test where they are at? Corey: Actually in 2010 and 2011, there was a group of companies that were doing just that. There is a group of seven consulting companies, like Relevance and Optiva and [8th Light]](https://8thlight.com) and a few others around the world. They started swapping employees for a week here, two weeks there. Derek: That’s great. Corey: Yeah. It was really neat to see. The Downside To Jumping Around Derek: I suspect there is a ton of great experiences. What were some of the bad experiences? What was the worst part about being on the road and working with different pairs, different technologies, different thing, every week or every five days? Corey: A lot of it was, this is kind of a weird answer, that the worst part was the fact that it was just so utterly exhausting. I look back and I’ve thought about it a lot and there weren’t a lot of moments where I was like, “Man, this kind of sucks” or “This is difficult.” It was a wonderful experience, I was going around, I meet people, I pull my car into somebody’s house that I had never met before, just come in, sleep on their couch and then code with them all day. But it was incredibly exhausting and probably about the first five or six months, I was doing short, several weeks, may be month long trips. Then I spent the summer of 2009, 3 weeks or 3 months, continually on the road and drove 6,900 miles, went from Cleveland to Miami to Prince Edward Island back to Cleveland. It really was incredibly exhausting, but that exhaustion was exhilarating because I was learning so much and I was meeting people and seeing things and so I think it was really just that exhaustion was the major negative part. Software Craftsmanship Derek: It is part of this kind of journey of learning, so to speak, we’ve really seen the software craftsmanship movements start to bubble up and the metaphor of going from apprentice to journeyman to master. I know that you’re a big part of the craftsmanship movement. Why do you identify with that, and why does that metaphor strike a chord for you in relationship to software development? Corey: Well, I really like the craftsmanship movement, the craftsmanship community because it covers the gambit of how do we bring people in to software. How do we train them through the years? Along the way, how do we interact with our customers? How do we take pride and how do we treat our code? All of these things, specifically with the apprenticeship to journeyman and beyond. I have a hard time bringing the master term in mostly because…The only place that I use it is when there’s somebody that I personally look up to and learn from as opposed to an external, “This person is considered a master.” I have much more focus on the idea of apprenticeship, of coming into a trade and learning somebody else’s way. I look at it as, apprenticeship is when you are studying under somebody and learning the way that they develop software. You find somebody who is an effective, proven software developer, and you learn their methodology and their techniques and their practices. Then there’s a point where you got those practices down, and you can sit there on your own and really take the effective atom. When you have that, it’s important, I think, to go out, cast your eyes out, look at the people around, find somebody and say, “Hey, they’re doing something completely different than I am” or “They develop software differently. They don’t use some of the practices that I use, but they’re being effective.” Go look and learn from them as well. You’ll bring stuff to share with them. You’ll be able to learn somebody else’s style. When you do that, you then start to merge those two styles in yourself, and you start to learn, and you start to reflect over those techniques. That is something that I think really could further our understanding of software development that I really like to happen. Criticisms Of The Craftmanship Movement Derek: Absolutely. There’s a few folks in the agile community that are critical perhaps of the craftsmanship movement and really struggling with tying the concepts of software development as an art form opposed to more of a scientific form. The biggest criticism that is universal between the detractors seem to be that when we move to the metaphor of craftsmanship, the fear is that we’re turning all of the focus into the actual act of the creation of the product opposed to the deliverable of the product or the output or the effects that the product has on whoever you’re building it for. Some of the examples are ‑‑ if you’re more worried about the stylistic making of the table so to speak in which it would be used, you’re not focused then on how it would necessarily be used in the real world. So maybe you can answer some of those detractors. Corey: I understand where that is coming from and where those fears are coming from. There are people who have written [indecipherable 14:18] . I have a tremendous amount of respect for and had a great conversation with them about this last fall. The thing is that being in the software development community and being in the agile community and in the craftsmanship community, we spend most of our time developing software. The things we talked about tend to be around developing software and the screencast that we do tend to be about developing software. But there’s a very important part of the Craftsmanship Manifesto, which is the Productive Partnerships, which is really about the way that we deal with our client, the way that we partner with them to deliver software to them that is fit for use. It’s exactly what they need. No more, no less. A lot of the craftsmanship thoughts came out of a reaction towards just the general level of horrible code that’s out there. So a lot of the emphasis that we put is on learning some of these techniques. There’s no more question about whether or not automated unit test provide value the majority of the time, and that TDD is a valuable, value‑providing method for doing design of your system. Is it always a hundred percent of the time the thing you should do? I was talking to Fred George…He had given a great talk at SCNA where he said that if it’s faster to rewrite your system, then you don’t need to do TDD. Well, that makes sense. If it’s fast, if you’re writing a script or if you’re writing just something that’s very quick to put out there, maybe you don’t do it. But the majority of people aren’t at that point. The majority of developers out there were not to the point where we have the experience necessary to make those decisions. I very much tell people, “Always write tests.” It’s better to overwrite them and then to reflect on the problems that that caused than to have no test at all and not do any sort of test‑first development and suffer the consequences of that. We’ve all been through those projects, and we know that doesn’t work. We have a set of practices that ‑‑ discussion’s over ‑‑ they do work. It’s just a matter of knowing how to apply them, and you learn how to apply them by practicing them. We talk a lot about this. If you go to the conferences that we’ve had, if you talk to the people that are involved in the community, and you go look at some of the companies that consider themselves craftsmanship companies, like say 8th Light here in Chicago, their focus entirely is on satisfying what the client needs. It’s not about polishing it. It’s not about gold plating it. They have a very active, incredibly successful apprenticeship program. They do [indecipherable 18:00] with their people. They do all of the things that we talk about that people say we’re overly focused on, but you can’t get better if you don’t practice. The state of the software industry is atrocious right now, where doing things and making mistakes that we should not be making on our day‑to‑day jobs, so that’s a long one to [indecipherable 18:25] , so I hope the kind of… Community Coding (Code Retreat / Code & Coffee) Derek: It’s great. When you get to the core of it, I think the community is addressing the symptom that we see on a regular basis, which is really bad code and really bad practices. You have to get through that to get to the good stuff. Corey: Yeah. Derek: Speaking of community, you do a ton of community work with Coderetreats and Code and Coffee. You’ve got a number of projects out there whether it’d be your CodeCast or How I Got Started Programming series, I definitely think people should check out and get engaged. Do you have anything new that you’re working on that you want to share with people? Corey: I just last December started a nonprofit sort of centered around the Coderetreat stuff. We had this Global Day of Coderetreat] last December where we had 94 cities, all doing Coderetreat on the same day. They were Skype calling back and forth, and it was just this wonderful day of bringing basically the whole globe together on a single day. Out of that, I brought out a nonprofit called the Coderetreat Community Contribution Fund], which right now it’s operating as nonprofit. We’re under 501(c)(3) review, but the goal of that is to be sort of an umbrella organization for doing fund raising to support kids programming events as well as a small amount of the funds will go towards supporting adult practice oriented workshops of the Coderetreat nature, don’t have to be Coderetreat but just sort of practice oriented. I’ve been working a lot on that lately, just sort of how do you fundraise. I just did a Coderetreat in January that raised $400 and turned that around and sponsored, in San Francisco, there’s an organization called Black Girls Code, which is focused on teaching underserved girls to program. They’re doing a six week course on the national stem challenge for writing video games and stuff. We took the $400 we had and we paid for snacks and drinks and stuff for them. The big thing that I’m really excited about now is that is sort of figuring out how to help these programs out there like KidsRuby, Hackety Hack, Black Girls Code, Code Now, and use some of the excitement that we built up around Coderetreat as a way of raising money to support that where we’re going to be doing Global Day of Coderetreat again this year in December, and the plan is for about 200 cities around the world to do it. My stretch goal is to have a Skype call with a space station. Derek: There you go. Corey: I figured if you’re going to have a stretch goal, it should stretch to outer space. Derek: I’ll say if you’re listening to this, next year you need to participate in the Global Coderetreat. We’ve done it here at Gangplank a few times. We definitely participated last year in the global initiative, and it’s well worth everybody who participates time. Corey, thank you so much for joining us today. I love the work you’re doing. I love what you’re doing to pay it forward, and you’re really a model for other developers out there to care about the code and really care about the community. Again, thank you for stopping by. Corey: Well, I appreciate it, Derek. Derek: Thank you. Corey: Thanks a lot.

Clayton Lengel-Zigich, Roy van de Water and Jade Meskill talk about potentially shippable software. Impossible!? How do you define what is potentially shippable? Does the product need to be pollished and perfect? Focusing on small problems (rather than the whole system) helps us deliver value sooner. It’s not an excuse to code yourself into a dead end. Value does not necessarily have to be targeted at Users, it might be the CEO or some other stakeholder. The post Episode #50 – Potentially Shippable Software appeared first on Integrum.

Derek Neighbors: Welcome to another episode of the Scrumcast, I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Jade Meskill: I’m Jade Meskill. Dealing With Someone Who Is a Bad Team Fit Derek: Today I think we’ve got a number of topics. The first one I want to talk about is what you do as a team member and as a management team or a manager when you’ve got somebody on your team that clearly does not seem to be fitting in with the team? Jade: Kick them off [laughter] Clayton: Kick them off the island or [inaudible 00:00:40] . Jade: Right, or make them VP or special projects or something. Roy: Yeah [laughs] . There you go. Clayton: Let’s see. Is this a self organizing mature team or any old average team? Derek: I would say let’s go from both angles. Let’s go from a mature team but maybe not fully self‑organized, meaning the participants are not necessarily juvenile in behavior. They are adult in behavior but maybe not fully self‑actualized. And then let’s go from a more mature approach. Like how would a mature team approach it? Roy: So, I think what I have often seen with less mature teams is they’ll notice the person not fitting in and not saying anything for a while until it becomes more that they can bear. And then they’ll go around the person directly to whoever is in charge of them and complain to that person. So like, if Derek is being a jerk all the time, then I’ll go to Derek’s manager and I’ll be like, “Hey, Derek’s being a jerk all the time. Can you do something about it?” And then the expectation is that to protect me. Derek’s manager is going to tell him to shut up or whatever. And I think that in a more mature situation, I would approach Derek directly and have a conversation rather than just telling him that he’s being annoying or a jerk or whatever. And then that type of environment, Derek might realize that he didn’t even know he was coming off that way. And I might not realize that to sensitive to some of the ways that he was saying something or something like that. And I think that’s how a mature would solve the problem is directly and head on and not try to…they might get a third party involved simply as a mediator to prevent from emotions becoming too heavy, but they wouldn’t get a third party involved as an intermediary. Five Dysfunctions of Team Clayton: Yeah, I think on the kind of immature thing, you could talk about the five dysfunctions of a team. So maybe they’re kind of lacking in trust, and they have some sense of false harmony, so in that case, it would be the kind of thing where everything’s kosher and it’s all great, but when this other person’s not around then I’ll complain about them. I don’t ever do anything about them because people revert back to, “If you want it done right, do it yourself.” I’m not going to totally kill myself to save the project. I can pretty much do all the work that I need to get done without involving this person. The two of us will be the heroes on this thing. We’ll figure it out. I think that’s a common pattern. I think also, when you don’t feel like a team. When you don’t feel like you are working with each other, for each other, then that’s when it’s easier to get management involved and say, “That’s above my pay grade. That’s not something I have to worry about. I’m just here to write code.” I’m going to go tell who ever I think is responsible for that. I’m going to go shove this problem off on them and hope they figure that out. Roy: I also think that an on a mature team, diversity breeds innovation. That person who is dissenting, is the least like everybody else, and might be the awkward person, is somebody who’s got a different view point and different experiences, can bring different things to the team that the other team members just aren’t capable of doing. Casting them off, writing them off, or not involving them in the team work, I think, could be a huge mistake. I have definitely seen cases in which somebody is absolutely poisonous to a team. I don’t know if it has always been irreversibly so. That is definitely a huge danger. I do think that every effort should be made to try to incorporate their dissenting view points. They’re just not fitting into the team. Make it an asset rather than something that hurts the team. Stages Of Team Development Jade: I think it’s a very enlightened team that could start to recognize and tackle this challenge. Usually it’s a team that is still in the Tuckman model, in the forming stage. They’re dipping their toe into the storming and getting scared, backing away from that. It’s a hard thing to overcome. It’s against most of our human nature to deal with that. Clayton: One thing I think that’s interesting though is that as the team starts developing some common practices, base lines for expectations, or a working agreement, it makes it a lot easier to have those conflicting moments when you can say, “We talked about how quality was important to us. You don’t seem very concerned about the build breaking” for instance. “We all agree that quality is important. What can we do about that?” I think that really takes the edge off the conflict versus if you don’t have that kind of precedence then you’re talking about “Hey jerk, why did you break the build, like you break the build all the time.” Maybe we haven’t even talked about why that’s important, or why we care about that. But if you kind of establish those things that makes it easier to say, “Hey, I’m not trying to beat you up personally, I’m just saying I thought we all agreed to this and it seems you’re violating that, like, why is that?” Roy: It also seems to be less about me versus you too because it’s not “Hey i don’t like that you’re not breaking the build,” it’s more like “We agreed as a team to not break the build,” right? Simple Rules Jade: Right. There’s a lot of studies that show in complex adaptive systems or in human interactions that you need those simple rules to help just kind of maintain civility, right? Then you can talk about violating those shared rules like you’re saying and not about an individual person and their personality. Derek: Yes, I’m kind of hearing there’s a few stages to this in the sense it looks like the first team is just not aware that the person doesn’t fit. The second one is that they’re aware that the person doesn’t fit but they probably bad mouth the person behind their back or they just feel like they have the trust probably in management even to deal with it. Then the third which is where most of the team’s I see somewhere fit into… or maybe they have some trust in management to the point where they are highlighting to management their concern. “I’m concerned about so and so”, “I’m concerned about performance” et cetera. Then I think the next one is the team that start to directly approach each other. And I think the last kind of model is the team that not only directly approaches but actively solves the problem, right? So it’s one thing to say, “Hey, you’re really pissing me off in ABC,” it’s another things to say “Hey, how do we get to the point where we’re including you in the team better.” So with that I am sticking with the team concept. I’ve seen a lot of organizations that are undergoing change and wanting to go to self organizing, where they’ve got a team that maybe isn’t performing up to par. They’ve done command‑and‑control and so they try to go to something that’s like a hybrid command‑control. Maybe it’s self organizing, with all sort of reporting structures back or status reporting mechanisms. They tend to flip flop back and forth between giving the team full reins or enough rope to hang themselves to completely command‑and‑control and ultimately they’re just afraid that products are not going to be shipped on time or they’re not going to be successful. What are some key triggers you see in that and if you’re a manager in that situation how do you get to the point where you let the team be self organizing and still mitigate whatever risk you’re kind of concerned with? Jade: I think again it goes back to some simple rules of engagement. If I were to look at that situation that you’re talking about, I’d say there’s probably some lack of trust happening there, probably for various different reasons. Either people aren’t doing what they say they’re going to do and so the command‑and‑control sneaks back in. There’s a lot of reasons that you can see that kind of flip flopping around. Kind of trying to sort of self organize. I think the trick with self organization is kind of an all in mentality. You have to give them the container to self organize within, or else they’re really not self organized. Your job as a manager is to figure out what that can look like and at the same time, help you team to not drive off a cliff. It’s a tough balance to find. Shock Therapy Derek: So I really like a blog post that was on Jeff Sutherland’s blog called “The Scrum Shock Treatment.” It was describing a way to jump a team into the idea of doing Scrum. It was very command‑and‑control, which is the part I didn’t like, but it kind of made sense in this context which is “I’m going to tell you how Scrum is going to work, and we’re going to do strict Scrum and you guys don’t get a say in the matter until these criteria are met.” He had some arbitrary criteria which, I think, you should probably negotiate for specific cases like, whenever you have more than 240 percent of your current velocity, or things like that. Then as soon as those criteria are met, then we’re going to slowly start to allow you to make more decisions because I think that’s one thing that I’ve seen a lot where a team starts doing Scrum but then starts making their own exceptions to the rules before they understand why the rules are there in the first place. And before they can understand why the rules are there in the first place, they have to see those rules in action and see how effective they can be. I think, Jade, you pointed out earlier that you’re coaching a Scrum team, and you saw them doing the almost traditional like, “Let’s start cutting ceremonies because they produce too much overhead.” Jade: Yeah, the wand of Scrum. Derek: Right. Then it’s the inevitable, “Let’s start replacing all of our physical tools with digital ones because that would just make things so much better.” I think that those are the types of things that we really need to get them to try doing the things the right way first, and then let them change things up and make their own decisions. Team Self-Organizing Through Impediments Clayton: I think all the Lean, Kanban people just collectively face palms at the “Scrum Shock” article. But with that said, I think an important thing if you’re a manager dealing with self‑organizing teams is to really make that clear distinction about self‑directing versus self‑organizing. You should never say self‑organizing without mentioning self‑directing as well. But assuming you can get that in place where you have some constraints, I think then you can switch into the role of, rather than being either the taskmaster or the tweaker or nitpicker person who’s just constantly looking for “whose shoulder can I look over?” that kind of thing, to be more of the enabler person who’s saying, “What’s my team missing, and how can I enable them to be successful?” I think that’s an important distinction to make. There’s probably some argument to be made for letting the team self organize and maybe a certain regard to get going. Then as they become more comfortable in that space, they expand in that. I think over the life of the team, that box probably gets bigger and bigger and bigger until it gets to a point where the box is no longer important. But starting out, I think you could probably let them self organize on smaller things first. I think with that said though, there’s probably never a good time to just say, “Now, we’re a self‑organizing team.” There’s always some impending release or something that’s coming up that’s going to, “Oh, we can’t do it now. If we waited six months, then it would be a perfect time.” And that time never comes. So you really just have to take the leap of faith, I think. Hiring Quality People Derek: Continuing with the team theme, there was an article that I think we were discussing earlier today about, “Don’t try to hire a Rubyist.” I think Bob Martin ranted a little bit is, “Don’t hire a Rubyist. Just hire a good programmer, and they’ll come.” Then we had some fun memories of, “Hire somebody who is not a Rubyist. Throw him in the pool, and then say, ‘Stop drowning. Swim faster. Stop drowning. Swim faster.’” So when building a team, what are your viewpoints on just hiring quality people as opposed to hiring people that are qualified for the job? And how would you integrate them into the team if you don’t go either direction? Jade: I think I get asked this question a lot by managers or executives who are looking to build their teams. I fall back on the Agile Manifesto that you need to find motivated individuals, and some baseline skill set is of course part of hiring someone. They have to have some basic skills that would allow them to be a contributing member of the team. Does that mean that they have to have the exact skill set that you’re looking for? No. You want to hire motivated, smart people that will adapt to whatever tools or whatever situation that they’re in and do a quality job. I tell them to look for attitude and aptitude. Those are the foundational things that if you’re looking for a Scrum master, don’t just hire someone because they say they are a Scrum master, but find the person who has that right personality to perform the duties and the hard role of being a servant leader versus somebody who just wants to tell everyone what to do, but they happen to be a certified Scrum master. Derek: I think Porsche has a great…I think their hiring motto is, “Hire attitude. Train skill.” I like the approach of doing that because I think we find a lot that people who are experts in their field tend to almost have a primadonna‑type nature to them. The Ruby community especially is famous for this, which is what Bob Martin is ranting about, but I’m sure that the same carries over to the Java world, into the .NET world, and to every other world as well, where if you get a guy who’s an expert, he’s going to demand special privileges above and beyond the rest of the team. He needs to have a lead in front of his title. He needs to get a higher paycheck and all of that stuff. Really, what that builds is a guy who doesn’t want to work in front of the team because he’s above the team. Fixed Mindsets Jade: Usually for me, the warning sign on that is when someone defines themselves as “I am a bloody blah. I am a Ruby programmer. I am a .NET developer.” That, to me, shows a very fixed mindset of that person. Derek: I think you meant to say “Ruby Ninja,” Jade. Jade: Yeah, I’m so sorry. Roy: I solved that by saying, “I am a god.” [laughter] Putting Technology Over People In Hiring Is a Mistake Clayton: I think it’s interesting though that if you’re a hiring manager and you’re saying, “We need more people on this team, and we need more qualified people,” they always want the people that are experts. “We’re trying to find people that know this technology like the back of their hand.” I think it’s a trick question. At that point, you’re elevating the tools and the technology over the people that you’re actually hiring. I think if you were to ask those people, “Hey, look back in your career, and think of all the great people that you’ve worked with.” I doubt they would say, “I worked with this guy, and he was so awesome because he could recite any Java method, and he knew all the classes” or like some nitty‑gritty technical detail. It’s never anything like that. It’s people that they enjoyed working with, and they collaborated well with, and they were able to produce great things. They were a friend basically. So I think it’s the wrong question to be asking. You don’t want to be hiring the perfect technical person. You want to be hiring people that for the long term would be good people to work with even though maybe they don’t have the exact skill set right now. Derek: The only problem I see with hiring good people rather than experts is that it makes it very difficult from an HR standpoint, where you have an HR department, and they are responsible for looking for your candidate. They need a checklist of stuff to check off before they can get the right person, and if your baseline, like you had mentioned Jade, is too low, then you’re going to get an influx of way too many candidates to go through, which makes it very difficult to single out the really good ones that you want. I don’t think I really have a good solution for that where you can narrow the stack down because I think a resume is such a really poor way to see what somebody is like that I almost don’t want to see this part of the hiring process. But how do you go through a hundred candidates and find the one guy who’s really going to make your team shine? Attitude, Aptitude, Ability Roy: I think that this is a big push right now. I am going back to what you’re talking about, Clayton, is the world is changing so fast. Ruby might be hot and popular now, but in three years, Ruby might not even be a viable language. I don’t know too many people that are looking for Studley COBOL programmers. That loop has gone from a 10 or 15 year arch to a five year arch in technology. If you go with that attitude aptitude ability, to me attitude certainly is important, but aptitude is the thing that HR department should be looking at. Which is how do we figure out whether somebody is capable of learning new things? The world is going to change significantly during their employment here. How do we make sure that they continue to grow? Jade: That requires a very different way of hiring. To talk to Roy’s point is, yes this is a problem for HR, but the problem is because of the pre‑existing practices that we have. The way that we are doing things currently are not adaptable for the new world that we’re entering. This causes systemic change throughout the organization. If you want to hire the best people, you have to find the way to identify the best people and doing it through resume is not going to work. Derek: With that we’re out of time. I want to add that if you are an HR person or an organization that is currently undergoing an agile transformation and has an HR department that are dealing with some of these issues, we’d love to have you on a future episode of the Scrumcast. You can get a hold us at facebook.com/agileweekly, and we’d love to hear from you. Until next time, we’ll thank you for joining us. Thanks! Jade: Thank you.