Posts made in July, 2014

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

Predicting Scope, Schedule, and Cost

Posted on Jul 16, 2014 | 0 comments

Predicting Scope, Schedule, and Cost

Every project has three key variables… The three key variables that project managers must manage are typically scope, schedule, and cost. Businesses tend to create project plans that assign constant values for these variables at the project outset, therefore creating the illusion that projects have fixed scope, schedule, and cost. So before we continue, allow me to dispel a myth so we can start down the road to improvement. Fixed scope, schedule, and cost is an insidious falsehood that undermines the entire project management institution and community. Whether or not you openly admit it… This is a true statement; and I must assume you understand and have seen the truth in your experiences on real projects. We propagate this lie despite the deleterious consequences. However, I believe that there are important sociocultural reasons why we do this, so don’t beat yourself up if you still live the lie. What is more important is the acknowledgement that in the real world scope, schedule, and cost are not fixed, and we must become excellent at predicting these things for business planning and management purposes, no matter what process we use. Agile projects have a unique set of challenges in predicting scope, schedule, and cost that differ from traditional projects. This is because Agile projects are managed differently… Different in key ways that impact scope, schedule, and cost. Below are some excerpts of the relevant principles of the Agile manifesto. Scope: “Welcome changing requirements, even late in development…” Schedule: “Deliver working software frequently, from a couple of weeks to a couple of months…” With constantly changing requirements… We need a way to measure and predict the final scope of a project that not only allows, but welcomes change. Furthermore, we must deliver a working product on a shorter timescale than the 12+ months that is sometimes typical in the IT industry. Lastly, if our customers and executive sponsors are accustomed to infrequent product revisions, then it is quite likely that despite any incremental releases, we will still need to predict and communicate the future delivery dates of major product features that are in development for several months (or even years) at a time. Okay, enough build up, how do we predict successfully? I will share with you some tried and tested techniques that I have been applying very successfully at my clients for some time now. However, I must warn you in advance, these are advanced techniques that will take some time and patience to understand and apply, so be prepared to run experiments and learn from your mistakes. Create a predictive model. I have found that the best way to model Agile software product development is by first assigning a relative point scale to user stories, which we refer to as “Story Points.” Numerically speaking, using a fibonacci scale seems to yield the best predictions, so we will use that scale. It’s important that this step is done correctly, and that the story points are relative to other user stories, not a point of reference, like “1 point is equal to 1 day of development.” Instead, a 1-point story must be roughly equivalent in effort to any other 1-point story, and a third less effort than a 3-point story. On Agile projects it is wasteful to break down long-term projects into fully defined user story backlogs because we expect detailed requirements to change, so we must also assign relative sizes to larger work items (I will use the term “feature”) that we haven’t broken into user stories yet. We can use the same fibonacci scale, but to avoid confusion, I recommend...

Read More