Actors playing different roles.

Actors playing different roles.

Classic requirements definition techniques, such as use cases, use roles and actors show interactions and movement of data between systems. An actor is defined as an entity that plays a specific role within a system. Conceptually, actors in systems and products are not very different from actors in a theater. In both cases, an actor can play one role in one situation and another role in another. For example, David Tennant played the role of Dr. Who and then later played the role of Alec Hardy in Broadchurch. An auto mechanic (actor) might play one role when using a piece of diagnostic software and quite a different role when entering your bill into the cash register. Actors play roles to accomplish some outcome which make them valuable for defining and documenting use cases. Actors are less useful if they are used for eliciting and documenting user stories.

Agile requirements (typically documented as user stories) use the concept of personas to identify interaction with an application or product. Personas and actors, though related concepts, are not the same and should not be used interchangeably. Use cases focus on defining a specific process and how that process will be accomplished in a step-by-step process. A user story defines an outcome, who needs the outcome and the benefit they will received. Actors and persona can be easily confused. When confused practitioners can easily fall into the habit of substituting actors for personas or vice versa, which reduces the effectiveness of which ever process is used.

Two related differences are helpful to understanding why actors and personas are very different. The first is definition granularity. Actors can be a person, group or external system, and are generally defined in very broad terms, either as a name or a short title tied to an explicit role. For example, I recently reviewed a use case for entering a purchase order that included actors for a “purchasing department clerk”, “general ledger system” and “accounting supervisor.” The purchasing clerk enters the purchase order, a feed sent to the general ledger and the accounting supervisor reviews the data entered. A persona represents one of the archetypical users that interacts with the system or product. Personas can play multiple roles depending on their current needs and motivation. A related difference is the documentation granularity in Personas: Nuts and Bolts we defined a template that included name, picture, motivation, backstory and needs. Persona are far more detailed and structured to connection between the team and the persona. Actors are typically defined as a title (note some methods add annotations however these never rise the level seen when defining a persona hence the occasional whining about persona being heavy weight).

Persona are used in user stories and generally are more robust than actors. A persona is designed to help the team understand who they are developing a system or product. The detail allows the team to “get into the archetypical users head” as user stories and functionality is developed. Actors are primarily used in use cases which are used as a tool to develop flow or process based requirements. Use cases are also often used to validate designs and as tool to drive testing activities. In these scenarios the focus is how the work will be performed and in what order rather than on why and what needs are being met. The way actors are used does not require the level of documentation to be effective.

Actors include far less detail than a persona and typically are identified at a significantly higher level of abstractions. Based on the higher level of abstraction of actors, many personas might be summarized into an actor. Both actors and personas have value however if you are using user stories, actors do not provide a deep enough understanding of the needs and motivations of the users and customers of the system. Alternately when using techniques like use cases, developing profiles archetypical users replete with their back story, needs, motivations and picture is overkill. I learned many years ago that the right tool for the right job makes the job easier.

Listen Now

Subscribe on iTunes

In this episode of the Software Process and Measurement Cast we feature three columns!  The first is our essay on the definitions of four critical words.  What do the words effectiveness, efficiency, frameworks and methodologies really mean?  These words get used ALL the time, however they really do have fairly specific meanings.  Meanings that, once understood and used to guide how we work, can help everyone to deliver more value and make our customers more satisfied!  The second column is from Jo Ann Sweeney with another of her stellar, Explaining Change columns.  In this segment, Jo Ann talks about content and a framework to guide the development of content.  Anchoring the Cast this week is Gene Hughson with another of his Forms Follows Function columns.  Gene extends his mini-series on microservices with a discussion of whether granularity is irrelevant.  Lots of content in this installment of the Software Process and Measurement Cast!

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

IMG_1249

The Goal: A Process of Ongoing Improvement, published in 1984, is a business novel. The Goal uses the story of Alex Rogo, plant manager, to illustrate the theory of constraints and how the wrong measurement focus can harm an organization. The focus of the re-read is less on the story, but rather on the ideas the book explores that have shaped lean thinking. Earlier entries in this re-read are:

Part 1                         Part 2                         Part 3                         Part 4                      Part 5

