I recently had the privilege of facilitating a Birds of a Feather session at PDC. The title of our discussion was “Agile – Triumphs, Teams, Trials, and Tribulations” and really just provided an opportunity for attendees to share stories. The session was extremely popular. So much so, in fact, that a fire marshal showed up to remove a few people from the room.

Cool, eh? Here is that not-so-cool part.

About 35 minutes into this discussion, I realized I hadn’t heard a question or comment that wasn’t related to Scrum. I asked the room, “How many people are on an agile team that is NOT using Scrum?”

5 hands. Seriously, out of about 150 people of so. 5 hands.

What in the world?

Is this simply a sign that Scrum won in the marketing wars? Is this just because some people have heard about Scrum? What’s the root cause of this?

Is it the C-word (certification) that goes along with the 2 day CSM course proving you didn’t die midway through class? Is it the fact that there are some MS Press books on the subject? Is it the fact that there is a soon-to-be-released Scrum Developer course endorsed by Microsoft?

I am not bashing Scrum, but it certainly isn’t for everyone. In fact, I find that Lean with a Kanban system is typically far more effective in medium to small organizations. I am just incredulous that Scrum is so ubiquitous in the Microsoft-stack enterprise.

Scrum does not define agile software development. It drives me crazy to hear someone say, “We are doing Agile. We have Sprints and everything.” I assure you, dear reader, 2 week time boxes does not an agile team make.

The other thing that really fries my chips is that something south of 20% of people who profess to be using Scrum actually are doing so. I have seen so many ScrumBut implementations I have started to expect it in any company that claims to be using the process.

My standard advice for any team is to implement a process without modification for at least 3 months before they think they understand it ell enough to tune it to better fit their needs. Of course, no one does this because “we are different”.

Yeah, sure you are.

The bottom line was stated perfectly in the BOF session by Simon Bennett.

“Don’t tell me by-the-book doesn’t work without at least reading the entire book.”

Duh.

I have worked with Team System quite a bit and with alternatives just as much. With a lot of experience behind me on this, I feel confident I can make a legitimate case for using Team System in a small team.

I consider a small team a development organization of fewer than 10 people.

Some Context and Disclosure

• I am a Team System MVP
• I use Team System on a daily basis
• I use SVN+Team City on a daily basis
• I care more about pragmatism and craftsmanship than tooling, and that means focusing on how to use tools, not just the tools themselves
• I have been present on day one of a brand new team
• I have been in a team that has grown quickly over a short time

Focus on the Work

What happens when teams squabble about tools instead of just getting on with it? Lots of churn and wasted energy, is my experience.

I can report having seen small teams succeed and fail. The success or failure in both cases obviously has a lot more to do with leadership and business than developer tools, but I can also say the way companies approach developer tooling can have a lot to do with culture.

Any startup or small team simply must be focused to succeed. This can also be extremely difficult to achieve. A small team simply doesn’t have the capacity or depth to be distracted with issues not pertaining to delivering product. Paradoxically, team members are often wearing several hats. That is, everyone is doing a little of everything. That can quickly trend to entropy, because no one ends focusing on the work at hand.

The last thing I want to do on day 1 of a new team, or very often in a small teams, is visit tooling. Not deliberately making choices about tooling, though, will eventually bite you. Hard. How many of us are in organizations with over 2 brands of source control systems because new ones were added in an ad-hoc manor? I’ve been there. How many unit test frameworks are being used? I have been on a team that used 4 at once. Think that caused some problems?

As team lead, I care far less about optimizations of specific tools, and far more about a cohesive and fluid process enabling flow within the team. I care a great deal that there is a single source of truth for requirements and very little that we are using the coolest new unit test framework.

Often, focusing on work simply means implementing a system of tools and getting past the discussion. Have you ever heard developers purse fight over text editors? Now, there’s a constructive use of energy. The same thing can happen when geeks whip out their favorite source control, merge tools, unit testing frameworks, Visual Studio add-ins, logging library, laptop brand, or bug tracking system.

Point number one is let’s get past the time suck of the my-NAnt-is-better-than-your-MS-Build and just prescribe a toolset so we can get on with the real business of our team.

Team System is Like a Box of Tools at Sears

When I go to Sears and browse the Craftsman (or DeWalt) tools, I usually see some interesting little specialty tools. I might buy a funky swivel socket or a single ratchet, but I rarely browse the aisle with the large all-in-one kits. The reason I don’t browse the kit aisle is because my father-in-law bought be a basic Craftsman starter kit almost 20 years ago and my collection of tools has grown over time.

