How does Design Thinking relate to Agile?

Design Thinking and Agile are two sides of the same coin. Design Thinking, when implemented correctly, can help an organization to identify which products add the most value to our customers. For example, in the world of banking, Design Thinking can be utilized to determine which new features should be added to an online banking platform to attract and retain customers. In the restaurant sector, we might use Design Thinking to determine which new services will help retain customer that have families.

If Design Thinking is a way to determine what to build or offer next, then Agile is the process that we then use to implement these ideas. Agile uses and iterative approach to building the product in services in such a way that we can provide the customer with something incrementally to generate feedback loops. We can then use these feedback loops to validate that we are building the correct product and to reduce our Return on Investment.

My teams are not UX designers, so why should they use Design Thinking?

There is a common misunderstanding that Design Thinking is about creating effective user interfaces. Why this can be part of what Design Thinking can be used for, it is only a small subset. Design Thinking is a process used by successful organization all over the work to help drive innovation and product development. Design Thinking focuses on working with customers to understand what motivated them, what problems they have, and how an organization can help solve these problems.

Design thinking focus on empathizing with customers, define root problems, determining real solutions to these problems and then experimenting to determine if our ideas add value and are beneficiation. Design Thinking highlights what problems and solutions are worth investing in, thus reducing risk and promoting cost efficiency.

Configuration Management – Just Do It!

Configuration Management, as applied in DevOps, is the practice of using tools to manage the configuration of our technical architecture.  Put simply, we document the desired state of one or more servers in a machine-readable form, and then use a configuration management tool (e.g. Chef, Puppet, Salt, or Ansible) to setup the real items to match the configuration.

Why?  As with many things, you might think “I barely have time to setup this server manually, never mind write a script for it”.  But the reality is, in today’s world, we’re probably going to have to do the same setup multiple times.  In enterprise environments, the software engineering process will require deployment to several environments (development, integration test, user acceptance test, performance test, then finally production).  It’s critical that all these environments are identical (so far as is practical).  This is a key tenet of DevOps operating practices – we can’t apply learnings from one environment to others if the environments are different.  Even in a simpler environment, you’re probably going to replace your servers in a fairly short time frame.

Once upon a time, we used to buy server hardware and nurse it along for years.  Nowadays, hardware and system software ends up obsolete in a matter of months, not years.  If you’ve done your CM work properly, it’s faster to deploy to a fresh OS image than to patch an existing image.  And if you’ve embraced virtualization or a cloud environment, you’ll find it’s easier to replace a server than to troubleshoot it.

There’s another advantage to Configuration Management:  The system state is documented and version controlled.  There’s no need to do archaeological work to find out what your technical architecture has evolved to – you just look at the configuration scripts.

So here’s your challenge for the next year: Stop managing your servers by hand.  Setup an open-source Configuration Management system and create a configuration repository (I’m partial to Ansible.  See https://www.webagesolutions.com/knowledgebase/kb024/kb024-install-sw-ansible for some tips to get started).  Every time you find yourself ssh-ing or logging in to a server, stop yourself and create a playbook, recipe, or run-list in your CM repository.   Make it a habit to use manual tools only to examine the server state, not to change anything.  Run your servers the way developers write code:  If it isn’t in version control, it didn’t happen!

For that matter, do the same thing on your laptop or workstation.  You’ll soon find that you’re much less stressed about maintaining your configuration or upgrading your hardware.