• Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 24 other followers

  • Archives

Form (ever) Follows Function

Ice, Water and Steam- Three forms of the same source serve different purposes. Each form serves multiple unique purposes. Force fitting these forms for functions not meant for them, don’t help and fails miserably.sample

This is a great natural example of “Form Follows Function” theory expounded by great architect Louis Henry Sullivan through his favorite design phrase, “form (ever) follows function,”

All great concepts like SAFe, LeSS, Lean,etc do insist on achieving the Goal collectively as an engaged organization. TOC nicely summarizes and advocates to Increase the throughput to maximum using leverage points / constraints.  Choosing a or a combination of any concepts before applying to any program should be judged by the function it should deliver rather than fitting the function into the templates of pre-determined concepts.

Common causes of failures of new initiatives in my experience are attributed to predetermined “Management flavor of the season” initiatives rather than focusing the function that need to be served.

What is your experience? please share your thoughts.

Advertisements

Release the Air, let the Value Flow

An engineer (Tech Arch) in a car manufacturing company designs a world class car.

While trying to bring out the car from the plant area, they realized car is few inches taller than the entrance. (Root Cause – Not factored all non functional requirements – Test and user environment set ups incomplete)

Engineer felt bad as he has not factored this requirement.

Painter (UX engineer) suggested they can bring out the car and there will be few scratches that can be touched up later on. (Applying patch after retrospective = extra cost)

Engineer suggested breaking the entrance (More cost, schedule delay), taking the car out, and later redoing the entrance.

A Gate Keeper was observing and remarked “Sir, the car is only few inches taller than the entrance, so simply release the air from the tyres, which will reduce the height and then you can easily take out the car”.

slide1

In TOC, this is an example of Inherent Simplicity and Never say I know – two key pillars of TOC.

Lean stresses this in its Lean Principle Respect People

In Agile parlance, it is involving all stakeholders during design retrospective (apart from Tech , DEV team include support teams as relevant) and be open minded and good listener.

Don’t look problems always from expert points of view.

There’s always a layman’s outlook that might provide an alternate solution.

DOD for Agile rationale – UB4I

UB4I  – DOD for Agile rationale 

Value delivered is the most effective metrics in Agile. Prioritization by Product owners  and relevant stakeholders make the user stories for first few sprints.

‘Don’t measure people but product’ paradigm is best  represented by Agile model.

You before I mindset is the greatest skills for an Agile team member. Like we have definitions of done for various  stages of Agile product development, an attempt at DOD for successful Agile practitioner is UB4I.  

Some traits for UB4I

  • teams share their work expertise
  • caring for other issues
  • Committed to common Sprint and product goals
  • pitching in whenever team requires help
  • Collaborative
  • co-creative
  • Be a product developer as against coder
  • wearing multiple hats in the projects

please add on…

 

Pythagoras values for Agile delivery

Value delivered (Working Features) = Product Backlog + Non value added features (incomplete
features)

Lesser the non value added features, more value delivered.

Though defects cannot be made zero, hence incomplete features and non priority functions (contextual defects) are pushed to the next sprint cycles. Ensuring effective prioritization will help teams to deliver more values

Practice Pythagoras for a perfect value delivery using Agile

When fix is painful than defect (Medicine pains more than illness) – Get to theory- 3.4 couplet

When fix is painful than defect (Medicine pains more than illness)

Get to Theory

~3.4 couplet

A small half cup (like that of cough syrup bottle) will contain 1 KG of water vis-a-vis around 74 mL of water. This is the practical way of informing the density concept to children, instead defining in formal physical terms like ratio of unit mass to unit volume expresses in kg/cu.m etc.

However as the child grows perception of density becomes a concept and understand the definition formally. When the child was not able to visualize concept, a direct visual demo was required as the child could not apply the density with just basic perception. However when the child becomes grown up, it will need to understand and extend the concept to broader areas and will be able to derive the density of various substance on its own use the property of density in the relevant application.

The point am trying to suggest is that quick and hot fixes in the name of Agile, will impair the long term solution/product rather than strengthen it.  Here we need the help of theory and concepts. Addressing the root causes and systematically eliminating them will make the model more solid and ensure that product / service is evolving in consistent and effective manner. There are cases where the fix is taking so much effort and cost than the leaving the actual defect in the system, resulting in more CoPQ.  Looking at this way also predictive capabilities if remain the focus and applied in true manner, then will ensure meeting long term objectives of all customers.

Solid grounding on basic concepts will help, in the words of great Toyota way provide the customers with what they want when they want and in the amount they want.

MUDA- Agile-combination – long term as well as short term benefits

Agile can be used to build a great product that can use best of both worlds like long term vision – building a good  overall product as well as quicker return of investment – by delivering working iterations in quicker sprints.

Awareness of MUDA  is more important at the mental level than the measurement level. Just to expand this,  the team need not have checklists of do’s and don’ts rather focus on what is really important to customer in the current project and eliminating everything that customer does not want. During the initial two to three sprints there will be mutual learning between the customer and vendor and then once the PULL mechanism is established , the MUDAs can be identified from all perspectives, the value and product will flow in smoother manner by eliminating the MUDAs

Identifying objectives for the common good of all stakeholders and customers in particular will help define the MUDAs that need to be eliminated from the system.  This will make to faster deliveries, better products and cheaper costs for all the stake holders

Quality principles and Agile

Customer Focus:

Internal and external customer focus. Pulling of values by customer. High level of customer transparency

Leadership

Servant leadership  – everyone owns the product

Involvement of People

Full stakeholder collaboration including developers, end users, QA, Management, etc

Process approach

Elimination of non value added steps and ensuring focus remain closely with respect to current priorities

System approach to management

Keeping in mind the bigger picture of product vision each sprint is developing a theme towards the making of final  product. Automated testing and continuous integration form system approach

Continual improvement

Learning from the previous deliveries of iterations of scrum, incorporating the customer / stakeholder feedback and striving for elimination of NVAs(non value added wastes) from the processes demonstrate continual improvement.

Factual approach to decision making

Decisions are taken through real data obtained through direct stakeholder like customer and end users. All iterations / releases can be directly consumed by users. User feedback gets incorporated into subsequent sprints. Great way of factual approach.

Mutually beneficial supplier relationships

Supply chain efficiency is at its best in Agile / Lean development since customers, vendors and all stake holders are in continuous contact with each other monitoring the product development. Software vendor delivers product to immediate customer, gets the billing done, customer releases products to end customers through various sales channels and monetize the product releases. End users get their requirements fulfilled