David Starr

Soft Skills are Actual Skills

2010-03-04T15:15:26Z

Adam

I will never forget my first day at my first programming job. I was excited, eager, and happy to be there, feeling like I had finally made the big time. I thought, “I am going to get to be a real software developer,” and I was stoked beyond belief.

In the elevator on the way up to meet my new boss, I stood with an older, grizzled and tired looking man. I was chatty and excited, and tried to strike up a conversation. I told him it was my first day.

“F%@! you, new guy,” he said as the elevator doors opened and he strode off into the hallway. I was stunned. I stood there dumfounded long enough that the elevator doors began to close before I remembered to walk out.

Over time, I got to know Mr. Elevator. His real name was Adam and like so many people that we tend to make excuses for, I can tell you that Adam wasn’t so bad once you get to know him. In fact, after some time, Adam became something of a mentor to me technically and I worked alongside him learning a lot as I did so.

Professionalism Isn’t Just in Your Code

My introduction into the world of work and many subsequent experiences all conspired to teach me that acting like an a-hole was absolutely accepted in the subculture of software development. I struggled for years in other organizations when I carried those behaviors to other employers.

Over time, I learned not only is this ridiculous, but that this institutional acceptance of unprofessionalism has contributed significantly to the negative perception many people have of our profession. Tolerance of behavior like Adam’s is pervasive in our industry and is often dismissed as “Oh, those pesky developers”.

You want to turn IT from a cost to a value center in your organization? This is where you start. I learned a lot of terrible behaviors from Adam and it took years to replace them with new ones. The good news is that it can be done and the way to do so isn’t a big mystery.

It’s Like Learning a New DSL

I struggled for a long time until learning that soft skills are, in fact, skills. That means they can be taught, learned, dissected, studied, practiced, and honed. This was great news for me because unlike so many nuero-typicals I know, providing good feedback (as an example) doesn’t come naturally to me. People who share my tendencies toward autistic spectrum disorders often think that soft skills are a magical talent some people are born with. BTW: If you are reading this blog you have a good statistical chance of having at least mild Asperger’s Syndrome (it’s a super power).

Learning soft skills is like learning anything quantitative. For instance, you know how user stories have a little pattern? There are patterns to effective communication, too.

An Effective Feedback Pattern

May I give you some feedback?
Here is something you do well.
Here is an example of a behavior that could be improved.
Here is the negative effect of the behavior.
Express confidence in the person’s ability to improve.
What are your thoughts about this?

Example

Hey, Dave, may I give you some feedback?

Uh, sure.

You have some great development skills. Your OO skills are particularly good and it would be great if you could provide some design leadership to the team in helping them improve.

Being consistently late to the daily standup is hurting your effectiveness. When you are repeatedly late, it causes resentment in the team toward you. Ultimately, this undermines your own effectiveness as a leader.

I know you can do well at this if you choose to, but its up to you. What do you think about this?

It Actually Works

You may think this example is contrived and over-simplified. It isn’t. I have had this conversation and it really works. Books on the subject provide all kinds of reasons the formula works, but the bottom line is that there are patterns of human behavior and communication just like there are patterns of effective software development.

Now What?

If you care about any of this (and you likely wouldn’t have read this far if you didn’t) I think the best place to start is to do some reading about communication techniques. The cool part of this is that as you learn new techniques, you get chances to try them out on a daily basis, and not just at work. The world is a huge discovery spike for this kind of thing.

Here are some books I have found helpful.

The Software Craftsman Cooperative

2010-01-13T17:58:48Z

I am honored and proud to announce the establishment of a new organization of software professionals, The Software Craftsman Cooperative (SCC).

This organization is a cooperative of independent developers who either work for themselves or as members of a very small team, and embrace the principles and ideas of software craftsmanship.

The Story

The idea for the Software Craftsman Cooperative came from conversations I had with Ryan Eastabrook while on a contract in Portland last summer. Ryan and I pushed around the idea of a group of developers who trusted each other, could work together, and retain their independence. There is a group of professionals who prefer to own their destiny, and live the ideals of agility and craftsmanship. Wouldn’t it be great if those people could come together to create something bigger than any one individual?

