A video of a conversation I had with Esther Derby, Geoff Watts, Maria Mastarelli, Susan DiFabio and David Koontz at Agile 2012 has now been posted on the Agile Alliance website. In this conversation, we talk about organizational values and how that impacts organizational behavior.
Are your well-intentioned actions having consequences you don’t intend and don’t want? Read “Unintended Demotivation,” my latest article on Gantthead (free registration required).
Also, I don’t think I ever announced my previous article on Gantthead, “Better Success Across Large Projects.”
Diana Larsen first told me about the Where Are Your Keys language learning game that Willem Larsen and Evan Gardner were playing in early 2009. I was initially intrigued, but when I experienced it with Willem later that same year, I became enthusiastic. My interest lay not in learning languages, but in applying the same techniques and framework to teaching Agile techniques. I immediately began thinking how to make that application, and I’ve been thinking along those lines ever since.
Thus, it was with tremendous expectations when I saw that Diana and Jim Shore had published Your Path through Agile Fluency on Martin Fowler’s website. Having read it, I’m both greatly encouraged and slightly disappointed. Read More
Most metals have a bit of springiness to them. If you want to bend them to a certain shape, you have to bend them further than that. When they spring back a bit, they’ll take the shape you want.
Today, I was looking at a milestone chart for a project transitioning from a serial lifecycle to an Agile one in a large organization. At first, I despaired at the picture it painted. There are Requirements and Design phases for the release, and a “hardening sprint” before release. Don’t get me wrong. Things are much better than they were before the transition started, but there is quite a way to go before this effort reaches what I would call truly Agile.
Then it struck me. Read More
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
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
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
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
Asked on the Agile-Testing mailing list:
Lesson 136: Testability is often a better investment than automation.
(I’m quoting “Lessons Learned in Software Testing” by Kaner/Bach/Pettichord)
If anyone has practical examples of improving testability, I’d be very interested to understand, and grateful. Read More
This is an unusual topic for this blog. And a bold statement: It’s time for AOL to go out of business.
Why? Because they are an irresponsible participant in the internet community. They are damaging the internet. Read More