What Does Agile Mean to You?

Over on Techwell, my monthly column is Agile Does Not Equal Scrum: Know the Difference. I wrote the article because I am tired of people saying “Agile/Scrum” as if Scrum was the only way to do agile. I use iterations, kanban, and the XP technical practices when I work with teams. I am not religious about the “right” way to do agile. I like any combination of approaches that help a team deliver value often. I like anything that helps a team to get feedback on their work and their team process. I like anything that helps management ask the right questions and create an environment in which teams can succeed. Dogma doesn’t work very well for me. (I know, you are so surprised.) If you are thinking about your agile approach, ask yourself, “What does agile mean to me? What value will agile deliver?” Before you decide on an approach, answer that question. You might be more Dan in my most recent Pragmatic Manager, Define Your Agile Success. Once you know what agile means to you, you might start to read more about possibilities that fit for you. If you are a leader in your organization trying to use agile more effectively, consider participating in the Influential Agile...

Influential Agile Leader, Boston and London, 2016

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 event in Boston, April 6-7, and in London, May 4-5, 2016. Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your business challenges. If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us. Super early bird registration ends January 31 for London. Our super early bird for Boston is sold out, and the early bird registration is still a steal. If you have questions, please post a comment or email me. Hope to work with you there. (See the servant leadership tag for the Pragmatic Manager  and the leadership tag on this blog to see relevant articles I’ve written...

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...

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...