This week I attended the CMMI EMEA conference.  Kirk Botula, CEO of the CMMI institute delivered a great speech about developing and managing capability.  Capability is ability to do something.  Without capabilities, individuals, teams and organizations are powerless. Tools like the CMMI, Agile and lean provide frameworks to decide which capabilities are important and then to measure the level and impact of current capabilities. During Kirk’s talk he referenced two books.  The first was Out of the Crisis by Edwards Deming and The Goal: A Process of Ongoing Improvement by Jeff Cox and Eliyahu Goldratt.  Deming’s work defined the continuous process improvement movement, while Goldratt framed the lean movement.  Later during the week I asked a group of C-level executives if they were familiar with The Goal and the Theory of Constraints.  Unfortunately the answer was not a resounding yes.  The limited awareness is problematic because that leads to a focus on cost containment and efficiency as the most important goals over effectiveness and throughput. Over focusing on cost and efficiency leads sub-optimal performance and in the long run market failure. In this installment of Re-read Saturday we begin to encounter the nuts and bolts that make the Theory of Constraints an effective tool for structured process improvement.

Chapter 17

After dealing with the complications of a household in turmoil (Alex’s household is a reflection of a series of dependent events and statistical variability), Alex arrives at the plant to find an order for an important client is late. Alex explains how dependent events and statistical variability will lead to the sub-optimal performance of a system. Despite Alex’s revelations from observing the scout troop, his team believes they can deliver the parts in time to make the last truck at 5 PM. Alex places a ten dollar bet that the parts will not be ready ship that day due to variations in the production process.  The production of the parts requires two steps. The first step in the production process averages 25 parts per hour. In this case the production started slowly, however by the end of four hours 100 parts had been completed. Therefore the process had averaged 25 parts per hour. The production ranged from 19 parts to 32 parts. While the second step in the process had the same 25 parts per hour capacity, because of the variability of the first processes the capacity of the second process was exceeded on two occasions, therefore all 100 parts were not completed.

Chapter 18

Alex and his now attentive staff (the performance on late order has gotten their attention) attempt to determine how to control the flow of work thought the steps in the process (dependent events) as they are subject to statistical variability.They consider longer lead-time as a method to smooth the flow, because longer lead times would generate higher inventories to reduce efficiency. As a group they elect to call Johan, who introduces another new concept: bottleneck and non-bottleneck resources. A bottleneck resource is any resource that has a capacity that is equal to or less than the demand placed upon it. Any variability in the flow of work that is beyond the capacity of the bottlenecked resources will generate a backlog. While The Goal was written from the point of view of a manufacturing plant, bottlenecks can occur in any type of project. Any resource that is planned to 100% capacity is a bottlenecked resource. Through discussion with Johan the team discovers that like the scout troop the capacity of the plant is governed by the step with the least capacity. In the plant, the team needs to discover the bottlenecks that are blocking their ability to deliver effectively.

Bottlenecks are neither good or bad in their own right. A process with infinite capacity at all steps will not be efficient because resources would be under utilized. Bottlenecks can be used to generate a predictable process. This a reflection of how Alex used the slow scout in Chapter 15. Also understanding the capacity and variability of the bottleneck step will help make the process predictable.

When the staff discovers the bottleneck, it generates a process of discovery in which the team discovers that they really don’t know the process well and that the time accounting data is less than perfect. The big revelation is that looking for steps in the process with build-ups of work-in-process waiting to be addressed are an indication of a bottleneck. In this case the team finds two culprits. The first is the industrial robot that is darling of senior management and the second is the heat treatment step. The bottlenecks cannot be moved to the head of the column like Alex did to solve the problem with the boy scouts, nor can extra capacity be generated by increasing staff or buying machines. The workday ends with Alex searching for a solution.

The affect of the combination dependent events and statistical variability on the plant floor is obvious. In a manufacturing plant where processes are heavily automated variability might be low, however it still exists. In software or product development same interaction of process steps and variability exits although because the work tends to be more discovery-oriented, the variability is probably higher making the impact more substantial and less predictable. The variability in flow through the process exposes bottlenecks that limit our ability to catch up, making projects and products late or worse generating technical debt when corners are cut in order to make the date or budget.

