I’ve said before that agile is a cultural change, not merely a project management framework or approach. One of the big changes is around transparency and safety. We need safety to experiment. We need safety to be transparent. Creating that safe environment can be difficult for everyone involved. John LeDrew has started a new podcast, […]
In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice. In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice. And, what if you aren’t doing Scrum, or you’re
Tom Cagley interviewed me a few weeks ago on his Software Process and Measurement Cast. It’s posted now, as # 180. When Tom interviews me, he makes me think. This is good. I would love to hear your comments about this one. We started with transparency and wove our way around to several topics. I
Using Checkins to Create Transparency Do You Want to Work More Effectively in Geographically Distributed Teams? In preparation for our geographically distributed teams webinar last week, Shane and I asked people what their greatest challenge was for their teams. Many of the comments were about communication and trust. One question was this: “How can I help
A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It’s not Scrum for these reasons: The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning
As a business owner, I have to remember to manage my own WIP, work in progress. Yves Hanoulle recently wrote about his own encounter with his wip limits, and what he decided to do it with respect to his “Who Is” series. When you are a manager, program manager, project manager—anyone who leverages the work
I prepare for my speaking and workshop engagements. This year, I’ve been all over the world. I’ve had a great time, and my clients and audiences have had a great time, too. Well, except for this past week at my session, “The Budgeting Black Hole: Predicting the Unpredictable” at Agile 2011. There, I bombed. I
I love it when my readers challenge and question me. Thank you, Sam and Paulo for asking the equivalent of “Huh?” for Refactoring and Redesign are Different. You asked great questions. Let me see if I can answer. For me, the time issue is the lack of transparency about the time required to complete the
I’ve been working with people starting their transition to agile. They are all smart people—some of them scary-smart. And some of them are misusing some of the terminology. Some people are using the word “refactoring” to describe significant work, say, weeks or even months of effort of rework. Sorry, I call that redesign. To me,
I’ve been working with several clients on their transition to agile approaches to their projects. They all have a common state: Many features to implement Huge technical debt Many defects They want to get a handle on all the work they have to do. I suggested they consider three backlogs, making sure that for a