Articles from June 2011

In its simplest form, planning is nothing more than sequencing and elaboration; that is, deciding what order to get things done, and then determining a more detailed manifest of work items required to produce each deliverable.

Sequencing: determining the desired order of delivery.

Elaboration: determining a detailed manifest of work items to produce a deliverable.

While I say this and hold it to be true, many will argue that planning is much more than this. To those, let me say this only: If there were no external constraints on the work – and you were the sole stakeholder (like Bill Gates doing a household project) – it would just be sequencing and elaboration. Every other aspect of planning is optimization against external constraints.

I have been saying for several years now that sequencing is a simplification of scheduling. By this I mean that, when I don't have enough information to produce a reliable schedule, I start with a sequence. I do this, so that I can start working to generate the information to produce the schedule. This method works all the time at the beginning of a complex project where people get paralyzed because they don't know where to start.

Today, I flipped this over. Sequencing is not a simplification of scheduling – scheduling is an optimization of the plan to meet an external time constraint. When I think of this, what I realize is that planning starts with a rational sequence of value delivery, and then becomes complex as we optimize to comply with external constraints – time, budget, resource availability.

In the prior post, Units Of Value, I said that defining the units of value is key to understanding and delivering what your customer needs. In order to create a delivery plan, you need to construct a repeatable process for converting units of value to units of work.

This is difficult when a software development process is not very mature, not because the team doesn’t know how, but because the how is different every time. The conversion of what your customer needs into what you are going to build is a solution design exercise.

If my units of value are stories, features, requirements – then my units of work are software components in some framework. Each platform will have different types of components and sub-components. Each unit of value will get a “punch list” – or list of components that need to be built. Some of the components will be shared across units of value, others will be bespoke to a specific unit of value. If there is environment build out (hardware, infrastructure, etc) this is shared across all or most units of value.

There is no right way to do this conversion. There is only consistency, predictability, and integrity. They way to produce these three is to adopt some principles that make sense, adapt your methodology to fit your principles, and refine both your principles and methodology to get better results each time. For this reason, teams that stay together over a series of projects will consistently perform better in this effort than teams that form for a single project and then disband.

Glen Alleman in his Herding Cats blog, asks some really good questions about emergent requirements.  Since Glen is always and forever explaining that domain has everything do do with process, this appears to be another example, where the domain that he is in does not have the same sources of requirements emergence, that the business enterprise has….

In the business enterprise, software is designed to enable a business process by adding capabilities that make human actions more efficient, less risky, and more effective.  But, in enabling the business process, it also changes the business process.  In my experience, this is where the vast majority of requirements emerge from – the building of software capabilities to change the business process, creates new requirements for new or different capabilities.  Why is this so, because once people start to use the new enhanced business process, or start to walk through it on paper or in models, on story boards or in design sessions, they realize the the process enhancements that they had envisioned either did not have the desired effect, or they realize new opportunities to add more value that they had not previously seen.

Simply put business process enhancement is itself an iterative process, with each enhancement.

Since requirements “emerge” in this pattern, we have a choice.  We can ignore the emerging requirements until the current project is complete, but what that creates is a case where the delivery of software capabilities is always a cycle behind the development of requirements for those capabilities.  Isn’t the goal to deliver the capabilities as close to the development of the requirements as possible?

When my customer constantly asks what have I done for her lately, I want to point her at what I am doing for her right this instant – and that is agility: “The ability to respond quickly”

I can imagine that a domain where software capabilities are bespoke to a larger program of capabilities – the software requirements can only emerge from requirements changes in the larger program.

There is power in a name. Primitive cultures often believed that to know the name of something or someone is to have power over it. Much superstition, and "magic" or spell casting has been based in this principle. It fact, even in more modern religions, exorcism can require the name of the possessing power, and certainly the deity that is casting out the demon. You may laugh or ask what does this have to do with leadership?

In our enlightened age, we no longer believe that that kind of power is able to be expressed by invoking the name of some person, object, or power. However, in leadership, there is power in naming things. That is, you can name a practice, a brand, a problem, a role – and in effect by naming it, you are claiming power or authority over it. This is true in the same way explorers and frontiersmen in centuries past claimed land in the name of their king, and named that land, thereby solidifying their claim to it.