Summary of The Goal so far:

Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture.

Chapters 4 through 6 shift the focus from steps in the process to the process as a whole. Chapters 4 – 6 move us down the path of identifying the ultimate goal of the organization (in this book). The goal is making money and embracing the big picture of systems thinking. In this section, the authors point out that we are often caught up with pursuing interim goals, such as quality, efficiency or even employment, to the exclusion of the of the ultimate goal. We are reminded by the burning platform identified in the first few pages of the book, the impending closure of the plant and perhaps the division, which in the long run an organization must make progress towards their ultimate goal, or they won’t exist.

Chapters 7 through 9 show Alex’s commitment to change, seeks more precise advice from Johan, brings his closest reports into the discussion and begins a dialog with his wife (remember this is a novel). In this section of the book the concept “that you get what you measure” is addressed. In this section of the book, we see measures of efficiency being used at the level of part production, but not at the level of whole orders or even sales. We discover the corollary to the adage ‘you get what you measure’ is that if you measure the wrong thing …you get the wrong thing. We begin to see Alex’s urgency and commitment to make a change.

Chapters 10 through 12 mark a turning point in the book. Alex has embraced a more systems view of the plant and that the measures that have been used to date are more focused on optimizing parts of the process to the detriment to overall goal of the plant.  What has not fallen into place is how to take that new knowledge and change how the plant works. The introduction of the concepts of dependent events and statistical variation begin the shift the conceptual understanding of what measure towards how the management team can actually use that information.

Chapters 13 through 15 drive home the point that dependent events and statistical variation impact the performance of the overall system. In order for the overall process to be more effective you have to understand the capability and capacity of each step and then take a systems view. These chapters establish the concepts of bottlenecks and constraints without directly naming them and that focusing on local optimums causes more trouble than benefit.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version

Two completely different personas using the same system simultaneously.

Two completely different personas using the same system simultaneously.

Personas are often used in software development to generate and group requirements. For example, one of the classic constructions of user stories is: <Persona> <Goal> <Benefit>. The use of personas has become nearly ubiquitous. A persona represents one of the archetypical users that interacts with the system or product. Every system or product will have at least one archetypical user that can be identified. The concept of personas was originally developed by Alan Cooper in his book The Inmates Are Running the Asylum. Personas represent different behaviors based on research into the jobs, lifestyles, spare time activities, attitudes, motivations, behaviors and social roles. I am often asked where a team should get a set of personas given the level of usage (as if they were a set of playing cards), and once a team gathers the data, how that data should be captured.

In most internal development enhancement and maintenance projects, personas are developed using some form of brainstorming process. Brainstorming with affinity diagraming is a great tool to develop personas. The Software Process and Measurement Blog has described the process of Affinity diagraming. The people involved in generating personas are critical. The team you use to generate personas needs to have a broad experiential base. It needs to be cross-functional and diverse. The team needs to be able to take systems views of who uses the systems or product, otherwise the list of personas and their definitions will be incomplete. Second, when generating ideas in the brainstorming session someone needs to act as a facilitator and provide seed questions to the team. The seed questions will help the team to uncover groups of users and potential users, their needs, behaviors, attitudes and both work and non-work activities. In the grouping portion of the affinity diagraming process, the team should first think about personas when grouping and then when naming the groups ask the team to give the groups persona names. A further twist on the tried and true affinity session mechanism that I have recently found to be effective is to have the team break up in to smaller sub-teams to review what was done and re-brainstorm entries that could fill the gaps after the grouping and naming exercise. I generally time box the second step to fifteen minutes, although time-boxing may constrain innovation. When the sub-teams return integrate the new entries into the affinity diagram. The named and grouped entries from the affinity diagram will form the basis for the documentation needed to capture the personas.

