It’s a classic binary argument in the software development arena. Do you want developers to be specialists or do you want developers to be capable at almost any development task and specialized on a few. I’m borrowing the term generalizing specialist from Scott Ambler.

I completely buy the generalizing specialist argument. Agile methodologies assume anyone on the team can step in and help out say writing/reviewing a use case or troubleshooting the ant deployment task. On Agile projects a whole team of specialists makes little sense and sends you straight back to serial development. Instead of the team being able to self-organize, many of them end up waiting on dependencies from others. And because the specialists are the only experts in an area, they are unlikely to welcome much of a review process of their work since it’s hard for novices to review the work of an expert.

A classic example here would be breaking up a team into specialists on front end and back end development. Say the front end developers pretty much get there code in place with the proper validations and AJAX type features. Then they’re stuck waiting on the back end developers who are familiar with object relational mappers and other technologies. Then of course maybe you have specialist DBAs who are the only ones allowed to do database design so the picture gets even worse.

A conversation with our company’s architect brought this up. He explained to me that the thinking is that we’ll have a few specialists who can do business process modeling (BPEL) with WID (Websphere Integration Developer). After I pointed out that my thinking was a little different. He countered with the idea that as a developer he isn’t very good at GUIs, so he’d rather leave that to a specialist. He’s good at BPEL (true) so he should specialize on that.

The arguments pretty much come down to:

• Specialists have really deep knowledge that can be powerful.
• Vendors like IBM often sell the idea of having very specialized roles. (I’m sure this isn’t to reinforce having to buy lots of specialized tools. And it can’t be that providing specialized roles allows IBM professional services to charge a lot of layered rates for different consultant titles.)
• Waterfall methodologies or classic RUP assume teams of specialists. Requirements Experts to gather requirements. Architects to do a big UML design up front. Developers to just follow all the UML and pound out the code. (Oh, does IBM own Rational now?)

I buy the following arguments as being more likely to succeed in practice:

• Generalizing specialists don’t let the project sit there, they just pick up the ball and run with it. If the database schema needs to change they just change it, no waiting around for the DBA. Even though they may not be the perfect specialist to perform a task, by pitching in to do what needs to get done they keep the project on track.
• Generalizing specialists on a project guarantees at the end of a project multiple people know how the system works and can be called upon for maintenance or later enhancements. It avoids silos that kill many organizations.
• Generalizing specialists are constantly learning new things by virtue of not resting on a narrow specialty.
• Generalizing specialists are often good at mentoring or teaching others what they know.
• Generalizing specialists can often converse better with clients and customers because they do things like requirements gathering, testing, or project management even if it isn’t one of their few specialties.
• You can often run a IT project with as few as two generalizing specialist developers. Specialists teams often need a large amount of staff who can’t be dedicated to the one project.
• Agile really doesn’t work without generalizing specialists.

I still require on projects my developers work on that everyone is able to build an entire slice of the system from database to javascript effects on the front-end JSP. Most of them are better in one area or another, but they can all do any of them. I’m really not planning on changing this requirement even if a project involves doing some BPEL.

We have a really good assertive Scrum coach on site. The impact can be felt almost immediately. We had a PM who was learning how to be a ScrumMaster, but she really wasn’t getting any serious feedback on how to handle the nuances of Scrum. One day after our Scrum coach started working with her I got a phone call about 9am.

She wanted to know if we could get some help deploying to our Websphere QA server and who she needed to follow up with. I pointed her in the direction of one our sysadmins. The phone call was no big deal really, but it was the first time for the whole Sprint the ScrumMaster had taken on the responsibility for removing an impediment. Since our PMs are by default put in more of a project admin role, switching to the team protector as ScrumMaster is very different.

The nice thing is with just some feedback from our Scrum coach, this PM instantly became a lot more effective.

I was asked recently by my boss, the Assistant Vice President of Application Development to review and give feedback on the most important impacts of Agile good and bad.

Good Impacts

