Thinking About Servant Leadership and Agile Project Management

For many people, agile means an end to all project management. I disagree. I find value in servant leadership in project management. I explain how you can think about servant leadership and agile project management in my projectmanagement.com column this month: Servant Leadership: The Agile Way. If you are looking to increase your servant leadership and help your project team (or program), check out the Influential Agile...

Value of Burndown and Burnup Charts

I met a team recently who¬†was concerned about their velocity. They were always “too late” according to their manager. I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they “committed” to for each iteration. This is what their burndown chart looked like. A burndown chart measures what you have finished. If you look at their burndown, you can see there are times when not much is done. Then, near the end of the iteration, they finish more. However, they don’t finish “everything” before they run out of time. An iteration is a timebox, by definition. In this case, having to “declare victory” and assess what they were doing should have helped them. But, when this team saw the burndown, two interesting things happened. They beat themselves up for not finishing. And, when they didn’t finish everything, they didn’t always do a retrospective. In addition, the product owner often took the unfinished work and added it to the next iteration’s work. Yes, added, not replaced. That meant they never caught up. They tried this burndown chart next, to see if they could meet their ideal. They realized they were “late,” off the ideal line from Day 2. They felt worse about themselves. They stopped doing retrospectives, which meant they had no idea why they were “late.” A burndown emphasizes what you have completed. A burndown with the “ideal” line emphasizes what you have done and what you “should” be doing. I have used story...

Four Tips for Pair Writing

I am shepherding an experience report for XP 2016. A shepherd is sort-of like a technical editor. I help the writer(s) tell their story in the best possible way. I enjoy it and I learn from working with the authors to tell their stories. The writers for this experience report want to pair-write. They have four co-authors. I offered them suggestions you might find useful: Tip 1: Use question-driven writing When you think about the questions you want to answer, you have several approaches to whatever you write. An experience report has this structure: what the initial state was and the pain there; what you did (the story of your work, the experience); and the end state, where you are now. You can play with that a little, but the whole point of an experience report is to document your experience. It is a story. If you are not writing an experience report, organize your writing into the beginning, middle, end. If it’s a tips piece, each tip has a beginning, middle, end. It depends on how long the piece is. When you use question-driven writing, you ask yourself, “What do people need to know in this section?” If you have a section about the software interacting with the hardware, you can ask the “What do people need to know” and “How can I show the interactions with bogging down in too much detail” questions. You might have other questions. I find those two questions useful. Tip 2: Pair-write I do this in several ways with my coauthors. We often discuss for a few minutes what we want to...

Taking Requests for New Edition of Manage Your Project Portfolio

I am about to update Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects to a second edition. What would you like me to add? To remove? To change? What have your challenges been about project portfolio management? Here are things I’m planning to add: Many more kanban views of the project portfolio and some words about visualization. Discussion (or more than one) about Cost of Delay. How a project’s product backlog is not the same as an organization’s project portfolio. More discussion about what you optimize and why. What else would you like to see? Please either comment or send me email....

How Long Are Your Iterations? Part 2

When I teach agile, I explain I like small and short stories. I want to see value in the product every day. Many developers can’t do that. That’s because they have interdependencies with other teams—not developers on their team, but other teams. They can’t implement in the way the picture next to this shows: small, coherent slices through the architecture. Instead, they implement in curlicues. When you implement by curlicues, you often have to wait for other teams. You might have component teams. You might have performance teams. But you can’t implement in nice “straight” features. Your features are complex and don’t take a straight line through the architecture. When I work with people who have curlicues instead of straight lines through the architecture, I often discover that the different teams can complete parts of features in one iteration. (It doesn’t matter how long the iteration is.) But completing an entire feature? Because that takes the efforts of several teams, the team members believe they have interdependencies and the full feature often takes longer than one iteration. The teams are correct. They have interdependencies. Sometimes, those interdependencies are quite difficult to see when you start. You only know that they exist when you get stuck partway in the feature. Implementing by curlicue creates delays. The iteration is not the two weeks, three weeks, four weeks. No, the iteration can be as long as eight, nine, or ten weeks. That’s because each piece of the curlicue has to get to the top of each team’s backlog. The teams might have different product owners who don’t realize each arc of the...