Design Thinking and Agile way of Software Development – Response

Few of the fellow agilest pointed me toward a picture in which Design Thinking, Lean Startup, and Scrum are shown in a sequence.

This picture is the brainchild of Gartner. Let’s talk about this picture. If you look deep into this picture, you will realize that this picture hides the waterfall mindset under the Agile camouflage. As per this picture, you need to understand the customer’s problem only once. Will you not go back to the customer for feedback again once you have understood the initial problem? In the software world requirements evolve as customer develops a better understanding of the solution – limitations and opportunities, changing business context, evolving technological landscape which essentially never allows designing phase to mark as completed.

What do you think?

 

Are efficiency and productivity good enough?

Recently, I was at Newark airport, terminal C. From the terminal, only one airline operates United Airlines. This exclusive use of the terminal by only one airline has its own side effects:

• A large number of people at the terminal as United is one of the biggest airlines in the USA
• Issuing of the boarding pass and collecting luggage items for check-in is centralized as per the flying classes. A large number of counters (manned as well as self-service) are dedicated to each flying class – Economy, Business, etc., located in clusters.
• Security gates are also centralized as per the flying classes. There is a separate set of security gates for each flying class and as per airline loyalty point status.

Centralizing the services combined with very effective crowed management by erecting artificial barriers to force queuing has resulted in very efficient (faster processing of passengers) and productive (a small number of personnel managing a huge number of passengers) system. The whole system works like a well-oiled machine.

When I was passing through the system, I was admiring its efficiency and productivity but somewhere I was not feeling happy. I was getting a feeling that to achieve a high level of efficiency and productivity, a human touch is lost or even not considered while designing the system. Passengers were treated like people in a prison camp – to be controlled and pushed in a certain direction on a continuous basis. I felt like cattle that are managed by people on the horseback. Though the whole system was super-efficient, it left a bad taste. After this experience, I realized how cattle feel when we treat them like cattle.

When do we design a system which involves human beings do we consider only efficiency and productivity? Do we need to consider something more beyond efficiency and productivity numbers?

Design Thinking and Agile way of Software Development

There is a lot of buzz around Design Thinking in Agile circles. It seems lots of Agilest are sold to the idea of Design Thinking for software development. Even SAFe has bought in Design Thinking in its fold.

As an Agilest, I prefer to look critically instead of part of the crowd; try to steer away from the herd mentality. Let’s try to understand what is Design Thinking?

Design Thinking is a methodology to design a product with close interaction with stakeholders (customers. consumers, financiers, etc.) in an iterative manner. Once product design is fit for the purpose, it goes into production and rollout.

Does this super brief description pose questions? For me, it certainly does.

In the core of Design Thinking, thought is about designing a physical product or a service. Once a physical product or service is designed and accepted as fit for the purpose, the design phase is over. In software development especially in Agile way of working, the design phase never ends. Design is an ongoing endeavor. Here is no mass production of software.

In my point of view, Design Think is a very good tool if you are working under waterfall assumptions – requirements are pre-determined (sic!), designers and coders are two different sets of people, etc.

In the Agile way of software development, Design Thinking may be useful to conceptualize the solution.  Even here, testing of the concept using Design Thinking remains an illusion. In my view, instead of Design Think, the Lean Startup model is better suited for Agile way of software development. Lean Startup model takes into account the iterative nature of software development which is in the alignment of reality.

Am I missing anything!!!

How Agile and DevOps are related?

Often I am asked: Are Agile and DevOps are the same? If we do the Agile transformation, do we need to do DevOps transformation separately? Can we do Agile transformation and DevOps transformation in parallel? What is common in Agile and DevOps? What is not so common in Agile and DevOps?

Answers to all of these questions can be obtained at two layers – Philosophical and Reality of daily life by answering one question – What is the relationship between Agile and DevOps?

Agile and DevOps both are the mindset, a style of working, treating your environment in an emphatic manner. Agile brings dev teams business together to serve the customer on a continuous basis. DevOps integrates dev and ops teams to release features on a continuous basis and monitor the solution continuously to ensure its availability with an appropriate level of performance.

Now it’s time to land in the real world. Agile aligns dev and business organizational structure to streamline the working rules between them to create business value with higher efficiency and productivity at a sustainable pace. Agile helps in managing changing priorities. DevOps aligns dev and ops organizational structure to fasten the feature release into production with predefined quality and enhances operational efficiency. Agile as well as DevOps promote contemporary engineering practices to increase flow, shift left, and continuous fight with entropy and drift to promote continuous improvement. Both Agile and DevOps are in favor of sustainable pace and resilient systems.

For embracing Agile, an organization needs both Agile and DevOps. There should not be two different initiatives to embrace Agile and DevOps. There should be one initiative – embrace Agile & DevOps.