• All three projects had production quality software that the users could see after one month. Any other projects of this size would be lucky to have a rough draft of the BRD (Business Requirements Document) done.
• All three of these projects have no real issues with communication between team members. Even though friction between QA, developers, business analysts, and PMs is pretty commonplace on large non-Agile projects we’ve seen none of this on the Agile pilot projects.
• The product owners on all three projects are very happy with the process. They all feel that the feedback every 30 days is much better than our old waterfall methodology.
• The projects have very low defect rates and have had no significant bugs at the end of any Sprints.
• The developers on the projects are more motivated and engaged with their team. The teams are actually having fun with things like one ScrumMaster being rewarded by their team with a rugby jersey embedded with a ‘Scrum Queen.’ Employees are more motivated when they come in to work.
• The use case approach results in much better requirements than our vague BRDs.
• Project managers are able to really have an impact and add value instead of filling in as a project admin role.
• Tasks on a project are broken down to 4-16 hour chunks. This has been a big help in two ways. First, team members can really commit to measurable tasks that are complete within a day or two. Second, teams become get better estimates because their actually forced to break everything into atomic tasks and they practice estimating every 30 days.
• Agile is forcing the organization to examine dysfunctional processes. Delivering every 30 days forces reexamining some decisions that don’t appear to be adding value.

Negative Impacts

• One of the benefits of releasing earlier hasn’t been realized. Product owners are still holding off for all possible features before releasing.
• It’s still hard to handle all the requests for smaller projects and leave staff dedicated on Agile projects.
• For a period of time at least one project was able to avoid following the normal migration process to QA servers.
• The business may not be ready to take on the faster pace of change and decision making that Scrum drives towards.
• The adoption of the entire Websphere stack at the same time as adopting Scrum has meant a painful level of change especially for web developers.
• Scrum is often sub-optomized because people aren’t solely dedicated to a project, or good collocation space can’t be found.
• The pace of change has proved difficult for a few team members requiring some substitutions on projects.

I think it’s a pretty good list, but it worries me a bit that I can’t come up with more negative things, makes me think I just may be drinking a bit too much Kool-Aid.

One of the big advantages of Agile software development and Scrum is that you have potentially releasable software at the end of every 30 days. That’s been a really hard sell so far with our product owners.

I attended the Sprint review meeting today for a project that has two of my developers on it. The whole team did a great job and delivered a good chunk of functionality that’s already running on our QA environment. The project is building on an existing application and adds functionality they don’t have right now and compacts information from 3-4 mainframe screens into one web page view. My guess is it would save quite a few of our employees a good chunk of time right now.

It wasn’t really suggested, but our Agile consultant/coach and myself both asked if there was enough value here to release it. The product owner explained that they didn’t plan on releasing it on this Sprint, but that maybe in another Sprint or two. That’s actually really progressive in general for our organization.

My recent experience would suggest that we are adverse to releasing anything that doesn’t have every possible feature the customer imagined:

• We just launched a 9 month long project that could have easily been broken into 3 releases based on the features.
• Another Scrum project has been through 4 Sprints and surpassed the functionality of the applications it’s replacing after Sprint #2. They still have at least another Sprint before they can release. The last 3 Sprints are totally focused on an admin interface for configuration which approximately 1 user will use a few hours a month.
• We’re working on an intranet project that may be releasable with one more Sprint, but the customer is currently thinking of releasing it this summer or maybe even September.

Apparently one of our more difficult challenges will be moving people to ship early and often.

I launched a Basecamp project today. Nothing fancy, just a little project site for our company’s core values committee. Yes, we fall into the Ken Blanchard Managing by Values type corporation or at least we’re trying. Anyway I’m a sucker for trying to make things better over just complaining and besides the theme this year for our annual employee offsite was Teamwork.

So far the coolest feature is that Basecamp lists the people on the project by the last time they logged in so you can get a sense in real time if people are actually using it. They just tuck it away in the right column after you log in, but I really enjoy that feature. Anyway these things often end up not being used so much so we’ll see how this goes. Since the majority of the committee aren’t IT folks, I’ll be giving a 10 minute demo on how to use it. Seems a bit odd, but then I spend a lot of time using various web applications so much of it is second nature to me.

Anyway it’s free for a single project, so it’s a great way to try it out.