This fall, I co-founded Guild 3 Software, along with Elegant Coders Jarod Ferguson and Jason Grundy. Just like with the SCC, we were a group of developers with a shared history and had great respect for each other’s work. We knew we could be better as a team than if we stood alone. The strong drive to make something better than any individual led Jarod and Jason to walk away from stable, well-paying jobs.

So far, so good.

Although we are busy with some great opportunities, we realize a need for a deeper pool of talent; but, we aren’t interested in growing into a large company with employees and it would entail. Instead, we want to work with other people bold enough and good enough to stand on their own as independents, as we are. We wanted to find a small group of developers we could trust and wouldn’t need to worry about when they were on our project. We take our reputation at Guild 3 very seriously, and we will not ship poor quality software. We want to align ourselves with others who share this value.

We at Guild 3 realize that a model like the one Ryan and I discussed has true merit.

So, what if we do something about it?

We have.

And it is a brave new world.

Why This is Good for Clients

Hiring consultants to create software is a risk. Plain and simple. According to the latest CHAOS report, 60% of software projects fail. With those kind of numbers, you need to work with people who give you the best chance of success. Your best chance doesn’t come from a group of entry-level programmers at a body shop you’ll never see. It will come from a group of highly seasoned professionals with shared, broad experience.

Some things about SCC membership:

Membership is by invitation only
Membership is subject to a vote of the standing members
Each member is an independent developer or a member is a very small consultancy, or software boutique

This is gold for clients. They can come to the SCC and know right away the membership page lists top-shelf talented developers and each member has a team backing them up.

There is no harsher critic of a developer’s work than other developers. Membership in the SCC means a developer has been vetted by peers, has delivered value on past projects, and practices our shared values.

Doing business with SCC members gives customers a great chance of success, because they are dealing with software professionals who understand how to deliver great things and have a track record of doing so.

Why This is Good for Members

As a small consultancy or individual contractor, it is almost impossible to find work as part of a larger team of skilled practitioners. Usually, if you are selected as part of a team, it is one assembled responsively rather than deliberately. That often means you don’t get to pick your teammates and worse, you end up in places you simply don’t want to be. The software professionals in this cooperative can now say, “I have a team I trust backing me up.” This allows any of the members to bid for larger projects and bring with them a team of mature and diverse craftsmen.

Think of the SCC as the exact opposite of assembling a large team of off-shore coders for your next project. This group of people know each other’s work, and are proud of their affiliations. We know that together we are better than any one of us.

Plus, as small business owners, we help each other with a shared knowledge around how to run a business. If it weren’t for others in the SCC, I would still be putting off buying professional insurance. Thanks, guys :)

Consider This

Many software developers live very content lives working in large corporations, or within smaller companies, and do some beautiful work. Software craftsmen can certainly be found among the halls of large enterprises. For those who fit this description and are happy with the lifestyle they have, I congratulate you for finding that thing that makes you content. For many others, there is a nagging question in the back of their minds, “Could I make it on my own?” That question ate away at me for years before I finally took the leap of faith required to try it out.

Hopefully, the SCC will inspire similar initiatives the world over. With more groups like the SCC, more developers might be willing to step out on their own because the risk will be lower. You can be part of something and still retain your independence. Maybe through initiatives like the SCC, software developers can start to take their careers back. Together, we can stand up and be recognized as the professionals we are, and stop sharing cube space with others whose drive may not match our own.

There are customers out there who value the higher quality we deliver, and in doing so let us live the professional lives we treasure, committed to craftsmanship and quality over mindless execution.

Our Values

All members are dedicated to working collaboratively with clients, which means alternative ways of doing business.

The Software Craftsman Cooperative members maintain the following values:

