Architects as Servant Leaders

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. Do we need project managers? We need management. Do we need managers? We need architecture. Do we need architects? As with all interesting questions, often the answers are, “It depends.” What do those people do? How do they do it? In December, I gave a talk, “Agile Architect as Servant Leader” for IASA. That talk outlines some of the ways agile architects might work as servant leaders. See the slides: Agile Architect as Servant Leader. There is more about servant leadership in Agile and Lean Program Management, for program managers, program product owners, and architects. Here is the link to the recording: Agile Architect as Servant...

Want to Write Non-Fiction Better?

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 page (paper or screen), and you have no idea what to write. Maybe you can start, but you get 23 words in and get stuck. Maybe you get 5,000 words in, and you know there’s good work in there, but you can’t see it. If you would like to address these challenges (and more), and deliver non-fiction articles, blog posts or newsletters to your readers, this workshop is for you. You’ll learn: How to make writing a habit. How to structure an article that people want to read. Write articles or blog posts or whatever that engage your ideal reader and build your reputation. What writing is. What editing is. How they are different. How to decide when to place your writing where. You will write during this workshop. We will focus on short non-fiction, such as blog posts and articles. I am the only person who will read your writing. I have published over 500 articles and well over 1500 blog posts. I write two columns each month and two quarterly columns each year. (If you have ever been part of a critique group, you know sometimes they savage you with feedback. I won’t do that.) I am a professional technical editor, as well as a writer. I am focusing this workshop for people...

Taking Requests for New Edition of Manage Your Project Portfolio

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 and some words about visualization. Discussion (or more than one) about Cost of Delay. How a project’s product backlog is not the same as an organization’s project portfolio. More discussion about what you optimize and why. What else would you like to see? Please either comment or send me email....

Helping Hardware Be Agile, Part 3

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 has to collaborate to create a product. The engineering teams simulate to see problems in their own work and solve those problems. Each team is ready for integration at a different time. They can’t integrate until they go to fabrication. That changes the feedback cycle(s) for the entire program. Questions you can ask are: Is there an interim physical form that would provide us value? How much does that form cost us to create? How long is it that prototype good for? If there is not an interim physical form that would provide us value, how can we obtain value and reduce risks with what kind of form or demonstration? Here are some sample problems you could test for and avoid with early prototypes: The footprint is too large/too small. The design by contract work you thought was good turns out to be wrong. You have a design that works but doesn’t produce the product you want. You may have other problems. Because the hardware parts run on different cycles than the software parts, we have at least two ways to manage these risks: set-based design and landing zones. In set-based design, the designers iterate on the design, they rule in or out designs that do not intersect with the rest of the design components....

Helping Hardware Be Agile, Part 2

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 way to see the work is to ask the engineers to use a kanban board. I recommend each component have its own kanban to see the work in progress. Here are possible kanbans for mechanical, silicon, and FPGA teams: The FPGA kanban might look much more like a regular software kanban, up until you make the decision to go to physical form. These are possible kanbans, not the way your organization might work. These kanbans help everyone see where the work is. The roadmap in Helping Hardware Be Agile, Part 1 shows when the Program Product Owner would like the demos to be. The teams use those deliverables to decide when to integrate and test. The more integration points your program has, the easier it is to see the entire product, not just one component. The issue with integration points is that going to physical form can be expensive (in money and time). What is the relative value of staying in simulation mode vs. creating a prototype that people can touch and use? There is no One Right Answer. Part of it depends on the cadence of each team and the team’s risks. I’ll address hardware risks in the next...

Helping Hardware Be Agile, Part 1

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 times in the product development. The program needs all of them by the end. But how do you see the product evolve? Is it even possible? Well, yes it is possible to see a product with hardware evolve. The problem is that hardware is expensive to transition to physical form. Every time you go to physical form, you incur NRE (Non-Recurring Engineering) Expenses. If you have to fabricate a chip or board, that’s expensive. In my experience, my organizations want to fab no more than three times(prototype, pilot, real product). And, all near the end of the program. The first problem is ranking the features and organizing a product roadmap. In the book, I have a possible product, a robot arm. (None of my clients are developing robot arms, so I’m safe.) Here is the roadmap I created. Notice that each monthly deliverable is a demo. For each of the first two months, the deliverable is component demos. The software team (OS) could show their completed software to date. The mechanical, silicon and FPGA teams would show their simulations. The simulations are separate for each component. For the third month, there is a potential joint simulation and a demo of the first prototypes. The goal is to show every team’s work to every other...