Given a couple days of thought after that last job, it became kind of apparent to me (and I knew this all along, but didn’t quite put two and two together about it), the previous place I worked, while I really liked the team and management, were still trying to figure out the Agile process. They knew that it would help them with estimates, but if all your focus on is estimates, you’re just adding bureaucracy without adding the teamwork element that makes Agile a better development philosophy for many teams.
A coach can tell you “I see you’re doing some of the basic pieces, and that’s great” and you can take that as a compliment, but Agile development’s entire purpose isn’t just for better estimating tasks, it’s about getting those tasks done more efficiently and making your team look better in the eyes of the company, provide better value. It’s not for every team or every philosophy, to do it justice, you kind of have to embrace some things that you might think aren’t totally intuitive if you come from a waterfall background.
One thing that really puzzled the hell out of me when I was driving out with my little box full of the odds and ends and books I pulled out of my desk was “why would you even try doing Agile if you want your team to work off in little islands on things anyway?” I got this massively schizophrenic reason that my contract hadn’t been extended, and all I can think is that this is a team that knows what it wants to be, but is still holding onto a philosophy that it was very used to. I was alternatively told that what they wanted for the team was for all the developers to go off on their own and “take ownership” of pieces, but was also told that what they wanted was someone to work “across the system on a little bit of everything”. To do both isn’t exactly easy, but I felt like I had managed to do that simultaneously. The thing is, the latter one fits better with a real agile philosophy, the former fits with waterfall method style development.
I like teamwork. I don’t seem like I would, but I really enjoy working off people. Sometimes I ask them questions I already have an answer to, because it’s possible that they might have a better answer or know something I don’t. The teams that I’ve worked in that worked like that got stuff done on time, sometimes even ahead of time. What was hinted at me was that they didn’t like that, they didn’t want me to talk to other people about things, they just wanted me to own something and not communicate with others. From working across their entire system, I learned in detail exactly how that turned out. From watching the team “fire” emails sent out on a regular basis, from listening to people, I figured out that the result of that has been that they have a hell of a lot of stuff in production that invariably ends up not working the way it should. I used to see several of the same stored procedure throughout the system, mainly because the person who wrote it didn’t ask the guy who was working on security how they were supposed to write it. The end result is when a third programmer got into it, they picked the one that either looked the easiest to figure out, or what seemed to look like the “most official” or “most commonly used”. The end result is that you would either have a security backdoor into the system, or you had a procedure that was far more inefficient than what was really needed in that spot. Or one that didn’t work as expected at all.
There was also little consistency in the overall architecture. One person would do things one way, one would do it another, and you could tell the lack of collaboration was probably at fault. And when someone else had to make both pieces play nicely together, it became a struggle that wasted time. If they had made sure things were in sync to begin with (usually one piece is made before the other…if not, then it can be developed in tandem if they communicate), it would have saved time for more than one person…it would have saved the QA person time as well. On one hand, when I originally interviewed there, I got the feeling that the team was a bit apologetic about it, on the other hand, I felt like they almost took pride in that because whether or not someone was comfortable with that was apparently a criterion as to whether or not to hire a person.
In a lot of ways, that’s like telling someone who walks in the door “Hey, we have a lot of spaghetti code that is the result of working on conflicting deadlines and team turnover rate. Are you comfortable with working within that and not trying to make things better for everyone?” If it were posed to me like that, my answer would have been “Hell no. I take my job seriously, and if I feel that I can add value by making things work better, then of course I’m going to do what I must to refactor things.”
Anyway, what I really feel was the real reason was that I have a wide range of skills, some sort of niche, and they couldn’t figure out how to use those tools effectively within the system. I got the feeling that they were trying, but the work they did was fairly purposed. They had a lot of work that didn’t seem to fit in with the focal work that they did, and that seemed to be the type of work that I was a better fit for.
The point of the title of this is that you can scrum away all the tasks and stories you want, you can put whatever numbers on it you want and you can get as great at estimating as you want, but if you want to improve velocity, you’ve got to encourage people to do things like trade tasks when working towards a release (working on tasks you have no familiarity with is fine when you have plenty of slack time planned in an iteration, but when you’re trying to increase velocity, it’s a really bad idea). You need to encourage the meetings, and even once in awhile, you’ve got to pair on a task.
When I saw them fighting fires, they were fighting fires because people who had taken ownership of their section of code had become so insulated from the rest of the team that they were breaking other people’s work. There’s no architecture document in XP. There’s no set of specs. You make up for that with communication. You have to. Scrum doesn’t solve that entirely, owners and scrummasters don’t always define tasks properly upfront because most of the time they don’t have their heads in the code. When the team was really putting out fires and making things work well, they pulled together and had the online conferences and communicated with each other. They bounced ideas off each other. It’s sad that they couldn’t extend that approach to the rest of their process, but they seemed bound and determined to hold onto those last fragments of waterfall…even though those are the absolutely worst things to hold onto when you switch to Agile.