A Sweet Spot!

In the essay, Balancing Control and Self-Organization to Avoid Heat Death I said that there is a need to strike a balance between controlling how individuals and teams work and just letting people do their own thing.  Stated slightly differently, there needs to be a balance between autonomy and control.

Finding The Sweet Spot!

In a world where organizations like Theranos (over control) and the City of Flint, Michigan (laissez-faire crisis management) exist, organizations have to find a way to make sure they attain their goal without killing the company or injuring their customers. A framework that guides how workflows and decisions are made provides structure so that decisions can be made when a crisis occurs (crises are inevitable). Too much or too little control makes decision making more difficult when a crisis occurs. Every organization has to find a balance between control and autonomy. Every organization and team will have a specific Goldilocks answer. This is true for whole organizations as well as software teams that have embraced agile frameworks and methodologies.  One size does not fit all without a bit of tailoring. This premise is not the controversial part of our last essay, the problem is that the word control bothered some of the readers. (more…)

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. (http://www.dsdm.org/)
  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 (http://disciplinedagiledelivery.com/)
  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. (http://scaledagileframework.com/)

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. 

Different philosophies yields different perspectives.

Different philosophies yields different perspectives.

The approach an organization takes to Agile user acceptance testing (UAT) depends on a number of factors. These factors generate the environment that will define how the organization approaches Agile testing.  The types of factors that influence Agile testing can be as global as whether customer satisfaction or efficiency drives behavior, or as tactical was whether manual or automated testing is used. While the potential factors that influence an organization’s Agile testing philosophy can be numerous, generally three factors are the most definitive: the influence of lean, use of test frameworks and the stance on text automation.

Lean: Agile and lean philosophies have become difficult to untangle. Philosophically, Agile can be represented by short, complete cycles with frequent customer feedback and an acceptance of the potential for change that feedback creates.  Philosophically, lean represents the relentless pursuit of efficiency. A common combination of the two philosophies is the use of the single-source information practice, where information is captured once and then reused. Acceptance test cases represent a perfect scenario to merge Agile and lean philosophies. Requirements are captured once and written as acceptance tests. This application of the single source philosophy avoids documentation (avoidance of a specific requirements artifact), reduces the possibility of transposition or misinterpretations between requirement artifacts, and can reduce the effort needed for bi-directional traceability. Organization that have not embraced a lean philosophy along with Agile may well leverage separate documentation techniques for stories and acceptance test cases.

Test Frameworks: Frameworks, such as Cucumber, provide a structure to think about acceptance tests.  For example, the “given, when, then” structure used in Cucumber provides a mechanism to not only focus on writing tests that can be automated, but also tests that are readable. Another framework for defining tests is “arrange, act, assert,” however this is generally used as a unit test pattern rather than an acceptance test pattern.  Readable tests increase the likelihood that more than just the most technical team members will be actively involved, which will result in better tests and higher delivered quality. Test definition frameworks like Cucumber are are generally linked to the use of test automation tools, however use frameworks to provide structure and discipline to acceptance criteria and testing even if you are not using a test automation tool.

Automation:  Test automation can be a game changer. Automation of acceptance testing can help increase the overall productivity of acceptance testing and increase the efficiency. Automation generally means that you can run more tests in less time than a manual tester.  Automated tests can also be rerun as the code base changes. However, automation is not cost free (we will explore this in depth later in the week), requiring time and effort to develop and maintain testing scripts (and possibly to pay for the software). In every case, the use of test automation is a balancing act between cost and benefit. Remember that automated testing is a great tool for efficient acceptance testing, but ultimately automation will need to be combined with manual techniques like exploratory testing to provide the broadest mirror of the production environment.

How an organization approaches Agile acceptance testing in the short run will be driven by the organization’s philosophies on lean, frameworks and automation. None of the decisions that an organization makes in these categories are trivial. A lean focus will guide an organization toward minimalistic techniques and methods, which influence how teams work and test.  Adopting standard frameworks for acceptance enhances communication within the team. Testing automation is a great tool but will require time, effort and money in order to implement.  Organizational philosophy will determine which paths are possible and in the end which path is taken.


Software development frameworks and methodologies are roadmaps.  Frameworks provide scaffolding based on a set values and principles. Methodologies (as we noted here) augment a framework with tools, processes and practices. One framework can be implemented by many methodologies, each representing different interpretations of the embedded values and principles.  Each different interpretation requires a different combination of tools, processes and practices.

Disciplined Agile Delivery (DAD) is a methodology that builds on many other frameworks and methodologies, including Extreme Programming (xP), which is also a methodology. Even though xP predates the Agile Manifesto (Kent Beck the creator of xP helped create the Agile Manifesto), both xP and DAD leverage Agile as their core framework.  DAD uses a three phase structure: inception, construction and transition, with iterations/sprints, stand-ups, demonstrations and retrospectives as processes in all phases.  xP features a flow that begins with an architectural spike followed by release planning, construction iterations, acceptance tests and small releases. Both represent very different implementations of Agile.

There isn’t a one-to-one relationship between software development frameworks and methodologies. One framework can be interpreted, and therefore implemented, in many different ways.  Different does not mean wrong, but it does mean that anyone that wants to embrace a specific framework needs to find (or create) a methodology that fits their interpretation of the values and principles within the framework.