Erik on Software

New Book Review: "Diagnosing and Changing Organizational Culture"

New book review for Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework (Third Edition), by Kim S. Cameron and Robert E. Quinn, Jossey-Bass, 2011, reposted here:

In the introduction to this book, the authors share the familiar Tom Peters quote, "If you're not confused, you're not paying attention", because the purpose here is "not to offer one more panacea for coping with our turbulent times or to introduce another management fad." In the words of the authors, this book "provides a framework, a sense-making tool, a set of systematic steps, and a methodology for helping managers and their organizations adapt to the demands of the environment. It focuses less on the right answers than it does on the methods and mechanisms available to help managers change the most fundamental elements of their organizations" at the cultural level.

While the authors also state that other proposed approaches to measuring organizational culture have been proposed, and that their intent is not to provide an extensive review of this literature, they also provide what I consider important background information to the Organizational Culture Assessment Instrument (OCAI), which includes the facts that the OCAI (based on the Competing Values Framework) is probably the most frequently used instrument for assessing organizational culture in the world today, and that although some versions are longer, some including up to 24 items that together describe organizational culture, the 6 items that are used in this book provide a simpler synthesis that addresses fundamental manifestations of organizational culture.

After walking through the OCAI current profile worksheet, which addresses basic assumptions (dominant characteristics, organizational glue), interaction patterns (leadership, management of employees), and organizational direction (strategic emphasis, criteria of success) that typify the fundamentals of culture, the authors present the two major dimensions organized into four main clusters that define organizational effectiveness. The first dimension differentiates effectiveness criteria that emphasize flexibility, discretion, and dynamism from criteria that emphasize stability, order, and control. The second dimension differentiates effectiveness criteria that emphasize an internal orientation, integration, and unity from criteria that emphasize an external orientation, differentiation, and rivalry.

These four main clusters can be visualized as the Clan, Adhocracy, Hierarchy, and Market quadrants of a graph. Because these quadrant names were derived from the scholarly literature, the authors also conveniently provide counterpart names to which they think business executives and other nonacademic audiences might better relate (Collaborate, Create, Control, Compete). The authors note that while designed to assess organizational culture, these clusters can also be used to assess leadership roles, organizational effectiveness, and management roles, and provide several examples that demonstrate applicability to these other areas. In chapter 6 and Appendix B, the authors even provide an extension to the Competing Values Framework based on the Management Skills Assessment Instrument (MSAI) to address the personal behavior change on which a change in organizational culture depends.

In my opinion, the nine managerial competencies addressed for management across the four quadrants are more tangible (Clan = managing teams, managing interpersonal relationships, managing the development of others, Adhocracy = managing innovation, managing the future, managing continuous improvement, Hierarchy = managing acculturation, managing the control system, managing coordination, Market = managing competitiveness, energizing employees, managing customer service), although while the authors present at length the fact that the four quadrants for organizational culture depend on a "Means-Does Not Mean" analysis to be completed by stakeholders in order to determine what chosen future state organizational culture actually means in a relative sense, this analysis is not provided in the context of managerial competencies directly since these are intended to lead to the desired future state organizational culture.

Overall, however, Cameron and Quinn present the process to diagnose organizational culture extremely well, and they do note repeatedly, as can be expected, that it is not possible to present a cookie-cutter approach because of the continuum nature of culture. From the perspective of a consultant, I especially appreciate the many examples that the authors provide that demonstrate example company profiles and shifts in company culture over time. The average culture profiles for various industry groups that the authors present are also well received, although it is important for potential readers of this book to realize that the categorizations for these groups are very broad.

For example, consulting services might technically fall under the "services" group, which obviously encompasses a wide spectrum of companies, although in such a case it might be beneficial to look at cultural profiles of client industry groups. As a consultant in the software industry, I could not help but notice that this book ties in well with a book I read several years ago entitled "Balancing Agility and Discipline: A Guide for the Perplexed", by Barry Boehm and Richard Turner. While that text is narrowly focused on choosing a software development methodology, a culture dimension of plots reminiscent of those seen in the book under review here can be seen as output from what Cameron and Quinn provide.

Interestingly enough, while the term "changing" sits alongside "diagnosing" in the title of this work, it is really not until Appendix C and Appendix D that the former is addressed with any substance. It is actually understandable why this is the case - change is multifaceted and covered by numerous other titles - but I would personally like to see the authors expand on these appendixes in another book, because the content provides hints for initiating organizational culture change and improving personal management competencies that specifically address the quadrants discussed in the book. Well written and focused business text recommended to anyone seeking understanding of organizational culture or personal management competencies as they relate to their own situations or to situations of customers and clients.

New Book Review: "Lean Integration"

New book review for Lean Integration: An Integration Factory Approach to Business Agility, by John G. Schmidt and David Lyle, Addison-Wesley, 2010, reposted here:

A text published several years ago by the same authors, "Integration Competency Center: An Implementation Methodology", initially captured my interest in this recently released book. Although the authors note in their introduction that this text builds on the earlier work, they also indicate that it is not necessary to read these sequentially. The concept of "lean integation" builds on prior works by other authors such as "Lean Software Development: An Agile Toolkit" by Mary and Tom Poppendieck (see my review), and because of my experience using Agile and Six Sigma, I have continued interest in how I might also apply Lean principles as a consultant. And this interest is especially in light of my involvement in various database and integation related efforts. In the context of this text, the authors broadly define "integration" as "the practice of making independent applications work together as a cohesive system on an ongoing basis", and indicate that solutions typically fall into either process integration or data integration.

