Written in direct collaboration with Richard Hensley (McKesson AVP).
“Knowledge is an unending adventure at the edge of Uncertainty.” – Jacob Bronowski, British mathematician, biologist, historian of science, poet, inventor, author of “The Ascent of Man”
“Maturity of mind is the capacity to endure Uncertainty.” – John Huston Finley, 1938 – New York Times editor-in-chief
“Many high performers would rather do the wrong thing well than do the right thing poorly.” – Thomas J. Delong & Sara DeLong, “Managing Yourself: The Paradox of Excellence”, June 2011 – Harvard Business Review
It’s common to see an organization (the people in them) focus on building systems with as many features as possible and targeting delivery by a specific due date. Yet, often the result is missing the date while also ignoring other important goals demanded by the businesses such as high levels of product quality, development productivity, planning reliability, employee satisfaction, and customer loyalty. Retrospectives, if done after such an occurrence, surface the dissatisfaction concerning missed dates, poor quality, technical debt, and more, still frequently this pattern repeats. Does this scenario sound familiar to you? If so, why do you think it is so? In a past or maybe your current organization, I’m guessing you’ve heard or thought, “We need our business and technology people on the same page.” How might “being on the same page” look in your organization? Does your current software development methodology, its principles, processes, and practices, contribute effectively to this objective? Is getting on the “same page” with objectives and goals enough?
Over the last three years Richard Hensley, AVP Process at McKesson Health Solutions, has worked to address these challenges within the three business units of the division he works in at McKesson. I’ve been able to catch up with him on several occasions and discuss his efforts over these years. This post is a brief “fly-over” of his experience, capturing some of the key thoughts Richard developed over this time, and shared during our conversations.
No Silver Bullets Here!
Anyone reading a blog post on getting business and technology people on the same page probably knows there is no “silver bullet” to this challenge. Chances are good you’ve already been a part of such an effort, right? If so, you know it is not a simple task. Or even if you saw them start out on the same page in your organization, did issues appear that caused this working relationship to return to its earlier challenging state?
In short, Richard suggests, “you won’t find quick fixes for this issue” and his experience indicates it takes a serious effort from both sides. It also requires a continuous commitment over time because “getting everyone on the same page is a good start but not sufficient to sustain the business.” Yes, getting on the same page upfront, by itself, can be a positive thing as it helps everyone feel good, knowing where others are at and being in the know. If you’re familiar with the practice of daily stand-ups, you can draw a comparison, getting on the same page only is like a stand-up where team members simply provide “status” of their work. It is a good start, but alone it is ineffective for helping to solve real issues. In a similar fashion, getting on the same page with objectives and goals, if that is all you do, doesn’t help anyone address how things might be done more quickly or more effectively. It is a good start, but more is needed!
In May 2009 the Lean & Kanban Conference was held in Miami, Florida. It was the first ever conference focused completely on applying lean-agile and kanban principles and concepts to the software development field, put on then by the recently formed Lean Software and Systems (LSS) consortium. The next year this conference was renamed to Lean Software and Systems Conference (LSSC) 2010 Atlanta, then followed by LSSC 2011 Long Beach, and most recently LSSC 2012 Boston. Though Richard and I both live in the Denver-metro area, the first time we ever met and began discussing his efforts at McKesson was actually at the L&K 2009 conference in Miami.
Richard Hensley (Brickell Key Award Winner – LSSC 2011) has worked twenty-five years in the healthcare technology industry, building systems supporting pharmacies, prescription insurance claims, clinical laboratories, and many more. At McKesson Health Solutions, he leads the lean business and product development transformation, working with business and product development leaders to “pull the quality lever” in a meaningful way. Over the last three years they have worked to transform the development organization responsible for products supporting four major lines of business that contribute significantly to the financial success of McKesson.
Employing the Kanban approach for change management, McKesson implemented new tools selected from RUP, XP, Scrum, and lean—daily focused planning, stand-up meetings, retrospectives, TDD, information radiators, user stories, etc. They automated anything they could and measured everything possible. These efforts have delivered 103 production releases with no significant defects, fulfilled sixteen multi-million dollar contracts, maintained high employee morale, and trained 5,000 users. Most importantly, though, they developed a culture that puts quality and continuous improvement at the forefront.
How Might Business and Technology “Peacefully” Co-creating Look?
To describe what business and technology “peacefully” co-creating in his organization might look like, Richard suggests you think in terms of “Getting in the same boat!” That is, it doesn’t look like a large boat dragging a dingy. It is clearly the organization’s business people and technology people getting in “one” boat, the “same boat”, and then everyone paddling in the “same direction.”
How does this look on the organization floor? At the highest perspective, Richard says business and technology peacefully co-creating looks like this:
- Co-making decisions
- Co-facing the outcomes and consequences
- Developing and using a common language to communicate with each other
It is about co-making decisions, with both business people and technology people engaged in identifying and creating a shared understanding of these decisions. This includes identifying key principles and having a common belief in them as a foundation for guiding these shared decisions.
Then, it is co-facing the outcomes and consequences of these decisions, especially during necessary and important learning phases when some of these decisions won’t be perfect and the water gets a little choppy. Without shared creation and shared accountability it’s too easy to slip back to “separate boats” thinking and actions. Again, it’s about being in one boat, paddling in the same direction in the good and easy times and in the tough (learning) and rough times. Richard’s experience indicates you really have to start here with these first two keys to visualize how business and technology “peacefully” co-creating would look in your organization.
A big part of making these first two keys work is the third key that he suggests which is developing and using a shared nomenclature across your organization’s levels. The nomenclature you develop and use needs to be meaningful in your context and it needs to become the primary tool that enables good communication between your organization’s levels. However, it’s important to also allow each level in the organization to develop and have their meaningful part of the nomenclature. That said, a level’s nomenclature must still be understandable and have meaning across the other levels in the organization. We’ll talk more about organization levels in the next section of this post as well.
As LSSC 2011 Long Beach came to a close, several groups gathered for open space sessions. Several of these sessions soon converged on discussing the challenge of helping higher business levels in the organization learn about the lean-agile principles many of us there were successfully employing at the technical levels within our organizations. Richard began sharing several of the thoughts captured here now in this post. His notion of developing upfront a common nomenclature caught my attention for a couple of reasons. The first is I think this explicitly states a key point (perhaps missing or not explicit enough) related to the ideas I’ve read about elsewhere for creating a Lean-agile PMO in an organization (see “The Lean-Agile PMO” by Sanjiv Augustine).
But what really hit me about this suggestion was the parallel to the idea of developing a “ubiquitous domain language” related to developing software architecture models used to aid builders (developers) of software with effectively communicating with users and business stakeholders (see “Domain Driven Design” by Eric Evans). In essence, Richard’s thoughts on developing and using a common nomenclature from an “organization architect’s” perspective addresses a similar challenge of facilitating effective communication across the business and technology levels of an organization.
How Does Business and Technology “Peacefully” Co-creating Occur?
So you’re in the same boat now, and paddling in the same direction. You’ve identified some key principles to guide your processes and practices, you’re co-making decisions, and you’re co-facing the outcomes together, both the good ones and the bad ones. And you’ve developed and are using a common nomenclature to talk about the things important to both the business and technology sides of the house and through the levels in the organization. What’s next?
Think back to “tough times” you’ve had when working with others. What do you remember most about these? Was it “frustration” with not being able to help someone “see” your perspective? A large part of keeping things moving in the same direction is handling these tough times constructively. How? A key to addressing this Richard suggests is to “focus on helping others learn by doing (not by teaching).” Why?
It is tempting to think you can “teach” the other side what they don’t know when differences arise. However, teaching doesn’t guarantee learning occurs (that is, learning by those being taught, even though teaching others about something does often help the “teacher” learn it more deeply). Learning models indicate learning occurs more deeply and effectively by doing (hands-on) in the context of what you are attempting to learn.1, 2
Richard’s experience leads him to believe the “the necessary education comes after the learning, learning by doing, not before doing, and not by trying to teach it up front.” In fact, he thinks “teaching up front would have likely constrained the solutions (their early efforts) prematurely due to yet incomplete knowledge of problems (their system’s yet undiscovered and not well understood issues).”
Again, what stands out for me is here regarding Richard’s thoughts, is how they parallel and adapt from what I’ve read about elsewhere. In this case the impact of focusing on learning upfront before specifying or designing an initial solution is a concept reflected in Michael Kennedy’s work studying the keys of the Toyota Production System3 and also reflected in ideas found in David Snowden’s work on complex adaptive systems4.
As you go through this process of learning together and, as mentioned earlier, develop your common nomenclature, Richard suggests you continue to ”recognize the following different organizational levels and roles.” At McKesson, for his division, he’s identified the following:
- Strategic Level – Business Leaders
- Tactical Level – Product Owners, Business Analysts
- Execution Level – Developers/Engineers, SMEs (subject matter experts) QA & Testers, Software Architects
Business Leaders are responsible for defining “Why” via “initiatives” needed to achieve the strategic business objectives and goals. In Richard’s context at McKesson these initiatives, this term itself and the language used to describe them, are part of the common nomenclature developed to communicate them to the other levels of the organization.
Product Owners and Business Analysts are responsible for defining “What” via product “features” needed to achieve the business initiatives. In essence, this represents the tactical aspects of achieving the desired strategy developed by the business leaders. These features, this term itself and the language used to describe them, also are part of the common nomenclature developed in Richard’s McKesson division.
Developers/Engineers, QA & Testers, and Software Architects are responsible for defining “how” via technical processes and practices needed to build the specified product features. At this third level, the notion of “stories”, the term itself and the language used to describe them, become part of the common nomenclature, as do many other terms related to processes and practices at this level. For example, terms like “sprint” or “expected lead time”, “flow rate or throughput”, “backlog”, “t-shirt size”, etc. need to be well understood and shared across the necessary levels in the organization too.
One last and very key point Richard makes is related to the terms responsible, accountable, and influence. We’ve already discussed “responsible” above for each level. But Richard feels it is critical that “no level should define for another level anything that it has no direct ability to truly influence.” For example, how long it takes to complete a requested feature, after the tactical level has specified it, is solely the domain of the execution level of the organization. The tactical level should not attempt to specify both what (the feature), and also how long it will take to develop (executing the building of the feature).
In closing, the intent of this post was to be a “fly-over” of Richard’s experience, capturing some of the key thoughts he’s shared with me during our conversations about his efforts over the last three years at McKesson Health Solutions and in his role as AVP Process. In particular, at a high level we’ve talked about how business and technology “peacefully” co-creating might look, identifying three key characteristics, co-making decisions, co-facing the outcomes and consequences, and developing a common nomenclature for communicating between the levels in the organization. We then suggested that business and technology people focus on helping each other learn the other’s differing perspectives in the context of doing and working together on real issues, not by trying to “teach” the other upfront with discussion or debate and why this was important based on learning models. Lastly, we identified three common levels in an organization and highlighted the differing perspective and focus of each and the importance of respecting these differences of responsibility and influence.
Going forward, ideally we’d like to hear from you any specific questions or comments on the concepts and ideas above. Our plan would be to possibly address and include those in a follow-up post maybe even two based on interest and the feedback received. There is certainly more to share about Richard’s experience including a deeper dive into the nomenclature he’s seen developed at McKesson, as well as looking more at how they have visualized their organizational level workflows and the key interactions between these levels. Depending too on interest, another area to explore further might be the key metrics they are using to help identify issues and monitor their improvements. We hope you share your thoughts too and look forward to hearing from you!
1 For a reasonably short but still usefully in-depth paper as a starting point on understanding how teaching, learning, and learning to learn, might differ, check out “Learning to Learn” by Karl R. Wirth and Dexter Perkins.
2 “Strategies for Learning from Failure” by Amy C. Edmondson is a reasonably short but still useful paper on how an organization’s attitude toward failure can inhibit or promote learning, not just learning, but rapidly learning, and provides insights for strategies in different work settings where learning can occur effectively.
3 See the book “Ready, Set, Dominate” by Michael Kennedy; also his earlier work “Product Development for the Lean Enterprise” for insights into concepts like set-based design (if you think SBD is only about simultaneously considering multiple potential solutions to a problem and converging to one, you’re missing a significant part of Kennedy’s message).