Posts Tagged "product development"

Choosing the Right Measure of Progress

Posted on Aug 9, 2014 | 0 comments

Choosing the Right Measure of Progress

What is Progress? Defining progress will help you to better understand the difference between being busy and productive. Unfortunately, I often see very intelligent and productive people falling into the trap of doing busywork instead of making progress. In order to effectively combat this problem, it helps to define progress much in the same way we define a vision: envision the end state. Attempt to describe in detail the properties and aspects of the ideal end state for your current task or project. For example, if I was trying to build an office chair, I may describe the end state as follows: “I can sit comfortably in the chair for several hours,” “The chair is elevated from the floor,” or “I can rotate the seat of the chair easily.” Each of these properties can be easily measured, whether objectively or not, and represent true progress toward completing my goal. Tasks do not represent progress. Continuing with my example from earlier, there may be many things that I need to do in order to build a great office chair. Perhaps I need to buy materials such as wood, steel, and fabric. Maybe I need to sketch designs, cut out upholstery, and assemble arm rests. All of these things represent actions that I can and probably should do in order to reach my end goal of having a lovely new office chair, but none of these things represent true progress. Tasks act as hypotheses to be tested, not the results of an experiment. For each task you decide to act on, you make an implicit statement: “If I complete this task, then I will be closer to achieving my goal.” Experience probably tells you that even the most successful and accomplished people regularly learn otherwise. At the end of each completed task, and often before, we learn about new tasks that must be completed. For example, before you can buy wood you need to find a store that sells the wood. Perhaps the store is closed and you now need to find another store or different wood, let’s say you chose to change to a different kind of wood. Now, the store that sells the new wood is open, but when you get there, they have run out and recommend another store. You don’t have enough gas to get to the other store, so you start off toward the gas station. We now have a situation where in order to make progress on my chair, I must go to the gas station. If I measure productivity by the tasks completed I may find that I am immensely productive, checking off task after task after task. However, without any measurable and tangible progress being made on the chair itself, I am failing to achieve my goal. How you measure progress directly impacts whether you feel most productive doing busywork or accomplishing your goals.  Measure Real Progress The real challenge with choosing a measure of progress is recognizing incremental steps toward a goal that represent true progress and not the busywork of tasks that may or may not contribute to the goal. This can sometimes be more art than science, but focusing on realized benefits as a measure of progress will almost always deliver results. Since user stories are the primary measure of progress on most Agile projects, it is important that they represent realizable benefits as opposed to tasks. Using our existing example to tie everything together here, the following benefits would be great measures of progress on our office chair. The chair has a designated seat. The seat is elevated from the floor. The elevated seat can hold...

Read More

The Argument for Emergent Design

Posted on Jul 30, 2014 | 0 comments

The Argument for Emergent Design

The Opposition Argument Let’s start off this post by exploring the arguments against emergent design. I often hear many different arguments and reasons to oppose emergent design, so I will share the few that I hear most often. First, I often hear that emergent design leads to wasted effort because building a product that only supports a small initial set of customer needs will later require the product development team to rebuild the entire product (or a substantial piece) in order to support more advanced customer needs. The wasted effort comes from the rework that the development team needs to perform in order to build the advanced features on top of the naively simple system. It follows that if the development team had asked about the advanced features before starting work, then the product could have been built from the beginning to support both the simple and more complex cases. Almost every experienced developer has several horror stories that they can very quickly relate about a poorly planned project where they endured the hardship of throwing away hours of work because the project direction (though, seemingly not the customer’s needs) changed frequently and dramatically. In addition to this, I also often hear that emergent design leads to poor system architecture because developers do not align their current efforts with a greater picture at the outset. Without steadfast direction, developers create code that works, but lacks cohesion and tends to feel more complex than necessary. After a long enough timeline of working without a big picture, the overall system architecture suffers. Almost every experienced developer has several horror stories that they can very quickly relate about a poorly designed system that was impossible to update or maintain because the system lacked a cohesive overall system architecture. While I have definitely heard many more arguments against emergent design, I have heard these two far more often than any of the others, so I want to explore these problems a little bit deeper. Product Rework and Bad Design I ask you to set aside any preconceptions for a brief moment while we try to discover the root causes of bad design and product rework. In my experience, product teams typically blame product rework and bad design on poor or inadequate initial planning. That is, if we spend more time on planning, or plan in a more skillful, careful, or comprehensive manner, then the outcome of bad design and rework can be avoided. This seems logical at first glance, so very few people give this a second thought, and attempt to solve these problems by bolstering planning activities. Improved planning generally leads to better outcomes, which gives us the impression that we have solved the problems, until they reoccur. But they do reoccur so frequently in software development that it has led some teams into a state we sometimes refer to as “analysis paralysis.” That means that the product development team cannot make any progress on the product because all of their time is spent in planning activities. The problem of bad design and rework cannot be completely solved by better planning, but both proponents and opponents of emergent design agree on one thing: The best designs tend to emerge from product development teams that have a very deep and complete understanding of a problem and its solution. So, if better planning does not completely prepare us for success, then what else must we do? True Emergent Design Great planning will only take a team so far because it is only one source of information and learning. In particular, planning typically revolves around certain constrained activities such as lengthy conversations with colleagues and customers, documenting decisions, drawing diagrams,...

Read More