Barbecue Recipe

A recipe is a form of procedure!

Models, frameworks, and methodologies are like the three outer layers of a matryoshka doll.  Once we have opened up the layers from models to frameworks and methodologies, components focused on defining “what” steps or tasks needed to build or deliver a product, the next set of layers shift to defining how to do a specific task or groups of tasks. The next three layers of our process architecture matryoshka doll are processes, procedures and techniques.  Each layer is more granular.

Processes are the workhorses of the most software departments. Processes define well-documented, repetitive groups of tasks and decisions needed to achieve an outcome. A simple example of a process is the steps needed to hold a standup meeting. A process provides a view of the main elements needed to meet the processes business goals.



Similar, but not the same.

Models, frameworks, methods, processes, procedures, and the list goes on and on.  Whether we are discussing Agile or plan based software development, works like methods, models, frameworks, processes and others are often used.  The people that use these terms in polite conversation often assume or imply a hierarchy in these terms.  For example, a model might include one or more frameworks and be instantiated in several methods. Each layer in the hierarchy breaks down into one or more items at the next level. Words and their definitions are an important tool to help understand how all the pieces and parts fit together and how to interpret the conversations about how software is developed and maintained in the lunch room or in hallways at conferences like Agile 2016. The unfortunate part is that few people agree on the hierarchy of models, methods, and frameworks.  These words are often used synonymously sowing seeds of confusion and mass hysteria (ok , that might be a teeny tiny overstatement). 

A proposed process hierarchy or architecture is as follows: (more…)

Warning: Ejection Seat

You have to plan where you’re going so you end up in the right seat.

“The new year stands before us, like a chapter in a book, waiting to be written. We can help write that story by setting goals.” – Melody Beattie 

Setting goals is an important ritual that marks the end of one year and the beginning of the next. It is an avenue for introspection, a filter to sort out the irrelevant, and to influence behavior. A goal is a statement of a person’s, team’s or organization’s ambition.  A goal can be strategic or tactical depending on how a goal is stated.  You can use a framework to consistently develop goals. A consistent framework can help you not to forget some key considerations that are useful for translating an idea into action. Such as ensuring goals are tangible enough to be measured. There are a huge number of frameworks, including SMART, PASTIE, and BHAG to name a few. (more…)


“I never knew anybody . . . who found life simple. I think a life or a time looks simple when you leave out the details.” – Ursula K. Le GuinThe Birthday of the World and Other Stories

The act of measurement either reflects how work was done, how it is being done and what is possible in the future. A measurement framework that supports all of these goals is going to have to reflect some of the details and complexity that are found in the development (broad sense) environment. The simple Agile measurement framework uses the relationships between the areas of productivity, quality, predictability and value to account and reflect real world complexity and to help generate some balance. Each quadrant of the model interacts with the other to a greater or lesser extent. The following matrix maps the nuances between the quadrants.

Impact Matrix

Impact Matrix

The labor productivity quadrant most directly influences the value quadrant. Lower productivity (output per unit of effort) equates to higher costs and less value that can be delivered. Pressure to increase productivity and lower cost can cause higher levels of technical debt, therefore lower levels of quality. Erratic levels of productivity can be translated into time-to-market variability.

Predictability, typically expressed as velocity or time-to-market, most directly interacts with quality at two levels. The first is terms of customer satisfaction. Delivering functionality at a rate or date that is at odds with what is anticipated will typically have a negative impact on customer satisfaction (quality). Crashing the schedule to meet a date (and be perceived as predictable) will generally cause the team to cut corners, which yields technical debt and higher levels of defects. Lower quality is generally thought to reduce the perceived value of the functionality delivered.

Quality, measured as technical debit or delivered defects, has direct links to predictability (noted earlier) and value. The linkage from quality to value is direct. Software (or any other deliverable) that has lower quality than anticipated will be held in lower regard and be perceived as being less useful. We have noted a moderate relationship between labor productivity and quality through technical debt. This relationship can also be seen through the mechanism of fixing defects. Every hour spent fixing defects is an hour that would normally be spent developing or enhancing functionality.

Value, measure as business value or return on investment, is very strongly related to productivity and value (as noted earlier).

Based on the relationships we can see that a focus on a single area of the model could cause a negative impact on performance in a different quadrant. For example, a single minded focus on efficiency can lead to reduced value quality and more strongly less value to stakeholders. The model would suggest the need to measure and set performance level agreements for value if labor productivity is going to be stressed.

The simple Agile measurement framework provides a means to understand the relationships between the four macro categories of measurement that have been organized into quadrant. Knowledge of those relationships can help an organization or team to structure how they measure to ensure approach taken is balanced.

Without a framework, the building falls.

Without a framework, the building falls.

