Agile Versus Whatever

In a number of posts over the last few months, Glen Alleman (Herding Cats) has been saying that Agile comparisons to “waterfall” or “predictive” are bogus, because the practices that they compare themselves to are simply BAD practices or anti-patterns in the domain of project management.

While I don’t disagree with Glen in the slightest, I want to start an argument about it. Just because they are bad practices, doesn’t mean they aren’t prevalent. There are many organizations with a software development life cycle (SDLC) that is waterfall-ish. And there are many organizations that have responded to regulations (Sarbanes-Oxley) by increasing the documentation requirements without thought to impact on software productivity or quality, that have effectively polluted their software development lifecycle with audit/regulatory oriented policies.

There are thousands of PMP certified morons who do not know (in practice) how to measure a project using any other tool than a gantt chart and a ruler. There are many software development managers who use project plans and process gates to indemnify themselves when things go wrong, who think that by mandating that requirements be “signed off” and requiring “change control” that they are immune to needing to deliver anything more than the minimum specified in the requirements.

There are thousands of software practitioners who have refused to give reasonable estimates because those estimates have been repeatedly weaponized by managers. (If I give you a stick and you hit me with it, next time I won’t give you the stick, or at least will wrap lots of padding around the it.) Many organizations have used “process” as an excuse to move much of the coding work “offshore” leaving ex-developers onshore in unacustomed roles as liasons, managers, project managers, analysts, and testers. They have imposed “process” in order to get work to “cheaper” resources, but have not invested in process maturity.

The thing about agile is that it appears to ALL to be a game changer. It makes it easy for us to drop all our anti-patterns at once. While I recognize that Glen is right – the dumb things that agilists say are similar to the dumb things that born again Christians say (“I don’t know how I would make it through the day with out Jeeesus.”) Agilist are often like ex-smokers – they can’t stop telling you how great they feel since they quit. Yeah – alot of the claims are based on comparisons to bad practices and known anti-patterns.

So Glen, to riff an old joke – why is using enterprise project management anti-patterns like hitting yourself in the head with a ball-peen hammer? Because it feels so good when I stop.

When your experience as a developer or project manager is fraught with project management anti-patterns, and you are a couple of pay-grades below the decision makers who are instituting said anti-patterns, what are your options?

a) Tell senior management that they don’t know their project management keister from a hole in the wall?

b) Find a new job at a better firm (oh wait – that assumes that there really is a better firm…)

c) Find some industry literature that shows a better way – a way that without faulting the folks who instituted the anti-patterns, can be adopted in small doses. A way that tries to put all members of a software development team on equal footing, creating collaborative realtionships rather than emnity.

So in the Dilbert world that most software projects are found in, – option C sounds like a huge winner. You really can’t fault the agilists whose primary exposure to project management practices has been in these environments from making those comparisons – that is their reality.

Agile Risk Mitigation

Before we talk about whether agile practices provide any benefits toward risk mitigation or risk reduction, we really need to talk about the nature of risk in a software development project or process.

In any discussion of risks, there are any number of attritbutes by which we can classify or characterize risks, but in order to discuss mitigation, comparing two methodologies side by side, it makes sense to me to use the source or cause of the risk as the primary taxonomy. So I will describe these risk sources, and how agile might offer some advantage in dealing with risk.

risk mitigation

Risk Source – Customer: Risks emanating from the customer inevtably involve scope, schedule and money. Sometimes it is that scope cannot be succinctly defined, or understood (requirements), sometimes it is that the buiness need changes more rapidly than expected due to external factors. Sometimes it is simply that the customer for whatever reason cannot make decisions.

Risk Source – Project team: Risks emanating from the project team inevitably involve productivity, skill, or leadership.

Risk Source – Organization: Risk emanating from the company or department producing the software, involve policy, resource management, coordination.

Risk Source – Technology/Environmental: Risk emanating from technical infrastructure or software development technology platform.

