The .NET Sweatshop (v2) : agile

'What The Heck Is He Doing Here?'

SandyK — Tue, 24 Oct 2006 22:29:00 GMT

For the last few weeks, I've been spending one day a week sitting in the shared workspace that several members of the Microsoft.com Commuinities team uses. We have about nine people sharing one large office in Building 6 that was once home to Bill Gates and then Steve Ballmer. "So what?", you may say. Well, I'm a manager (and in fact the manager of their managers) and therefore don't do any of the "real" work. In fact, I have my nice solo office where I can play my music, have private phone calls, and handle drop-ins from anyone on the team. Why on earth would I skip that for an admittedly cramped office that is bursting at the seams with little to no privacy? That easy: Spying. OK seriously, when someone e-mailed and asked me why I do it, I itemized some reasons and after I wrote it, I thought it would make a good blog post. It connects a little be with trying to be the best manager I can be for a team trying to do agile development and some other ideas about what I think effective leadership and management is about.

I am doing it for several reasons:

Empathy: I know it’s cramped in there and I am trying to empathize a little bit. I've grown to be a big believer of the shared workspace as a means of fostering (forcing?) communication between team members. Microsoft is an e-mail culture and e-mail leaves no room for nuance of diction or truly constructive dialog. But Microsoft facilities also weren't designed to support the shared workspaces and we've had to improvise. As a result, some of the conditions are tight. As I explained to the teams, I have a solo office because I need it for meetings, but I don’t like the “exec washroom” exclusivity it fosters, so this is my way of at least showing that I get it.
Communication: In the same manner that the shared workspace is about opening the lines of communication between teammates, the days I sit in the office are partly meant as an open forum for anyone to ask me questions at any time. I've tried to do lunches with each of the teams, but that comes off as a more contrived environment. Meanwhile, with the shared workspaces, it’s harder to do the “management walk-by” when people are sharing offices, so this opens the lines of communication. I'm just there working away, so if you have anything to say, go for it. I think I've gotten some pretty thoughtful questions and feedback as a result, including the fairest question of all: what do I do on a typical day? (Answer: there is no typical day)
First-Hand Knowledge: Get a little more in touch with the development teams. It's my effort to “trust but verify” the info from the leads that report to me. I also like the idea of being closer to the trenches whenever possible. I was reading the Wired article on Ray Ozzie and how he likes to sit with developers and practically work with them because (a) he understands the code and related issues better and (b) he draws a lot out of the conversations that are happening at the time. I don't know if I'll be pair programming with any of these guys any time soon, but I do think being "on the ground" helps my appreciation of the situation and associated challenges.
Feedback: Opportunity for the teams to show me their work, if they so choose. We are having monthly demo days , but if they want interim feedback, here I am. Also, to the point about Ray Ozzie, I also like hearing the conversations and issues that arise in the daily work that goes on. It's hard to give feedback on the spot (which is essentially what I ask people to do in one on ones or at the team lunches), but in the course of the day, many things will pop up.
Fear: Scare the living bejeesus out of them to keep working and not slack (that’s just a fringe benefit) ;-). OK, that's not true at all and that's part of why I picked Fridays--I want to pick a day that is a little more mellow, perhaps. Hopefully, the moods are a little better, people are looking forward to the weekend, and they can be a little more informal.

I don't think I would have done this nine months ago. I think there is a comfort zone that I think I feel with most of the team that allows me to do this. I’d do it for some of the other Microsoft.com Communities teams (there are two other teams as well as the CodePlex team), but those teams are either smaller where my presence might be a little more imposing or, in the case of CodePlex, they'd intimidate me :). In all seriousness, I do worry about the work equivalent of Heisenberg's Uncertainty Principle (the position of an object can't be determined because it is affected merely by being observed). I don't intend to scare them and hope that isn't the end result. I only do it one day a week because it's all my schedule really allows and I don't want it to reach a point where it does feel like Big Brother.

{Dave Matthews - Some Devil}

Management Accountabilty in a Scrum World

SandyK — Tue, 30 May 2006 21:40:00 GMT

Last summer, I was having a conversation with a friend who worked in Microsoft Research. I knew him from outside of work and we rarely talked shop, but in this specific instance, I was telling him about my projects. The biggest project on my plate was CodePlex. After bragging about the featureset, I began describing the way we were building the software using the agile methodologies, from the spike we did at the project inception to the weekly iterations and TDD. I was telling him about how we were even trying to get a shared workspace to put the entire team in one room (we did get it and, while it’s not as cool as my old team’s workspace, it is the office once inhabited by Bill Gates and then Steve Ballmer—so that’s pretty cool)…

