Is your agile transition proceeding well? Or, is it stuck in places—maybe the teams aren’t improving, maybe the people are multitasking, maybe you are tired and don’t know how you’ll find the energy to continue. You are the kind of person who would benefit from the Influential Agile Leader workshop. Gil Broza and I co-facilitate. […]
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
Define Your Agile Success I bet many of you are working to use agile in your organization. Is your agile approach working for you? If you think you could use agile better, maybe it’s time to define what agile success means to you. Consider these three questions: What is valuable to us? How will we
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
I no longer offer this workshop. Please see Practical Product Leadership: Deliver Better and Faster with Continual Replanning Workshop for the updated syllabus. Does this describe your product ownership predicament: You are supposed to be the product manager, product owner, and business analyst. You might even juggle different responsibilities for multiple teams. You struggle to read
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