I have listed these in the order of frequency or likelihood based purely on my own experience. You can argue with me on the customer risk being the most frequent or likely, and that all scope, schedule and financial risk emanate from the customer, but it’s their scope, it’s their schedule, and it’s their money, and all decisions around those three elements are made by the customer.

So how do agile practices help mitigate risk emanating from the customer?


  • By producing working software as early as possible, effectively shortening the feedback and delivery cycles, agile practices actually retire risk of unknown. When you produce working software capabilities that is ready to deploy, any risk of unknown that was attached to those capabilities is effectively retired. This includes risk of incomplete or incorrect requirements, or inaccurate translation between business and technical abstractions.
  • By assuming a model that inherently drives down the cost of deferred decisions by eliminating pre-work, the risks of changes to schedule or budget emanating from the customers funding model or the customers market strategy are mitigated.
  • By developing a model with a higher frequency of customer interaction, and reducing the scope (size and impact) of customer decisions (one milestone at a time) risks emanating from the customers own organizational decision making process, or internal committment model are mitigated.
  • By establishing a value scoping paradigm with finer granularity, agile practices can reduce the scope of customer decisions, and the minimum time span of value delivery. More granular deliverables (stories?), make it easier for the customer to prioritize and sequence, ensuring that key value propositions are delivered as early as possible. Customers have a increased ability to discriminate essential scope from non-essential (apple polishing or lily guilding) scope, and so can defer the non-essential, until all of the essential scope is accepted.

Likewise, how do agile practices help mitigate risk emanating from the project team?


  • By increasing the frequency of measurement (of productivity), agile practices give more timely feedback on the productivity from each skill to management, enabling adjustments as early as possible, rather than later.
  • By establishing a regular cycle during the project of milestone retrospectives, the project team can adapt and adjust without the permission or engagement of outside leadership.

And for risks emanating from the delivery organization?


  • By establishing cross-functional teams, and empowering the team to self-adjust their process, agile practices reduce policy oriented risks, as separate teams forming separate (and un-aligned) policies do not inherently collaborate or coordinate.
  • By increasing the frequency of measurement, feedback to resource management is actionable sooner, mitigating risk emanating from resource management.
  • Agile practices do not appear to provide distinct advantage in coordinating across delivery teams, or with service providers or vendors. But it also does not appear to disadvantage the team in any material way.

Finally, for risks emanating from the technical infrastructure or development platform?


  • Agile practices do not appear to provide distinct advantage in dealing with hardware or software environments or development tools. But it also does not appear to disadvantage the team in any material way.

While I am not suggesting that traditional software development life cycle does not have risk management capabilities, only that they are different, and especially, do not retire risk as early. The basis of the traditional lifecycle is that risk of unknown is mitigated by doing ALL of the analysis and ALL of the design up front, in an effort to optimize the development, which is thought to be the risky portion. I think that modern software tools, paradigms and techniques have made the development less risky, which means that the risk is more likely that the requirements that we captured change over time, or simply were inadequate, and that we cannot retire that risk, until we put software capabilites in front of users. That is where agile practices take us – in exactly that way.

Agile Value Delivery

Agile practices claim to delivery greater value to the customer.  This claim is based on agile tendencies to deliver software capabilities more frequently, which in and of itself, means that the customer starts realizing value from our efforts sooner. OK – this one is obvious. Traditional phase gated life cycles effectively require you to do all the work through each phase – all the requirements, all the design, all the development, all the testing – before any value is actually delivered to the customer. Agile practices – actively proclaim (this is not a passive benefit, but an assertion of the philosophy) that it is better to finish the smallest increment of usable software capability and deliver it to the customer as early as possible.