Documenting personas might be the most contentious part of the process of establishing and using personas. Documentation smacks of overhead to many in the development community. I have found that if you don’t take the time to document a persona, it is far less useful. Documenting personas does a number of things. First the act of documentation allows the team to flesh out their ideas and drive out gaps and inconsistencies. Second, documentation helps the team to establish collective memory. Third, fleshing out the nuances fleshed out and establishing institutional memory makes it more likely that the team will refer to the persona after development because the investment in time and effort generates a perception of value. When documenting personas, ensure that you keep the documentation to the absolute minimum. I use a single sheet of flip chart paper per persona; not only does the single sheet feel lean, it also allows teams to post the personas around the room. Templates are good to for maintaining repeatability.

In Agile Story Maps: Personas we discussed and referenced a template defined by Roman Pitchler. There are a wide variety of templates for capturing information about a persona. In general they all include the following information:

  1. Persona Name
  2. Picture: a picture gives the persona visual substance and personality.
  3. Job: What does a person in this archetypical group do for a living (as it relates to the product or system).
  4. Goal: A definition of why the persona would want to use the product or system. Support of the goal can be found in the more personality and lifestyle (often written as backstory) of the persona.
  5. Personality: How does the group that the persona represents think, act, or react. This attribute includes motivation, attitudes, behaviors and social roles.
  6. Lifestyle: How does the group that the persona represents actually act? What does the persona do both at work and in their spare time?

Every template that I have seen (or created) is nuanced based on the needs of the team and the project. For example, the personas generated to guide developing requirements for an enhancement to a data entry application would be different from the personas needed to plan a major Agile conference. In the latter case more emphasis might be needed around motivation and lifestyle which would influence the speakers that might be accepted, social events planned and when the speakers and events might be slotted in the schedule. Teams use personas to help them think conceptually about the problem they are trying to solve without getting bogged down by having to think about and address each individual that uses the system or product as a special, individual case.

Personas are a tool help teams to understand a class of users by creating an archetypical user. Personas need to be identifiable and have back-story that includes needs and goals. The use of fictional people allows the team to dissociate themselves from the large number of individuals in the user base so they don’t get trapped in paralyzing detail. Personas need to be written down or you will not remember the nuances of personalities and lifestyles that make any two personas different.

Are you ready to build change?

Are you ready to build change?

Many times an organization or individual will start a change program because they deem it necessary for survival. But change is never easy. Survival and pain avoidance, while powerful, can lead to pursuing change as a reaction to pain rather than as pursuit of value. Pain avoidance and generation of business value both are necessary pieces of knowledge as the intellectual benefits persuade, while pain avoidance sells. In order to ensure that both sides of the change are addressed a framework can be useful to generate focus. The simple CMMI Readiness Checklist can be used for any major change initiative, but is tailored toward the testing whether the requirements for implementing a framework like the CMMI have been addressed.

I have broken this checklist into three categories: resources, plans and attitudes.  Each can be leveraged separately; however using the three components will help you to focus on the big picture.

Scale

The simple checklist can be used as a tool to evaluate how well you have prepared for you CMMI journey using the questions as evaluation criteria.  To use the checklist, evaluate each question on a scale of high, medium, low and not present (with one exception). Each question will potentially contribute points toward the total that can be used to evaluate preparation.

Section and Question Weights:

Resources: Forty-two total points. Each component contributes up to 7 points (7, 3, 1, 0).

Plans: Eighteen total points. Each component contributes up to 6 points (6, 3, 1, 0).

Attitude: Forty total points. Each component contributes up to 8 points (8, 4, 2, 0).

Resources

Resources are the raw materials that you will consume on your journey.  As with any journey having both the correct resources and correct amount of resources will make the journey easier.  Just think of trying to canoe from New York to London for a meeting; the wrong resources can make the trip difficult.

Management Support

Support from management is critical as we have discussed in past checklists, but so is support from your peers and from the teams that will be using the processes.

Score

7 – Senior management is actively involved in guiding and using the outputs of the CMMI.  Senior managers stop people in the hall to discuss progress and recently process implementations. Discussion of progress is an agenda item at all managers staff meetings.

3 – Senior and middle managers attend formal CMMI informational meetings and talk about the need to support the CMMI initiative.

1 – Senior managers attended the kick-off meeting, then relocating in mass to Aruba, leaving the middle managers in charge.

0 – The change initiative is a grass-roots effort.

Cash

