Dave Nicolette posted a relevant question to my short post on Deconstructing Manager One on Ones.

Ed, IMO PM and Scrum Master are really two roles and team members relate to the individuals in those roles differently. Even so, most companies today do not explicitly staff a Scrum Master position at all. Instead, the PM is expected to play that role in addition to the usual PM duties. There seems to be a natural tension between relating to a team member as his/her manager and relating to him/her as a process facilitator / agile mentor. What have you found most challenging in trying to function in both roles simultaneously for the same teams?

– Dave Nicolette

ScrumMaster is probably an actual position only at a handful of small companies and startups. My experience has been the ScrumMaster is often a repurposed project manager. That can work really well. Real project management involves closing the gaps for a team to give them the best chance of success. Unfortunately for PMs steeped in PMI, Scrum may be a difficult transition. Currently of our four semi-official ScrumMasters three of them are PMs and one of them is a functional manager.

None of our PMs are 100% dedicated ScrumMasters, but two of the former PMs are about 80% dedicated to their projects which is almost as good as 100% dedicated. I’m the ScrumMaster on one project and I’m about 20% dedicated which really isn’t enough to be fully effective. Still you have to adjust to circumstances.

So on my current Scrum project where I serve as ScrumMaster we’re tasked with putting together a content heavy Intranet portal. At the start of the project there were eight developers on the project and all but two of them reported to me. Currently there are five developers on the project and only one of them report to me.

As the functional manager I have a lot more control of resource allocation. This has resulted in rolling off the seven developers onto other projects. The developers were able to explain to me that they were frustrated by the lack of actual development tasks. As new projects appeared I took the opportunity to roll them off. Had I been a normal PM repurposed as a ScrumMaster that frustration would have likely continued as I would have been less likely to spin them off.

My biggest challenge is devoting enough time to the project. I’m certain the project suffers to some extent from my lack of attention. I take too long to remove impediments, because I spend 80% of my time on other things like one-on-ones, meetings on future projects, and fire fighting on production issues. Today I finally scheduled the Sprint Review meeting with about one week left in the Sprint.

Another challenge is that I can never be sure my team members are completely honest with me. If I’m failing as a ScrumMaster to remove impediments quickly, I think it’s really hard to tell your manager the brutal truth.

Sub-optomizing is par for the course, but I hope to eventually work through the issue by training up a few more dedicated ScrumMasters from QA, development, or even the remaining PMs.

I came across another reference to the Scott Ambler‘s idea of the generalizing specialist via The Earth is Flat. Apparently Gartner study defines versatilists as:

That begs the question: Just what is a versatilist? The Gartner study describes a versatilist by explaining what it isn’t, a specialist or even a generalist. “Specialists generally have deep skills and narrow scope, giving them expertise that is recognized by peers but seldom valued outside their immediate domain,” the Gartner study said.

Generalists have broad scope and shallow skills, enabling them to respond or act reasonably quickly but often without gaining or demonstrating the confidence of their partners or customers. Versatilists, in contrast, apply depth of skill to a progressively widening scope of situations and experiences, gaining new competencies, building relationships, and assuming new roles.

The term came out via Gartner a few year backs when the downsizing was still all the rage in IT. It doesn’t appear this has been taken up too much by the analyst world, and in general I think the idea of generalizing specialists is more descriptive.

These are the employees you want to hire or inherit.

It would appear that SOA is coming down off the hype cycle after a few years as the preminent buzzword. CIO magazine has a cover story on The Truth About SOA.

CIOs need to pursue an SOA strategy carefully because the service development and architecture planning pieces of SOA are distinct but not independent—they need to be considered and executed in parallel. Services built in isolation, without taking into account the architectural and business goals of the company, may have little potential for reuse (one of SOA’s most important benefits) or may fail outright. Grand architectural planning exercises may drag on endlessly, without providing any real business benefit.

It’s nice to see a fairly conservative IT magazine like CIO mention that the big up front SOA design isn’t likely to work. We’re still grappling with SOA ourselves as an organization. There’s been a lot of hype, a good bit of grand design, and as of yet only one web service in production. At the end of the day with product owners really involved in Scrum projects, they’re not willing to compromise all the effort involved to use an SOA style architecture on their application.

Rands in Repose has done a great series on Deconstructing Managers recently where he touches on one-on-ones.

Managers who don’t have a plan to regularly talk to everyone on their team are deluded. They believe they are going to learn what is going on in their group through some magical organizational osmosis and they won’t. Ideas will not be discovered, talent will be ignored, and the team will slowly begin to believe what they think does not matter… and the team is the company.

Stronger terms than I’d probably use, but after about 5 months now doing weekly one-on-ones with 8 direct reports I’m not about to stop doing them. I still learn things every week that I used to think I’d pick up on.

I sit in a cube in the midst of most of my team with the exception of a few who are collocated on another project in another building. I often don’t find out how frustrated someone is with a particular technology problem or political issue until the one-on-ones. As everyone’s gotten more comfortable with them they’ve been able to explain why they’re frustrated and I can attempt to solve the problem.

Another thing I’ve noticed is several developers are realizing they can bring up questions around architecture and design in the one-on-ones and get my feedback. We’ve started to do more whiteboarding around how we’re architecting some of our web applications. That way they can check out their approaches on at least a weekly basis with someone outside the project team.

If you’re still debating getting started just do it. I stalled for at least a year after I ran across the idea of weekly one-on-ones.

About a week ago I signed up with our local Java Users Group to do a talk on Fitnesse, since they hadn’t been able to line up any speakers. The talk went fairly well and there were quite a few questions which is always a good sign. It did force me to bone up on my Fitnesse knowledge.

The community seems to be getting more sophisticated at least locally. In the open discussion things like AspectJ and profiling code came up. One nice thing was that many of the audience actually had some unit testing exposure. Many of them weren’t doing hardcore TDD, but trying to move in that direction. All told it’s a nice sign that unit testing adoption is picking up in the general java community.