Taking the Long View in Software Development

My article, Taking the Long View in Software Development, has been published on ProjectManagement.com. Free registration is required on that site.

Dysfunctional Commitment

Team commitment is a wonderful and sometimes fragile thing. Many responses to my description of it are indications of how frequently the word “commitment” is used in a dysfunctional manner. Indeed, the post was prompted by similar conversations.

Believe me, I’ve seen these dysfunctions many times. They are so numerous and varied that no catalog of them could be complete. It’s not the word, commitment, that causes the problems, however. And avoiding that word will not solve the problems. Instead, we have to look at the behavior and attitudes behind the problems in order to reliably recognize them and choose strategies for correcting them. (Continued)

Team Commitment

Most Scrum teams estimate their top priority stories, select those stories that add up to their historical velocity for their sprint backlog. Some teams simplify this by merely counting the stories, or using the mathematical reciprocal, cycle time. Others make it more complicated, calculating the effect of days off and other known distractions from the work.

However they calculate it, some people put a lot of faith in the historical data to guide the future. “It’s data,” they say, “it’s better than guesses and not subject to cognitive bias.” Not all data is easily measured and converted to numbers, though. Limiting yourself to this initial calculation is, itself, an example of anchoring bias. (Continued)

Adding a new team member

Adding a new team member to an existing team always introduces challenges. The introduction changes the makeup of the team, and if the team had jelled, it has to do so, again, with the new member.

Also, the new member has to learn about the team and its work. There are many tacit assumptions held within a team. It’s impossible to document them all and, even if you could, both reading such a document and keeping it up to date are daunting herculean tasks.

So how do you maximize the integration of a new team member with a minimum amount of work?  (Continued)

Lessons from Sailboat Racing

Recently, I was attending a sailing seminar on racing small keelboats. As the lecturer talked about the crew requirements for winning races, I noted a lot of similarities with effective software development teams. Both situations require a small group of people to work in coordinated concert to achieve a common goal. No one on the team succeeds alone–they all reach the finish line together. There is a mix of specialized skills and general work that almost anyone can do. And there is a constant need for improvement, coupled with a desire to go fast. (Continued)

Separate Retrospectives

I was talking recently with a friend about separate retrospectives for sub-groups. They were worried about thing devolving into separate silos, with a retrospective for programmers, a retrospective for testers, a retrospective for analysts, …. I would be worried if that happened, too, but I can see value in separate retrospectives. How can we know when they’re appropriate and when they’re not? (Continued)

Specialized Skills

Whether we’re talking about revolutionary new web services, IT systems to automate internal procedures, or products to sell in boxes, there are many different sorts of things that need to be done. We need to envision the product, decide what’s required to be done, design it, build it, make sure it works, and put it into production where we can reap the benefits. Except in the smallest of circumstances, doing all of these things requires the work of multiple people. And, given that we need multiple people, and that we need a variety of skills, it’s natural that some people specialize in some thing and others specialize in different things.

But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. (Continued)

Simplicity and Perspective

Everything should be made as simple as possible, but no simpler. — Albert Einstein

Dave Rooney recently bemoaned on Twitter about how complicated people make things, pointing in particular to a thread on the scrumdevelopment yahoogroup.  It’s a thread that started with a question about a team wanting to adjust the Sprint Backlog in-sprint when something changed about their capacity to complete the work.  From there it spawned a long discussion about various ways to estimate the work and commit to it.

To me, most of these approaches to estimation are more complicated than is necessary.  Some go into detailed calculations that are far more complicated than what most teams do.  I could tell you a really simple technique, but I suspect most teams aren’t ready for extreme simplicity, yet. (Continued)

Agile In 6 Months

How long does it take to take a team from where they are to becoming an Agile team?  Of course, that depends on many things, including where they are and how badly they want to succeed at Agile.  It’s reasonable to think they can make a transition in six short months.

If you’d like your team to become Agile, give me a call to find out how I can coach the team to do that for about the same cost as contracting a senior developer.  If your team has already made a transition, but you find that you’re not as effective with Agile as you’d like to be, I can coach using the same framework to help you reach that effectiveness.

Distributed Development

A recent post on the scrumdevelopment yahoogroup got me thinking about the age-old problems of distributed software development.  The author of the post described having a Product Owner in California, developers in CA, TX, NC, & India, and QA in India.  (No mention if all of the workers in India were in the same place.)  I’m not picking on this individual.  I’ve heard similar stories many times.

It reminded me of something I’d read in Martin Fowler’s book, Patterns of Enterprise Architecture.  On page 88, figure 7.1 shows a common but distressing architectural design of distributed objects.  In the diagram, the components for Invoice, Customer, Order, and Delivery are each deployed to separate machines.  Why do it this way? (Continued)