This book is divided into three parts. The first provides an overview and justification for Lean as well as an overview of Lean practices and what the authors deem the "Integration Factory". The second part walks through the seven lean integration principles associated with the Integration Factory: focus on the customer and eliminate waste, continuously improve, empower the team, optimize the whole, plan for change, automate processes, and build quality in. The third part discusses best practices grouped by seven competency areas: financial management, integration methodology, metadata management, information architecture, business process management, modeling management, and integration systems. Aside from the typical glossary and terminology that the appendixes provide, the authors also include the "Integration Laws" from the predecessor to this book: "The whole is greater than the sum of its parts", "There is no end state", "There are no universal standards", "Information adapts to meet local needs", and "All details are relevant".

The first two parts of this book continued to capture my interest, and although the third part on implementation practices contains some relevant material, the lack of cohesiveness in these last few chapters was disappointing, and because the term "implementation" used here implies a bit more concreteness than was offered by the authors, my expectations were unfortunately not met. Exceptions include Chapter 11 on financial management, which addresses the ability to secure funding for integration projects, rightly calling this the weakest skills among IT professionals, and Chapter 16 on modeling management, in which the authors address important risks to IT professionals, such as the risk that use of Service-Oriented Architecture (SOA) can lead to new hairballs. As with another recently read book that I recommend, "Enterprise Master Data Management: An SOA Approach to Managing Core Information" published by IBM Press (see my review), one refreshing aspect of this text is that even though the authors are from Informatica, the content remains very much vendor neutral. Well recommended.

Certified ScrumMaster Training: Day 2

Notes taken for posterity during the second of two days of a Certified ScrumMaster Training course that some of my colleagues and I attended this week. These notes are only intended to call out some areas that I found of particular interest during training, and are not intended in any way to summarize the course, which covers material far beyond what is outlined here.

• Release planning was pulled out of the July 2011 Scrum Guide, which returns Scrum to its original definition, but the Scrum Alliance will continue to include.
• Definite delivery dates, cost, and scope are not included in Scrum release planning. Release planning is not the purpose of Scrum. The purpose of Scrum is to be transparent and to determine what is available when.
• Scrum and Extreme Programming (XP) arose from the Patterns movement, because each of these is based on natural practices. Patterns are discovered, not invented.
• A release plan really just indicates which Sprints involve a shipment.
• Estimating is really design, because the clock is not brought into the equation. The conversation becomes more comfortable because the subject matter is more familiar and the entire development team is involved.
• Sometimes "ideal days" are used instead of story points, but for some this brings time back into the equation, which is not the objective. According to the instructor, ideal days in general tends to work.
• Larger tasks tend to be underestimated. The instructor advised not assigning numbers when an estimate is too much of an unknown, because estimates will be thrown off. This forces stakeholders to be aware that these larger tasks need to be broken down in the future. It is the stakeholder's call whether to spend time on one or more Sprints assigning estimates to these larger tasks.
• If there are many small tasks, it is permissible to bundle them as long as it makes sense to do so. In other words, the tasks are related and can be completed within a Sprint.
• Planning Poker sets are typically based on Fibonacci, so the instructor tends to suggest this sequence.

---

During the discussion, I had mentioned Powers of 2 as being popular, but the instructor tends to think that the numbers in this sequence increase too quickly. In speaking with some colleagues, we agreed that Fibonacci and Powers of 2 are similar if capped at say 16, and I later distributed a presentation I delivered a couple years ago that included several slides on how Powers of 2 were used for story points and how spikes were used on my project to assign story points to the building of proof of concepts with unfamiliar technologies that were planned to be used on the project. But since it is not always reasonable to cap at a certain number in the sequence, in retrospect I will be considering other sequences such as Fibonacci in the future, especially since we enjoyed using a traditional card deck to play Planning Poker (Ace = 1, 2, 3, 5, 8, Jack = 13, Queen = 21, King = 34).

During an exercise where the class broke down into 2 teams, we used Fibonacci to estimate tasks associated with kitchen remodeling.

The points that my team assigned to each of the tasks are listed on the left. Points are relative, and we did not see any tasks as being far removed from the others in terms of points. However, we did not end up assigning any points to the last task listed, because of the disagreement that ensued regarding the work to be completed. This task is an example of where a portion of a Sprint might be assigned to additional estimating.

The other team viewed the first two tasks as being relatively far removed from the others in terms of points, and in this case it is understandable how Powers of 2 might not be appropriate. As discussed by the teams following this exercise, the points assigned are either a reflection of unfamiliarity of this type of work, or the relative difference in skills between the individuals on each of the 2 teams.

---

• This type of estimation is really qualitative, not quantitative. Affinity Estimation enables quantitative estimation and is the fastest way to estimate a product backlog. The rule is that if a story estimate changes 3 times, it is set aside. Not only is time removed, size is removed. Affinity estimation is relative. The Fibonacci series is then applied afterward. The team quickly develops collective intuition.
• XP introduced the "courage value", which takes the lower number, rather than a conservative higher number, in the case that a team does not reach a concensus.
• During a class exercise that involved measuring velocity, the instructor pointed out that the team that is participating needs to be involved in estimating. Those not involved are not qualified to interpret past velocity activity.
• Use of Scrum is always forward looking by evaluating the past. What the instructor refers to as "Point Accounting" comes into play as tasks are not completed and work needs to be forwarded to the next Sprint. One strategy is to figure out how to complete a subset of the task in the first Sprint, and then forward the remainder. Another strategy is to move the entire task to the next Sprint and then count the points for the whole task. The instructor does not necessarily like this latter method, but for a services company like ours it might make sense.
• The Sprint is the only timeboxed item that cannot be changed.
• Part 2 of Sprint planning is where the bulk of planning occurs. The first part of planning tends to go quickly because much of the work is performed in the prior Sprint.
• Velocity should be used to determine what the development team thinks it can complete in a Sprint, not what it needs to complete in a Sprint based on expectations.
• It is rare that developers will sign up for risky tasks.
• Be careful about assessing importance based on the task name in itself, because for example the task might be associated with strategic work that is trying to set the stage for future Sprints.
• The Burndown Chart tracks how many hours remain, not how many hours have been applied to tasks. Keeping track of how many hours have been worked can be separately maintained elsewhere.
• The "truck number" is sometimes used to communicate how many people need to be run over for a particular skillset to be lost. A truck number of 1 is obviously never desired.
• It is a good idea to reserve a portion of points in each Sprint for support activities.
• It also sometimes makes sense for the experts on the team to be assigned no points in order to raise the skillsets for the rest of the team.
• Kanban is really an evolution of Scrum where work needs to fit into more traditional phases.
• It is not the purpose of the daily Scrum to report to the ScrumMaster. The purpose of the daily Scrum is for individual developers to share status with the rest of the team.