My friend’s response took me a bit by surprise. He was more impressed with the development approach than the product and he went out of his way to not only praise the team, but also praise me as the manager. He pointed out few managers had the patience and trust to support agile development at Microsoft as there’s a leap of faith that is required and trust in the team. He believed managers couldn’t handle the ambiguity of the schedules and deliverables (though I believe that is changing at Microsoft). After all, with waterfall software development, everything is lined up and the dates are in stone—when you say it is going to be “Code Complete”, it will be complete. That’s a mirage, of course as software projects rarely hit dates, but managers still manage to get some level of satisfaction from deluding themselves. Personally, I’ve always felt that you can’t effectively run a business on a twelve-month ship cycles and assume no changes. Waiting until month eight to determine there’s a slip or key features will get dropped is borderline suicide. Either the product will come up short of expectations or the date will slip and surprise upper management. It also guarantees the infamous death march. The ability to continually course-correct is something that has a sister-theory in business called “Discovery-Driven Planning” and I see it in the NFL every Sunday in the Fall. But agile is not perfect and isn’t the cure-all for every software project. What happens when results are less than perfect?

Recently, Doug Seven from my team posted a blog entry entitled “Accountability in a Scrum World”. In the past several months, Doug has really come to embrace many of the agile principles. Well, with one of our projects, a team that is very new to agile development had struggled with the first two iterations. Doug was obviously frustrated with the progress and was trying the get to the root of the problem. In this specific case, I think there were many things working against them that make any sort of assessment unfair. Plus, to judge after two iterations in any case is WAY premature. I think it’s easy to fall into an expectation of everything working in textbook fashion from day one. Guess again—nothing in life works that way. While I myself am inherently impatient, this is one case where I refuse to be so. In fact, I gave the team a short-tem goal I felt was very achievable in a fair timeframe. I wasn't looking to stretch the team on a deliverable. In fact, my manager and I locked horns about it as he thought I was sandbagging. In a way, I was. Why? Because I wanted the team to have enough room to take risks. If you are under time pressure, you will revert to your old approaches. When adopting agile development, teams need to be allowed to struggle without fear of reprisal. Changing the way you do your craft is scary and that’s what we’re asking from the team. As a manager, I need to be willing to make the short-term investment for the long-term prosperity. Again, it's a matter of trust.

The unintended consequence of Doug’s post was to scare the team into thinking they were under the gun, which draws them back into the world where they fear failure. That spins them into a world of the blame game, whether it’s teammates, the process, management, and other things. And let’s face it—all those are likely guilty of something, right? I don’t want people on that team thinking about reviews or their bonuses or anything like that and their need to defend that (yes, that is naïve, but I want to at least minimize focus)—I want them focused on the success of the team. To the sports analogy, the athlete should be thinking about winning a championship first and then trust that if he contributed sufficiently to the cause, he will be rewarded (yes, another sports analogy—I can’t help it).

But, to Doug’s question, what of accountability? Not in the case of this team, but with all teams, successful and not. With the infamous Microsoft performance curve no longer in existence, we can now operate in Lake Woebegon, where all the children are above average (well, not quite…). I believe the only way agile works is when everyone feels accountable for everyone else. That’s the purpose of the daily stand-up—people sharing their progress and their obstacles, in some cases looking for help. If one person fails, everyone fails. Communication is vital, everyone on the team should be looking to assist, not blame, and the accountability must hang with the team. At the end of the project, you can certainly do the retrospective and recognize who stepped up for whom. I’d rather reward the person that chips in to help a teammate get past a tough issue than someone who writes the random killer feature. I'm not talking about the hero dev thing (which can be a different problem), but rather taking care of the little things and removing obstacles to keep the cadence. In fact, I’ve been on projects where one person failed miserably, but the team was successful because the rest of the team stepped up. Once the project shipped, the rest of the team was rewarded nicely and the person whose contribution did not measure up was not with the team for long. That said, we gave him the full v1 release to prove his worth before casting judgment on him. But when you start playing the individual accountability game from the start, then it’s every man for himself. Agile will fail in that mindset. My personal management philosophy is to keep an eye on any unique events that need immediate attention, but I try to reserve judgment on people until the project is out the door. Trust the team and give them the ability to self-correct. Once they ship, it is clearer to assess why the project was able to ship and what could’ve been better.

So will the team that struggled with the first two sprints succeed? My confidence is very high. There’s too much talent there for it not to. In fact, the third iteration has already gone MUCH better by all accounts. But just as I won’t judge the 2006 Orioles baseball season until October (though I will keep an eye on the standings), I won’t judge this team until we’re much further along in the project. They know what they’re accountable for as a team and that’s all I am keeping an eye on at this point.

{Foo Fighters – In Your Honor}