Team-based frameworks, techniques and methods have dominated the discussion over short history of Agile as a named movement. Concepts like Scrum and Extreme Programing (just two of the more prominent frameworks) caught the interest of software developers and IT management for many reasons, including the promise of customer responsiveness, faster delivery rates, increased productivity and the implementation excesses of heavyweight frameworks, such as the CMMI. Excess of the later still resounds in the minds of many developers, process improvement specialist and IT leaders. The fear of excess overhead and administration has dampened the discussion and exploration of techniques to scale Agile to the address program level and enterprise issues.  In the past few years, three primary frameworks have emerged to vie for the heavyweight championship of Agile. They are:

  1. Dynamic Systems Development Method (DSDM). DSDM is a project delivery/system development method. Originally released in 1994, DSDM predates the Agile Manifesto and was one the frameworks that drove the evolution of lightweight incremental development. DSMD takes a broader view of projects and integrates other lifecycle steps into the framework on top of a developer lead Scrum team. The framework has been tailored to integrate the PRINCE2 (European Project Management Standard) as a project and program management tool. DSDM is open source. (
  2. Disciplined Agile Delivery (DAD). DAD is a framework that incorporates concepts from many of the standard techniques and frameworks (Scrum, lean, Agile modeling and Agile Unified Process to name a few) to develop an organizational model. Given that DAD was developed and introduced after the introduction of Agile-as-a-movement, DAD explicitly reflects the Agile principles espoused in the Agile Manifesto while reflecting organizational scaling concerns. DAD has been influenced and championed by Scott Amber (Disciplined Agile Delivery: A Practitioner’s Guide to Agile, 2012) and IBM. The model is proprietary (
  3. Scaled Agile Framework Enterprise (SAFe). SAFe as a framework leverages Kanban as tool to introduce organizational portfolio management and then to evolve concepts to programs to project and finally to Scrum teams. SAFe explicitly addresses the necessity of architecture to develop in lockstep with functionality. As with DSDM and DAD, SAFe’s goal is provide a framework to scale Agile in a manner that addresses the concerns and needs to the overall business, IT and development organizations. SAFe is a proprietary framework that was originally developed by Dean Leffingwell and now is supported by the company Scaled Agile. (

There is a huge amount of controversy in the Agile community about the need for frameworks for scaling Agile, as evidenced by shouting matches at conferences and the vitriol on message boards. However many large organizations in both commercial and governmental organizations are using DSDM, DAD and SAFe as mechanisms to scale Agile.  Shouting is not going to stop what many organizations view as a valuable mechanism to deliver functionality to their customers.

Size matters

Size matters.

All jokes aside, size matters. Size matters because at least intellectually we all recognize that there is a relationship between the size of product and the effort required to build. We might argue over degree of the relationship or whether there are other attributes required to define the relationship, but the point is that size and effort are related. Size is important for estimating project effort, cost and duration. Size also provides us with a platform for topics as varied as scope management (defining scope creep and churn) to benchmarking. In a nutshell, size matters both as an input into the planning and controlling development processes and as a denomination to enable comparison between projects.

Finding the specific measure of software size for your organization is part art and part science. The selection of your size measure must deliver the data need to meet the measurement goal and to fit within the corporate culture (culture includes both people and the methodologies the organization uses). A framework for evaluation would include the following categories:

  • Supports measurement goal
  • Industry recognized
  • Published methodology
  • Useable when needed
  • Accurate
  • Easy enough
A good framework helps Agile and waterfall teams flow together.

A good framework helps Agile and waterfall teams flow together.

A process framework provides a common language and outline to estimate.  The outline provides a scaffold into which project or program specific processes and functions can be inserted. An estimation framework will define a structure for estimation, the relationship between how estimation is being performed and both other engineering processes and program and portfolio level processes.  For example, in a program with Agile and waterfall teams, a framework would define how estimates generated by the different teams would relate and integrate.  A framework helps estimation become a repeatable process and also to help organizations institutionalize estimation.

A repeatable process, defined as a common set of actions that ensure the efficient use of resources and reduce variation, provides the routines needed for teams focus their creativity on delivering value rather than defining process. Reducing variation does not mean that Agile teams have to estimate the same way as waterfall team, rather that they follow a process that is appropriate to Agile methods. For example Agile teams leveraging a framework that called for estimates might use a combination of story points, planning poker and capacity while waterfall teams used parametric estimation processes. The more complex the project or program environment, the more useful frameworks are in reducing variability as teams do not have determine how estimates should be done and how they should integrate.

An institutionalized process is a process or set of processes that have become part and parcel of how team or organization delivers value. An estimation framework helps both teams and organizations know when and where to perform estimation so that performing the process is ingrained. Processes that are institutionalized don’t revert to chaos or into redefinition mode when projects are stressed; muscle memory takes over and the work gets done in an appropriate manner.

An estimation framework in a complex (but typical) IT organization must account for the needs of not only Agile team and waterfall teams, but also project, programs and portfolios that have teams that are using different techniques. Couple that with project and program offices that have different reporting requirements (some regulatory and/or contractual) and estimation needs get complicated.  Defining a framework so that all parties understand what needs to happen, when it needs to happen and the information that needs to be shared is not just important, it is required.