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

    Join 24 other followers

  • Archives

  • Advertisements

Gemba – try out for sales

Gemba in Sales

Gemba is generally associated with actual place typically at  shop floor in manufacturing and in Agile development right at the sprint teams.

How about using them in Sales.  Some thoughts. Should Sales team simulate customer usage and customer experience and customer communications too. May be yes worth trying out.

Customer usage : How customer tests and uses all features of the product in functional, performance and security aspects. How is the user environment response?  Perhaps Devops has simplified this aspect in major way.

Customer experience : The initial response, feeling. This is quite complex and difficult as this pertains to customer emotions. Perhaps using a third party representative from the same domain will give some idea.

Customer communication : Simulation activity as if customer reacts after release of product into user environment. Here in addition to present requirements, customer will think of using the software vendor for future requirements also if the vendor product behaves as expected or more.

These said, it is easier to simulate above perspectives for existing customer, however for new customers it maya be a challenge. Still it is better to try it out simulating than being at the receiving ends.

Do you agree?



Contexts are important, not polarization

Same thing can be both a bottleneck and a flow.  How can some thing remain a hurdle and an enabler.

In the Pole vault example the player pegs the pole after the run-up and swings to the top trying to reach the bar with aim of crossing the bar. The Goal here is crossing the bar without displacing it from the poles.

Initially during run up and reaching the bar, pole served as a tool and a process of swinging.  Pole was an enabler. After reaching the bar, the pole vaulter will need to let go off the pole to cross the wooden bar. Here the pole is a bottleneck.  Player gets rid off the pole and cross the bar and reaches the Goal. Within a span of few seconds same object worked as tool, process and a bottleneck.

This is so true in any game like for example a soccer,  where the center forwards want to hold the football and keeps passing between their teammates. Finally one player gets rid off the ball but with a focus and direction. The Goal is literally achieved.

In Software development parlance we can map these processes to usage of checklists, referring of process assets, best practices by developers. This phase all these are artifacts. However for an adept developer he works on his own experience and indeed goes beyond the checklists and best practices to delight the customer with product quality. Here, adept developer gets better off than the lists and goes beyond for delivering innovative products.

Will not be nice if we work on contexts on usage of processes rather than getting polarized with “either use or throw”.

Happy sporting!

Restrain complexity, adapt simplicity

I blogged few years ago on Simple Vs Simpler here

Inherent simplicity is the one of the basic premise advocated in Theory of Constraints by Goldratt. here the simplicity is making the focus clear and unambiguous. Using metrics like Throughput, operating expenses and inventory. Though these metrics are seemingly simple  in definition, minds of leaders / well qualified managers always tend to ignore and look for complex metrics and measures. I heard there are some companies who use more than 20+ metrics for a 5 member team having projects duration of few months. This is clearly metrics gold plating and just satisfies the efficiency mind-set and not at ll effective. How good it will be to cut the metrics and measure time to do additional design thinking, making great libraries for code, automating effort for testing, improving upon customer experience.

While the number of metrics may be looking more, its simpler to collect and not use them, This is what making things simpler by complex mindset.

That’s why attune to the Einstein’s wisdom of “Make things simple not simpler”.

Of values and non values in processes

Value added processes :

Engineering activities from product conceptualization, architecture, creating product backlogs and sprint backlogs. Environment setups,  developing code, review and testing, customer demo and release.

Non Value Added processes which are required :

Some processes like keeping records and creating dashboards for the above activities will be used by software vendor for tracking their work progress. Does not add value to customer.  Gold plating of requirements, coding, testing and documentation where it was not required by customer, still organization insists to follow as part of “best practices”

Non value added processes which are waste :

There are seven to eight wastes described in the Lean development. Some examples may be waiting time for approval of artifacts, piling up of requirements in the form of backlogs which are not required in current sprint, rework on the development already made, sign-off time delays in artifacts, delaying due to late in the cycle testing etc.

Will continue to post on this sooner.


Disharmonic convergence for great solutions

Disharmonic convergence – can bring breakthrough results. It has to be properly planned and directed. Limiting the work / reducing the velocity of an Agile sprint is on one hand looks like missing a beat on velocity patterns of the few sprints maintained. However a good retrospect that has participation from all stakeholders might actually want to ensure the stories planned and being delivered are defects free. In addition fixing od previous defects if any. Here the convergence is getting all stakeholders in one page on defect free product that prove stable. Users will be happy. To get this convergence we may need to disharmonize the velocity a little bit.

So context and goal is more important than consistent productivity.

Just my thoughts.


Waste Elimination and Risk Management

Waste Elimination and Risk Management.

Waste elimination is removing unnecessary wastes in effort, time, resources, etc. Risk Management is ensuring there is back up and business continuity just in case if some risk scenarios occur. In case of services industries resource planning and risk planning involve some additional buffers in terms of resources and buffer. How do we balance then the waste elimination and risk management through back ups.

Guess there is no any single silver bullet fixing this issue. For the established organization with resources more than 5000 it is easy to loan out some resources who are not completely loaded into projects that require critical resource support. This way without increasing the organization’s counts of employees resources can be managed.

However for the start-up scene, this is a significant challenge. It will be better of to chart out the make or buy decisions for the organization in deciding what to build and what to outsource. Automation of possible activities will also help a good deal, though in the initial stages it might appear expensive.  In the long run s the business scales up, Risk and Waste elimination can be combined effectively in beating the cost through attainment of more business acquisitions.

Respect people and learn from everywhere

Respect for people is one of the key principle of Lean and Theory of constraints. It creates an environment for people to understand their team’s views on all aspects of development and release of product. If open-minded conversations are allowed freely, the flow is very effective for product / solution flow. Some times learning comes from outside the company’s scope or even industry segment’s scope. The team should be encouraged to attend technical forums and meetup on the same domain as well as cross functional domains.

The moment complacency sets in terms of ‘knowing all’, the learning will stop and slowly the competition will take edge over the complacent organization. A further step in this direction of learning can be setting up some free hours say every quarter of the business year say some 10 hours of best practices learning from outside company will go a long way in refreshing and innovating new solutions