Working together produces better results than working alone
Transparent and collaborative client relationships are healthier than fixed bid contracts
Delivering business value does not always mean delivering lines of code
Deliberate action is preferred to reactive heroics
Well crafted software produces more value than utilitarian execution

Agile is Not Scrum, Part 2

2009-12-13T19:13:41Z

A while back I wrote a post entitled Agile is Not Scrum. Machiel Groenveld commented on that post:

There is quite a bit of frustration in this post. You say you’re not bashing Scrum, but you are bashing something, I can’t make out what exactly though.

This question has been percolating since I read it, and I think I have my answer. I get what is so frustrating to me.

The typical developer in a a small to mid-size IT department has more responsibility than simply writing code. He takes action when the network goes down. She gets called when the receptionist can’t “find her email”. This is just reality for many.

The Software Craftsmanship movement is about getting everyone, even these developers to care about quality and form. We can easily agree that it is a big win to move folks beyond drag and drop to deliberate software design.

I propose we stop dragging and dropping Scrum on these teams. Explore alternatives that may very well work better.

The Conversation

The situation is typified by a real conversation I had with a Guild 3 customer recently. It went like this:

Customer: So, my developers are telling me we gotta get some of that Scrum around here. Can you teach us that?

Me: Well, yes. I can teach you how Scrum works and how you could use it, but I don’t think that will help here.

Customer: Why not?

Me: Not to be cheeky, but this is our 3rd phone call and you’ve been late to each one. You haven’t been able to stay for the entire scheduled time in any of them, and you constantly describe your environment as “on fire”.

Scrum says that the Product Owner may not change her mind for 2 weeks or so. Even a week is possible, but you must allow the team to focus without changing your mind for some period of time.

Customer: You know me pretty well, I see (laugh). I can’t commit to a set of work for 2 weeks.

Me: I know. That’s why I don’t believe Scrum will work for you. Yes, Scrum works for those companies whose business is supported by the model, but that isn’t how you do business.

The core of Agile software development is communicating well with our customers, and delivering well-crafted software iteratively. If you buy into those ideas…

Customer: I do!

Me: Great! Then the only thing left is to find a structured way of developing software that supports your business. Trying to change your business to support a process like Scrum just doesn’t tend to work in my experience with an environment like yours.

Customer: I like that a lot. So where do we go from here?

Me: Let me tell you a bit about this Lean stuff…

The Reality

You may be tempted to be frustrated with the client here. You may want to say, “But, the way he’s doing business isn’t effective! Context switching is killing him!”

I agree.

I also recognize it is a long road from this situation to a Lean or Scrum-Driven organization. The most effective path to get there is hardly to say, “Well, the team needs you to commit to 2 weeks worth of work, so just do it.”

Even if he agrees, the more common causes of flaccid Scrum will remain:

No identified Product Owner other than a departmental manager or lead.
No consistently groomed and managed backlog. The team will end up having to define their own backlog.
No respect for iteration boundary

And the last ugly truth is that I don’t know these people’s business enough to say that their constant priority shifting is wrong! It may well be perfectly appropriate to their business. I don’t know enough yet to make that recommendation, I just know that there would be a huge cultural change needed to make Scrum effective here.

An organization trying to implementing Scrum is more often than not trying to change their existing culture to fit the process, rather than the process being flexible enough to accommodate the organization.

The Advantage of Lean

In my experience, sure signs of Lean being more appropriate than Scrum include:

The person who developed the application is responsible for keeping it running in production.
Software developers have duties that call them into tactical fire-fighting situations like bringing up a dead network, or troubleshooting an ailing Exchange server.
The organization does not think in terms of “Products”.

I think this describes many small to mid-size IT departments. When you are dealing with smaller teams, people tend to have responsibilities beyond just that of writing code.

This doesn’t fit well within Scrum. Although it can work, it is a constant discussion and point of tension rather than an an embraced situation. Lean allows us to embrace this reality.

The advantage of Lean is simple. Lean say’s let’s take what we are doing now, and make it better. Let’s identify what is working, and use it. Let’s find what isn’t working and change it. Let’s just embrace the reality of our organization and support the way our business needs to do business.

