Software Crastmanship in the Enterprise

[Paul Wallace]

Hi Sandro

I came to know your work through some of the screencasts you posted on youtube, these are great.

Do you have any tips on how to promote software craftsmanship in an enterprise setting?

One of the concepts I've used is to refer to software craftsmanship in terms of internal quality - as described by Martin Fowler: http://martinfowler.com/bliki/TradableQualityHypothesis.html
This is useful as it creates a parallel with the developer world of testing and the QA/UA world of externally visible testing.

However it is as much a problem to convince developers, who are set in their ways, as it is to convince management of the benefits of a software craftsmanship approach.

Paul;

[Junilu Lacar]

Allow me to share my experience...

I work for a large, publicly-traded enterprise in the IT industry. I'm not just an IT guy; I'm an IT guy in an IT company that is on the Dow 30.

As you can imagine, there are countless development teams in my company all over the world. There are good teams but they are far outnumbered by bad teams. Rather, I should say, there are teams that perform well but there are seemingly more teams that perform rather poorly. Even in my group of about 200+ people and dozens of development teams, the majority of these teams perform quite poorly. They are constantly moving delivery dates, always dealing with quality and testing issues, and have very poor engineering practices.

My formal title is Technical Leader. That puts me at the level of line managers and I have several peers who are line managers. It also puts me in a position of influence, albeit somewhat limited. I am also a remote worker. I work from home in the US Midwest whereas the bulk of our engineers work out of our corporate headquarters in Silicon Valley.

You'd think that with the kind of isolation and limited circle of influence that I have, there wouldn't be much that I can do to promote software craftsmanship. That's not quite true though. I started out teaching my immediate team about Agile and TDD. We adopted practices that addressed both sides of the coin: process management and improvement, as well as engineering practice improvement. I joined a grassroots effort to promote Agile methods at on company-wide level and we organized and hosted an internal conference that we dubbed Agile@(ourCompany). We even had Mary Poppendieck as a keynote speaker address a roomful of engineers in California from a living room in Norway.

We formed interest groups and set up mailing lists. Slowly but surely we recruited more advocates and started holding regular virtual meetings and having different people give presentations. We sent people to the annual Agile 20XX conferences and had them share what they learned from there. It was going great. For a while I thought there was hope. But then stuff happens. People move on or leave the company. The momentum and synergies that we had so painstakingly developed over a few years quickly petered out. This year we didn't have an Agile@(ourCompany) conference. It kind of makes me sad to think about it, actually.

On the bright side, my group of 200+ people has been plodding along with this group-wide "Agile Transformation" program that I helped start some two years ago. I have been asked to give another TDD workshop in California, this time expanded to a full two days (prior offerings of my workshop were only one day affairs) of hands on exercises and collaborative learning. After all that, the bottom line is that you need enthusiastic and vocal champions. And you need people who can lead by example. I had the support of my boss' boss, who championed the group-wide Agile Transformation effort. But most of all, I had the support of my wonderful boss, who said to me when I joined the company in 2006, "Just do what you need to do and I'll make sure you have what you need to get other people to do it as well." I think the secret to being able to influence other people lies somewhere in there.

I know, you asked about software craftsmanship, not Agile, and there may be some subtle lines of delineation between those two but to me, they go hand in hand.

[Sandro Mancuso]

Paul Wallace wrote:

I came to know your work through some of the screencasts you posted on youtube, these are great.

Thank you.

Paul Wallace wrote:

Do you have any tips on how to promote software craftsmanship in an enterprise setting?
...
However it is as much a problem to convince developers, who are set in their ways, as it is to convince management of the benefits of a software craftsmanship approach.

Promoting Software Craftsmanship in an enterprise environment is almost impossible if they haven't embraced Agile yet. I don't mean that the company needs to be truly Agile. I mean having the willingness to adopt Agile values and practices.

Normally Agile transformations come first. They increase the business appetite for a better process, a short feedback loop, and a quick return on their investment. Agile processes also help to increase the visibility of things that are going well and the things that are not going so well.

Once this "appetite" for improvement is there and they gave the first steps towards a more Agile way of working, embracing Craftsmanship values is less painful.

The second half of the book is dedicated to exactly that. I was hired by a major investment bank to help them improve the quality of their software, a few years after they started their Agile transformation. I spent almost 3 years there working in a global department where we had a good degree of success in embracing Craftsmanship values and XP practices. All the things I wrote on the second half of the book are things I tried at a large scale and some of them may be quite useful to you.

Bringing Craftsmanship to an organisation has many challenges and affects many different things: from how you write a unit test to how you re-engineer your entire global recruitment process; From creating a culture of learning to dealing with ivory-tower architects and managers. From trying to deploy software multiple times a day to adapting your practices to work in projects that are part of a 5 year initiative in a heavily regulated environment, where devs don't even have access to production.

I hope you find many tips in the second half of the book.

[Junilu Lacar]

I will go through the section about Ivory-Tower Architects later tonight. I'll just say a couple of things about them before I leave for a few hours to get some Work-Life Balance in by taking my daughter to her volleyball practice.

We all know who these guys are. We also refer to them as "Visio Architects" - the guys who spend all their "development time" creating Visio diagrams and looking for new technologies to put on their resumes. These guys annoy me to no end. I once told a room of engineers that to succeed in our Agile Transformations, our architects needed to start coding alongside the development teams at least twice a week. One very successful Agile group in our company that is based out in Boston, MA has exactly this policy. They have a chief architect who coordinates ideas and designs with the project architects and they all do code reviews and help with the coding at least two times a week..

When I mentioned the idea of architects coding with the developers, one such architect scoffed and said, "What?! That's a joke! How are we supposed to get our work done if we start coding?" This was also one of the guys who was very vocal about his objections to Agile.

Anyway, thanks again for joining us this week, Sandro, and I'll check back with you guys later when I get back from my daughter's volleyball practice.

[Junilu Lacar]

I just read through the whole section about the Ivory Tower architects. I wish we could have that same kind of conversation with our architects. My manager has made the same point about responsibility and accountability but to no avail, unfortunately. Sometimes I think about what Martin Folwer was once quoted as saying: "If you can't change your organization, change your organization." But I have the greatest boss and I work with some great people on my teams. It's tough to find these kinds of people and I'd rather stick it out with them and fight the good fight than jump the fence in search of greener pastures. There are a few to be found, supposedly, in my immediate area, but then again, I don't think they can match what I have right now, despite the knuckleheads we have to deal with once in a while.