A colleague asked me for some tips about writing. With hundreds of articles, blog posts, and 10 books, I know what works for me. I suspect some of these ideas will work for you, too. Tip 1: Write every day. Write for 15 minutes every day. This practice exercises your writing muscles. For me, it’s […]
I have several public workshops this year. I’m offering the Influential Agile Leader with Gil Broza April 6-7, 2016 in Boston and May 4-5, 2016 London. If you have not read some of my writing about leadership, take a look at these previous newsletters: ▪ Lead Your Agile Transition Through Influence ▪ Creating an Environment
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