While agile does not claim to have invented this concept, it does seem to have taken it to the extreme. Here is the “thing” – in a corporate culture where results are measured in quarters and not years, the faster we can implement even incremental improvements in work process, the faster we can show results (cost savings, risk mitigation, staff headroom, etc). The balancing factor is how frequently/rapidly can the organization assimilate change. Yet, even in an organization that is not particularly good at change management, the early delivery of value emanating from agile practices, puts the organizational management in the drivers seat. You can have a “pile” of completed, validated software changes ready to go, and you control the pace of change by scheduling releases. Whether the company wants two releases per year or twelve doesn’t matter to the team – because they just keep piling up the value and the customer controls when it is released into the enterprise. The customer controls the sequence of value that is being piled up, and the customer controls the timing of when the pile is rolled out.

Here is how it works pragmatically:

1) The customer constructs a list of valuable changes (scope).
2) The customer ensures that the list of changes are organized by sequence of delivery (converts scope to a backlog).
3) The team and the customer analyze (write requirements and estimate) these valuable changes in sequence and decide how many of them can be done in a measurement milestone (sprint).
4) The team delivers the changes (designed, coded, tested) for customer review.
5) The customer reviews the delivered changes, and adds any observed deficiencies to the backlog.
6) Repeat steps 2 – 5

One of the things that agile does, simply by sequencing by deliverable value, rather than by skill or life cycle phase, is that it makes it easy to decouple releases from life cycle phases. In a phase-gate lifecycle, I can’t release until all phases (analyze, design, code, test) are complete. Using an agile lifecycle decouples release from phase, because it assumes sequencing by deliverable, instead of sequencing by activity. Other than the “extra” activities required to release (regression testing, data conversion, code migration and deployment) the software itself is continually in a “releaseable” state.

This change in sequence assumption actually gives the “customer” more control over what order value will be delivered in, and allows them to alter the order of value delivery without loss of productivity. This is true, when the order is not altered during a measurement milestone, but for the next milestone, because very little work is done on deliverables before the milestone begins. In a phase-gate life cycle, all of the analysis is done for all deliverables before the design starts, all the design is done for all deliverables before the code starts, all the coding is done before the testing starts, etc – so the later you alter the scope (or change the sequence by swapping one scope item for another) the more completed work you are “throwing away”, which becomes lost productivity or waste. This is why everyone in phase-gate life cycle works so hard to avoid change in scope – we use change control because we recognize that change after analysis is complete means lost productivity.

Now of course WE ALL KNOW that it doesn’t really work like that in phase-gate life cycles – phases are allowed to overlap, and plans are optimized for dependencies, and we can carry risk of unknowns for later analysis or design on our projects – but because of the assumption in sequence by activity inherent in the life cycle model, these things add complexity to the planning process, and to the measurement process, and to the execution of the project because they are execptions, rather than the rule. This complexity itself has a cost in lost productivity and extra coordination or collaboration. The point being that because overlap and deferred analysis are inherent to the agile lifecycle, they do not increase the complexity of the project, plan, or execution, and the collaboration and coordination points are baked into the practices designed to implement the agile life cycle.

Running Agile

The key difference between agile and more traditional phase-gate life cycles is the key assumption around delivery sequence, and all of the implications emanating from that assumption, especially the greater control of delivery of value afforded to the customer. It is this greater control over the delivery of value that the term agile describes – agile life cycles respond to changes in strategy, direction, market conditions, available budget much more gracefully, and with much less drama than traditional phase-gate life cycles. This is a direct win for the customer, and as such, can be sold as an advantage for the provider.

Agile Predictability

Predictability is probably the least hyped benefit of agile practices. It is not sexy or fun, nor does the team gain from it, in a positive way. But the team does benefit from it, from a management perspective.

so predictable

The benefit of a predictable software delivery process is realized in three ways:

  • Rational Planning Process – when I can measure the capacity of the team, I can create a rational plan. This allows consulting firms to bid project or enterprise software organizations to budget more accurately.
  • Builds customer trust – when I can predict the delivery pace, I can communicate this to the customer, and build trust and reputation. This allows for repeat engagements in consulting, or greater latitude in decision making within the enterprise. When the team demonstrates predictable delivery, the customer can relax and focus on defining the output rather than the mechanisms of accountability.
  • Sustainable Pace – when I can project delivery based on the capacity of the team, I can ensure a more sustainable pace. I can negotiate in trust with the customer, understanding their need. I can increase capacity when needed, rather than forcing the team to stretch (work overtime) to meet goals.

