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.
Leave a Reply