faded picture of luke
a semi-random photo | click for the full photo gallery
click to browse photos
homepage navigation

Luke Melia

Take Back the Web

A pleasant night of blog-reading and hacking turned sad and distressed when I read Kathy Sierra’s account of the awful threats against her. Warning: this is a disturbing read. But it’s real life on the web everyday. And it’s not OK.

When I was in college, my girlfriend was an impassioned feminist. One of the events she participated in every year was called “Take Back the Night.” It was a nighttime walk through the city of Charlottesville, ending in a candlelight vigil. The message was simple and clear: women should be able to safely walk the streets of the city after dark; there are places where that’s not possible, and we’re not going to stand for that.

I don’t know how it translates exactly, but we need a movement like that for the web. We need to demand a safe space for women and call out, expose and expel people who dole out threats.

A Management Design Guideline

My last post was about the benefits of a Development Manager collaborating with a Scrum Master to be more effective. It struck me this morning that this (and flatter organizations in general) follows the OO design guideline “Prefer composition to inheritance.”

On Technical Management and the Scrum Master role

A Scrum Master lets the technical manager use his or her skills more effectively, and mitigates the Catch-22 of technical management — promoting a strong coder to the point that he is no longer coding.

Like more and more software development organizations these days, my team practices a hybrid of Extreme Programming (XP) and Scrum practices. The blend works out quite well because Scrum is generally a management- and business-oriented methodology and XP is an engineering-oriented methodology.

Both approaches share the ideal of a self-managing team. The concept is that the developers have the best understanding of how to approach the work iteration-to-iteration, and they can organize themselves around that understanding better than a well-meaning manager who is less intimately involved with the work.

If you accept that as true (and I do), where does that leave the technical manager? Titles vary, but I’m specifically thinking about the person who the developers on the team directly report to in the org chart. Let’s call this person the Development Manager.

Many very good Development Managers in non-Scrum organizations are hip to the insights I described above. They realize that their teams are best qualified to make technical decisions. They know their team’s time is very valuable and that each developer needs uninterrupted time to get into the zone (either solo or with a pair) and get quality work done. Armed with this info, these development managers make themselves “servant leaders.” They dedicate themselves to “protecting” the team — making sure they never have to attend unnecessary meetings, are insulated from corporate politics, and don’t have to deal with issues like software licenses or faulty hardware.

This servant leadership I just described is defined in Scrum as one of the core responsibilities of the Scrum Master role. The remover of obstacles. Many XP projects have the role of Iteration Manager, which also shares this responsiblity.

So where does that leave our Development Manager? Let’s assume for this conversation that he was promoted or hired into this role after proving that he was a competent developer and had good communication skills. (For someone thrust into the Development Manager role with no hands-on development experience, I would suggest that servant leadership is probably the best approach, and that he might function day-to-day in the Scrum Master/Iteration Manager role.)

Here is my take on the appropriate responsibilities for the Development Manager:

  1. Managing a self-managing team mostly means getting out of the way. He or she must actively and/or passively empower the team to self-organize.
  2. Hiring is the highest yield activity of any manager, and is exponentially greater when hiring developers. He or she must pull out all the stops in hiring the best developers possible.
  3. Agile methodologies are team-oriented — the team works in pairs, shares code ownership, designs together, sets goals together, succeeds or fails together — but each individual is on her own life path. The Development Manager must connect with each team member as a person, support his personal and professional growth, help him discover how he fits into the team and how he can satisfy hist needs for personal recognition and achievement inside or outside of the agile process.
  4. It’s likely that the Development Manager also has some role in corporate and departmental strategy as part of the larger software development organization’s management team. Here his responsibility is both to help the overall organization define and achieve its goals, and also to help evolve an organization in which his team can execute, maximize its value, and be happy and healthy.

These are important responsibilities, but unless the team is huge or growing quickly, they don’t add up to a full-time job. Honestly, if it wasn’t for the fact that these 4 points are critically important, I would advocate eliminating the role. If possible, however, the Development Manager should regularly (as in most hours of most days) be part of the team and be a contributing developer.

This is a point of contention, to be sure. I’ve been told on various occasions that I’d have to let go of coding to be effective in my role. I think that’s probably true in teams without a Scrum Master. Bring in a Scrum Master, though, and the Development Manager is freed up to get closer to the people he is managing by rolling up is sleeves and being their peer in the self-organizing work of the project.

