Coaching is fun. It's great to watch a group of developers really get something for the first time. We had iteration planning today, and I put up a Scrum board in our work area right after the meeting. Within minutes, developers had started to gather around it, and just automatically started to update it to reflect what they were doing.
24 March, 2010
Agile Coaching
It's been some time since my first abortive attempt at keeping a blog. I've since left the company where I was working, and have hung out my shingle as an independent Agile coach. I'm doing much the same work as my major thrust when I was an internal employee: transforming an organization into one that delivers reliably and without drama.
30 July, 2008
A tale of three projects
Let me tell you about three projects that I've worked on recently.
Project A was a waterfall project for a Fortune 500 equipment manufacturer. We had a department of around 150 developers and QA people. We ran a full year behind schedule at one point, and had to spend three months just fixing bugs to stop churning. Late in the project, the team wound up working lots of overtime, which burned everyone out. Eventually, the whole product line was canceled, which torpedoed a billion-dollar initiative for the company.
Project B was an XP project developing an n-tier workflow and billing system with a custom desktop client. We had a team of 15 developers and two or three support people, working in three agile project rooms. The system was of roughly the same size and complexity as project A. In a typical 3-4 month release, we accomplished more than project A did in the four month release that ran to 16 months.
Project C was an xP@Scrum project doing SaaS with a modern rapid development framework and a RIA front end. It was a "green field" project, staffed with a team of five experienced agilists, including several veterans of project B. We avoided some of the agile adoption pitfalls that project B ran into, stayed on top of our technical debt, had effective tests (at full coverage) from the start, and generally got off to a good start and stayed there. We estimated our work by using the same number of "story points" that it would have taken us on project B... but at one point per pair day, not per pair week.
Doing some quick back-of-the-envelope math, project B was at least 40 times as productive as project A, and possibly more because B actually delivered reliably, and A didn't. Project C was five times as productive as project B, and therefore 200 times or more as productive as project A.
Which project would you rather fund?
Project A was a waterfall project for a Fortune 500 equipment manufacturer. We had a department of around 150 developers and QA people. We ran a full year behind schedule at one point, and had to spend three months just fixing bugs to stop churning. Late in the project, the team wound up working lots of overtime, which burned everyone out. Eventually, the whole product line was canceled, which torpedoed a billion-dollar initiative for the company.
Project B was an XP project developing an n-tier workflow and billing system with a custom desktop client. We had a team of 15 developers and two or three support people, working in three agile project rooms. The system was of roughly the same size and complexity as project A. In a typical 3-4 month release, we accomplished more than project A did in the four month release that ran to 16 months.
Project C was an xP@Scrum project doing SaaS with a modern rapid development framework and a RIA front end. It was a "green field" project, staffed with a team of five experienced agilists, including several veterans of project B. We avoided some of the agile adoption pitfalls that project B ran into, stayed on top of our technical debt, had effective tests (at full coverage) from the start, and generally got off to a good start and stayed there. We estimated our work by using the same number of "story points" that it would have taken us on project B... but at one point per pair day, not per pair week.
Doing some quick back-of-the-envelope math, project B was at least 40 times as productive as project A, and possibly more because B actually delivered reliably, and A didn't. Project C was five times as productive as project B, and therefore 200 times or more as productive as project A.
Which project would you rather fund?
13 May, 2008
Sue needs developers!
Call Genie is inventing the future of voice-enabled mobile local search, and we need the best software team in the industry to do it. As a member of our team (we have offices in Toronto, Calgary, Oakland, and Aarhus, Denmark), you'll be responsible for a variety of small and not-so-small software applications and components that make our products work together and allow our staff to manage them. You'll also help invent better and cheaper ways for us to scale our applications for greater demand and automate previously manual tasks.
We're looking for people who:
- are brilliant,
- get things done on time, and
- get along well with the rest of our team.
We're very picky about who we hire, and we care a lot more about your problem solving skills and your ability to write well-tested, well-designed, efficient code than we do about how many years of experience you have with which specific technologies. That said, having any or all of the following characteristics would make you more attractive to us:
- A track record of success with more than one language and technology stack. You may be expected to write or maintain code in Java, Python, C#, Groovy, Ruby, JavaScript, or other languages. Java is by far our most widely used language, and recent Java experience involving Spring and/or Hibernate is particularly valued.
- Experience with agile methods such as Scrum and XP, especially as a leader or on a self-organizing team.
- Past successes in picking up new domains quickly, cultivating relationships with internal and external customers, and applying domain-driven design to solve customers' underlying problems.
- Experience in any of the following is a definite asset: VoiceXML, telephony protocols, GIS and mapping, search engine technologies.
- Test-driven and/or behaviour-driven development experience, and superior testing skills.
- Strong refactoring, object-oriented design and patterns expertise.
- Extensive SQL experience, including a clue about good data modeling, query optimization, and object/relational mapping issues.
- Experience with aspect-oriented programming.
- Continuous integration, source control, and project build expertise, particularly involving Maven, Ant, Ivy, and Subversion.
- Skill and interest in mentoring junior and intermediate developers.
- A regular habit of reading up on the latest technologies, and a track record of applying them to help projects you've worked on.
- The ability to pick up new technologies quickly, evaluate them critically, and recommend or teach them to others.
- Passion, enthusiasm, and a commitment to succeed.
We don't expect every successful candidate to have every one of those qualities, but they're all pluses. And successfully convincing us that there's an important point that we left off that list, and bringing to us relevant experience in it, would make you particularly attractive. In return, we offer competitive compensation, a good work/life balance, and the opportunity to help shape the direction of tomorrow's systems.
Interested?
If you're a high performer in search of a great opportunity, and would like to join an all-star team of other high performers, please send a copy of your resume in confidence to hr@callgenie.com, and let's talk!
15 April, 2008
16 October, 2007
Two kinds of velocity
A couple of iterations ago, our product owner made the comment that he was unhappy with the progress that we were making. As we had exceeded our velocity target on the previous iteration, I challenged him on this. He referred me back to our original tentative plan that came out of our planning effort at the start of the project; we were clearly nowhere near that point.
In the course of the ensuing discussion, it became obvious that we're really using velocity to measure two entirely different things:
We decided to start tracking two velocity numbers by dividing our story cards into two categories: system features and everything else. We have a blue star stamp that we use to identify the system features, and we keep track of our velocity both overall and in "blue star stories." We've been tracking the fraction of our total effort that goes into completing those stories, and managed to raise it from around 60% into the upper 80s.
The obvious danger is that useful technical work will be thrown out along the way, but we've been reasonably good about not doing that.
In the course of the ensuing discussion, it became obvious that we're really using velocity to measure two entirely different things:
- the rate at which the team was completing useful work (and by extension, the rate at which we could plan future work), and
- the rate at which we were making progress toward getting the system we're building into production.
We decided to start tracking two velocity numbers by dividing our story cards into two categories: system features and everything else. We have a blue star stamp that we use to identify the system features, and we keep track of our velocity both overall and in "blue star stories." We've been tracking the fraction of our total effort that goes into completing those stories, and managed to raise it from around 60% into the upper 80s.
The obvious danger is that useful technical work will be thrown out along the way, but we've been reasonably good about not doing that.
19 August, 2007
Scanning whiteboards
In one of my previous jobs, I led a development team for a very large photography company in Rochester, NY. It was standard practice there for there to be a digital camera available in every conference room for meeting participants to use to photograph the whiteboards to capture diagrams, minutes, and so forth. Buying a cheap digital camera, preferably with something like an EasyShare dock to make the process of extracting photos from it trivially simple, had been on my "to do" list for setting up our new office.
Instead, our CTO bought us a pair of PLUS M-11W scanning copyboards. I had used "digital whiteboards" in the past that used magnets or such, and wasn't impressed, but these are actually quite nice. The writing surface is an endless conveyor belt that feeds through a linear array scanner; you write on it with regular whiteboard markers, and it can save the scans to a USB thumb drive, or print directly to a colour inkjet printer. They were a bit of a bear to get physically into our project room and set up, but they've really grown on us, and we routinely post whiteboards from meetings and design sessions to our team wiki.
The down side is that they're only two of the seven whiteboards in our project room (and we're likely to simply cover the walls in our permanent space with 4' x 8' bathroom tile when we move), and are useless for capturing what's on, say, the whiteboard that we use for our status tracking. On the other had, the conveyor belt design means that we essentially get two whiteboards in the same physical wall space, one of which can be rotated out of the way. That has allowed us to do things like keep an updated living design of our main system workflow on one of them, without permanently sacrificing an entire whiteboard.
Would I buy them again for a future team? Probably. They cost about as much as a developer workstation, but scanning takes such little effort, and the scans are of higher quality than a digital camera photo (and free of glare) that we use them all the time, and the ability to keep a whiteboarded design around for later modification practically sells the gadget by itself. And a good magnetic whiteboard of similar area would cost an appreciable fraction of one of our scanning whiteboards.
We're also likely to be acquiring an inexpensive digital video camera with a still frame function very soon, so this isn't really an "either-or" choice for us anyway.
Now we just need to rig them so that they post to our Wiki automagically when we hit the "save" button....
Instead, our CTO bought us a pair of PLUS M-11W scanning copyboards. I had used "digital whiteboards" in the past that used magnets or such, and wasn't impressed, but these are actually quite nice. The writing surface is an endless conveyor belt that feeds through a linear array scanner; you write on it with regular whiteboard markers, and it can save the scans to a USB thumb drive, or print directly to a colour inkjet printer. They were a bit of a bear to get physically into our project room and set up, but they've really grown on us, and we routinely post whiteboards from meetings and design sessions to our team wiki.
The down side is that they're only two of the seven whiteboards in our project room (and we're likely to simply cover the walls in our permanent space with 4' x 8' bathroom tile when we move), and are useless for capturing what's on, say, the whiteboard that we use for our status tracking. On the other had, the conveyor belt design means that we essentially get two whiteboards in the same physical wall space, one of which can be rotated out of the way. That has allowed us to do things like keep an updated living design of our main system workflow on one of them, without permanently sacrificing an entire whiteboard.
Would I buy them again for a future team? Probably. They cost about as much as a developer workstation, but scanning takes such little effort, and the scans are of higher quality than a digital camera photo (and free of glare) that we use them all the time, and the ability to keep a whiteboarded design around for later modification practically sells the gadget by itself. And a good magnetic whiteboard of similar area would cost an appreciable fraction of one of our scanning whiteboards.
We're also likely to be acquiring an inexpensive digital video camera with a still frame function very soon, so this isn't really an "either-or" choice for us anyway.
Now we just need to rig them so that they post to our Wiki automagically when we hit the "save" button....
Recording daily stand-up
One of the things we've done on our project that has really helped is to record our daily stand-up meetings with a digital voice recorder and post the recordings to our team Wiki.
Our old CTO was big on written status reports, and asked everyone on my team to spend fifteen minutes every day writing status reports into their news space on our Confluence server. It inevitably takes half an hour to write a "fifteen minute" status report, which adds up to two and a half hours per week per person... or 6% of our capacity.
The next day, right before stand-up, I noticed a USB voice recorder on our product manager's desk. I decided to try making that the "talking stick" for our stand-up instead of the stuffed animal that we had been using. By passing the recorder as a talking stick, we got a good quality recording of each speaker's voice, and the fact that it was a USB digital recorder made it trivial to get the recordings off at the end of the meeting and post them to my daily reports in Confluence.
The recordings have been a huge hit. Our old CTO loved them (though they failed to fend off the written reporting requirement), and they quickly spread to the rest of upper management. Since we finish our stand-up meetings in ten minutes, they're short enough to fit into a busy executive schedule, and because they're recordings, they're asynchronous, and can be listened to between meetings or while doing other tasks. Our CEO is now a regular listener, among others... and other groups that hadn't been standing up are now doing so, having trained themselves by listening to our model. Also, because we can offer the recordings to all interested parties, there's less pressure for "chickens" to be physically present in the meeting, although that's less of a concern for us because we're located in a different city from the rest of the company. (Naturally, the recordings have helped to bridge that distance.)
A couple of weeks ago, I needed to work from home for half a day to take some lengthy phone meetings without disturbing our team, and I had the opportunity to actually use the recording to catch up with what the team was doing. It really worked, and in fact, I picked up some important status information from it that I was able to use in my phone conference with our investors. Having the recordings also gives us a lot of valuable institutional memory, for no additional cost beyond having morning stand-up, which we were going to have done anyway.
Memo to myself: investigate how much it would cost to have a transcription service transcribe our stand-ups... or better yet, look into speech-to-text options.
Coda: We're still doing regular Confluence reports, but they've morphed from a status reporting function (which is now fulfilled by recording stand-up) to a record of technical details to be communicated to other team members. We've kept them, because they've become valuable.
Our old CTO was big on written status reports, and asked everyone on my team to spend fifteen minutes every day writing status reports into their news space on our Confluence server. It inevitably takes half an hour to write a "fifteen minute" status report, which adds up to two and a half hours per week per person... or 6% of our capacity.
The next day, right before stand-up, I noticed a USB voice recorder on our product manager's desk. I decided to try making that the "talking stick" for our stand-up instead of the stuffed animal that we had been using. By passing the recorder as a talking stick, we got a good quality recording of each speaker's voice, and the fact that it was a USB digital recorder made it trivial to get the recordings off at the end of the meeting and post them to my daily reports in Confluence.
The recordings have been a huge hit. Our old CTO loved them (though they failed to fend off the written reporting requirement), and they quickly spread to the rest of upper management. Since we finish our stand-up meetings in ten minutes, they're short enough to fit into a busy executive schedule, and because they're recordings, they're asynchronous, and can be listened to between meetings or while doing other tasks. Our CEO is now a regular listener, among others... and other groups that hadn't been standing up are now doing so, having trained themselves by listening to our model. Also, because we can offer the recordings to all interested parties, there's less pressure for "chickens" to be physically present in the meeting, although that's less of a concern for us because we're located in a different city from the rest of the company. (Naturally, the recordings have helped to bridge that distance.)
A couple of weeks ago, I needed to work from home for half a day to take some lengthy phone meetings without disturbing our team, and I had the opportunity to actually use the recording to catch up with what the team was doing. It really worked, and in fact, I picked up some important status information from it that I was able to use in my phone conference with our investors. Having the recordings also gives us a lot of valuable institutional memory, for no additional cost beyond having morning stand-up, which we were going to have done anyway.
Memo to myself: investigate how much it would cost to have a transcription service transcribe our stand-ups... or better yet, look into speech-to-text options.
Coda: We're still doing regular Confluence reports, but they've morphed from a status reporting function (which is now fulfilled by recording stand-up) to a record of technical details to be communicated to other team members. We've kept them, because they've become valuable.
The middle distance of communication
During my last job search, I had a really great conversation with the SVP of R&D for one of my top companies. The company was opening a new office, and our conversation got onto the subject of agile project rooms, which I was proposing to set up for the team if I came on board.
Two of the best teams that I've ever been on were an agile project co-located in a single room, and a "virtual office" project with no two team members in the same city. With the co-located team, it's obvious that sitting around the same table makes it easy to just speak up to talk to someone, or to overhear a conversation between pairing partners. In the virtual office case, it seems counterintuitive that we had good team communications (and jelled well), but it was so obvious to everyone that we absolutely had to make an effort to pick up the phone regularly and talk to one another.
I've worked in plenty of cube farm environments, where team members would sometimes go for weeks (or between weekly staff meetings) without ever having a conversation about pressing technical issues. It's easy to get complacent about a coworker being just down the cube aisle, or over in the next row, and then never get around to walking over and talking to them. As flimsy as cube partitions are for blocking out noise and distractions (i.e. they don't), they do create a barrier to communication that people need to spend some energy to overcome, and without the reinforcing effect of being obviously remote, it's one that's easy to let drop.
Joel Spolsky is big on giving all of his developers private offices with doors that they can shut. Leaving aside the extra real estate costs involved in doing that, that seems like an even easier way to let intra-team communication fall into that "death zone" in the middle distance. Certainly, cubes that let in noise and interruptions are far worse, but while private offices allow each individual developer to have more "flow" time to work independently, that's very much optimizing for the wrong thing -- what matters is the team's output, and that's largely a function of effective communications.
Communicating with people right next to you is easy. Communicating with those far away is important enough that you won't skip it. It's the middle distance where the danger lies.
Two of the best teams that I've ever been on were an agile project co-located in a single room, and a "virtual office" project with no two team members in the same city. With the co-located team, it's obvious that sitting around the same table makes it easy to just speak up to talk to someone, or to overhear a conversation between pairing partners. In the virtual office case, it seems counterintuitive that we had good team communications (and jelled well), but it was so obvious to everyone that we absolutely had to make an effort to pick up the phone regularly and talk to one another.
I've worked in plenty of cube farm environments, where team members would sometimes go for weeks (or between weekly staff meetings) without ever having a conversation about pressing technical issues. It's easy to get complacent about a coworker being just down the cube aisle, or over in the next row, and then never get around to walking over and talking to them. As flimsy as cube partitions are for blocking out noise and distractions (i.e. they don't), they do create a barrier to communication that people need to spend some energy to overcome, and without the reinforcing effect of being obviously remote, it's one that's easy to let drop.
Joel Spolsky is big on giving all of his developers private offices with doors that they can shut. Leaving aside the extra real estate costs involved in doing that, that seems like an even easier way to let intra-team communication fall into that "death zone" in the middle distance. Certainly, cubes that let in noise and interruptions are far worse, but while private offices allow each individual developer to have more "flow" time to work independently, that's very much optimizing for the wrong thing -- what matters is the team's output, and that's largely a function of effective communications.
Communicating with people right next to you is easy. Communicating with those far away is important enough that you won't skip it. It's the middle distance where the danger lies.
18 August, 2007
Manager-flavoured blogs that I read
I'll have a separate post at some point about technical blogs that I read, but since I'm a relative n00b at being a manager (I had a matrix-y job with a management component for a year, and 5+ years as a team lead, but this is my first stint with "the M word" in my title), I've been concentrating lately on trying to learn as much as I can about good management practices.
Some resources that I've found helpful:
Joel on Software -- Part technology, part management, all good reading. Joel and I part company on the subject of agile project rooms (he hates them; I see them as a best practice), but there's a lot of good advice there, especially about hiring and retention.
Rands in Repose -- His Management Cheat Sheet is a great introduction, and the rest of the blog is well-written and packed with neat insights.
Manager Tools -- Now we've left the technology world entirely in favour of the world of management. This podcast is a gold mine, and they've probably forgotten more about good management than I've learned yet. Some parts are less relevant in a specifically technical setting (in particular, the one-page resume they recommend absolutely won't cut it for an individual contributor position in software), and some can stand some adaptation in an agile environment like we have, but it's generally great stuff.
Marc Andressen is always a fun read. He goes into the economics and business needs of startups more than into line management.
Other recommendations for good resources for new managers would be gratefully appreciated!
Some resources that I've found helpful:
Joel on Software -- Part technology, part management, all good reading. Joel and I part company on the subject of agile project rooms (he hates them; I see them as a best practice), but there's a lot of good advice there, especially about hiring and retention.
Rands in Repose -- His Management Cheat Sheet is a great introduction, and the rest of the blog is well-written and packed with neat insights.
Manager Tools -- Now we've left the technology world entirely in favour of the world of management. This podcast is a gold mine, and they've probably forgotten more about good management than I've learned yet. Some parts are less relevant in a specifically technical setting (in particular, the one-page resume they recommend absolutely won't cut it for an individual contributor position in software), and some can stand some adaptation in an agile environment like we have, but it's generally great stuff.
Marc Andressen is always a fun read. He goes into the economics and business needs of startups more than into line management.
Other recommendations for good resources for new managers would be gratefully appreciated!
The M Word
Back when I was a teenager working summer jobs at startup companies and corporate MIS departments (they called it "MIS" back in those days, when dinosaurs (OS/MVT; 8-bit micros) roamed the earth), I marvelled at tales of senior programmers (there were "system programmers" and "application programmers" and even "programmer/analysts", but we hadn't become "developers" or "engineers" yet) moving "up" to management later in their careers. What self-respecting geek, I wondered, would do such a thing? Who would ever give up the joy of writing code in order to push paper around?
Fast forward to now, and you guessed it -- I've been promoted to management. Much to the surprise of my teenage self (and if I could have ten minutes to talk to my teenage self, boy howdy would I ever have optimized my intervening years around a different set of assumptions), I really enjoy the management side of my job, almost as much as I love writing code. All of the crappy, annoying things that used to come down from management in previous jobs that made my life so miserable, I actually get to do right here... and that's exciting.
Dave Thomas recommends learning a new language every year. "Manager-speak" certainly qualifies as a language (and a "programming paradigm") all its own. And just like other languages, I've started to notice some neat hacks as I've been learning this one. Hence the point of this blog.
I also get to still write code, thankfully... which is mostly a mad scramble to keep up with my team technologically, since I only get about 50% of my time (in a good week) to spend on code rather than on management, and that number looks to only go down as I advance. Not only am I no longer the best developer on my project -- any project -- it's now very important that I not be, because I'm going to be away from the code at least half the time, and can be a significant roadblock if I'm the information silo. Thankfully, I was clueful enough to hire the best people I could find. We're doing some really cool things technologically, and it's really a fun project to work on.
Anyway, welcome to my shiny new blog. Isn't it shiny?
Fast forward to now, and you guessed it -- I've been promoted to management. Much to the surprise of my teenage self (and if I could have ten minutes to talk to my teenage self, boy howdy would I ever have optimized my intervening years around a different set of assumptions), I really enjoy the management side of my job, almost as much as I love writing code. All of the crappy, annoying things that used to come down from management in previous jobs that made my life so miserable, I actually get to do right here... and that's exciting.
Dave Thomas recommends learning a new language every year. "Manager-speak" certainly qualifies as a language (and a "programming paradigm") all its own. And just like other languages, I've started to notice some neat hacks as I've been learning this one. Hence the point of this blog.
I also get to still write code, thankfully... which is mostly a mad scramble to keep up with my team technologically, since I only get about 50% of my time (in a good week) to spend on code rather than on management, and that number looks to only go down as I advance. Not only am I no longer the best developer on my project -- any project -- it's now very important that I not be, because I'm going to be away from the code at least half the time, and can be a significant roadblock if I'm the information silo. Thankfully, I was clueful enough to hire the best people I could find. We're doing some really cool things technologically, and it's really a fun project to work on.
Anyway, welcome to my shiny new blog. Isn't it shiny?
Subscribe to:
Posts (Atom)