---

Interestingly enough, the role of the ScrumMaster in the daily Scrum was one of the topics that lingered during hallway chats while back at our client the next day. In our experience, it is common that ScrumMasters will address the rest of the development team one at a time during the daily Scrum, reminiscent of status reports to a project manager, but this should be taken care of prior to the meeting itself so that developers can share with each other. In my opinion, reverting back to the traditional status report format with which many are familiar is common when trying to create a Scrum hybrid that blends Scrum with current state client project methodologies, but should be relatively easy to steer away from when there is common understanding across the development team as to the purpose of the daily Scrum.

---

• The Burndown Chart should not be updated during the daily Scrum. The team should update before the meeting so that it does not lose its purpose.
• There should be a common vision coming out of Sprint planning that the team has a shared commitment. The purpose of the daily Scrum is not to focus on your own work as an individual.

---

Another topic that was discussed periodically the next day was the Ball Point Game exercise in which all attendees participated as one big team. For this exercise, we were to pass tennis balls to each other in a way where everyone touched each ball before it was placed in the bucket. But there were stipulations which stated that air time was required between each person, that balls could not be passed to direct neighbors, and that the person that passed the ball first also must be the person that touches the ball last.

And it so happened that I was the individual that was the one that passed the ball first and touched the ball last. By the nature of this position, I was also the one that kept count of how many times balls entered the bucket. Very challenging. Everyone remarked the next day how I was the one with the hardest task. Much like the ScrumMaster. Two of the many take-aways were that we found rhythm as at team after the first few Sprints, and that time spent on Agile Retrospectives is very small compared to the rest of each Sprint.

The exercise ran for 10 Sprints. During the first 3 Sprints, our velocity increased. Following the first 3 Sprints, I suggested we create a new formation and so velocity decreased while we were finding our rhythm again. Other suggestions on formation ensued, and velocity rose again until we found a more optimal formation in which velocity continued to accelerate. It is probable that had we run the exercise for additional Sprints we would have continued to increase velocity prior to reaching our limit.

Certified ScrumMaster Training: Day 1

Notes taken for posterity during the first of two days of a Certified ScrumMaster Training course that some of my colleagues and I attended this week. These notes are only intended to call out some areas that I found of particular interest during training, and are not intended in any way to summarize the course, which covers material far beyond what is outlined here.

• The course started by individual attendees identifying 5 of 22 provided topics that we thought might be important take-aways, followed by the class breaking up into pairs in order that one might convince the other to switch one of the 5 chosen to another topic.
• The 5 topics I had chosen were items I had not yet encountered to any significant degree in the workplace or graduate school, such as specific artifacts and distributed Scrum. The plan was then to apply post-it notes to each of the 5 topics as they were covered in class.

---

Of the 22 take-away concentrations, the following 5 were the most popular in this class session (all written intentionally in the form of user stories):

7- I can describe how to use the Scrum framework on large projects using Scrum of Scrums and/or other approaches to scaling.
6- I can facilitate the team through the Sprint.
6 - I can advocate for Scrum teams to be colocated, but also help a team overcome the reality of distributed teams.
5 - I can explain the importance of complexity and its impact using empirical or defined processes.
5 - I can describe the responsibility of the ScrumMaster.

These types of exercises tend to interest me, because much of the value add for me in corporate training tends to come from the interactions between colleagues rather than the material itself.

---

• The latest Scrum Guide released 3 weeks ago was included in the handout workbook. The instructor noted that the release planning portion was removed from the previous Scrum Guide.
• Development of the Certified Scrum Professional from the Scrum Alliance had its origins in the failure of the Agile Software Development with Scrum text by Ken Schwaber and Mike Beedle and the desire to help realize Scrum practices in its readership.
• According to the instructor, worldwide there are about 160k Certified ScrumMasters, about 10k Certified Scrum Professionals, 130 Certified Scrum Trainers, and an unknown number of Certified Scrum Coaches and Certified Scrum Developers.
• The instructor also noted that there is some redundancy between Certified Product Owners and Certified ScrumMasters. Although Certified ScrumMaster Professional is the drive right now, it is not a certification that should be called out in one's email signature etc because it does not represent skills or experience, just understanding.
• In Scrum, "programmer" is not equivalent to "developer". The development team is comprised of the programmers, architects, business analysts, testers etc with which we are familiar, and all are developers. In addition, the Scrum team is comprised of both the product owner and the development team.
• Deliverables are intended to be in a shippable state at the end of each sprint, but not necessarily shipped or deployed to production. To release to production is a business decision.
• Identified tasks are not an explicit requirement of Scrum. The development team determines how this is to be done. Even though tasks are the most common method to plan, this requirement was removed in recent releases of the Scrum Guide.
• Project resource needs are starting to be requested in terms of Scrum teams of x people for x months.
• During our discussion of Scrum motivations, we discussed at what point project tasks are performed during traditional Waterfall and Scrum project timelines. It was amusing for the my colleague and I to find ourselves working through estimation, requirements, analysis, and design, and then working backward from production deployment to fill in the rest of the activities for traditional Waterfall.

