Travel outside of your comfort zone helps to establish your beginner’s mindset.

Audio Version:  SPaMCAST 177

Why is it easier for some organizations to innovate? Why do some organizations become less flexible after a new idea is successfully implemented? I believe that the concept of the beginner’s mind holds a substantial clue about why some people and organizations either embrace or resist change.

The beginner’s mind is a concept from Zen Buddhism known as Shoshin.  It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject.  The beginner’s mind can be present even when studying at an advanced level.  Quoting the Zen teacher Shunryu Suzuki, “In the beginner’s mind there are many possibilities, in the expert’s mind there are few.”  The beginner’s mind embodies the emotional qualities of enthusiasm, creativity and optimism.  These qualities are critical for tackling tough problems and for innovation.  The beginner’s mind is just one framework for understanding why some organizations and individuals seems to embrace the boundlessness of the environment around them but nevertheless it is a powerful tool for self-reflection or judging change readiness.

I would like to address the idea of change willingness through the filter of the beginner’s mind from two perspectives: The first is from the point of view of the constraints we accept or create for ourselves and our organizations, and the second would be to reflect on attributes that help us accelerate embracing change. (more…)

Like IT professionals, perhaps too optimistic?

Like IT professionals, perhaps too optimistic?

In Software Project Estimation: The Budget, Estimate, Plan Continuum we defined a numerical continuum that makes up estimation.  There are numerous specific techniques for generating budgets, estimates and plans.  The techniques can be sorted into three basic categories.  Hybrids exist that the leverage components of each.


Expert techniques use the judgment, generally based on experience, of an individual to determine the cost, duration or effort of a project. The primary strengths of an expert approach is that it can be developed relatively quickly and is championed by a person who has developed a high level of organizational trust. The obvious weakness of these techniques is the reliance on an individual with all of his or her biases.  Dr. Ricarado Valerdi in SPaMCAST 84 noted his research has found that IT personnel are notoriously poor estimators.  One of the reasons cited in the interview was that IT personnel are generally overly optimistic of their problem solving ability. Techniques such Delphi and Planning Poker use multiple experts as a technique to fight individual bias by using collaboration in an attempt to triangulate on the better answer.  Developing an estimate or budget leverages past performance on a specific project to anchor the estimator(s) memory, and then uses judgment to determine how much one project will be like another. Expert techniques make the most sense when there is little or no data to base the prediction, for instance when a budget is being developed.

The second technique is parametric estimation.  Parametric estimation is generally an estimation technique (as opposed to a budget or a plan, although many commercial products also include planning features) that generates an estimate based on historical data of productivity, staffing and quality that is used to create a set of equations.  These equations are then fed information about the size of the project (IFPUG Function Points for example), project complexity and the predicted capabilities of the team.  Tools like SEER-SIM and COCOMO II are parametric estimation tool. The strengths of parametric estimates are derived from the historical performance data they use to generate the estimates and the enforced rigorous estimation process.  The weakness of any parametric based estimation model is that they require the estimator generate, or have access to, a numerical size which can add overhead to the project or take time that would be better spent building the software.  We have discussed the fallacy of these issues in the discussion of IFPUG function points.  A bigger issue exists when there is no historical data that can be used to generate the productivity equations.  When no data exists I would recommend seeking external data (many firms, including the David Consulting Group – my day job – and ISBSG can sell or help you with this issue).  When no trustworthy data exists, parametric estimation does not make sense.

Work breakdown structures are the third category.  This category is generally used for planning, and some cases, as means of building a bottom-up estimate.  In this category a planner or team will generate a list of tasks need to complete the job. The level of granularity of the tasks can vary greatly – I had a colleague that planned tasks at an hourly increment. Constraints, staffing and sequence can be added to the plan to generate schedule.  The sprint backlog used in Scrum is a form of this technique.  The power of the techniques are derived from a focus on what is to be done, by whom and when at an actionable level of detail. The problem is that you need an incredible amount of information about the project and project team to be able to generate an accurate task list let alone an accurate project schedule.  It is well known that the amount of data needed for this technique is generally only accurately known over short time horizons. However, I have seen processes that require detailed schedules for long projects up to a year before they are scheduled to start.   These techniques are best use for deriving short term plans.

Most IT organizations tend to fixate on one of these categories of techniques however organizations that understand differences between a budget, an estimate and a plan will use techniques from all three categories.  Using the data and knowledge gained from using each tool or technique as a feedback loop to improve the performance of all the techniques the use.  For example, an organization I recently spoke with uses both parametric and expert techniques to generate estimates on critical projects.  Both techniques cause the estimation team to surface different assumptions that need to be understood when deciding which work can be done and how much money to ask for from the business.

Under-performing Agile? Part 1 Organizational Issues

Audio Version: SPaMCAST 225

Agile is not a panacea. Regardless of methodology, technique or framework; delivery is not assured. Realistically just about anything can happen in the world we practice our profession. Tomorrow a storm could interrupt operations; another project of greater value might catch management’s eye, changing the resources or staffing available for the project. Many of the things that happen are outside of our organization’s control or at the very least outside of our control.–However many things are within our control or at least within the broader organizations control; therefore, we do not have to be victims.

These are the issues this essay will focus on as they affect the performance of Agile. So meteors hitting the planets or super storms striking will be what they are. People, processes and behaviors are another matter entirely and are the core of why most agile implementations go off the rails.