I don’t need a lot of $5 consultant terms like “Scrum Master” to help a team start becoming more effective almost immediately. We just look at what is happening today and how that’s going. Then we propose and execute small changes everyone can agree on.

This is often a palatable way to begin the transformation to a truly agile organization.

Conclusion

Introducing a team to Scrum when Scrum’s rules won’t be respected by the organization is a failure waiting to happen. Although a Scrum-driven organization is a beautiful and highly effective thing, it isn’t always possible due to conflicting needs and values of the organization.

Lean practices offer a viable alternative for many teams looking to adopt agile practices.

Introducing the Pluralcast

2009-12-04T18:57:23Z

One of the best things about being a developer is the opportunities we get to hang out with other developers and talk technology. Whether it’s hanging out for beers after a user group meeting, sitting around a restaurant table at lunch, or talking smack with each other while playing video games, it is always a good time. The way we tend to have these conversations is by telling our stories. It makes sense, given no two developer stories are alike.

That’s why I was delighted when Pluralsight offered the opportunity for me to talk to even more developers about their stories of technologies and developer practices. Not only will I be getting the opportunity to swap stories with developers, but we get to make a podcast out of it! I mean, what’s more exciting than talking tech? (I really meant that last bit.)

That’s the idea behind the Pluralcast, which came online today. The Pluralcast will be a bi-weekly audio show that focuses on a particular topic each episode, and shares stories from people with experience in that topic. This isn’t just an interview with the latest technology wonk of the day. The intent is to provide real world stories, some insight into the technologies themselves, and maybe a little guidance if you are thinking of trying something new.

The first 2 episodes are online today. Both are fairly light to get us kicked off well, but I already have plenty of stories on disk that get to deeper in technology. We’re going to be talking Silverlight, Agile, SharePoint, Data Access, Microsoft Research, language level features, and plenty more things in future episodes.

The best part is that you get to participate! If you are reading this, there is no question that you have a story to tell yourself. So, tell it! Or tell us what kinds of stories you are interested in hearing.

Every day we learn something is a good day, and I want the Pluralcast to help your day be a little bit better. So, check it out and see what you can learn!

Agile is not Scrum

2009-11-26T04:43:14Z

Most people who read this blog will not find the title of this post a revelation. I know firsthand, however, that this is not the case for many.

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.”

PDC Notes

2009-11-17T17:23:30Z

I am grateful to INETA to be attending PDC this year. Also, I grateful to Visual Stuart, who is letting me crash in his room. Turns out, I am a cheap skate I am sitting in the keynote on Tuesday and thinking about the week. In addition to the Wait? What Read More......(read more)

Why my Mom and Ted Neward Irritate Me

2009-11-09T06:56:31Z

My mother is a psychologist and recently visited me us here in Idaho. We spent some time talking about the psychology behind some agile practices. Pretty cool! Additionally, we ended up on the one mystery topic that has always eaten away at me. That mystery Read More......(read more)

On Software, Sewing, and the Craftsman

2009-10-29T20:23:09Z

My wife, Eleanor, runs a small side business making some extraordinary things with needles, thread, and cloth. She makes quilts, dresses, stuffed animals, clothes, and reupholsters furniture to round it off. She’s been honing her skills, trying new things Read More......(read more)

Introducing Guild 3 Software

2009-10-20T15:22:59Z

Three of the Elegant Coders, myself among them, have an announcement to make. Jason Grundy, Jarod Ferguson, and I have all left good, stable jobs to do something we’ve all wanted to do for a long time... We’re starting a software company! Specifically Read More......(read more)

Goodbye Team System. We Hardly Knew Ye.

2009-10-19T19:19:45Z

Visual Studio 2010 Beta 2 is available on MSDN this morning. It will be more widely available soon. With a new look and feel it is off an running. After working with it for awhile, I can honestly report that it is a pleasurable product to use. Much attention has been paid to aesthetic, and the customization story for products like ReSharper and Code Rush is even richer. This means that companies have a great platform upon which to make our favorite development environment dance.

