Gary Allison's Leadership Blog

Ok, so your want to startup or install self-directed teams.(see a previous post on change). As with any change, this is a big challenge and there is no guarantee that it will be accepted completely by the team. Some will be uncomfortable with accepting accountability, a strong Scrum master will be needed, and some just don’t like having to fit within a structured process. In our adoption of Scrum, a few things have helped us gain acceptance:

Training We are fortunate to have a certified Scrum Master on board who has trained the whole team. A full day of training was invested in every member of the team. Additional training is needed for Scrum Masters because their execution needs to be effortless for the process to flow.Executive Buy-in and Support All levels of management must support the process. The integrity of Sprint content must be held in tact for the process to work. During the sprint, business needs sometimes require us to trade Sprint tasks for backlog items, but the integrity is maintained if the team signs up to the change.Strong Leads that are Willing to take on Scrum Master role this process of self directed team still requires someone on the team to drive the process. In my experience, a strong and effective lead developer is one of the most rare and valuable commodities in the Software Engineering world.In short, the only mistake we have made with Scrum is not more quickly adopting the process everywhere in the team. At the end of the day, team success is the greatest motivator for this or any other change.

About 18 months ago, we adopted a self-directed process called Scrum in part of our development team – the part that focuses on end user applications.  Most of the team was a little apprehensive, but they are solid folks and they put it in action. 

 

Recently, we made the move to transition the whole team to Scrum, something I should have done long ago.  Initially, I believed that complex pieces of server-side software had longer life cycles, longer testing cycles, and therefore perhaps the Scrum process wasn’t a good fit.  I was wrong.  What we could have seen are the same benefits on the server-side that we’ve seen on the client.  So, now we are rolling it out team-wide.  So what are some of those benefits?

 

The most important benefit is the placing of ownership where it needs to be – at the team level and ultimately at the individual level.  Whether they are taking a turn at Scrum Master, or just part of the team, each person owns reporting on their progress, the whole team owns the sprint backlog delivery, and has the power to say no to things not in the Sprint.

 

Team planning and ownership of the deliverable by the team – each Sprint (we use a month), the team signs up to a number of developer days, test days, and Tech writing days available.  We estimate the line items in the backlog and allocate the available days.  Its all team driven, and as such, the team owns the plan for the Sprint delivery.  In addition, the team demonstrates the deliverable from last Sprint – a powerful way for them to show accomplishments.

 

Peer-to-peer accountability – another significant benefit.  With Scrum, there is no place to hide from missed deliverables, poor quality, and lack of skill.  Any team member can take any item of the backlog and work on any piece of the system. As such, Scrum breaks down artificial barriers.  And, with daily scrum meetings on what was accomplished and planned for each day, it is pretty easy to tell if someone isn’t pulling their weight.

 

Forcing the business to define priorities – Scrum forces a booked plan, reconciled to business priorities at the beginning of each Sprint, monthly for us.  It provides a systematic way to pull in all the business inputs (sales, marketing, support, et al) into the planning process – and enforces that this is there only chance to get input into the development cycle until next Sprint. (Not really of course, but it does force the conversation.)

 next Blog…. Success Criteria for Adoption of Scrum

The Second Law of Software Dynamics:  shipping software is a commitment, not an event.

Customers generally expect once they have adopted your software or service that you are going to continue to develop it, service it, respond to their requests for tweaks, and keep up with competitive forces.  In short, they made a commitment (time, dollars, training, or perhaps a key part of their business) to you, and they are expecting the same.

Yes, this applies to Web 2.0, SAS, and whatever the new paradigm of the day is. It is all just software in different cloth. It may be delivered in a different way, or have a new business model attached, but the commitment remains the same.

(What is the First Law?  Given any non-trivial system, as long as you test software, you continue to find bugs. I need to blog on when is enough, enough someday soon)

Do you watch Dirty Jobs on Discovery Channel? I have to admit, I think I’m hooked on this show. It might be the deadpan delivery of Mike Rowe, or could it be somewhat deeper? As a leader in software development, sometimes you can feel like the star in the PigWrangler episode (and no developers are not pigs). Bear with me as I take metaphorical license… Sometimes you have an uncooperative environment, and after the product goes to market, well, theres just a lot of poo to clean up. And, boy is there poo! Well, you’d just have to see the episode.

 In fact, the poo theme seems to run through many of the Dirty Jobs episodes. At the end of the day, in the midst of all the poo, there is a successful business. Art imitates life again.  In software development, there is more than a fair share of poo – changing requirements,customer promises of features that don’t exist, missed sales targets, layoffs, inept people at all levels (yes executive management too), pass-the-buckers, slackers, hackers, you name it. Face it – on any given day, we are all capable of poo. Still, out of all this comes innovation and products that people use every day. For many of us, this makes the job worthwhile, even when it’s a Dirty Job.