Tuesday, December 17, 2019

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?

Wednesday, December 11, 2019

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?

Monday, December 9, 2019

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!!!

Thursday, December 5, 2019

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.

Wednesday, December 4, 2019

When not to use Scrum?

  • When not use Scrum?
  • When to use Scrum?
  • What are the preconditions to use Scrum?

 The answer to the first two questions is pretty straight forward. If the work you are executing belongs to the Complex domain of the Cynefin framework, Scrum is an appropriate choice. If work belongs to the Simple/Obvious domain, Scrum will be overkill. For work belonging to the Complicated domain Scrum might be ok but I will prefer to look for an alternative. Work belonging to the Chaotic domain needs to be brought into Complex or Complicated or Simple domain.

The answer to the third question is a little more nuanced. Before going into details of the answer, I want to introduce two new words:

  • Sufficient-Condition
  • Continuous-Condition

 Sufficient-Conditions: The bare minimum set of conditions to adopt a process or start working under a methodology. It is possible sufficient-conditions may not allow adopting the process/methodology in full but good enough to start and moving toward its full implementation. 

Sufficient-condition is not the same as pre-condition. Pre-condition does not bother about what happens after pre-conditions are met; sufficient condition is OK with partial adoption.  

Continuous-Conditions: These conditions build up over sufficient-conditions and existing continuous conditions. With continuous execution of the process or working under adopted methodology, the quality of adopted process or methodology keeps on increasing as the environment presents the increasing number of opportunities and more and more conditions are met to adopt process/methodology.

As we have sorted out vocabulary, it’s time to list sufficient-conditions to adopt Scrum:

  • The team should be willing to deliver in increments (Iterative approach is preferred over incremental)
  • The team should be willing to stick to a time box (fixed time-box is an excellent start, variable time box is a slippery slope) for each increment. This time box should be under four weeks
  • There is someone to play the role of Scrum Master (Full time is the best-case scenario, it is OK to start as an additional responsibility by one of the team member)
  • Team has technical skills to create increment with acceptable quality
  • Team has access to the tools, space, and allied resources to create an increment

Continuous-conditions build over sufficient-conditions and existing continuous-conditions. Some of the continuous-conditions are:

  • Dedicated Scrum Master
  • Scrum events (Sprint Planning, Daily Scrum, Sprint Review, and Retrospective) are observed regularly
  • Fixed time box for the Sprint
  • Product Owner is engaged with the team
  • Continuous refinement of the Product Backlog
  • The relative sizing of work items
  • Well understood Definition of Done (DoD)
  • DoD reflects desired results from completed work items
  • Every member of DevTeam is full time in the team
  • Scrum Master is competent and has resources to tackle the impediments 

In very simple terms, sufficient conditions are a good starting point to adopt Scrum with desire and will for continuous improvement. If desire and will for continuous improvement are lacking, opportunities presented to meet continuous-conditions will be lost.