I don’t still have all of the tools in that original kit, but I do still have many of them. Further, my need for hand tools have gotten more specialized over time. Also, I am making a bit more money than I was when I married my wife, so I may spend extra for a special-purpose hammer rather than always relying on the one that came in the original kit.

Without that original kit, though, I would never have been able to even get started. No, it didn’t have every tool I would ever need, but it had almost everything I needed right then.

Team System is much the same. A team can absolutely hit the ground running with the rich toolset VSTS provides. Maybe you’ll augment the toolbox over time. Maybe you’ll even change tools (can anyone say [TestClass]?) but the kit that comes in the box really can provide most of what a small team needs to get going, and do it in a single solution.

That’s huge.

As soon as I start looking around to sub-optimize my hammer or my source control, I am going to start slowing the team down. GIT? SVN? PerForce? There are a ton of options for source control, each with their strengths and weaknesses. It’s freaking source control. Get on with it. I mean, how sexy can a hammer be?

It May Not Cost What You Think

You can buy a big toolkit at Sears for far less than it costs to buy all the tools individually. Further, buying the toolkit for the person without tools is a good move because they will have all the basics covered in a single purchase.

Craftsman Toolkits are a favorite gift of mine for graduates and newlyweds for this very reason.

Microsoft has the same insight that Sears had. If a person gets accustomed to Craftsman by selling the kit cheaply, they’ll be a customer for life. This is the exact idea behind the BizSpark program. If you aren’t familiar with it, BizSpark is a Microsoft program that allows free (that’s right, free!) access to all developer tools, operating systems, and other software for startups.

Is your company less than 2 years old? Do you make software? If yes, you qualify, I kid you not.

Integration Matters

Even if you are paying full price (which you shouldn’t :) ) I believe the value of VSTS is still there. The productivity loss involved in setting up a system of disparate and non-integrated developer tools is tremendous. I have been there and done that.

I know SVN is good. I know Team City is good. I also know that setting up a basic Continuous Integration build in Team System is stupid simple. And the real money shot comes with Work Item management. How many teams out there are using work item management systems or defect tracking systems they hate?

Well, we all are.

So, we may as well have one that works right in the IDE and allows me to tie check ins to work I am performing. The context switching that occurs in non-integrated systems of reporting, SCC, build, and work item management is HUGE. Huge! No really.

Get On With It

The people involved in the recent online Team System kerfuffle are folks I would consider in the top 1% of developer talent. Quite frankly, it makes a lot of sense to me that people at that level will have replaced their hammer from the kit with one that has an ergonomic grip.

That said, there are a lot of startups and small teams in entropy out there. For those folks, I firmly believe that standardizing on an integrated toolset for the development team is a bigger savings than “free like a puppy” solutions that can work well, but with more churn.

Now quit fussing about source control and learn how to use a decent ORM, people.

I have taken the time to study what Mr. Pettit proposes and to read some other opinions around the sphere. What I have found doesn’t jive for me all the way around.

To put it mildly, there are differing opinions on the ability to measure Agility with a maturity model. The most common rebuttal (rooted in Lean Thinking)  is we should “measure up” and simply evaluate Return on Investment (ROI).

Measuring Organizational Success

Human nature and then the stock market figured this out eons ago. How do we reliably measure an organization’s success in a free market? Profitability. Essentially, ROI.

Simple measurements like ROI look great on paper and are notoriously elusive to use in improvement because of the vast number of mitigating factors involved in deriving the final number. But it sure is tempting, so sayeth the Lean Thinkers.

In order to demonstrate ROI of a team, we simply look at cost and revenue directly attributed to that team.

Easy, right?

Not so fast, Gomer. What about the fact that what really happened during the year in question is that an aggressive sales team enables a boat load of sales of an essentially crappy product?

We all know that happens all the time. Billions have been made on spaghetti code while at least as much is lost on elegant solutions. So how do we define success?

Lean offers many other ways to view an organization’s effectiveness. Value stream, flow, ROI, Kaizen, and pull systems can genuinely eek every miniscule efficiency in your company. Indeed, in my opinion taking a holistic Lean approach in your organization holds the highest promise of making things better. But is this measuring Agile?

I’ll go with “No.”

Measuring Agility

Every since the first teams called themselves “Agile” and delivered in increments, business analysts  have been relentlessly following these teams around with slide rules and calipers measuring their excrement. Some of the first sessions I attended years ago at Agile conferences looked at varying models for measuring Agility and effectiveness of teams.