Change costs money. Costs can include consultants, training, travel and an odd late-night pizza or two.

7 – A reasonable budget has been established and the implementation team can draw from the budget for planned expenditures.  Emergency funding can be attained to handle issues.

3 – A reasonable budget has been established and approved; however, access must be requested and justified for all expenditures.

1 – Any time that money is required funding must be requested and approved.

0 – Donations are sought in the organization’s lunchroom on a periodic basis (consider a PayPal donation button on your homepage).

Effort

Even if you have bales of cash, developing and implementing processes will require effort. Effort will be required from many constituencies including the process-improvement team, management and from the teams using the process, just to name a few.

7 – A reasonable staffing plan has been established and the change program is the only project the assigned resources have been committed to.

4 – A reasonable staffing plan has been established and the change initiative is the highest priority for the assigned resources.

1 – All resources are shared between the change initiative and are also assigned to other projects with high priority.

0 – You have all the effort you need after 5 PM and before 8 AM and during company holidays.

Change Specialist

Organizational change requires skills that are not generally found in an IT department. The skills needed include sales, marketing and communication.

7 – An organizational-change specialist has been assigned as a full-time resource for the project.

3 – An organizational-change specialist is available within the organization and works on many projects simultaneously. The specialist may or may not have had experience with IT change programs.

1 – Someone on the team has helped craft an organizational change plan in the past.

0 – Organizational change websites are blocked and your best bet is buying a book on Amazon using your own cash.

Projects

Change requires something to impact.  The organization needs to have a consistent flow of projects so that changes are not one-shot attempts.

7 – Projects are constantly beginning that will provide a platform for implementing process changes.

3 – There are numerous projects in the organization; however they typically begin early in the year or on some other periodic basis that makes waiting a necessity if you are not ready exactly on time.

1 – The organization does only a small number of projects every year.

0 – The organization does one large project every year.

Calendar Time

Calendar time is a resource that is as important as any other resource. Severe calendar constraints can lead to irrational or bet-the-farm behaviors which increase risk.

7 – The schedule for implementing the CMMI is in line with industry norms and includes time for tweaking the required processes before appraising.

3 – The schedule is realistic but bare bones. Any problems could cause delay.

1 – Expectations have been set that will require a compressed schedule; however, delay will only be career limiting rather than a critical impact on the business.

0 – The CMMI implantation is critical for the organization’s survival and is required on an extremely compressed schedule.

Expertise

A deep understanding of the CMMI (or any other framework for that matter) will be needed to apply the model in a dynamic environment.  Experience is generally hard won. “Doing” it once generally does not provide enough expertise to allow the level of tailoring needed to apply the model in more than one environment. Do not be afraid to get a mentor if this is a weakness.

7 – The leaders and team members working to implement the CMMI have been intimately involved in successfully implementing the framework in different environments.

3 –The leader and at least one of the team members have been involved in implementing the CMMI in the past in a similar environment.

1 – Only the leader of the CMMI program has been involved with implementing the CMMI in another environment.

0 – All of the team members have taken the basic CMMI course and can spell CMMI assuming they can buy a vowel.

Plans

Planning for the implementation of change can take many forms — from classic planning documents and schedules to backlogs.  The structure of the plan is less of a discussion point than the content.  You need several plans when changing an organization. While the term “several” is used this does not mandate many volumes of paper and schedules, rather that the activities required are thought through and recorded, the goal is known and the constraints on the program have been identified (in other words the who, what, when, why and how are known to the level required).

Scale and Scoring

Plans: Eighteen total points. Each component contributes up to 6 points (6, 3, 1, 0).

Organizational Change Plan

The Organizational Change Plan includes information on how the changes required to implement the CMMI will be communicated, marketed, reported, discussed, supported, trained and, if necessary escalated.

6 – A full change management plan has been developed, implemented and is being constantly monitored.

3 –An Organizational Change Plan is planned but is yet to be developed. .

1 – When created, the Organizational Change Plan will be referenced occasionally.

0 – No Organizational Change Plan has or will be created.

Backlog

