By Brian Lucas
Wayne Bruch is a hyper productive, natural agilist who has found a way to improve both process and productivity by 10% a year for the last 5 years by focusing on the key 20% of the Pareto Principle. He is the IT Manager at Easton Hospital, 250 South 21st Street, Easton, PA 18042.
Lucas: Even though you are an IT Manager with experience as a consultant you never had any formal training or education in agile, have you?
Bruch: That’s correct.
Lucas: Tell us a bit about your responsibilities.
Bruch: Well, I work under a different model than most IT managers. I oversee the IT Department as the right hand of the director. At a high level, I am responsible for the following areas:
- Project management
- Infrastructure design
- Systems design
- Implementation oversight
- Managing IT’s resources
- Staff and equipment cost projections for the facility’s needs
- Maintaining vendor relationships
- Coordinating with IT staffs at other facilities
- Consulting with medical and administration employees on services and technology
- Process improvement
Lucas: You also work at a very detailed level, don’t you?
Bruch: At a very detailed level, I also am responsible for:
- Clinical systems analysis
- Maintenance of 30 applications
- Expert knowledge of all applications
- 24 hour call support as the primary or secondary contact
- Hardware and network support
Lucas: How do you manage to keep all that discrete application knowledge and detail in your head?
Bruch: I maintain my knowledge of the applications by approaching them from the user’s perspective and understanding at a basic business level what they are trying to accomplish. I keep a model of this system flow in my head. I also have it documented – something I have tried to do for all basic processes. When a specific question arises, I know what the application is trying to accomplish, so I can either remember directly how the system does it or expeditiously rediscover how a particular detail was implemented. It really is an application of top/down thinking where I work my way to the middle or whatever level is necessary to solve the problem.
Lucas: Do you know that you are describing a thought process that is very similar to the concept of high level functionality being described in epics which are then detailed in user stories?
Bruch: Yes, I am aware of that now, but I actually gained that articulation of those terms from my recent reading of your blog. Prior to that; it was something that I just did naturally because it made sense to do it that way.
Lucas: How do you control the various amounts and levels of work that you do and deal with?
Bruch: I encapsulate each request to stand on its own. That’s important! I would equate it to a user story. I move them through a process that is similar to what you refer to in your blog in transforming a user story, into acceptance criteria then test cases then an implementation. I always have the concept early on what is the definition of DONE for the issue. That’s critical!
Lucas: How do you set priorities and make estimates?
Bruch: Estimates are always difficult to make and subject to change. I always determine priority first, so I can focus in on the key items. If it concerns patient care or patient health related information it has the highest priority and must be addressed immediately and correctly.
Lucas: How do you ensure quality?
Bruch: In essence, I follow much of the philosophy that was documented in the Toyota Way. I ensure I have all the facts as it pertains to the event by good communications with all the various users involved. Frequently a problem doesn’t originate in one department or one place. That is why it is important to reach out to everyone involved. I try to break a problem down quickly into its constituent parts and hypothesize each one and test the hypothesis. If any of my hypotheses are false then I reevaluate and create a new one. Each department has its own unique understanding of the process – registration is different from bed control which is different from nursing. I have to look at things from an overall process and goal and then resolve how each department implements it often by looking at the underlying system.
Lucas: How many separate items are you dealing with on an average day?
Bruch: There is on average around 20 items that require my direct attention, an intense day would be more than double that.
Lucas: That is quite a work load! How are you effectively able to communicate with so many different people in a single day?
Bruch: By conversing with them in the language and terms that they use every day and understand. It saves a significant amount of voice, email and text time. Plus it puts the user at ease since you are not introducing terms to them that they are unfamiliar with when they are in the middle of a problem.
Lucas: Good communications is one of the prime ingredients of agile. You seem to be taking it to another level and have implemented something that I have heard being referred to as “agile speak” where people use a common and often precise language to communicate.
Bruch: It’s important to communicate well throughout the organization structure. I also always keep my management apprised of the status of items that could escalate to them. These are issues they would need to facilitate. That way, when an issue rises to that level, they are in a position to rapidly mobilize resources, because they already understand the problem.
Lucas: How do you manage to maintain progress on your strategic tasks while dealing with so many tactical issues?
Bruch: I always focus on the goals. It sounds like a cliché, but too many people often lose sight of the end goal. They get mired in minutia and form that doesn’t count. They waste most of their time and effort on triviality and processes that don’t add value. It’s very much an aspect of the Pareto Principle’s 80/20 rule. I constantly keep a queue of work items; both electronically and in my head, which I verify the priority. I reorder this stack daily. This is very similar to the concept of product backlogs and stack ranking. I also distribute responsibility and work as much as possible and employ a team concept vigorously. However, the situation I have at the hospital does not allow for single focus dedication. I might have, at any one time, 10 people, each one working on more than one team at a time and each team dealing with more than one unit of work.
Lucas: That’s usually contra indicated in agile where focus and dedication bring on velocity. How are you managing to keep that all straight and maintain the efficiency of your team’s actions?
Bruch: It does get hectic, I would say very hectic; but I believe strongly in the concept of team empowerment. That’s the first key – good decision making at the lowest possible level is always the most expeditious way of resolving work. The second key – I call “T2 communications”. It stands for terrific and tight communications. By terrific, I mean, immediate and complete; by tight I mean to the point and directed at the right person or persons. I implemented this, first by being the communications conduit myself. Then as the teams got used to what was being communicated; I began to ask an individual to relate what they just told me to specific people. I explained why those individuals needed to know that information. Gradually by cross pollinating my teams; they were able to share information with each other. I phased out of being the conduit. I also, as a part of this concept; do a lot of MBWA with my cell phone glued to my ear. In fact, I do a lot of things with my cell phone glued to my ear. That can at times become overwhelming, but it’s a matter of balance. My focus during my MBWAs is always on maintaining quality first and ensuring a common understanding of priority. I also, where necessary, provide guidance. I always treat myself as a team of one when I am working as an individual. That sounds like a strange concept to some people, but it is really about expectations and treating yourself no different than others. I have always believed in leading by example and won’t ask someone to do something I am unwilling to do – provided I am technically able to do it.
Lucas: So by a scrupulous application of the Pareto Principle and teamwork, supported by terrific and tight communications, you have achieved a level of agility that has enabled you to implement a sustained continuous improvement program.
Bruch: Yes and thanks to your blog I am more aware of better articulations for the things I have been doing. They have helped me to coalesce my thinking and express it in better terms. I especially liked your post, “HCM, HIM and Agile are Perfect Together” which I would like to follow up with more research. “A Simple Definition of Kanban Leads to Agile Productivity” I thought was helpful in creating a simple spreadsheet that I now use to track my work in progress. I thought your post “Middle of the Road CIOs are Getting Hit by the Innovation Truck” was something every CIO and MIS manager needs to read. The comic screen bean image fleeing before the truck caught my eye. I also recently read, based on your recommendation, Stephen Denning’s book, “The Leader’s Guide to Radical Management. It was a fascinating read and I can see much of what it refers to a long term trends already gaining movement within industry.
Lucas: Your cell is giving off a custom notification tone; I guess it’s time for you to focus on the 20% again.
 A top-down approach (also known as stepwise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. Top-down design was promoted in the 1970s by IBM researcher Harlan Mills and Niklaus Wirth. Top-down methods were favored in software engineering until the late 1980s, and object-oriented programming assisted in demonstrating the idea that both aspects of top-down and bottom-up programming could be utilized.
 The Toyota Way is a set of principles and behaviors that underlie the Toyota Motor Corporation’s managerial approach. Toyota first summed up its philosophy in 2001, calling it “The Toyota Way 2001.” The two focal points of the principles are continuous improvement and respect for people. The principles for a continuous improvement include establishing a long-term vision, working on challenges, continual innovation, and going to the source of the issue or problem. The principles relating to respect for people include ways of building respect and teamwork. In 2004, Dr. Jeffrey Liker, a University of Michigan professor of industrial engineering, published “The Toyota Way.”
 I will define this more at a later time since I have not found a good generally accepted definition for this yet.
 The Pareto principle (also known as the 80–20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes. It was named it after Italian economist Vilfredo Pareto, who observed in 1906 that 80% of the land in Italy was owned by 20% of the population.
 Pronounced T-Squared
 The term “management by walking around”, refers to a style of business management which involves managers wandering around, in an unstructured manner, through the workplace(s), at random, to check with employees, or equipment, about the status of ongoing work. The emphasis is on the word “wandering” as an impromptu movement within a workplace, rather than a plan where employees expect a visit from managers at more systematic, pre-approved or scheduled times. The expected benefit is that a manager, by random sampling of events or employee discussions, is more likely to facilitate the productivity and total quality management of the organization, as compared to remaining in a specific office area and waiting for employees, or the delivery of status reports, to arrive there, as events warrant in the workplace.
The origin of the term has been traced to executives at the company Hewlett-Packard, for management practices in the 1970s. The management consultants Tom Peters and Robert H. Waterman used the term in their 1982 book In Search of Excellence: lessons from America’s best-run companies.