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 weeks ago, the nice folks at FogCreek interviewed me. It’s here: Technical Hiring and Cultural Fit – Interview with Johanna Rothman. The interview ranged over many topics: Cultural fit Diversity What to do when you look for a job Much more I hope you enjoy it. If you want to read more about how
Agile 2015 was the week of Aug 3-7 this year. It was a great week. Here are the links to my interviews and talks. Interview with Dave Prior. We spoke about agile programs, continuous planning, and how you might use certifications. I made a little joke about measurement. Interview with Paul DuPuy of SolutionsIQ. We
, In my session at Agile 2015, (Agile Hiring: It’s a Team Sport) one participant asked me if I hire contractors the same way I hire employees. I do. I use the same approaches for reviewing resumes, phone screens, interviews and decisions. The one difference is the offer—instead of a yearly salary paid in some
If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas. You have a couple of preconditions: The teams get to done on features often. I like small stories that the team can finish in a day or so. The teams continuously integrate their features. Frequent features
A cargo cult occurs when people adopt rituals expecting some good behavior to occur. They really don’t know why they are doing these rituals and don’t understand the reasons behind them, yet they keep doing the rituals expecting great results. In this article, I’ll give two contrasting examples that I’m familiar with: Project A talks
I’m working on the program management book, specifically on the release planning chapter. One of the problems I see in programs is that the organization/senior management/product manager wants a “commitment” for an entire quarter. Since they think in quarter-long roadmaps, that’s not unreasonable—from their perspective. There is a problem with commitments and the need for
In agile, we separate the Product Owner function from functional (development) management. The reason is that we want the people who can understand and evaluate the business value to articulate the business value to tell the people who understand the work’s value when to implement what. The technical folks determine how to implement the what.
The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management. I hope you like the information there. If you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta now.
Ryan Ripley “highly recommends” Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. See his post: Pragmatic Agile Estimation: Predicting the Unpredictable. He says this: This is a practical book about the work of creating software and providing estimates when needed. Her estimation troubleshooting guide highlights many of the hidden issues with estimating such as: