Scaling Agile and Lean to Programs Using agile or lean for one project can be a challenge. What happens when you want to extend agile or lean to multiple projects or across the organization? Many people try frameworks. Frameworks assume you have the same context and challenges as other efforts–even inside your organization. You have […]
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.
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
A couple of weeks ago, I had a great time participating in the Agile in Large Enterprises panel, a part of the Continuous Discussions (#c9d9) that Electric Cloud hosts. Here’s the recording: We discussed these questions: Why agile in large enterprises and what are the challenges? Where should you start? Centralized? Decentralized? Where should agile
The discussion to now: Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability When you move from resource efficiency (experts and handoffs from expert to expert)
This is the next in a series of posts about resource efficiency vs. flow efficiency… Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability: Accountable to the project for finishing their own work Accountable to their team for participating fully by doing their
Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System explains resource efficiency and flow efficiency. Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People explains why flow efficiency helps you get features done faster. Here, in part 3, I’ll address the performance management question. New-to-agile (and some experienced) managers ask, “How can I manage