These are serious benefits, but we haven’t said that agile practices deliver – only why and how predictability benefits an organization. So how does agile deliver on this benefit?

  1. Frequent, measurement on regular intervals – by defining arbitrary milestones at regular intervals ( iterations, sprints, time boxes, etc) and measuring the output of the team through each interval, agile practices generate the metrics that support predictability. While it is important to measure, it is also important to have a light weight measurement practice – so that the team doesn’t trade productivity for predictability. The velocity metric (calculated as completed units of estimated effort per unit of duration) is typical. Combined with a remaining estimated effort metric, and planned cost per unit of duration, or average cost per unit of estimated effort allows an accurate projection of both duration and cost. If my measurement frequency is a week, I can know each week how far off plan I am in terms of both schedule and budget. I can choose how I react to this knowledge.
  2. Cross-functional milestones – what differs within agile software life cycles from more traditional gated software life cycles is that each milestone in agile is self-contained, and has elements of all phases of software delivery – analysis, design, development, testing. This means that each skill is consumed and measured in each milestone. In a phase gate life cycle, the last skill (testing) is not consumed or measured until the last milestone – and so is not predictable – so I am using measurements from other projects at best. If I form virtual teams for projects (consulting), I can only predict at best from prior individual performance, which does not account for team dynamics.
  3. Repeatable, lightweight measurement framework – agile practices propose a lightweight estimation practice, a repeatable practice of measuring delivery against estimate. Agile estimates are done with less precision, but much less effort than gated methodologies – again trading productivity for predictability. Traditional project managers (Glen Alleman) get aggravated by this, because it does not have the precision of the more industrial strength estimation and measurement frameworks, however, it also does not have the overhead. Agile applies that same principle to planning that it applies to software delivery (YAGNI) – that is, I do not implement more sophisiticated measurement or estimation schemes, unless the nature of the work, or the project merits that level of precision. If the customer provides requirements that are less defined, I will by definition, provide estimates that are less precise, even using the industrial strength mechanism. Since software development is a largely non-repeatable process, with no standard units of measurement for output, agilists argue that using a precise estimation and measurement framework that costs more is a waste, because it does not yeild greater predicitability.
  4. Lower planning skill requirement – agile planning practices are typically simpler, easier, and less effort, than other practices. This means that your project manager doesn’t need to know how to do a PERT chart, a Critical Path Method (CPM) or Earned Value measurement. In agile plans, you don’t focus on dependencies between tasks, you simply sequence the deliverable capabilities in the order of customer value, and go. All of the more sophisticated plan maintenance, are optimizations that may not be necessary, or beneficial, given the level of unknown in the work being contemplated. Here is the kicker – because it is easier to implement, it gets done more consistently. It gets done with more discipline – so a lower fidelity process executed with greater discipline actually delivers higher predictability over time than a higher fidelity process being executed with less discipline.
  5. Emphasis on learning and improvement – agile practices call for retrospectives after each milestone. The purpose of the retrospective is to identify opportunities to improve practices in use. As the team works together, they find ways of working better, and have a stated process for proposing, deciding and implementing improvements. Since the team owns the process, and the improvements they are incented to implement (it was their idea) and thus each team adapts agile practices to suit their specific situation and goals. Through the process of self-improvement, the team becomes more predictable, because this milestones surprises become opportunities.
  6. Progressive elaboration – in phase gated software development life cycles which assume that all inputs are known early – (requirements, design, etc.) the temptation is to plan in more detail than you actually know. This introduces fiction and reduces predictability. Agile’s preference for progressive elaboration in requirements, designs, and plans recognizes the FACT that you cannot know everything before you start. This leads to plans that grow and shrink as knowledge is acquired and accounted for, but always currently reflect the state of our understanding of the work. This provides the ability to decide and adjust based on a plan that is as accurate as it can be with the knowledge that we have. Anything more is speculation, or fiction, that leads to poor decisions and improper adjustments.

