Benjamin Day

The emphasis in product development should not be simply on correctly following the Scrum process, but rather on delivering a finished, working software; this is the true purpose of Scrum. Scrum provides a framework with established accountabilities, events, and artifacts which all relate to creating a working product. Therefore, using Scrum effectively will improve the delivery process. However, solely mastering Scrum won't guarantee success. The end goal should always be to deliver valuable, functioning software.

I've given the same advice to almost all of my clients -- "you need a clearer Product Backlog", "You're working really hard but you're not getting anything done", and "You need to cut scope, launch your product with a more focused scope, launch it, and then get feedback." ...

Your Sprint Planning Meetings don’t have to be a chore. Your Sprint Backlog doesn’t have to be a mess. Do short backlog refinement meetings twice a week and sleep a lot.

As part of the on-going Scrum Myths series at Scrum.org, here are three myths related to people skills. When I say people skills, I mean topics like emotional intelligence, emotional IQ, and person-to-person interactions. Myth #1: Scrum must be "huggy / feely" Word on the street is that Scrum has to be "huggy / feely". Basically that Scrum has to be all emotional or it's not going to work. It's part of that classic misconception that Scrum is just a bunch hippie-dippy, Birkenstock-wearing, Jeff Lebowski wannabes who just want to talk about their feelings and never actually get anything done. Ok. Sure. There's some of that out there but -- well, it doesn't have to be that way. There's no need to be all emotional and "huggy / feely" if you're doing Scrum. You can do Scrum, be successful at it, and be completely emotion-free. If you're getting the results that you want out of your team and you're excluding all the emotional stuff entirely, that's fantastic. But what if you're NOT getting the results that you want? On a scrum team or in an Agile organization, there's almost always room for improvement. Sure, you can probably do ok just by following the rules of scrum from the Scrum Guide -- but at some point, you'll be looking for ways to improve. This is where addressing the human, emotional, "huggy / feely" stuff can be important. Software development would be wonderful if it weren't for all the people. Back in the olden days of software, you could have one or two developers and they could crank out what everyone thought was amazing. Fast-forward to today and the software that's expected is a lot harder to deliver (in any reasonable amount of time) with just one or two people. This might mean that your organization is working with a small team of 5 to 10 developers or maybe you're working with multiple teams with hundreds of developers. That's a lot of people. That's a lot of human interaction. Seems pretty unlikely that they're all just going to get along perfectly. Scrum doesn't *require* emotional intelligence and emotionally aware leadership -- but it sure does help. Myth #2: Anyone Can Be the Scrum Master Here's the myth: anyone can be the Scrum Master and it doesn't matter who that person is. This comes up all the time -- especially in organizations that are new to Scrum. Here's how it starts. Either there's no obvious choice for who should be Scrum Master or nobody actually wants to be Scrum Master. So they either randomly pick someone or they decide that they'll trade off the Scrum Master role from Sprint to Sprint. "Steve'll be Scrum Master for Sprint 1. Anisha will be Sprint 2. Tarun in Sprint 3." Yah…that's pretty unlikely to work. Not everyone is meant to be the Scrum Master. Not everyone is going to be good at being the Scrum Master. The idea that "anyone can be Scrum Master" is kind of like saying "I can type therefore I think I'd make a good software developer." It just doesn't work that way. If you know the rules of Scrum, you can be a passable, functional Scrum Master. But there's a pretty huge difference between a passable Scrum Master and a really good one. Emotional intelligence is a *huge* part of being a great Scrum Master. Your goal is to help your team to be productive and to self-organize towards delivering fantastic, done, working software. If your Scrum Master is seriously lacking in emotional IQ, you're going to have trouble. If your Scrum Master is a control freak who can't stop giving orders and has a "my way or the highway" attitude, chances are slim that that team is going to do well at self-organization. So while Scrum doesn't require "huggy / feely"-ness and good people skills, the Scrum Master role probably does. Helping all those people to get along and be productive and creative is no small task. Merely following the rules of Scrum is probably not going to be enough. Myth #3: The Scrum Master has to be "techie" Ok. So not everyone can be Scrum Master. But surely the Scrum Master should be a technical rockstar or at least have a technology background, right? Usually the thinking goes, "well, if my Scrum Master can't understand all the technology discussions then how are they going to tell the team when they're wrong?" Well, that's not really the Scrum Master's job. Sure, it can be helpful sometimes to have that expertise but the Scrum Master isn't necessarily the technical leader of the team. The Scrum Master's job is to help everyone remain focused and productive on the mission of delivering that done, working software. That's a whole lot more about reminding the team about their Definition of Done and on human-oriented team facilitation than actually saying anything about the code or software architecture. In fact, I think that having a coder or a former coder as a Scrum Master can sometimes be a liability. Usually, this code-centric Scrum Master gets stuck in the weeds of the technology solutions rather than being focused on the ultimate goal of delivering software. This isn't because they're being malicious -- it's because the code is where they're most comfortable. Coders think that software is about code when what you really want is for the team to think about delivering finished, usable functionality. There's a huge difference between code that's written and features that are delivered. Helping the team to efficiently get from written code to done, working, delivered software is most of what the Scrum Master worries about. You really want to have someone in that Scrum Master role with fantastic interpersonal skills and a big picture view of software delivery. It's important for Scrum Masters to be able to get some distance from the tech and hang back so they can see the big picture. Summary One of the biggest problems in the software development industry is the name -- "software development industry". We're way too focused on code. The more that your team can think "Software Delivery Industry" versus "Software Development Industry" the more successful that you'll be. And so much of this has to do with helping all the humans to work together and get along. Remember: play nice! -Ben