The backlog records what needs to be changed in prioritized order. The backlog should include all changes, issues and risks. The items in the backlog will be broken down into tasks as they are selected to be worked on.  The format needs to match corporate culture and can range from an Agile backlog to in a waterfall organization, a requirements document.

6 – A prioritized backlog exists and is constantly maintained.

3 – A prioritized backlog exists and is periodically maintained.

1 – A rough list of tasks and activities is kept on whiteboard.

0 – No backlog or list of tasks exists.

Governance

Any change program requires resources, perseverance and political capital. In most corporations these types of requirements scream the need for oversight (governance is a code word for the less friendly word oversight). Governance defines who decides which changes will be made, when they will be made and who will pay for the changes. I strongly recommend that you decide how governance will be handled and write it down and make sure all of your stakeholders are comfortable on how you will get their advice, counsel, budget and in some cases permission.

6 – A full-governance plan has been developed, implemented and is being constantly monitored.

3 –A governance plan is planned, but is yet to be developed.

1 – When created, the governance plan will be used to show the process auditors.

0 – Governance . . . who needs it!

Attitude

When you talk about attitude it seems personal rather than organizational, but when it comes to large changes I believe that both the attitude of the organization and critical individuals are important.  As you prepare to address the CMMI, the onus is on you as a change leader to develop a nuanced understanding of who you need to influence within the organization. The checklist will portray an organizational view; however, you can and should replicate the exercise for specific critical influencers.

Scale and Scoring

Attitude: Forty total points. Each component contributes up to 8 points (8, 4, 2, 0).

Vision of tomorrow

Is there a belief that tomorrow will be demonstratively better based on the actions that are being taken? The organization needs to have a clear vision that tomorrow will be better than today in order to positively motivate the team to aspire to be better than they are.

8 – The organization is excited about the changes that are being implemented.  Volunteers to help or to pilot are numerous.

4 – Most of the organization is excited about most of the changes and their impact on the future.

2 – A neutral outlook (or at least undecided) is present.

0 – Active disenchantment with or dissension about the future is present.

Minimalist

The view that the simplest process change that works is the best is important in today’s lean world.  In many cases heavy processes are wearing on everyone who uses them and even when the process is okay today, entropy will add steps and reviews over time, which adds unneeded weight.  Score this attribute higher if the organization has a process to continually apply lean principles as a step in process maintenance.

8 – All processes are designed with lean principles formally applied.  Productivity and throughput are monitored to ensure that output isn’t negatively impacted.

4 – All processes are designed with lean principles formally applied; however, they are not monitored quantitatively.

2 – All processes are designed with lean principles informally applied.

0 – Processes are graded by the number of steps required, with a higher number being better.

Learner

A learner is someone that is learning understands that they don’t know everything and that mistakes will be made. They understand that when made, mistakes are to be examined and corrected rather than swept under the carpet. Another attribute of a learner is the knowledge that the synthesis of data and knowledge from other sources is required for growth.  In most organizations, an important source of process knowledge and definition are the practitioners — but not the sole source.

8 – New ideas are actively pursued and evaluated on an equal footing with any other idea or concept.

4 – New ideas are actively pursued and evaluated, but those that reflect the way work is currently done are given more weight.

2 – The “not invented here” point of view has a bit of a hold on the organization, making the introduction of new ideas difficult.

0 – There is only one way to do anything and it was invented here sometime early last century.  Introduction of new ideas is considered dangerous.

Goal Driven

The organization needs to have a real need to drive the change and must be used to pursuing longer-term goals. The Process Philosopher of Sherbrooke once told me that being goal-driven is required to be serious about change.  In many cases a good, focused near-death experience increases the probability of change, but waiting that long can create a negative atmosphere. A check-the-box goal rarely provides more than short-term localized motivation.

8 – The organization has a well-stated positive goal and that the CMMI not only supports, but is integral to attaining that goal.

2 – The pursuit of the CMMI is about checking a box on a RFP response.

0 – CMMI is being pursued for no apparent purpose.

Conviction

