Several years ago, a client, Alex, asked me, “What’s wrong with this team? They don’t want to learn anything.” I was surprised. I asked him for more information. “Well, when I ask them to use TDD, they don’t want to even learn about it. When I ask them to use CI, they don’t want to. […]
I’m a monthly contributor to the Gurock blog. This month’s article is Feedback & Feedforward for Continuous Improvement: Using Double-Loop Learning Challenges Our Assumptions. Single-loop learning is when you “Plan the work and work the plan.” Double-loop learning is when you challenge assumptions during the project. Agile approaches allow us to do so. This is the
Back in the ’90s, everyone was into repeatable processes for software. What that often meant was we were supposed to do all projects in exactly the same way, regardless of the type of project. We were supposed to document what we did and deliver the same documentation each project. It didn’t matter how much innovation
For me, writing has four main parts: researching or deciding what to write and organizing it, writing, editing, and publishing. You might think of these steps as analysis and design, coding, testing, and release. I like to keep my writing chunks small so that my editing occurs soon after my writing. Small chunks also means
Many people like to start the new year with resolutions. I’m not one of them. I don’t like resolutions unless they are very small action steps I can take every day. Too often, people select resolutions such as “Lose twenty pounds this year.” That’s big. It doesn’t have small things I can do each day.
I meet many people who are convinced there is One Way to Do Agile. Oh, and it’s the way they are using the agile practices. In their opinion, everyone should do agile their way. They believe that the kanban board is more valuable than a Scrum board—or the other way around. They believe that as
I see people measure all kinds of things in projects. Too often, they are single-point or single-dimension measurements. Those measurements don’t provide you with a good idea about the health of your project. They might be a start. However, they are insufficient. Imagine you, like me, would like to lose some weight. You weigh yourself
Several years ago, I had a senior VP as a client. He wanted his managers to work as more of a team. He thought they were not working together for the good of the company. I asked him why he thought that. “When they estimate, they don’t work together on an estimate. They each estimate
I spoke with a new manager, Drew, the other day. His days are full. He’s got tons of meetings. He tries to provide feedback and coaching to his team members, but he has crises up the wazoo. Drew asked for coaching: “I have way too much to do. I need to learn how to manage
I was thinking about the best projects and teams I know. They work in different industries and have different customers. Some are engineering teams. Some are IT. Some are agile; some aren’t. Some are in transition. One thing they have in common is that they are happy teams. If you asked them to show you