The benefit of predictability is one that is less intuitive that the rest. Who really benefits from it? In the end, all benefit. Management has more control, the customer is satisfied, and the team can reach a sustainable pace – that sounds like win-win-win.

Agile Productivity

One of the hyped benefits of agile software development practices is increased productivity. It is also the benefit that I am most skeptical of. Software productivity is notoriously difficult to measure. That is because there are no relatively standard units of measurement of output.  Martin Fowler said this in 2003, and as far as I can tell it is still relatively correct.  This is true regardless of whether you are using agile practices or not. In fact, the measurement of software output itself is an expensive activity, so in any normal case study it would be hard to prove. Since books have been written on this topic, I do not feel the need to delve deeper into this topic, except to say that all of the problems described in Fred Brooks’ famous Mythical Man Month still exist today, and there has not been a universally adopted solution.

Nevertheless, I am not totally willing to call bullsh*t on the productivity benefit. There are three completely anecdotal reasons for this:

1) Agile practices tend to focus less on documentation and more on producing working software. This leads to spending less time on speculative documentation that ends up being revised many times. Rather than guessing what users want, agile teams build it as quickly as possible, and get feedback, and revise it, until it IS WHAT THE CUSTOMER WANTS! So from a productivity perspective, it is less work to deliver what the customer wants, not what they thought they wanted or what we thought they wanted. Is this real measurable productivity? NO – but it sure as hell feels good to both the developer and the customer.

2) The shorter measurement cycles that agile favors help resources focus on the needful, rather than the fanciful. This means that developers are focused on working in the next feature. Management theories put forth by Elliot Jacques talk about time span – the individuals ability to plan into the future. Developers typically do not a have long time span. I have often experienced developers who became overwhelmed trying to figure out what order to work in, and ended up being unproductive or paralyzed by unscoped tasks. The rhythm of consistent pacing, tends to allow the team to relax around planning, because there are regular intervals of planning activity, broken by longer periods of uninterrupted development. Is this real measurable productivity? NO – but the developers will tell you that they are able to relax and focus on solving technical problems rather than worrying about deadlines and planning.

3) The agile principle YAGNI (Ya Ain’t Gonna Need It) reduces the investment in complex architecture, or over-engineered solutions, or premature optimization. The principle is less about improving the productivity of individuals, and more about improving the output of the team. It is a principle that allows the team to hold itself accountable to deliver the smallest, thinnest, cheapest version of each capability, rather than the most ornate, most performant, most scalable, most beautiful version. Agile principles direct us to deliver an acceptable solution with the least effort, rather than an acceptable solution that anticipates all future events. Is this real measurable productivity? NO – but as I learned early in my career – the best way to get more done is to figure out all the things that don’t need to be done and not do them.

When I evaluate these reasons, I recognize that the perceived increase in productivity may be much greater than any actual increase, but at the same time, perceived increase in productivity can improve morale and reputation in ways that by themselves lead to real increases in productivity. Agile life cycle projects often feel less like a “death march” than gated life cycle projects, and that alone can lead to increased productivity and motivation.

Agile Benefits

Of course there has been loads of hype about agile in the software development community. Lots of folks have now been certified as Scrum Masters. I have been involved in agile transformation since 2004/5 when I had a proprietary methodology forced on me from above. Said methodology was brought by a “Management Science” consultant, who incidently was also selling a software product that would help implement said methodology. This same consultant was also married to a signficant client of our firm, and so you can do the math.

Like any other practice, people who have a positive experience with agile, are looking for opportunities to repeat that positive experience. After I rid myself and our firm of the management science consultant and his methodology and his product, I took a long hard look at what he was trying to accomplish. I read some of the broader agile literature. I was looking specifically at the benefits that were being hyped.

