Daily Stand-Up Meetings

It’s my observation from watching small groups of people working together that it’s almost universally common that some people will take charge and direct the common effort and others will get quiet, abdicating any such role.

It’s also my observation that, even in a small team working together daily, people notice different things, interpret the things they notice differently, and assign different significance to those interpretations. People often think that because they are immersed in a common experience that there’s no need to talk about it. This appears to not be so.

Groups of technically oriented people often want to optimize the work process to those activities needed for the technically oriented output, and overlook those that are focused on the needs of humans and groups of humans working together. Yes, you can have a standup and not get any value from it. You can also not have a standup and avoid providing a convenient mechanism for taking advantage of the differences in observation, interpretation, and significance made by the entire team.

If you’ve got a really good team facilitator, they’ll likely notice this and help bring it out. If they’re really excellent, they’ll convince the team to work in a fashion where it can more easily come out without them acting as a middleman to make it happen. They might use a simple technique such as a daily standup to create such an opportunity.

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.