Now we recognized that naming is only the beginning of it, and that after naming something, one must define it. One must give it boundaries or shape. One may have to conquer the natives who are "squatting". One may have to colonize it. All of these activities are valuable – but none can be done until the thing has a name.

So why is this important? Because names are important. Names have denotative and connotative meaning, they imply specific meaning. In fact, at times, by naming something, you confer definition, and boundaries and shape to something without intending to. Carelessly naming things can cause confusion, and can make subsequent colonization and conquest difficult. If the name is ambiguous, then it needs to be separated by the definition from the other similar things. If a name is meaningless, then it survives on the establishment of a definition or a brand. If the name is misleading (i.e. you call something by a name that confers the wrong definition, boundary, or shape) then you will spend all of your energy explaining it.

Here are some tips or ideas for naming things:

Problems – Names should express impact and/or cause if known. Often problems are named for symptoms, and this can be misleading. (e.g. Client trades delayed by network firewall outage vs. Trader order entry application is unavailable)
Roles – Names should confer responsibility, more than activity. Often roles are based on industry categories or HR constructs, but may those may not be team or project specific. (e.g. Software Quality Analyst vs. Tester)
Practices – Names should articulate principle and activity. (e.g. Domain Driven Design vs. eXtreme Programming)

So when you have the opportunity to name something, take advantage, and then use the name to drive clarity and urgency into the situation, rather than ambiguity, confusion, or apathy.

Sometimes we need to learn to lead by asking. As a leader, we need to correctly frame the question, so that those we are leading will get the answer themselves.

By asking questions, we are helping those we are leading to draw their own conclusions. In fact, we are providing direction, by asking them to form an opinion.

In truth, this works, whether you are leading from authority, or influence. If you are leading from a position of authority (you are the boss), as it helps develop your staff's self-sufficiency. They learn what is important to you based on your questions. They learn (over time) how to ask the questions of themselves. Your staff take ownership of the answer.

Give this a try. Instead of directing by telling someone what to do and how to do it, ask them "What needs to be done?" and "Why that is important?" Let them articulate their own thoughts on the subject. You can steer their thinking by asking additional questions like, "How are you going to handle this problem?", or "How does your solution accomplish some goal?" These questions allow us to understand and influence their thinking, as opposed to merely directing their doing.

If you are leading from a position of influence (meaning you are a peer or subordinate to those whom you are leading), this also works, because those in positions of authority can take ownership of the answers.

Try this out: Instead of proposing a solution to a problem in front of a group of powerful or politically motivated managers or executives, ask the following question: "What criteria are we going to use to measure the success of any solution to this problem?" or "What goals should we be striving to achieve while solving this problem?". These questions get hidden agendas out in the open where they can be discussed. We can steer this conversation by asking follow on questions like: "Why is that criteria or goal important?" or "How important is that goal or criteria relative to the others?" These questions allow us to expose their thinking, as opposed to proposing solutions or answers and getting shut down by ideas that never made it to the table.

Questions help frame the problem. They help focus attention on decisions that need to be made, problems that need to be solved. Questions allow a conversation to be steered by opening decision points; forks in the road or intersections requiring decision. Questions increase the number of choices. Answers limit the number of choices.
Questions allow us to explore the thoughts of others, where as answers allow us to expose our own thinking.

In a discussion with a colleague this week, I was trying to articulate how writing business capability requirements can help guide both development and software acquisition processes.  My explanation apparently was not very good, because he definitely got the impression that I was talking about some super strategic high level requirement that was not really implementable or helpful. 

I had to go back and read my own post to figure out why my conversation had that unintended impact.

I failed to articulate the need for a business context for the requirement.  Without this, he got seriously hung up on how general the requirement sounded: "reduce the amount of time or labor input to complete some process by 30%".  It is the context that makes this requirement real.  There is real analysis in preparing the context, and understanding the business value in resolving issues in context.

Business Capability Requirements are generalized, meaning that they do not propose a path to solution, and from that perspective they treat one solution like another.  My colleague got this confused with strategy, because I failed to provide any specific context for the requirement, and so his brain instantly applied it at a very high level.  This is because it is generalized.  However the value in writing requirements this way is that they clearly separate the value target from the path to solution.

The software capability requirements imply (but do not describe) a path to solution.  These often accompany business capability requirements, and should reference them.  If your organization is like those that I have worked in, you see these much more frequently, and usually without the business context or an understanding of the business capabilities that are to be affected.