I work with a lot of companies to help them to improve their development processes and to either adopt Scrum or improve how they’re currently doing Scrum. Lately, I’ve noticed that a fair number of companies run into problems with a certain kind of project: The Rewrite Project. On this kind of project, the company has an existing application and, for whatever reason, they’ve decided to re-write it. It starts out ok but somehow it turns into a little bit of a train wreck – no one knows when it’s going to be done, there’s a massive amount of technical debt (aka. work that’s not completely done), and people are starting to worry about the budget . You’d think that this kind of project would be straightforward because 1) the organization has a deep understanding of the business problem, 2) the existing version proves that the business problem is solvable and 3) they usually have an existing team who either wrote and/or maintains the existing application. There’s a lot of knowledge there and these are not incompetent organizations – they managed to write this application and keep it running. So why are they getting crushed by this project? I think they’re stumbling because their knowledge lulls the management team and the development team into a false sense of understanding what they’re trying to do and that it’s going to be easy to develop. In short, it’s software development hubris. They think it’s easy and that they have the requirements nailed and because they feel they don’t have much uncertainty and then their process discipline – how well they’re doing Scrum – suffers. If this Scrum-centric organization were tasked with writing a completely new application, following the incremental delivery of the Scrum process would be a no-brainer for them. Create the wish list of features (the Product Backlog), work with management (the Product Owner) to prioritize the features on the Backlog by business value, then start breaking the work down into iterations (Sprints) and start developing. It’s obvious to them. You can’t do everything at once, and some features are more valuable than others so work on small, manageable chunks of the application and deliver completely finished features in the order than that business thinks is valuable. On a rewrite project, you’ll frequently hear the Product Owner say “we don’t need a backlog – just go look at the existing application and build that.” So, there’s a definite temptation for the Product Owner to mentally check out. Then on the development team side of the house, they’re going to think that they understand the application already and either 1) don’t estimate or adequately de-compose the work and/or 2) come up with insanely overly optimistic time estimates. Put these chunks of Scrum dysfunction together and bad things happen quickly. The way to break the curse is to change how you’re thinking about the project. Think of it as writing a similar but new application rather than “rewriting”. Remember that the original version is filled with hundreds of little and not-so-little dissatisfiers that you’re trying to fix in the new version. So, whenever you hear something like “build this screen exactly like it is in version 1 except change X, Y, and Z” or “make this subsystem work just like before except make the database better” remember that you don’t understand it like you would a feature in the old version anymore. When you’re working on a project like this, keep in mind that there’s a lot more uncertainty in the requirements than you think. Also, remember to keep, maintain, and prioritize a Product Backlog. Most importantly, watch out for signs that you’re neglecting your software development process.