Belief in the underlying concepts of the CMMI (or other change framework) provides motivation to the organization and individuals.  Conviction creates a scenario where constancy of purpose (Deming) is not an after-thought but the way things are done. Implementing frameworks like the CMMI are long-term efforts — generally with levels of excitement cycling through peaks and valleys.  In the valley when despair becomes a powerful force, many times conviction is the thread that keeps things moving forward. Without a critical mass of conviction it will be easy to wander off to focus on the next new idea.

8 – We believe and have evidence that from the past that we can continue to believe over time.

4 – We believe but this is the first time we’ve attempted something this big!

2 – We believe  . . . mostly.

0 – No Organizational-Change Plan has been created.

Scoring

Sum all of the scores and apply the following criteria.

100 – 80   You have a great base; live the dream.

79 – 60   Focus on building your change infrastructure as you begin the CMMI journey.

59 – 30   Remediate your weaknesses before you start wrestling with the CMMI.

29 –   0   Run Away! Trying to implement the CMMI will be equivalent to putting your hand in the garbage disposal with it running; avoid if you absolutely can!

www.spamcast.net

                       www.spamcast.net

Listen Now

Subscribe on iTunes

In this episode of the Software Process and Measurement Cast we feature our interview with Agile coach Mario Lucero.  Mario and I discussed the nuts and bolts of coaching Agile teams, what is and isn’t Agile and the impact of coaching on success. Mario provided insights on Agile that span both Americas!

Mario describes himself as an Agile evangelist (including Kanban) delivering coaching for Agile transformations and Scrum mastery. He performs as a Scrum Master for several teams while mentoring and coaching other teams, Scrum Masters and product owners.

Mario is as comfortable advising senior management on the Agile transformation strategy and implementation as he is working with teams.

Email: metlucero@gmail.com

Twitter: @metlucero

Blog:  http://mariolucero.cl/

LinkedIn: http://cl.linkedin.com/in/luceromet/en

Call to action!

Can you tell a friend about the podcast? If your friends don’t know how to subscribe or listen to a podcast, show them how you listen and subscribe them!  Remember to send us the name of you person you subscribed (and a picture) and I will give both you and the horde you have converted to listeners a call out on the show.

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

CMMI Institute Conference EMEA 2015
March 26 -27 London, UK
I will be presenting “Agile Risk Management.”
http://cmmi.unicom.co.uk/

QAI Quest 2015
April 20 -21 Atlanta, GA, USA
Scale Agile Testing Using the TMMi
http://www.qaiquest.org/2015/

DCG will also have a booth!

Next SPaMCast

The next Software Process and Measurement Cast will feature our essay on the definitions of four critical words.  What do the words effectiveness, efficiency, frameworks and methodologies really mean?  These words get used ALL the time, however they really do have fairly specific meanings.  Meanings that, once understood and used to guide how we work, can help everyone to deliver more value and make our customers more satisfied!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

IMG_1249

The Goal: A Process of Ongoing Improvement, published in 1984, is a business novel. The Goal uses the story of Alex Rogo, plant manager, to illustrate the theory of constraints and how the wrong measurement focus can harm an organization. The focus of the re-read is less on the story, but rather on the ideas the book explores that have shaped lean thinking. Earlier entries in this re-read are:

Part 1                         Part 2                         Part 3                         Part 4

In the next 4 chapters Alex stumbles on the how the concepts of dependent events and variability affect the flow of work, nearly literally.

Chapter 13

Chapter 13 begins with Alex awaking to his son, Dave, in his Boy Scout uniform waiting to go on a weekend hike and camping trip. Alex ends up as the leader due to the absence of the normal scout master.   The column of scouts sets out with an adult, Ron, leading the way. Alex asks Ron to set a pace that is consistent and maintainable. The scouts create a queue based on the arcane rationale of young boys, and Alex anchors to the column to ensure the troop stays together. The column spreads out immediately even though everyone is moving at the same “average” speed. The interaction amongst the hikers is a series of dependent events. Scouts speed up and slow impacting those behind them. The act of speeding up and slowing down is the statistical variation described in Chapter 12. The speed of any individual hiker is influenced by the person directly ahead them in the line. Finally Alex realizes that the speed of the overall hike is less a reflection of first person in line than the last person in line. In the software-testing world, testing is not complete when the first test is done, but rather when the last test is completed.