My colleague immediately translated generality into broad scope.  Generality in this case is scope neutral, you can apply the scope in context at any level.  If you apply it at a higher level, you will then need to do the analysis to determine subcontexts in which you can propose meaningful solution paths.  It is hard to propose a meaningful solution path for make employees in division 123 30%  more productive.  Any meaningful solution will require contextual knowledge of what those employees produce and how the produce it.

If my goal were posited in that way, I would create a context around every product output of division 123, and create a business capability requirement specific to each context.  Here is the catch, maybe they make 3 products, and one of them is 90% of production, but a different one takes 60% of all labor input.  If I wanted a net 30% increase in productivity, why wouldn't I make the big labor ticket 50% more productive.  This frees up 30% of my labor force to do whatever I want. This is the analysis that allows us to figure out what to do, business context. 

We talk alot about the scope of a project.  In this case we are talking about the scope of a requirement – in terms of the business context it lives in.  The way you write your requirement always guides your solution.  The business analysis to write the requirement – to frame the problem we are trying to solve is the key element. 

I have been working on an "Agile" product with our IT Project Standards and Governance group at work. When analyzing the values and principles that are espoused in our "gated" product, I realize that the difference between agile and traditional (waterfall) project methodologies is singular. There is all kinds of hyperbole around why agile solves problems that waterfall doesn't, but that is really not on the mark. As Glen Alleman of Herding Cats says "Bad project management is simply that", meaning that the problem is less with the methodology than the execution. What is different between agile and waterfall is really a small number of preferences, and ones that may only apply well in the software development domain.

The main difference is which of the primary project constraints the methodologies have a bias towards, or prefer not to vary:

Waterfall prefers to vary time and budget whereas agile prefers to vary scope. If this sounds incredibly oversimplified, think through it. By stacking all the analysis up front, the cost of varying scope in a waterfall project continues to increase over time, while the benefit of varying scope decreases. This is necessarily true, because all the analysis and design work is done "up front", before we really know how much effort is in the plan, and then when we make the decision, that work is "sunk cost" that usually must be redone if things change later. The theoretical benefit of this approach is that we can optimize the development sequence to minimize cost of re-work. This assumes that we know how to perform this optimization, and that other factors (like emerging requirements and budget and time constraints ) don't cause us to compromise this benefit.

On the other hand, Agile has a preference for a static team (it's hard to be predictable using agile metrics while your team is a moving target), and therefore a fixed burn rate, and uses typically time boxes to manage duration. But agile prefers a sequence that has implies less waste when changing scope, because rather than doing analysis and design "up front" it has a "just in time" approach – meaning within a time box. Thus the cost of changing the scope of the next time box is nothing or just the cost of re-planning, because little pre-work has been done. The risk resulting from this that causes concern is that since we don't know "everything" up front, we will learn things that cause us to go back and re-do something that has already been developed.

In theory, as analysis and design activities of a software development life cycle are completed, knowledge of the work required increases, and the risk of unknown is understood, and risk of rework correlates to the unknown. None of this really helps deal with the risk of business driven change (market change), or constraint change (reduction in time or budget). The traditional lifecycle creates waste out of the analysis and design work that was completed for capabilities that are abandoned when these events occur. The agile lifecycle reduces the waste resulting from "change". while dealing with waste (in rework) resulting from risk of unknown by allowing the stakeholders to trade lower value capabilities for higher in order to align with budget and time constraints.

Because the agile lifecycle allows the delivery of incremental value to the end user earlier (it does require everything to be done to release), the business gets value sooner, while the risk of spending without any return on investment when a project is abruptly cancelled or funding is abruptly cut is much lower. Furthermore, the agile lifecycle expects shorter feedback loops on smaller scope value targets, which creates greater focus both in the stakeholder community and on the delivery team.

So which is better? It depends on where your risk comes from. If your risk comes from the unknown, and there is little risk of the goals or funding changing in the middle of the the project, or if there is limited value in delivering part of the product early in the lifecycle, then a traditional lifecycle may work well. If your delivery in a more volatile environment, where business needs changes very frequently, where funding is driven by short horizon events, or where delivering partial solutions as early as possible is valuable – then an agile lifecycle offers some distinct advantage.