---

During class, I recalled to my colleagues the practices that one of my project managers followed early in my career following the implementation of an enterprise-wide project dashboard. The project manager would spend considerable time each week tweaking the project plan until it would turn green, and consistently trimmed estimates provided by my colleagues in order that they would fit in the predefined timeline, not unlike the Waterfall portion of this exercise.

---

• Scrum is similar to Extreme Programming (XP), except XP has more constraints around how programmers are to perform tasks.
• Project complexity is really the driver to determine whether to take an empirical approach. Requirements and technology (and maybe organizational complexity) determine complexity, not factors such as team size and colocation of team members etc.
• Of the 3 pillars that uphold every implementation of empirical process control (transparency, inspection, and adaption), adaption is usually the most difficult. The question ends up being: What is the most tolerable empirical approach for my organization today? And agile hybrid approaches are common.

---

After discussing project complexity and empiricism, we broke up into teams of 3 and 4 to discuss the 12 principles behind the Agile Manifesto, and chose 3 principles that we thought can be removed, and 3 principles that we thought are the most important.

Across the teams in this class session, the following 3 were the most popular for principles we thought are the most important:

3 - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
2 - Working software is the primary measure of progress.
2 - Business people and developers must work together daily throughout the project.

The following principle was the only one that managed to get any hits for being removed from the Agile Manifesto:

2 - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The instructor indicated that some of the writers of the Agile Manifesto have indicated that some of these principles would have been better left out, but that coming to agreement on these principles during a relatively short meeting 10 years ago was a huge achievement. That said, this exercise resulted in considerable debate.

One principle that generated debate was as follows: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." One team argued that "requirements" is often assumed to be business requirements, but the term can also be assigned to technical requirements, and so they argued in favor of this principle.

Another principle that the teams did not generally agree upon was as follows: "Business people and developers must work together daily throughout the project." The term "daily" was the catalyst of the disagreement, because of the mandated frequency of working together.

My team chose the following principle as being one of the 3 we thought are the most important: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly." Speaking from my experience, I have witnessed the value that the Agile Retrospective provides, having used them on multiple projects throughout my consulting career.

---

• One problem that the instructor has witnessed is that few Certified Scrum Trainers have been product owners. Most have been programmers and project managers.
• According to Scrum, only one person is intended to be product owner, but in practice this is very difficult.
• There appears to be a move in the Scrum community to replace "prioritizing" with "ordering" the Sprint Backlog, and "committment" language has been replaced with "forecast" in Scrum literature, although the instructor prefers the original verbiage.

---

Unfortunately, I introduced the term "semantics" as part of the discussion on prioritizing versus ordering. What I had intended to convey was that "prioritizing" seems to communicate business needs or wants, whereas "ordering" seems to communicate the order in which tasks need to be completed, perhaps because of dependencies between tasks.

---

• A lot of discussion surrounded the term "shippable" during the portion of our class session working on an exercise where we broke out into teams of 3 and 4 to talk about our current projects and what we can do in each Sprint, what we would like to do in each Sprint but are not able to do today, and what tasks should not be considered as needing to be completed in a Sprint.

---

The term "shippable" is intended to convey that a deliverable is in shippable state. In other words, it can be released to production or shipped to customers, but is not for any of a number of reasons. For my contribution to this exercise, I indicated that during my upcoming project, I might consider refactoring a task to be done as part of a Sprint, but tasks such as load testing probably fall outside the Sprint, and that I may like to include testing on counterparts to the proprietary appliances that are expected to be used in production, but will probably not be able to do so. 

---

• In addition, the instructor said jokingly that "what goes on in the Sprint stays in the Sprint", meaning that hand-offs between programmers and QA for example within a Sprint should not be counted as defects. Remaining defects go back in the Sprint Backlog if not resolved during any particular Sprint. In Scrum, a defect is just work prioritized by the product owner.

New Book Review: "The Lean Startup"

New book review for The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, by Eric Ries, Crown Business, 2011, reposted here:

Good introduction to the application of Lean principles to the startup effort. As with its Lean ancestry in the manufacturing world, and later other areas of business such as software development, Lean seeks to eliminate any waste that does not add value to the end customer. Applied to the startup, Lean enables entrepreneurs to determine what customers want during product development to help minimize wasted efforts when rolling out products to the marketplace. As Ries states in his introduction, this is a book for entrepreneurs and the people who hold them accountable.

The five principles of the Lean Startup that are pervasive throughout this text are as follows: (1) entrepreneurs are everywhere, (2) entrepreneurship is management, (3) validated learning, (4) build-measure-learn, and (5) innovation accounting. While presenting these principles, the author first walks the reader through his vision that the products a startup builds are really experiments and that the outcome of these experiments is learning how to build a sustainable business. The author then examines the build-measure-learn feedback loop, the core of the Lean Startup model, and then turns his discussion to the growth of startups within this model.

The bulk of the material that Ries provides is in these first two parts. As a Six Sigma practitioner familiar with Lean, I especially appreciated how the author interwove the startup journey with Lean practices, while providing some of the historical background with which some readers might not be familiar. To a degree, some of the comments that other reviewers here have provided, however, are a demonstration of the build-measure-learn feedback loop as applied to book publishing in that readers in this space often expect detailed, step-by-step instructions on how to implement presented ideas, but doing so is not the purpose of this text.