One change we see as part of the Beta 2 drop is the exclusion of the term “Team System”.

That’s right! Team System is no longer going to be used as a product name going forward, even though all the favorite tools are still in the box. So, what’s going on here?

We’ve been struggling with the following product lineup for several years now:

Visual Studio Professional 2008 with MSDN Premium
Visual Studio Team System 2008 Development Edition with MSDN Premium
Visual Studio Team System 2008 Architecture Edition with MSDN Premium
Visual Studio Team System 2008 Test Edition with MSDN Premium
Visual Studio Team System 2008 Database Edition with MSDN Premium

There’s a mouth full, eh? Not so funnily enough, the more frequent questions I get from customers investigating Team System has been around licensing. Frankly, it is confusing. MSFT heard this loud and clear and has taken steps to rectify the situation with this release. Instead of continuing with the Team System brand, we’ll now be talking about fewer and simpler options for purchasing Microsoft tools.

Visual Studio 2010 Professional
Visual Studio 2010 Premium
Visual Studio 2010 Ultimate

OK, so fewer choices must be simpler, so what do I buy now? Well, this page shows the various tools available in the different versions. The truth is that there is still a decision process around what tools you want to pay for. Let’s take a look at just the testing tools available in Visual Studio.

	VS 2010 Professional with MSDN	VS 2010 Premium with MSDN	VS 2010 Ultimate with MSDN
Unit Testing (MS Test)	X	X	X
Code Coverage		X	X
Test Impact Analysis		X	X
Coded UI Test		X	X
Web Performance Testing			X
Load Testing			X

If I want Code Coverage, I buy Premium. If I want Load Testing, I buy Ultimate.

Hopefully this packaging will actually be easier to understand and digest.

Removing U3 from Your Thumb Drives

2009-10-03T18:31:17Z

U3 is a technology used install boot software on thumb drives. Companies use this to ensure that some little application will get loaded or something when you plug their thumb drive into your Windows machine. This can be a favorite move of vendors who Read More......(read more)

Team Build without Tests Lists

2009-10-02T19:40:04Z

Test lists drive me nuts. I recently recorded a screen cast showing how to pull of CI without the test lists. Here ya go! Here’s a link to the screen cast. Read More......(read more)

Healthy Team Habits with Team System

2009-10-02T19:36:21Z

I wrote an article recently for the Pluralsight newsletter discussing how to use a tool like Team System to drive positive organizational change. Here’s a pointer to the article. Read More......(read more)

Code Cast 32 – Tommy Norman

2009-09-30T06:10:00Z

At the Agile 2009 conference in Chicago, I got to meet some great people I’d previously known only in electronic form. Tommy Norman is one of those folks, as he and I have had many conversations on Twitter. Tommy is a System Architect at Compuware in Nashville, TN where focuses on Application Lifecycle Management. He is also heavily into Scrum, Team System, and the Nashville .NET User Group. When not working he enjoys being at home with his family of 5, playing guitar and baby dolls, and making music.

In this episode, Tommy visited with me about effectively applying Team System to some agile software development practices. This ranges from Continuous Integration to the tool aisle at your neighborhood Sears store, but I’ll leave that for you to discover.

Get the show here

Code Cast 31 – Agile for Families

2009-09-01T04:17:00Z

This episode is a recording I made during my talk at the Agile 2009 conference in Chicago. The session, “Agile for Families, Iterating with Children”, was surprisingly popular. In addition to the slides and the audio, I am including a link to the IEEE paper that went along with this session. That’s right! There is an IEEE paper about Agile at home. Awesome :)

The slides from the talk are available below. The slide deck I am posting here is a bit larger than the one used in the talk. These slides include some interviews with the Starr kids that were left out of the slides at the conference for time reasons.

This episode is less rocket surgery, and more brain science. I hope you enjoy the show.