If your implementation of Agile is underperforming, where should you start looking for the problem?  I suggest that three macro areas are the typical sources of Agile performance problems:

  1. Organization
  2. Processes
  3. Contracts

The organization category relates to both the physical organization and the gravity well the organization exerts. The gravity well includes the other organizations or people that they influence. These can include suppliers, customers, suppliers to suppliers, restaurants, and dry cleaners; the list can go on and on. The bigger or more influential the company is, the deeper its gravity well. The process category includes the tools and techniques used to deliver functionality. The final category is titled contracts. Contracts can be used to govern how work is done or how it will be delivered. Agile projects governed under non-agile contracts will have issues of effectiveness and efficiency. In a broader sense, contracts tend to be a marker for low trust transactions. While contracts could be construed to be a process or organizational issue, I believe it tends to be a broader and more emotional issue; therefore, the solutions will differ.

Organization Problems

There are three major organizational problem sub-categories that impact Agile implementations:

  • Value / Cultures
  • Process
  • Contracts

Values / Cultures

The first of the sub-categories are value / cultural issues which are driven by differences in mindsets. Viewed as a dichotomy, classic management / fixed mindset and Agile management / Agile mindset are polar opposites which have very different views of ability and paths to success.  Examples of the differences in the two are as follows:

Fixed Mindset

Agile Mindset

  • Ability – static
  • Goal – look good
  • Challenge – avoid
  • Failure – defines your identity
  • Effort – for those with no talent
  • Reaction to challenge –


  • Ability – can grow
  • Goal – to learn
  • Challenge – embrace
  • Failure – provides information
  • Effort – path to mastery
  • Reaction to challenge – resilience



Mindsets are expressed in differences in how people learn and adapt which creates differing expectations of how they want to be managed and how they will tackle problems. When the mindsets of teams differ from how they are being managed, something will have to be given up. The usual victims in this equation include efficiency, effectiveness, innovation, morale and stability. Agile teams with the wrong mindset will be less than effective. Agile teams fighting managers that are managing from a fixed mindset paradigm will have tragic results.

An example of the how the two mindsets systemically differ is as follows:

The goal of someone with a fixed mindset is to look good and to avoid failures. Failure avoidance is a key behavior pattern because failure defines who you are and what you can accomplish. It will define your promotability. This type of belief structure will define how you act and react and what you expect form others.

An Agile mindset expects people to learn and grow. Growth is generated by embracing challenges. Risk and potential failure provides the experience to grow. Growth at the individual and team level will equate to greater value to the customer and to the organization.

Agile teams or teams with an Agile mindset need to push the envelope, which means a team may fail in the short run. The word failure tends to panic people in many environments. No one wants to fail; however, the only way not to fail is to always play it safe — to never stretch the envelope — to never explore new ways to address problems.

Clashes of the two very different mindsets cause conflicts. Resolution of conflict requires time, effort and mostly attention to resolve. All three of these items –time, effort and attention, are precious resources that would be better spent delivering customer value.

For further reading on how our mindset can affect our success, I recommend Carol Dweck’s Mindset: The New Psychology of Success.


The solution to the problem of a mindset mismatch is for the organization to embrace an Agile business philosophy throughout its structure or to forget being Agile all together. The change in business philosophy will help mold the organization’s culture so that an Agile mindset can flourish. The five basic tenants of an Agile business philosophy are

  1. Alignment of goals:  Supports transparency and motivation
  2. People:  A diverse skilled workforce
  3. Involvement:  Build true teams, not just collections of individuals
  4. Change:  Listen to feedback and dynamically adjust tactics and strategy
  5. Value Focus:  A single-minded focus on delivering business value that is continually reprioritized

None of these tenants will be easy to enact. I was recently told that if there wasn’t pain in the transition, you wouldn’t be doing it right.

Pseudo Experts

Everyone has an opinion about what is Agile and how to “do“ Agile. Opinions are often formed by grazing through books, articles, conferences or websites. To paraphrase a popular State Farm Insurance television commercial, “Everything you hear on web is true, right?” Unfortunately, many of the opinions, when they are put into practice, can do more harm than good.

I would like to suggest that expertise is built not only on academic knowledge but also upon experience that has generated both good and bad outcomes. Real experts are built on good doses of theory, reflection, experience, mentoring (from those who are smarter) and then experimentation (do this last).


Every Agile organization should have at least one coach. A coach helps the organization and teams by make sure they are aligned and have the tools so that learning happens. As a learning organization begins to crystalize, less coaching is needed.  Coaching will always be required however over time as learning becomes the norm we will begin to need less outside help, because everyone will be a player / coach.

Lack of Measurement

When the word performance gets used I tend to get antsy unless dealing with evidence, rather than supposition or individual anecdotes. Many immature Agile organizations think that measurement is “old” school. Without measurement, how can you build a release plan and more importantly how can you know and prove that you are delivering business value? Just saying “trust me” or “it feels better now” is not a long-term solution.

Measurement is important but there isn’t one answer. Each team may have a different set of needs; as does every organization. What I suggest is that what can be a one size fits all solution is a framework.


First every team needs to focus on what they need to know in order to plan, monitor the work it is delivering and then to know how to improve. Leveraging a framework like GQM (Goal, Question, Metric) provides teams or groups with a means of thinking through what is really important (not just what the PMO tells them is important) and what they can do to improve.  The goal of measurement is to provide information so that a team, a product or an organization can know if and how they are contribute to the results of the overall system.


Part 2 in Two Weeks.  We will pick up with the process category!