Thoughts, questions and alternate theories on the role of the Development Manager in Agile are welcome.

Notes: Reading this post from Rands in Repose helped me crystallize these thoughts. My mental model for my own work at Oxygen (managing a team of 5 full-time developers and 2 consultants) is that I’m 75% an indvidual contributor and 25% a manager. The freedom to focus in at a line-of-code level of detail for several hours a day would never be possible without my colleague Salim doing a great job as the team’s Scrum Master.

A Manifesto of Our Own

My colleague Ken shared the manifesto we came up with for our (still shadowy) project:

Building consumer software is a joyous and daunting challenge. We, software developers, owe Oxygen and Oxygen’s customers every chance at success. We believe success springs from the following principles…

Give it a read. I like this one because the tone is not just inspiring, it is also rough and uncompromising with the team (manifestee?).

Manifestos are fun, free, useful in carving out a domain and purpose in your organization, and a great guide post in case you get off track.

GoRuCo 2007 Speakers Feed

When planning to attend a conference, I think it’s useful to get to know the speakers via their blogs. To that end, I created an aggregated GoRuCo 2007 Speakers Feed [RSS] using Yahoo Pipes. Enjoy!

GoRuCo speakers announced

We’ve just announced the speakers for the Gotham Ruby Conference (affectionately known as “GoRuCo”):

  • Trotter Cashion – Contexts, mocks, and stubs, oh my!
  • Paul Dix – Categorizing Documents in Ruby
  • Jay Fields – Business Natural Language Ruby Systems
  • Jeremy McAnally – Going Camping
  • Jay Phillips – Adhearsion
  • Nick Sieger – JRuby: Ready for Prime Time

We’ll also have lightning talks open to conference attendees. It’s going to be a great day. My head already hurts — in a good way.

The GoRuCo site has more details about speakers and their talks and registration info.

Code Camp Wrap Up

I spent my Saturday at Code Camp NYC at Microsoft, and aside from getting no lunch because there wasn’t enough pizza, it was a pretty cool day.

I finally met Don XML in person and attended his talk on “Syntactic Sugar”. I liked his exploration of the language features of C# you can use to clean up your code. He covered indexers, implicit and explicit conversions, and operator overloading. The yield keyword was conspicuously missing, and he lumped in a lot of stuff that falls outside of my concept of syntactic sugar. Nevertheless, he delivered all the information with aplomb and had an excellent rapport with the room.

David Laribee’s talk on NHibernate, Domain Driven Design and TDD was interesting. He definitely tried to cover too much for the time allotted, but the clarity of the design he presented was compelling. And his slides were beautiful — great imagery.

Enough people, now including Don and David, have recommended the Eric Evans book that I’m going to have to read it. I suppose I’ve kept it in the queue because with TDD and BDD, I wondered if I really needed something else “driving” my design!

Watching Chris Donnan speak about Scaling Agile, I thought of my colleague Ken — Chris and Ken would get along well. Both seem to be good strategic thinkers that think deeply about the holistic dynamics of introducing agile into a business. Chris was not able to complete his presentation in his time slot either — the timing thing is not easy!

After watching other people eat the last of the pizza, I set up for my talk. In the presentation, refactored a simple application using some key WPF concepts and using dependency injection with Castle. I’ve never done a live-coding talk before and I was pleased with the results. I prepared each step of the refactor with notes and talking points in a binder which I flipped through as I went, and gave a great Resharper demo in the process.

The only bummer was that attendance at my talk was light — I think I had 15-20 people. I was up against Scott Watermasysk‘s “ASP.NET for Web 2.0″ talk and a TestDriven.NET talk, so people certainly had worthy alternatives. My topic “Supercharging the WPF Command Pattern with Dependency Injection,” was probably too esoteric for this setting. Considering people’s experience levels, an Intro to WPF or Intro to Dependency Injection might have been more useful in hindsight.

Anyhow, I’ll get a blog version of the talk up soon.

In the last two sessions of the day, my colleagues Wendy Friedlander and Oksana Udovitska led excellent sessions on “The Gentle Art of Pair Programming” and on Rhino Mocks. Their poise was excellent; their explanations creative and clear; and their enthusiasm contagious to everyone in the room. Instant stars!

LukeMelia.com created 1999. ··· Luke Melia created 1976. ··· Live With Passion!
Luke Melia on software development freelance web development how to contact me Luke Melia, Software Developer letters and more from my travels photo gallery personal philosophy