As more teams and organizations transition to agile, they discover something important about leadership. Leadership is part of everything we do in an agile project. It doesn’t matter if it’s development or testing, management or architecture. We need people with high initiative and leadership capabilities. That leads me to these questions: We need project management. […]
If you write as part of your job, I have a new online workshop starting in March. It’s Writing Workshop 1: Write Non-Fiction to Enhance Your Business and Reputation. Here’s the problem I see. You’re a consultant or other entrepreneur. You know you need to write to enhance or build your reputation. You see a blank
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
The big problem with hardware going agile is that the risks in hardware are not homogeneous. Hardware and mechanical engineering are on different cycles from each other, and they are each different from software. Even with each discipline, the risks are different when the teams collaborate together on one deliverable and when the entire program
Once you have a roadmap/product backlog for hardware, the teams need to know what to do and when. As a program manager, program product owner, or other interested party, you might want to know where the work is. The roadmap shows the big picture. The demos and team-based backlogs show the details and interdependencies One
I’m writing like mad, trying to finish the program management book. I’m working on the “Integrating Hardware” chapter. The problem is that hardware comes in several varieties: Mechanical engineering Silicon (part of electrical engineering) FPGA (which looks like software to me) Each component (yes, I do call these components) has a different value at different
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,
I spoke with a Scrum Master the other day. He was concerned that the team didn’t finish their work in one 2-week iteration. He was thinking of making the iterations three weeks. I asked what happened in each iteration. Who wrote the stories and when, when did the developers finish what, and when did the testers
I’ve been teaching workshops these last few weeks. A number of the participants think that they need to create great estimates. I keep hearing, “I have to create accurate estimates. My team needs my estimate to be accurate.” I have found that the smaller the work, the better the estimate. If people work as a team,
I’ve been traveling, teaching, speaking and consulting all over the world. I keep encountering managers who talk about the “resources.” They mean people, and they say “resources.” That makes me nuts. I blogged about that in People Are Not Resources. (I have other posts about this, too, but that’s a good one.) I finally determined what