I did a coaching and training session with a company recently. They're a small, early-stage company in the Greater Boston-area. I got a call from the owner (let's call him Mike) looking for help solving their problems with Team Foundation Server version control. Mike was complained that they were regularly "losing changes containing days worth of work" and their branching structure was "out of control". He also said that the situation had gotten so bad that some of their employees had started taking local backups of their source code tree multiple times per day "so they could work." The assertion from some team members was that TFS just wasn't stable and Mike wanted me to come in to train them on how to use TFS. Is Branching the Problem? When I got there, we got the team together and started chatting about what their pain points and questions were. “Lost changes.” “Lots of branches.” “Merges are next to impossible.” “All we really want to know is how do we handle TFS branches for long-term, medium-term and short-term work?” All this branching talk started making me wonder how they get software out to customers. I asked, "so, what does a release mean to you?" The room got lively and everyone started shouting out ideas. "Well there's a database and code." "What I was able to do was to keep it to one month." "Oh and there's Silverlight and Entity Framework." "When I feel that there's enough stuff that it's worth it." "Anywhere from 4 to 8 weeks." There wasn't a clear answer. On a team of 4 people, the technical people generally said it was code and the business people said it was something that was vaguely time-based. What was surprising was that no one said anything about delivering features. Next question. This one directed at the owner. "Mike, what's your team working on? And how do your people know what you'd like them to do?" Mike: "Well, I've got a spreadsheet that I create once per month of what I'd like them to do." Me: "And do they do it? We're about halfway through the month. Are they about halfway done?" Mike: "They're all working. I don't know if they're half done. We've had some emergency fixes lately." Me: "Team, how are you doing on your list of tasks?" Frank the UI guy spoke up, "well, there are the fixes that I just did for production and then there are the quick tweaks that we're doing right now and then there's the re-write for the reporting system that I'm working on…but that's not due for a few months." When I went around the room, it became clear that everyone was working on a bunch of different tasks simultaneously that were all due at very different times and what they were working on was only loosely related to what their other team members were doing. Everyone was working on different stuff. Integration was awful and they had trouble getting anything done because they all kept stomping on each other's work. This was only made more complex by having to work on 'big feature' development efforts that were going to ship sometime way off in the future. And to make it more interesting, it came to light that there's a 5th member of the team and he didn't want to be at that meeting. He didn't feel like he needed to be there because he "never checks anything in because he works on the database." They were creating branches all over the place in the hopes of keeping everything straight. One of the developers was actually working outside of source control most of the time so he could manage the complexity. That developer basically had an improvised, local branching structure. Everyone thought that their code didn't affect their fellow developers but, in reality, everything was highly related because it all had to integrate and work together at the code level and at the database level. Too Much Work In Progress They didn't have a branching problem. They had a branching symptom. Like an immune system creating antibodies to attack a pathogen, the teams were creating branches in order to get something -- ANYTHING -- done amidst the chaos. Their real problems were 1) too much work in progress and 2) poor team communication. Over lunch, I asked Mike what his biggest problem was. It turns out that what's really costing him a lot of money and hurting his business is employee turnover. "For some reason, I can't keep any employees for more than about 9 to 12 months. We’ve got a lot of very complex business logic and it takes a long time for anyone to get enough understanding of that logic to become productive. Just when they've started to figure it out, they leave." Mike is clearly stressed out and tired. And he's been stressed out for so long that there's almost a numbness to what's happening around him. I can't say that I could blame any of the people who left. That would be a very difficult company to work in. There are a zillion things happening at one time. It takes forever to get anything really and truly done. Each employee has about 10 features that they're responsible for that all need to be done "right away" and are all only partially implemented. They only get a couple hours to work on one of these features until their focus gets ripped away by one of the many fire drills or changes in priority. Even though they're working with other people, everyone's really on their own team of one. It's stressful work, it's lonely, and you rarely get the satisfaction of a job well done. My recommendation to Mike was to consider adopting Scrum or something like it. Start with 1-week sprints because their environment and focus changes so fast. Minimize their work in progress. Pick one or two features that you want to ship and set the team loose on them. Establish a written Definition of Done with the team and encourage the team to really focus on getting those one or two features to Done each sprint. Have the team work on these features together simultaneously so that they're not getting in each other’s way, so they know what's going on, and so they're functioning as a unit. But most importantly, minimize your work in progress and really focus on getting to Done. Remember, minimizing your work in progress doesn't mean doing less, it just means doing less right now. People need to know that their work matters and they need to see that they're accomplishing something. Developers in particular love being able to focus on a feature and then see it be done at the end of the sprint. It gives their work meaning and it keeps them happy and motivated. Sanity & Teamwork My prediction to Mike was that minimizing work in progress and focusing on Done would reduce the stress level for everyone and make everything more understandable and predictable. As a result, since they wouldn't have to worry about working on so much simultaneously, those over-grown TFS branches would just quietly disappear. Most importantly, he'd have happier employees who wouldn't want to leave and he'd have his solution for his employee retention problem. Fingers-crossed. -Ben -- Think you have a "branching symptom" but you don't know what to do? Need a therapist for your team? Want some training on TFS and/or Scrum? We'd be happy to help. Drop us a line at info@benday.com.