Leanness for agility with jidoka and code monkey


Improving ‘FLOW’ (using jidoka) towards a smooth automated build & deployment system is an extremely challenging journey for large corporations
One of the root causes is the presence of huge legacy systems.





History has proven that the first baby step is to consider defining a recurring frequency for build & test. The next iterations are to continuously measure and improve upon the first step.

It is both painful and time-consuming in the start and carries numerous long term benefits.

‘Jidoka’ comes from lean manufacturing and maps into automated software builds for our industry
It means that an automated process is sufficiently "aware" of itself so that it will:



In ManufacturingIn Software

  • Detect process malfunctions or product defects

  • Detect failing automated tests (regression & unit)

  • Stop itself

  • Stop the build

  • Alert the operator

  • Escalate the build failure accordingly

Create a role “build monkey” who shares the build information as part of the daily scrum routine. Discussing the potential jidoka in the daily scrums is an effective and logical first step.


In addition to "What I completed yesterday", "What I intend to complete today" & "Any blockers" - the build monkey answers one extra question - "Build failures?".

Highlighting this root-cause of lower quality and missed deadlines, can go a long way.

The ultimate result is improvement in productivity and a solid foundation for continuous innovation.

CXOs' portfolio prioritization conundrum [Part 1 of 2]

CXOs & Portfolio Management has been a star challenge in the agile transformation for the past few years. Organizations continuously endeavor to master this art of forecasting (in simple terms - what to work on - "Next Year").

Various methods including:

  • Return on Investment (ROI)
  • Highest Paid Person's Opinion (HiPPO)
  • First In First Out (FIFO)
  • Cost Benefit Analysis (CBA)
  • .
  • .

and numerous other techniques are used to help answer this prioritization conundrum.

Unfortunately all the above mentioned initiatives frame us into the boxed thinking of return on investment focused financial models.

Imagine this. You have a box of apples to choose from. Our choice is limited to the selection of apples presented to us. 

Do we have a choice not to pick any?

........ stay tuned for the next blogpost (part 2 of 2) for a potential solution to this rotten challenge.




Principles of Product Development Flow [Part 0 of 12]

In the coming weeks - I will be sharing excerpts of my notes on this amazing and complex book.

Donald Reinertsen's instant classic "Principles of Product Development Flow" has been very instrumental in helping numerous organizations redefine the VALUE and PURPOSE of deliverables based on the principles of FLOW.



Mark Twain's perspective bridges the gap between science and art of product development.

It ain't what you don't know that gets you into trouble. It is what you know for sure that just ain't so.
[Mark Twain]


 I highly recommend the book - however, it is extremely dense and one chapter can take days (if not weeks) to scratch the surface of those complex topics.

 

Popular Posts