Agile Buddha - Demystifying Agile, getting to its core www.agilebuddha.com

02/09/2023

Agilebuddha.com has moved to http://agilebuddha.in . You may want to see all posts there.

Demystifying Agile, Getting to its Core

30/07/2022

Humphrey's Requirements Uncertainty Principle - For a new software system, the requirements will not be completely known until after the users have used it.

29/07/2022

It may become difficult to understand sometimes what Trunk Based Development means in large enterprise environment, and how people working in traditional environment could move to such practice with ease. Here's a large bank case-study which you may want to look at. Also the idea got implemented 10 years back.

In the first part of the case-study, we looked at the difficult conditions the team lived in. This part focuses on how they moved on from the branch merge hell they lived in.

28/07/2022

With so many scaling frameworks becoming mainstream, somehow people forget the foundation. So with this post I want to be loud and clear.

Scaling frameworks are useful when more than 50 persons work towards one single product. If you are working with a couple of teams, it's worthless to even think about concepts like PI planning or applying SAFe/LeSS scaling concepts there.

27/07/2022

Until we can truly implement basic Scrum/Kanban, there is nothing to « SCALE ».

26/07/2022

In Toyota Production System, customers doesn't only mean just the end customer; *on the assembly line the person at the next workstation is also your customer*.

25/07/2022

Innovation in Agile methods comes from customer centricity, e.g "what could be the simplest but innovative *solution* to the problem customer is facing?".

The innovation in the solutions comes though understanding customer need deeply, and also through situational awareness of intra or across industries inventions or practices, domain, technologies (e.g. Machine learning, new programming language, AI etc).

The second level of innovation comes from the need to move to the customer as early as possible to (in)validate your hypothesis early, also also to reduce the technical risk by deploying to prod early and often.

In the available time box, what could the possible solution which a) becomes possible in that time box b) solves the problem customer has.

Instead of building your feature incrementally only (e.g. first sprint is building the micro services required, and second sprint is to integrate the UI with those services), it helps to work in incremental and iterative fashion so that each iteration provides an increment which solves the problem customer has.

25/07/2022

Agility is never only about delivering faster, it's about ability to create changes and respond to the changes quickly and with ease. That requires loads of thing. Working on the right thing (ability to identify that scientifically and in the most capital efficient way) is the first one. Going to the customer as soon as you can to receive his feedback could be second. Innovation could be third. There could be many more such things. However getting stuck with speed and delivering loads of features doesn't make any sense.

25/07/2022

When you start doing the right thing (deliver what actually a user needs and acting on his feedback continuously), you may a deliver a lot less as rest of the waste (assumed requirements) never requires to be delivered. At the end you deliver the objective sooner. It may happen that 6 months of work gets delivered in 4 months.

17/07/2022

" is something you strive to get rid of, not to be proud of.
-- Jeffery Liker (The Toyota Way)"

It is desirable to develop a learning organization that will find ways to reduce the number of kanban and thereby reduce and **finally eliminate the inventory buffer**.

Just to make sure, "In Progress" items are inventory as well. The ideal is "one-piece flow", i.e. building one piece at a time. Doing that in manufacturing has practical constraints. However in software such constraints are not there.

The team can pick up one piece at a time, work as a team together, and move to the production. In such a scenario team works in simultaneous phases (teams perform significant analysis, design, testing, and coding every day as activities but not as phases) as happens in XP.

There are only 3 classifications waiting, in progress, and done instead of David Anderson's multiple stages: Engineering Ready Queue, Systems Analysis, Development, Build, Test, Release Ready, and In Production.

In David Anderson's Kanban the team works on multiple features at a time, which leads to a need for complex configuration management, and lengthens cycle time, and potentially creates silos in a team.