It’s been two weeks since my last blog on the transformation of our internal Continuous Delivery process, and while the progress has been slow, the ‘baby steps’ approach is moving into ‘toddler’ mode – at times chaotic and all over the place, but the interest and enthusiasm for change is intoxicating, motivating me to stick with it and press on.
Last time, I focused on how I applied design thinking to transform the way we planned for Continuous Delivery within the ALM organization. Let’s turn now to the specifics of the planning process itself and how I propose we integrate design thinking as part of planning for Continuous Delivery to ensure our success. In a recent Gartner report, Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology, they wrote "DevOps is not a set of technology tools…it is a cultural shift to improve quality of solutions that are business oriented.” Precisely! And in our effort to ‘walk the talk’ and be a good example to the rest of you struggling with this cultural shift, I want to explain why design matters as part of the transformation to a Continuous Delivery model.
Good Design is Good Business!
IBM recognizes that good design is good business. That’s great, but unless design is actually an integral part of planning and execution, we’re kind of insignificant in the overall scheme of things. My challenge is to come up with a process for our internal ALM organization that involves design in a practical way, that shows how we operate, what we deliver, how we really contribute tangibly to Continuous Delivery. Design is relevant for Continuous Delivery and brings real value to the overall process, but believing it and doing it are worlds apart.
I start by proposing this: if we as an organization are to make that cultural shift to improve the quality of solutions that are business-oriented, we must shift from a process that supports the delivery of features in products (with little or no business context) to a process that considers the business requirements first and then delivers solutions comprised of products with features to support them. We are really turning the existing process on its head, focusing on the delivery of business-oriented solutions not just feature-packed products.
The taxonomy below defines the planning artifacts we are employing as part of our new process. Design activities bridge the gap between business planning and IT execution by focusing on the articulation of Business Requirements to define the capabilities required by users, identifying the gaps in our existing solutions to support those requirements, then ultimately refining them into work items that drive IT execution and delivery of product-level capabilities.
The design exercise examines the business-oriented solution from the outside in, from the perspective of the user, performing user-level research, exploring existing capabilities and deriving the vision for our solutions going forward. Development teams try to do this, but it’s not their day job…in a quarterly release cycle, with a chunk of time devoted to prioritizing a backlog of work and another chunk devoted to creating spreadsheets and attending meetings to report on status, it’s kind of amazing that anything gets delivered at all. Having a team dedicated to the design activities allows us to focus on that very critical aspect of the overall process, which is explored in detail in the illustration below.
Creating Actionable Designs
At this point in my spiel, I get a lot of nodding heads. No real disagreement. But tell a technologist, a developer, an IT architect, a technical lead, that a bunch of pretty pictures is a key part of the overall planning process and that it can help them prioritize the tremendous set of work on their backlog and all niceties go out the door. Design is fine, but there is real work to do! My challenge is to not only show where design fits within the planning process, but how it will actually make a difference. Time for another Wow!
Working with scenario design leads on my team, we brainstormed on the idea of creating actionable scenarios in order to take this beyond a drawing exercise. No offense to my fellow designers, but we have an image that needs a bit of work if we are to be taken seriously. We came up with a proposed list of deliverables that development is typically responsible for that could be seeded from design scenarios:
- Task Guides (reflections of User Stories that could be used for betas or technology previews)
- Online Help Outlines
- Demonstration Scripts
- Proofs of Technology Tables of Contents
We also considered the significant contribution design can make to our testing effort. Rational’s quality management organization is successful in validating the quality of our products, but validation of solutions is far more difficult. Enter design. The scenarios we develop can, and should, provide the foundation for our solution-level test plans. In fact, our detailed design artifacts, which include wire frames, acts and scenes, actually begin to identify the steps required to accomplish a business task – the skeleton for a test script.
We’ve covered the development and test organizations and made a strong case for how design can help. One last critical group of stakeholders to impress remains - the decision-makers, the business leaders in our organization. The Wow! for this group of users is two-fold: inform them about the business capabilities that will be delivered to customers, and tell them when it will happen. At the end of a release cycle, the bottom line is “what can my customer do with this?” By including design as an integral part of the overall planning process, we can answer that question and many more about what will be coming in the next delivery cycle and the next and the next. We have a complete process, one that ensures quality of our solutions, not just from a feature/function perspective, but from an understanding that in the end, we have delivered what is required from a business perspective.