Q: Why so fascinated with measurement?
A: Because it is necessary to being taken seriously.

Many attempts have been made (many successfully) to co-opt Agility to mean something beneficial to the person using the term. In my mind the only true definition of Agility comes down to what we find in the original manifesto.

If we are to truly measure Agility, one must therefore be able to quantitatively measure the degree to which an organization holds true the Agile principles. To some extent, that is what Mr. Pettit’s AMM endeavors to do. After thinking about it, I must conclude that this is a fruitless and nearly hopeless task.

On a scale of 1-5 how much does your organization value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Well, that’s gonna be a tough nut to crack, isn’t it?

Measuring Craftsmanship

There is no question that the Agile movement has been pivotal in the evolution of software development. Both in methodologies (process) and in engineering (practices) we have evolved the software development field more in the last 10 years than the previous 30.

The most obvious effect for coders on the ground is in the practices side and includes subjects like Test First Development, emergent design, automation, Continuous Integration, and other practices that are inarguably good for teams to practice.

Thanks to some vocal proponents and notable cantankerous grouches (thanks, Uncle Bob) we are now starting to talk about these things as Craftsmanship.

So now the question becomes, can we measure craftsmanship? To this I resoundingly reply, “Yes!”

In fact, this has been done for thousands of years. We can point to any trade and see the evolution of the craft and the teaching of modern practices in it. An 18th century blacksmith’s apprentice had specific skills to master to qualify as a practitioner. Mastery of those skills is inherently measurable because they are skills, not art.

The guild model for craftsmanship just works here. Here is a fictitious scoring sheet for a blacksmith’s apprentice.

Is it really such a stretch to construct similar evaluation areas for software development? I think not. In fact, many are in existence today in the form of thoughtful job descriptions.

Although the skills desired and measured will undoubtedly be guild specific, there are fundamentals that shouldn’t be too hard to agree on.

Pick a Guild

The guild spats are (and should be) over the specific skills deemed important. Fine, let’s let the discussion spiral to that, but can we agree on some basics?

This is why I actually like the Application Lifecycle Management model proposed by Microsoft. I wrote about it here (and here), and have since used it to actually work with teams to better their skills. Sure, it is guild specific, but so will be many of the instruments to come.

The important thing is to use one, and to use it deliberately with a genuine Kaizen approach.

1. Pick a skill
2. Assess your proficiency
3. Make a decision to modify your behavior in a deliberate way
4. Perform this new way
5. Evaluate your skill level
6. Repeat

Simply put, we need these things as a way to make deliberate and lasting change in our skills, and to hold each other accountable for that advancement. I’m just saying.

Like It or Not, Tools Play a Role

Have you ever watched “The New Yankee Workshop”? If so, you’ll no doubt recognize that Norm Abram is a master craftsman. Notice anything else? The man has a different tool for every minor job in the workshop. Further, he has more than one! And he has mastered the use of each one.

Norm can obviously execute a tenon joint with perfection. Once those pieces of wood are joined, let no man break them apart! And watching the show indicates Norm has a preferred way to execute the joint.

He uses a $3000 table saw.

That doesn’t mean he doesn’t know the principles behind a solid tenon. In fact, he has probably carved many of them with chisels in the past. That doesn’t make his tenons executed on the table saw any weaker, though.

Given a choice, Norm chooses the tool he enjoys and the one that makes quick work of the job. He doesn’t need to carve the thing with a pocket knife every time.

Nor does a software guild member need to limit their mastery of a principle to always rolling their own. Indeed, tool mastery is significant part of the program.

Will the budding apprentice need to learn Make, FinalBuilder, MSBuild, NAnt, Ant, and Maven in order to demonstrate mastery of build automation principles? No.

But they will need to use something, just like Norm. And the tool they use will likely be a function of the guild. It will probably be the tool the shop steward already has laying in the corner. It is important to note that one need not master all the tools available for a given job in order to execute the job well. One must invest in a specific tool set on the road to mastery.

We’ll be comparing test frameworks and IDEs for years to come just as Norm surely argues with his cronies about the best chisel set. Just recognize the debate for what it is and move on.

Conclusion

We have the tools we need to move forward in front of us already. An Agile Maturity Model doesn’t resound with me as a necessary thing.

Using instruments of Lean as the rubrics for organizational improvement is sound. Further, there is more to come. We are really only getting started with Lean.

Using guild-specific instruments like Microsoft’s ALM assessment as a rubric for personal and team performance holds intrinsic value. Want different skills? Try a different guild.