Category: Individuals and Interactions

Component Stewards

I’ve been an advocate of using feature teams instead of component teams for a long time. Back in the 1980s and 1990s, when I was working on embedded systems using 8-bit microprocessors, I often did both the hardware and software development. The easiest way I found to work was to develop both in parallel, adding complete functionality feature by feature. Working in this fashion also gave me great insight into choosing whether to implement a particular bit of logic in the hardware or software. Sometimes a software implementation could save a lot of expensive hardware, and other times a small bit of hardware could save a lot of software or provide better performance. Since I was working on both sides of the fence, I could easily move the logic from one to the other, sometimes changing my mind as I learned new information while implementing the functionality.

When working in larger teams, the work was usually split between hardware engineers and programmers. Occasionally I could influence a change in the hardware while working as a programmer, but not always. I really missed the ability to optimize across the hardware/software interface that I’d had when doing both sides.

When you scale up to large numbers of people working on a system, things can get out of hand, though. What happens when a lot of people make changes to the same components without talking with each other? Usually, the conceptual integrity goes out the window. So, what to do? Read More

Retrospective Principles

I’ve talked about the goals of a retrospective. Now I’d like to talk about four principles of effective retrospectives. I generally find that principles help me more to be effective while doing my work than do definitions. Principles help to connect the abstract to the actual practice.

One of the principles is that it’s important to understand the goals. If you don’t know where you’re going, any road will take you there. That road is, however, unlikely to be a retrospective. As a facilitator, I find the general goals helpful in planning a retrospective. I think that the specific goals are valuable to the participants, and generally discuss them as part of Setting the Stage at the beginning of the retrospective. As always, this is moderated by the understanding of the participants and the time available. Read More

Goals of a Retrospective

In my previous post, I talked about what a retrospective is not. Understandably, I got immediate questions about what a retrospective is. This post is a partial answer to that.

My current definition of a retrospective is “looking at the past to guide choices for the future.” That definition, however, is insufficient to offer guidance on making your retrospectives effective. It’s even insufficient to distinguish what I would call a retrospective to those who use the word for other similar or related activities. A retrospective is different from a “post-mortem,” a “lessons learned,” or many other forms of “process improvement,” but is often confused with these.

A retrospective should have a purpose. If it’s merely a formality, it’s unlikely to provide much benefit. Perform your retrospectives mindfully, thinking about your goals prior to the retrospective and choosing activities to meet those goals.

You may have many different specific goals for different retrospectives. Whatever the specific goals, the general goals of a good retrospective seem to fit three categories. Read More

The Wrong Impression about Retrospectives

People get the wrong impression about retrospectives. They read that it’s a meeting where you list what went well, what didn’t, and what you want to change. They describe it like this:

The Sprint Retrospective is an opportunity for team members to bring up anything about the Sprint they feel needs improvement.  For example, a team member might say he felt he had to complete work that should have been completed by another team member.  Or a team member might say she received emails constantly which prevented her from getting any work done….

Or like this:

The format is a discussion and brainstorming. The ScrumMaster facilitates the retrospectives and let the team choose what aspect they want to improve for the next Sprint. Because the team is very technical, most of the discussion revolves around improving engineering practices, i.e latest frameworks, continuous integration, BDD, etc. Improvements get accomplished. But the point is the team thinks that rather than allocating special time to do retrospectives, they said why can’t they just do that within the sprint? The team gets the idea from Kaizen that is implemented in Toyota where the team gather in an instance to find a way where they can improve rather than going to a specially allocated sprint retrospective. Read More

Post-Agile?

Seen on Twitter

“Most people doing Agile today are actually doing Waterfall with Agile terms. Agile is dead.”

There are a lot of people talking about “post-agile” now that the word Agile has been taken up by the masses, including those selling products and services with the word without ever doing what some might consider to be truly Agile. Read More

Safety Exercise

In my recent posting on Separate Retrospectives, I mentioned sometimes performing a Safety Exercise at the beginning of a retrospective where the situation was unknown or seemed a bit charged with emotion. I was asked about that exercise.

I use a simple poll of how safe people feel. I got this from Norm Kerth’s book, Project Retrospectives (page 110). Read More

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? Read More

Agile Planning Tools

One of the most exhilarating moments in my coaching career was when I entered the client team room one Monday morning to find they were pulling the cards and tape off of their backlog corkboard, and arranging it in a different fashion. I knew then that they had taken charge of their own process. That team became one of the best I’ve coached.

One of the low points was when several people, including a business analyst, product owner proxy, and the program manager, individually said that they couldn’t alter the “user stories” to cut across multiple components of the system because they were already in the computerized planning tool (and Word documents) and it would be too much work. That team did not appear to be getting much value from their “Agile approach” and had significant integration risk that was being studiously ignored.

One of the most frequently asked questions on public mailing lists and forums devoted to Agile development is “What Agile Planning Tool should we use?” There is always a chorus of answers touting this or that computerized tool, usually without asking any questions about the context. Is there one best tool? Read More