Side Note: Anyone that wants to understand why every effort should be made to remove or reduce dependencies needs to read these this of chapters carefully. Dependencies make any process A LOT more complicated.

Chapter 14

Rogo considers how to reduce the statistical variation in the column. While stopping for lunch, Alex recruits a few of the scouts to play a game using match sticks, bowls and a die (they are boy scouts . . . ready for anything, including dice games). The game is played by moving match sticks between bowls. The number match sticks moved in each step is based on the roll of the die. As Alex gathers statistics by repeating the game, the combination of dependent events (movement of the match sticks from one bowl to another) and statistical variation (die roll) show him how build ups of inventory occurs between steps. The flow of work becomes irregular and unmanageable.

Side Note: This is a great game to play with software teams to drive home the point of the impact of variability.

Chapter 15

As the troop starts out from lunch, Alex considers the concept of reserves as a mechanism to fix the flow problem (spreading out) the troop is having. He watches the slowest kid in the troop fall behind and then sprint to catch up over and over, generating a large gaps in the line. The troop is utilizing all of its energy to stay together meaning that it has no spare capacity to recover when gaps appear. Consider software teams that generate plans with 100% utilization. As any developer or tester knows nothing goes exactly as planned, and as soon as a problem is encountered you are immediately behind if you are 100% utilized.

Another option he considers is to have everyone hike as fast as they can individually. In this scenario everyone would optimize their individual performance. The outcome would be chaos with scouts strung out all over the trail. With the troop spread out on the it would be impossible to know when the last person would get to the camp for the night.  Remember the hike is only complete when the last person gets to camp, therefore chaos does not promote predictability. In Alex’s plant, even though they are using robot and each step is running at high levels of efficiency orders are not completing on-time. Similar problems can be seen in many software projects with developers and testers individually running at 100% capacity and high levels of efficiency while functionality is delivered well after it was promised.

When Rogo realizes that the process is only as fast as the slowest person, he decides to re-adjust the line of scouts so that the slowest is in front. The gaps immediately disappear. With the process now under control he can shift to helping the slowest person speed up, therefore improving the whole process.

Chapter 16 moves the novel plot forward with Julie, Alex’s wife, dumping Alex’s daughter at Alex’s mother’s house and leaves Alex.

Chapters 13 – 15 drive home the point that dependent events and statistical variation impact the performance of the overall system. In order for the overall process to be more effective you have to understand the capability and capacity of each step and then take a systems view. These chapters establish the concepts of bottlenecks and constraints without directly naming them and that focusing on local optimums causes more trouble than benefit.

Summary of The Goal so far:

Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture.

Chapters 4 through 6 shift the focus from steps in the process to the process as a whole. Chapters 4 – 6 move us down the path of identifying the ultimate goal of the organization (in this book). The goal is making money and embracing the big picture of systems thinking. In this section, the authors point out that we are often caught up with pursuing interim goals, such as quality, efficiency or even employment, to the exclusion of the of the ultimate goal. We are reminded by the burning platform identified in the first few pages of the book, the impending closure of the plant and perhaps the division, which in the long run an organization must make progress towards their ultimate goal, or they won’t exist.

Chapters 7 through 9 show Alex’s commitment to change, seeks more precise advice from Johan, brings his closest reports into the discussion and begins a dialog with his wife (remember this is a novel). In this section of the book the concept “that you get what you measure” is addressed. In this section of the book, we see measures of efficiency being used at the level of part production, but not at the level of whole orders or even sales. We discover the corollary to the adage ‘you get what you measure’ is that if you measure the wrong thing …you get the wrong thing. We begin to see Alex’s urgency and commitment to make a change.

Chapters 10 through 12 mark a turning point in the book. Alex has embraced a more systems view of the plant and that the measures that have been used to date are more focused on optimizing parts of the process to the detriment to overall goal of the plant.  What has not fallen into place is how to take that new knowledge and change how the plant works. The introduction of the concepts of dependent events and statistical variation begin the shift the conceptual understanding of what measure towards how the management team can actually use that information.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version

Follow

Get every new post delivered to your Inbox.

Join 4,244 other followers