As the lead functional designer in charge of complex IT scenarios for the IBM Rational Design Team, I was challenged recently to help our internal development organization ‘walk the talk’ – drink our own champagne, practice what we preach, use what we sell. After all, we are a large enterprise. We develop software solutions that epitomize the same complex IT scenarios I’m trying to get my head around. What a great opportunity to practice this, to use our own organization to validate my scenarios. In this blog, I give you a window into my designing mind so that you can see how I applied design principles in a practical way to help our organization transition to a Continuous Delivery process. Ultimately, this project is also helping me refine the complex IT planning and management scenarios that lay the foundation for the solutions we deliver to delight all of you. This blog is not about Continuous Delivery specifically, it is about design. For more information on the details of this journey, please visit DevOps on jazz.net, where you will find blogs from me and others on how we are actually doing this.
Making the move from more traditional methods to an agile, Continuous Delivery model is anything but trivial. (If it's a new term to you, watch this Continuous Delivery video.) Particularly in an enterprise organization like IBM, there are all the typical challenges associated with large scale transformational efforts. But change is good, right? Sure…it’s also really hard. So where do we start? When challenged with a complex problem, my go-to approach is to take ‘baby steps’…understand the challenge, articulate the short- and long-term goals, try it out, revise, repeat. By practicing what we preach, only then am I confident in sharing the process with others. I believe that we must first act as the consumers of our software to solve a real business problem before we can even propose to understand how another organization might do it. Man, do I love this idea!
Designing the Continuous Planning Process
This ‘baby steps’ approach might be more accurately portrayed as a ‘design thinking’ approach. Design thinking dictates that I consider the Who, the What, and the Wow. My goal with this project was to do that for our organization. By embracing this challenge, I get to play the role of the user, the Program Manager who needs to spin up a complex project from business planning to development and test and finally to deployment. I also get to try out this scenario with some of the executives in our organization to not only help them do their jobs, but also show them how our software allows them to do that. This is going to be fun!
With my ‘design thinking’ hat on, I started by tackling the Who, identifying the roles in our organization involved in the Continuous Delivery process. The short list from a planning perspective includes the executive stakeholders, the business leaders that make investment decisions, and IT Program, Project and Product Managers that must ensure we deliver on those objectives.
Next, the What. What are the activities these roles engage in, what information do they need to plan and manage a complex project throughout this process? In particular, what would Dibbe Edwards, our VP of Development, need to know in order to better manage the software development and delivery process for CLM? Got the Who and the What. Now how do we Wow! them?
In trying to come up with the Wow! solution to this challenge of planning and managing complex projects to enable Continuous Delivery, I considered what a “day in the life of Dibbe” looks like and how she does her job today. In short, spreadsheets and meetings. Sound familiar? There is a better way, and not just for Dibbe and the other business stakeholders. Better for Dibbe means better for managers all the way through the development lifecycle. Here is the Wow! My goal is to eliminate the spreadsheets and minimize the meetings. This doesn’t address all of the problems with our Continuous Delivery transformation, not by a long shot. But it is a perfectly reasonable ‘baby step’, a Wow! for some of the key roles in this scenario.
We are just starting this journey and have a way to go before we can claim success, but by applying design thinking principles I have been able to frame the problem by looking at the users and what would excite them about a solution that helps them do a better job every day.
What can we do to make your job better every day?