Like any other business change program – if you are going to adopt agile practices, you must start by describing the benefits you expect to get. Before you challenge me on business change, let me just smack you down. Software development is a business activity. Whether it is a consulting practice for cash, as a software vendor building a product to sell, or as a company building bespoke systems – software development is a business activity. To adopt a new methodology, life cycle, set of practices, technology stack, etc. is therefore a business change program and should rightly be treated like a business change. That means:

  • you don’t start until you are prepared to invest sufficient resources to make the change stick.
  • you have to be ready to sell executive management on the investment.
  • you have to be able to articulate the benefits you expect to get from the investment.

So what are the benefits that are so overhyped?

1) Productivity – agile practices claim to be “lighter weight” processes, meaning you spend less effort on maintaining the process and more delivering valuable software.

2) Predictability – agile practices claim to deliver greater predictability, meaning that we will know earlier that our plans are reasonable, and have more time to adjust if they are not.

3) Improved Value Delivery – agile practices claim to delivery greater value to the customer, this claim is based on agile tendencies to deliver software capabilities more frequently, which in and of itself, means that the customer starts realizing value from our efforts sooner.

4) Improved Risk Mitigation – agile practices claim to reduce certain types of project risks faster and more effectively than other practices, meaning after the same amount of time an agile project has less remaining risk than otherwise would be true.

In a following series of posts, I would like to describe each of these benefits in more detail, and how I have seen agile practices deliver these benefits. I think that agile practices certainly can deliver these benefits, but I do not believe that there is a guarantee, nor is agile the only way to get these specific benefits.

Vision, Strategy, Policy

Sometimes it seems like we get “hung up” on moving forward with some initiative, because we cannot separate vision from strategy, and strategy from policy. I want to posit some definitions of these terms that might help us to keep making progress. One of the reasons that we conflate these is that they all have goals. In my initiatives, I see many goals, some of them are complementary, others are conflicting. Vision, Strategy, and Policy each have goals, but the goals are different, and understanding the origin or alignment of goals with vision, strategy or policy can help us stay on the path.

Vision – a description of the end state of some change initiative. The vision should be a picture of what the “world” looks like when this change initiative is successful. The “world” is determined by the scope of the change. From the vision, one should be able to discern the differences from current state, and define clear success criteria for the initiative. The goals deriving from the vision, are clearly detailed success criteria articulated so as to be measurable.

Strategy – a description of the plan to change from the current state, to the end state as described in the vision. The strategy should be articulated as a series of changes from current state to end state, encompassing interim states necessary to acheiving all success criteria. From the strategy, one should be able to develop an action plan, consisting of a series of distinct changes in a defined sequence providing a path to arriving at the end state described in the vision. The goals defined by the strategy are really the success criteria for each distinct change in the action plan.

Policy – a description of rules that we will hold ourselves accountable for following. Policies can be designed to maintain the status quo, or they can be designed to support the end state, or interim states defined in the strategy. Policies define constraints necessary to implement the strategy, and the goals of policies define the desired behavior of individuals and organizations that are impacted by the change initiative.

— I am sure that people will pick these definitions apart, but at the end of the day, if we don’t articulate vision, strategy and policy in ways that make the objectives of a change initiative clear, confusion will swallow the change.

Premature Plan Optimization

In PlanningSequencingElaboration , I shared my realization that sequencing is less a simplification of scheduling, than scheduling is an optimization of the plan around a time constraint.

Here are some typical variables and constraints that a project plan must contemplate:

1) Cost – can we complete the necessary work and deliver the expected value at a cost that someone is willing to pay.
2) Time – can we complete the necessary work and delivery the expected value in a timeframe that supports some goal.
3) Resources – are the resources/skills/knowledge we need to do the necessary work available.
4) Risk – what unknowns exist in the definition of value or the elaboration of work

