In Part 1, I suggested that when we organize by function, the recognition and rewards might prevent a successful agile transformation. In this part, I’ll discuss an option for a product-oriented organization. Consider a Product-Oriented Organization Instead of organizing by function, consider a product-oriented organization. Again, I am not saying this is the only way […]
We hear a lot these days about project-based organizations vs. product-based organizations. Much of what we do in software is in service of products. Products tend to evolve over time. When we work on projects, we learn from the experience. However, once we finish this release, the “product” (the output of the project) doesn’t change
Many organizations plan to create certainty, guarantees of some variety. What if we thought about agile planning as a way to manage uncertainty? When I look at long roadmaps with all the “must-do” feature sets and the pressure managers put on teams to commit to delivery, I wonder about this question: How well do we
I’m working on my roadmapping talk for Agile 2018. I finally had the transforming idea about how to position the talk: Roadmapping and product planning are about feedback loops. The shorter the feedback loop, the faster and more often we can learn. That feedback loop works in at least these ways: The faster we learn,
Agile approaches can help a team release more often. When a team releases more often, the product people can replan the product roadmaps. The project portfolio people can replan the project portfolio. Not every team releases often enough to take advantage of replanning small and often. Everyone falls prey to “too much” thinking. The product
In software, overloaded operators exist when an operator or operation has different meanings in different contexts. A developer might do this unintentionally when she uses a variable to mean one thing in one context and that same variable has a different meaning in another context. We even overload conversational operators. A number of years ago,
I write a twice-yearly column for Better Software magazine. The title of the column is called “Technically Speaking.” For this column, I decide to tackle the question of “What’s a Professional?” If you don’t already subscribe to the magazine, you do have to join the site. It’s a free registration to join.
A great way to destroy a program is to avoid writing a charter. When I do assessments or work with teams, I often find that programs do not have charters, or that the charter is too big, or is missing some key piece of information. But what do you really need in a charter? Too
Mark and I visited his family in the Midwest. We used miles to pay for my ticket. Aside from spending 50,000 miles (is it possible to get a ticket for 25,000 miles? We haven’t in years), it cost $5 for the ticket, $75 for the “services fees” and $15 to check one bag. Yes, this
Every two years, my good friend and colleague, Brad Goldense, gathers research about the state of product development metrics. It’s that time again. Here’s the information: GGI