The other common thread of criticism throughout the other reviews here is that the author concentrates on the technology space, and although I agree that he spends considerable time talking about web related businesses and agile software development, he does so because these areas are what comprise his background. And as a technology consultant, I can attest to the fact that many of the practicies discussed that started in manufacturing have been successfully adopted in the software development world. Many of these practices can be further pursued in other industries, but much of the drive has been concentrated in these two areas and so such examples are more readily available.

In his epilogue, the author reminds the reader of the Peter Drucker quote that states that "there is surely nothing quite so useless as doing with great efficiency what should not be done at all." Ries furthers this thought by stating that "most people I meet believe that in their industry at least, projects fail for good reasons: projects are inherently risky, market conditions are unpredictable, 'big company people' are intrinsically uncreative. Some believe that if we just slowed everything down and used a more careful process, we could reduce the failure rate by doing fewer projects of higher quality. Others believe that certain people have an innate gift of knowing the right thing to build. If we can find enough of these visionaries and virtuosos, our problems will be solved."

"These 'solutions' were once state of the art in the nineteenth century, before people knew about modern management. The requirements of an ever-faster world make these antique approaches unworkable, and so the blame for failed projects and businesses often is heaped on senior management, which is asked to do the impossible. Alternatively, the finger of blame is pointed at financial investors or the public markets for overemphasizing quick fixes and short-term results. We have plenty of blame to go around, but far too little theory to guide the actions of leaders and investors alike. The Lean Startup movement stands in contrast to this hand-wringing. We believe that most forms of waste in innovation are preventable once their causes are understood. All that is required is that we change our collective mind-set concerning how this work is to be done." Well said.

Past Book Review (November 16, 2008): "Medical Errors and Medical Narcissism"

Past book review (i.e. posted prior to starting this blog) for Medical Errors and Medical Narcissism, by John D. Banja, Jones & Bartlett Learning, 2005, reposted here:

 

Published almost four years ago at the time of this review, it is rather interesting that other readers have not yet shared their thoughts about this book. Quite simply, this is an extremely well written, well organized text, and the subject matter is relevant to a large segment of society. Health care touches almost everyone, and understanding the mind of the health care worker, especially the physician, is important when assessing medical errors. According to author Banja, Associate Professor in the Center for Ethics at Emory University, behavior that he refers to as "medical narcissism" can have a profound influence on how the physician reacts to occurrences of such errors. Before Banja discusses narcissism in health care, he first explains error and rationalization, and follows the discussion of narcissism with chapters on forgiveness, remedies, and empathic disclosure.

The author indicates that "it is important to note that the variance, departure, or straying from the standard of care that is presently being offered as a definition of error must be morally problematic, or uncomprehending, or unintended by the actor. Simply calling an error 'a failure to accommodate the standard of care' would imply that medicine could not have progressed since Hippocrates without its practitioners making 'errors', which seems intuitively wrong. The failure to follow the standard of care, then, must be unwarranted and, overwhelmingly, the errors discussed in this book are just so". And "it is grossly unfair to hold health professionals to a standard of competence that defines 'error' in a way that exceeds ordinary and reasonable levels of performance. Because imputing error can have onerous repercussions, health professionals and especially risk managers must insist on a coherent understanding of error and resist imprecise definitions that could confuse or compromise hospital policy on patient safety and managing adverse outcomes. Consequently, the definition of error that will be used throughout this book is: 'An error is an unwarranted failure of action or judgment to accommodate the standard of care'."

Following his discussion of medical errors, Banja then takes a look at how such errors are handled, providing many examples of such scenarios, which suggest "a temporally tight juxtaposition of immense anxiety and concern for the patient's welfare, followed closely or even simultaneously by the provider's intense anxiety about his or her own welfare. The lock-step nature of these dual anxieties is key". As the author continues with his presentation, he indicates that it is unfortunate that there is no national consensus (i.e. within the United States) that dictates how such errors need to be communicated to affected parties. According to cited studies, what is often the case is that information associated with such errors is withheld, and in one study where disclosure practices of over 200 hospitals were examined, the conclusion was that only 10% to 20% of serious, preventable, iatrogenic harms that occurred to patients were disclosed. What is often the case, according to surveys of physicians, is that harm-causing medical errors are often rationalized.

One of the most interesting portions of the text is the discussion on the origins of medical narcissist characteristics (emotional disengagement, ideological rigidity, and compulsiveness), which often start in childhood and are later reinforced during medical training. And the author's later secular discussion of forgiveness is superb. While Banja indicates that there is no consensual definition of forgiveness, a very compelling presentation is presented of what true forgiveness might look like from psychological and moral perspectives, beginning with a quote which reads as follows: "What is annulled in the act of forgiveness is not the crime itself but the distorting effect that this wrong has upon one's relations with the wrongdoer and perhaps with others". The cognitive-emotive-behavioral triad that the author presents is powerful. Forgiveness for the forgiver from each of these, respectively, might be: "I will stop thinking about the offense", "I will cease to feel anger and hatred toward the offender", and "I will not seek revenge"; forgiveness for the forgiven might be, respectively: "I will acknowledge and admit my wrongdoing", "I will feel and express sorrow for what I did", and "I will desist from committing that wrong again and make amends".

The stumbling block for the medical narcissist, however, is that forgiveness "requires a humbling of the self and a relinquishment (at least temporarily) of grandiosity". Considering the lengthy discussion on errors and how errors are handled, this book would not be complete without the chapter on remedies, which includes sections on tort reform, the blameless and nonpunitive environment, and mindfulness. And the following chapter discusses the empathic disclosure of medical error, how errors arguably should be handled. Within the closing pages, the author indicates that he "wrote this book with a particular kind of health professional in mind. He or she is one who believes it is immensely important to: (1) maintain a professional distance or guardedness with patients that largely precludes empathically reacting to their anxiety or suffering, (2) appear utterly competent always, (3) understand and ground that competence in scientific method and a densely clinical vocabulary, (4) never admit ignorance, hesitation, or error, (5) direct and control the conversation with patients always, and (6) use the power of his or her white coat to direct how the patient should behave and feel".

