Ever since I was on the Troubleshooting Agile podcast, I’ve followed Squirrel and Jeffrey. (I highly recommend their podcast.) Recently, Squirrel posted something fascinating on LinkedIn: Aim for a “single source of lies” about your business. That’s quite a provocative idea, especially when many of us persist in looking for a “single source of truth.” […]
How do you know when you finished a feature? You might have a checklist, to make sure multiple people looked at all the artifacts, and that everything is checked in. (This is easier if you work as a mob/ensemble, pair, or swarm.) In addition, a product leader might approve the feature. Finally, the team, a
Three Tips to Move from Agile in Name Only to Real Agility Several of you have written to me, asking about the problems you see. Your managers focus on certifications, practices, and vanity metrics—not real agility. The managers don’t understand how agility can help them. You see cargo cult agile. You worry that agility is
Shaun’s comment on Measure Cycle Time, Not Velocity suggested a team might be better off measuring both cycle time and velocity. Why? For two reasons: “Beating” the last sprint goal Assisting the PO in a forecast of when things might be done. Let’s examine these ideas. Clarify Story Points Why even bother with story points?
I’m not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes. (See Velocity is Not Acceleration.) Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish
I’ve met a number of agile coaches recently. They tell me they’re hired as Scrum coaches or as Scrum Masters. They see their job as “better Scrum.” It would be lovely if that was their one and only job. However, many of these coaches work in organizations just starting a cultural transformation. Even though the
Three Secrets for Improvement by Subtraction Too often, when we change something, we add to our established practices. However, many changes succeed only when you subtract something. What will you stop? Here are three questions you might consider: Who needs information in what form? Who needs to work together? Who needs the work? Secret 1:
I delivered a webinar called Agile Metrics for Team and Product Progress last week, thanks to the nice folks at Innovation Roots. I had fun and so did many of the participants. One person gave me a new saying about metrics (at the end, during the Q&A): Are you data-driven or data-informed? It’s such a great
Ryan Ripley interviewed me on his podcast, Agile for Humans 83 about Create Your Successful Agile Project. We had a blast. I didn’t stint on my opinions or on my experience with agile teams. One of those opinions was about teambuilding, which I wrote about in Creating an Environment of Teamwork. The other opinion (based on
See Your Agile Measurement Traps In honor of my new book, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, this is the second in a series of four trap emails, the measurement trap. Here are three common measurement traps: You/your management thinks velocity is a target or a measure of progress. Someone (often a