As project managers, we are trained how to elaborate the work (build a WBS), how to find the critical path, how to optimize the sequence for dependencies, how to assess and mitigate risk, how to estimate cost, but all of those activities assume that we are optimizing for a single point in time: the completion of the project as a whole. It is this assumption that causes us to optimize in a certain way, and it may exclude the most important variable to optimize for (customer desire).

What if your customer asked you to deliver valuable releases of software to them every month. How would any of these activities or processes help? The answer is they really would be of very little use in that model. The most important thing would be the customers desired sequence of value delivery; which UnitsOfValue will be delivered in each monthly release. In order to balance this, we also would want to understand an optimized risk retirement sequence; that is which of the UnitsOfValue have unknown risk, that might interfere with the delivery of other UnitsOfValue. We might want to negotiate sequence of value delivery to balance the retirement of risk against the delivery of value. This delivery sequence of the UnitsOfValue is then the initial basis of the plan. We do not have an estimated cost or duration, we have not converted UnitsOfValue to UnitsOfWork, and we have not contemplated resources.

What we have done is construct a simple delivery roadmap, a planned sequence of delivery, and agreed with our customer to deliver value in a rational order, on a regular schedule. From there, we can convert units of value to units of work, estimate, allocate resources, form a team (if we don’t already have one), build a schedule.

The point of this all is: if you assume that delivery is single in time, you cannot optimize for value, value is assumed to be fixed. Except that we all know that value (aka scope) is not fixed. So if you assume that scope is fixed, and you cannot optimize for value, when you run out of time or money, you may have nothing to show for it, or you may not have completed the most valuable units.

While this is completely logical and intuitive, what we react to is that optimizing the sequence for value often introduces an opportunity to spend more, or take more time to get to done. The logic goes like this: If we deliver the most valuable unit first, some subsequent unit may require us to build differently than the first, and so we introduce some “re-work” with a less valuable unit. Re-work has a cost. It appears to be a waste. Building something that we know or suspect is temporary, or will be replaced appears to be foolish. When thinking about the plan with a view towards optimizing cost and duration, this is an unacceptable compromise, but may be completely rational when optimizing value delivery. Especially if future funding is uncertain (budget cuts are imminent), and we want to get the most value for our spend.

We have become so accustomed to optimizing cost and time that we don’t think about value in the same way. If we deliver value early, our customer can realize the value sooner, and so might be willing to negotiate on price or schedule.

Decision as Attribute

Business process documentation often reflects decisions that are made during the process that affect subsequent steps in the process. Somtimes the decision can affect the necessity of a step or the outcome of a step. When decisions are made during the process that affect subsequent steps, the result of that decision becomes a data element or attribute that feeds the decision framework for the affected steps.

By making these decisions during the process, the user is adding information to the process that must be modeled and captured.

Sometimes the decisions are non-discretionary, meaning that the decision is always made the same way. In the manual version of the business process, the human evaluates input data attributes, and makes a decision that reflects the state of the data at the time of the decision. While it appears that the human is expressing discretion over the process, in fact they are acting as automaton, merely processing the information and reflecting the state.

Other times decisions are discretionary, meaning that the decision involves some “art” of the human executing the process. This “art” or skill, may require the ability to evaluate information that is not readily available within an automation context like customer preferences or long-text instructions. Other times, the art may be evaluation of the physical state of equipment, or work product. Sometimes the “art” is knowing other facts about the world (like market conditions, competive environment, etc.) and how they impact our execution.

For discretionary decisions, often the “art” or skill is executed differently by different practitioners. In these cases, software requirements often are written to expose or present the information needed by the majority of those expressing the art or skill. Capturing their decisions, and the data that was presented, is often required for future analysis and refinement in the decision making process.

Again, discretionary or non-discretionary capturing or rendering the decision as an attribute of the process or metaphor is important in developing the decision framework for subsequent steps and processes. Capturing the information used to render or make the decision at the point of capture is important for future process improvement or operator skill evaluation.