New Book Review: "Project Decisions"

Recently posted book review for Project Decisions: The Art and Science, by Lev Virine and Michael Trumper, Management Concepts, 2008, reposted here:

Reading this text was a follow-up by this reviewer on reading "Why Can't You Just Give Me the Number?", by Patrick Leach, and "How to Measure Anything: Finding the Value of Intangibles in Business", by Douglas W. Hubbard (see my reviews). While these two efforts delve to some extent into the mathematics associated with measurement and probability, however, the reader will see very little calculation in the text at hand because it concentrates on the processes surrounding making effective project decisions, most of which involve human factors (both one's own and those associated with other project stakeholders). As Virine discusses in the preface to this book, an effective project manager needs to be conversant on how rational choices in project management can be made, how improved ability to make these choices can be achieved, and what tools are available to aid the decision making process. The authors provide a look into the structured decision analysis that can answer these questions.

This text breaks down the discussion into five parts: (1) "Introduction to Project Decision Analysis", (2) "Decision-Framing", (3) "Modeling the Situation", (4) "Quantitative Analysis", and (5) "Implementation, Monitoring, and Reviews". The bulk of the text is weighted toward the introductory first part, followed by the fourth part on analysis. In addition, the authors provide four appendixes that provide a listing of risk and decision analysis software products used in project management, a summary of the heuristics and biases in project management, risk checklists for both generic and software development projects, and a listing of multi-criteria decision-making methodologies. Since this book covers a lot of ground, it is difficult to review the content from an everyman perspective (every reader is going to gravitate to those sections in which they are interested, either because they want to investigate what the authors have to say on a given topic with which they already have an opinion, or because they want to explore topics with which they were not previously exposed).

This reviewer found the first and fourth parts especially relevant to his project work, and the following chapters within these parts: (2) "'Gut Feel' vs. Decision Analysis: Introduction to the Psychology of Project Decision-Making", (7) "Are You Allowed to Make a Decision? Or the 'Frustrated Developer's Syndrome", (15) "Decision Trees and the Value of New Information", (16) "What is Project Risk? or PERT and Monte Carlo", (17) "'A Series of Unfortunate Events', or Event Chain Methodology", and (18) "The Art of Decision Analysis Reporting". Despite the witnessing of failed projects, and the various degrees of success leading his own projects, this reviewer especially appreciated the author discussions on cognitive and motivational biases, perception, bounded rationality, heuristics and biases, and behavioral traps. In addition, although as a consultant much of the politics to which this reviewer would otherwise be effected can be thwarted, the project politics that the authors discuss always exist to some extent regardless of client, and this reviewer finds invaluable presentations of how these issues are commonplace in industry and how they might be addressed.

While most of the graphs and charts are not provided until the fifteenth chapter, the ones provided in the fourth part of this book are well done and very relevant to the corresponding discussions on quantitative analysis. While the content is presented at a high level, the illustrations provide excellent introductory as well as reminder segments on topics in this space. In the eighteenth chapter entitled "The Art of Decision Analysis Reporting", the authors discuss an experiment they conducted with 23 engineers. Each engineer was asked to assign a percentage of probability to verbal expressions covering a range of certainty from "Almost No Chance" and "Highly Unlikely" to "Highly Likely" and "Almost Certain". The results, which demonstrate a wide disparity in interpretation, are quite fascinating. For example, the engineers interpreted "Improbable" as a 0% to 40% probability, and "Almost Certain" as a 70% to near-100% probability. As a Six Sigma practitioner, this reviewer understands the value of concrete metrics and how language can easily be misinterpreted, but the chart accompanying this discussion proved very effective for this reviewer. Well recommended.

RSNA 2010: Quality Improvement? - MRI Workflow

As posted recently, I had the opportunity to spend the day at the RSNA 2010 trade show at McCormick Place in downtown Chicago the Sunday following Thanksgiving Day. Rather than discuss statistical control as in my recent post, since the exhibit being discussed here offered no control charts, I present before-and-after workflows provided by one of the hospitals (any indicator of specific project, as always, has been purposely excluded).

As with the previous post, this exhibit was associated with magnetic resonance imaging (MRI), not a surprise since RSNA is the Radiological Society of North America. While meaningful decreased cost was the eventual goal of this project, the end results provided a seemingly more pleasant hospital experience judging by the summary of improvements that the hospital provided.

The point of this post, however, is not to spend much time looking at quantifiable results (since no statistics were provided to enable looking at this aspect in sufficient detail), but investigating hospital presentation of the workflows, which in this case follow patients from the time they arrive to receive their MRI scan to the time they leave.

As someone who is often complimented on visual presentation skills, I personally find the workflows presented in this exhibit to not only be confusing, but potentially misleading. In the before-and-after workflows, the exhibitor shows a series of boxes representing rooms or areas of the hospital, as well as indication of patient flow by showing direction as well as steps along the way.

Because these two workflows depict the same process, there is obviously overlap between the rooms or areas of the hospital as well as the process steps between the two. Both workflows depict "Radiology Reading Room", "Nurse Prep Area", and "MRI Scan Room", as well as "Patient arrives", "Patient disrobes", "Scan performed", and "Patient dresses and leaves".

Fewer steps are depicted in the second workflow, presumably due to the process improvement gains achieved by the hospital because of "decreased patient handoffs (freed up clerk and nursing time)". But the "decreased patient walking by 90% (300ft to 30ft)" is not apparent by solely reviewing each diagram. In addition, it is not apparent whether the location of each step in the diagrams has any significance.

Perhaps these do have significance, or too many steps were associated with each room or area of the hospital in the first diagram to line them up as in the second diagram. Does patient flow really consist of traversing around the perimeter of the "MRI Scan Room", and do patients really just walk to the door of the "Nurse Prep Area" in the first workflow? Why does more space exist between the "Radiology Reading Room" and the "Nurse Prep Area" in the first diagram than in the second?

Why does the "Nurse Prep Area" in the first diagram look so much more far removed from the rest of the rooms than in the second? All of these questions lead to other possible lines of questioning, such as whether there really are four fewer steps following process improvement, or whether fewer steps is really due to decreased granularity in process depiction.

One can improve visual presentation of workflow before and after process improvement by either creating spaghetti diagrams or functional deployment maps. Spaghetti diagrams depict the physical flow of work or material in a process, and are used to improve the physical layout of a workspace or the way in which a workspace is utilized. Functional deployment maps, or swim-lanes, emphasize who does what and help enable discovery associated with handoffs between individuals or work groups.

In the case at hand, creation of functional deployment maps can be used as input to spaghetti diagrams, but not enough information was provided in the exhibit to create such a diagram for any real use. The first goal needs to be removal of ambiguity from the original workflow diagram. The following functional deployment map is a reworking of the original workflow diagram produced in this exhibit.

For the audience that might not be familiar with these types of diagrams, let me be clear that these are two types of diagrams, even though they might look similar. In the diagram that I created, boxes represent processes. Note that each process is an action, such as "Notify Nursing Station" or "Perform Scan". In the before workflow provided in the exhibit, boxes represent rooms or areas of the hosptial.

In order to figure out workflow, processes must first be discovered. Rather than completely reworking the problem space, I simply reorganized the original information to make sure it makes sense. Some steps in the original workflow actually contain multiple steps. For example, the third step indicates "patient fills out screening form in waiting room" as well as "clerk notifies nursing station". In the swim-lane I provide here, these have been simplified as "fill out screening form" and "notify nursing station".

In addition to reworking to be process oriented, I also examined where each of the original steps was taking place in the hospital. For example, the fourth step indicated "patient brought back to nursing station" at the "nurse prep area" location. How did the patient move from the "waiting room" location to the "nurse prep area" location after "clerk notifies nursing station"? It is an obvious possibiliy that the patient walked themselves. But "brought" implies someone else is leading the way.

Because of this, it becomes clear that the nurse arrives at the "waiting room" in order to perform "patient brought back to nursing station", so this process appears in the new "waiting room" swimlane and associated with "nurse". It simply does not make sense to have this process at "nurse prep area", because if the patient was already at that location, there would be no need for this process. Now that process steps have been delineated, further analysis can be accurately performed.

RSNA 2010: Quality Improvement? - MRI Wait Time

This past Sunday I had the opportunity to spend the day at the RSNA 2010 trade show event at McCormick Place in downtown Chicago. Following my attendance at RSNA 2009, I posted some observations that I made about a p-chart (a type of statistical quality control chart) on display at one of the research exhibits, and what I would have recommended to the researchers as a consultant.

That particular p-chart in my professional opinion was unfortunately incorrectly constructed. While the following snapshot is more of a general run chart than a control chart, it seems clear from the comments made later in the associated exhibit (any indicator of specific project has been purposely excluded) that this chart was intended to provide input to a process improvement effort.

This run chart is simply a plot of wait time in days for magnetic resonance imaging (MRI) by month (at the 90th percentile). The objective in this process improvement effort was to decrease routine wait times. A couple aspects of this run chart immediately jumped out at me: (1) the plot of year-to-date average is seemingly nonsensical, (2) the values of the data points decrease and then increase over the time period provided (and there are multiple waves of increasing and decreasing periods in the interim), (3) the data points are not lined up with markers on the x-axis, and (4) the wait time is plotted by month.

The plot of year-to-date average is seemingly nonsensical. Which year is this average intended to reflect? And why was average chosen by the individuals who constructed this run chart? The only way I can see the "YTD AVG" providing any value is if it were the mean for the entire date range. The raw data was not made available in the exhibit, so let's assume that this is the case.

The values of the data points decrease and then increase over the time period provided (and there are multiple waves of increasing and decreasing periods in the interim). Since run charts like this are intended to be used for process improvement, in this case cycle-time improvement, and statistical control is first needed in order to demonstrate meaningful improvement, this run chart does not provide any evidence of Sigma increase. It is possible that a process improvement initiative occurred at some point between April 2008 and February 2010, but if that is the case it is not clear why wait time began to increase again over time.

The data points are not lined up with markers on the x-axis. Admittedly, I would typically consider this aspect minor, but this can be a bit distracting. For example, for which month is the first data point plotted? Presumably April, but perhaps it is actually for March.

The wait time is plotted by month. Why are aggregates being used at such an early stage? Why not just break down the data points day-by-day? Or perhaps even better, booking-by-booking? It is not possible to determine, for instance, whether a data point reflects wait time for a single MRI visit, or 50. Let's take a look at the results that the exhibitors provided. Perhaps all of these initial concerns are unwarranted.

The fact that 103 days was the MRI wait time for February 2009 indicates that all of the data points are offset to the left of the x-axis markers. But the fact that MRI wait times decreased for a 4-month stretch in the midst of a 22-month time period does not indicate anything of significance unless there was a short-term measure in place. Unfortunately, there are three downward trends throughout this 22-month time period, so this 4-month period does not provide any assurance of process improvement.

The exhibitors indicate that the MRI wait times increased in March 2009 due to "decreased Provincial MRI funded hours", but what about the increase that occurred later that Fall? And it is unfortunately not clear why only the 90th percentile is displayed in the run chart. It is probable that focus was directed at the greatest MRI wait times, but aggregating at an apparently arbitrary monthly level is likely to lead to false conclusions.

Booking turnaround times apparently decreased from about 35 days to less than 2 days, but no data is provided to determine whether this level of defects has been sustained (and given what has already been discussed about the run chart, there is no reason to believe that there is statistical control in this case, either). The data simply needs to be provided at a more granular level. Doing so will provide more data points and presumably more variation. Only if statistical control is achieved can cost savings and the accompanying quality improvement be measured.

New Book Review: "Controlling Software Projects"

New book review for Controlling Software Projects: Management, Measurement & Estimation, by Tom DeMarco, Yourdon Press, 1982, reposted here:

 

This text was initially noted by this reviewer while reading a white paper written by Johanna Rothman that a colleague recently passed on to me entitled "Are We There Yet?: Creating Project Dashboards to Display Progress", and after a good experience reading "Waltzing with Bears: Managing Risk on Software Projects" by Tom DeMarco and Timothy Lister (see my review) this reviewer was ready to re-experience the superb writing style and diagram notation of the author. But then the publish date was discovered. Is it possible that a 30-year-old project management text can be appreciated in an age of agile development? In the opinion of this reviewer, large portions of this book are still viable, but the reader needs to maneuver through some of the information that is outdated, and in many cases downright risky to follow. Because of this intermingling, this reviewer can only recommend this text to readers with a substantive amount of software development experience.

While following a reading of this book this reviewer still recommends "Software Estimation: Demystifying the Black Art" by Steve McConnell (see my review) as the best overall project estimation text, what is appealing to this Six Sigma practitioner are the metrics presented throughout this text even though McConnell indicates that many of the early metrics that are still being referenced within the industry were harvested from large government projects. Metrics can be compelling, but it helps to understand that there are many different types of software development projects taking place in many different corporate cultures, and "Balancing Agility and Discipline: A Guide for the Perplexed" by Barry Boehm and Richard Turner (see my review) interestingly enough co-written by the individual who wrote the forward for the object of this review 20 years prior can greatly aid leadership in this industry as they choose which direction to take in this regard.

While the content in this book is well connected throughout, DeMarco discusses four main areas that are each dedicated a section in the book, although the largest amount of text is dedicated to the second section: (1) "Chaos and Order in the Software Development Process", (2) "System Models and System Metrics", (3) Cost Models, and (4) Software Quality. Some of the questions that DeMarco addresses might be posed as follows: What does it mean "to control" a software development project? What is estimation and how can it be approached effectively? How can project costs be projected into the future? How are metrics generated and who should do this work? What long-term benefits can be provided by a cost model? What exactly does software quality mean and how can related goals be achieved? The author also provides four appendixes, but in the opinion of this reviewer only the third, entitled "A Tailored Primer on Statistics", is suggested reading.

While less than 300-pages, this book covers a lot of ground. While the author carefully lays out his approach on how to gather metrics in the second part of the book, it is obvious from a year-2010 perspective that this method relies much too heavily on the classic Waterfall software development methodology, and so this part of the book should only be given a cursory reading. Some of the material in this section is beneficial, but harvesting this information is like separating the wheat from the chaff. In other words, while still taking into account the excellent conversational writing style of the author, the reader is advised to read other material such as that found in texts sited earlier in this review. Because DeMarco offers so many great diagrams in this book, a possible way to explore this third section is by looking at these diagrams to determine whether reading the surrounding text is worthwhile. The fourth section on quality does not seem to belong in this book, even if it were not for its lack of inclusion within the subtitle. The other two sections were well received by this reviewer, especially the first.

At the outset, DeMarco is entertaining by presenting the default definition of "estimate", which he writes is "the most optimistic prediction that has a non-zero probability of coming true", and his proposed definition of "estimate", which is "a prediction that is equally likely to be above or below the actual result". In addition, the author exposes one chief villain of accurate estimates: corporate policies that use estimates to create incentives. As the author explains, "when such a policy is allowed to prevail, the estimation process is nothing more than a charade. Whenever estimates are required, the person requiring them is not truly interested in the estimator's probabilistic assessment of when the work will be done or at what cost. Rather, the 'estimator' is being asked to establish goals for performance. In many cases, it's even worse: The 'estimator' is being asked to accept previously established goals. And what shall the characteristics of those goals be? If they're going to serve real prods for the development process, they have to be totally unachievable."

If you do not have time to sit down with this book for long periods, this reviewer recommends that the latter portion of chapter four where the author discusses five objections to empirical software projection be read at a minimum: (1) "We don't have the data. Without that vaunted bluebook, the metal extrusion estimator would be nowhere. That's where we are." (2) "Even if we have the data, we haven't got anything to correlate it with. What can we use as the early measurable indication of size? (If you say lines of code, I'll scream.)" (3) "Each software system is different. You can't use data about developing small on-line systems in PL/I with experienced people to project results for a development of large batch systems in assembler by novices." (4) "The data don't converge. The tolerances will be so wide that no one will accept the results." (5) "Upper managers won't accept the projected numbers because the figures will be too high. The worker bees won't work as hard without unreasonable numbers to strive toward. Everybody's ego will be offended by the idea that the work is predictably doable and that people's efforts are interchangeable."

As this reviewer wrote the list in that last paragraph, he was reminded of some of the technologies mentioned by Frederick P. Brooks, Jr. in his classic work  entitled "The Mythical Man-Month" (see my review). "PL/I"? "Batch systems"? "Assembler"? As this reviewer mentioned in his earlier review of "Object-Oriented Technology: A Manager's Guide" by David A. Taylor, "the next language of the day/week/month/year" will come and go soon enough.