• 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?

 

Advertisements

Attune to Systems thinking and avoid local management

Time management – is not the end solutions. Time management has become more of task management and completing the tasks within the time frame. Efficiency ! Local optimization.

Time management is more of individualistic and compartmental. Goal is more apt for successful product development and sustainable organizations. While pursuing goal we need to share our cooperation by sharing our saved time / effort to people who may be struggling. So it’s the collective time and effort of the systems that is important than managing individual time / tasks.

It starts from the top and percolates down to the floor.

Attune to Systems thinking and avoid local management.

Some key aspects in scrum

Necessary

Product Acceptance criteria – understanding the stories requirement clearly and preparing the stories completion as per the criteria. Mostly Product owners decide these. Development needs to understand them.

Sufficient

Definition of done (DoD) is a set of checklists and ‘musts’ before the release of sprint / product. It covers the acceptance criteria too.  DoD is generally a guideline and remains the same during the sprint.

Necessary but not sufficient

Set of product acceptance criteria for all stories without considering the whole sprint release falls under this category. Larger picture is more important and valuable than the sum of individual stories

 

 

Meetings should enable help to address bottlenecks

Meetings should be done if required with relevant people only. Preparedness is mandatory and sticking to agreed agenda is time saver as well as motivator. Minutes is just action plan which creates a platform for everyone involved to help each other to complete the common goal.

Having standard agenda irrespective of the meeting’s objective with templates to comply will make the inventive mind demotivating. Mostly in project management scenarios meetings serve as record for minutes. It is not bad, but not sufficient. Can the moderator of the meeting ensure wherever the bottleneck is and ensure all other functions / subordinates to help ease the bottleneck . Can the flow of the work be made smooth through the bottleneck. Then meeting works.  Less the time, better. Frequency of meeting can be adjusted depending upon the flow of the product / solution.

My thoughts on meetings!

 

Defeat the defeatist attitude

iDumbaikku iDumbai paDuppar iDumbaikku
iDumbai paDAa davar

(To) sufferings, create sufferings, by sufferings
these(people), don’t suffer

Whenever there is a misery, (leaders) don’t suffer by this, rather they choose to create hardship for the misery.

Great saint poet revealed this powerful gem of a wisdom 2000 years ago in his work Tirukkural.

It is relevant in today’s constantly changing world. Changes and complications are constantly happening in the business world today in a rapid manner. It is here the great leaders takes them and convert it into opportunities. While principles like embracing change is the beginning to handle and manage the changes for business survival, the leaders create change by thinking ahead of the curve and innovating. Honestly when no product or solution can expect to live beyond 10 years it is all the more important to identify and innovate ahead of the curve. convert risks into opportunities and give risk to risks.

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!

Out of the box thinking process

Getting knowledge outside of the box.

Already there are plenty of resources available on Out of the Box thinking, reaching out to parallel industries on getting ideas and solutions.

Some questions on this to ponder :

How much of these practices are really practiced?

What were the success rates?

What are the inhibitions on the organizations to reach outside of the company?

The way we do things always here, restrains these type of approaches. Can we take a shift in mindset?

Do we need external people as coaches for looking out to get more knowledge or can we train our own coaches?

Will there be any impact on the existing business in terms of schedule, cost or quality in the long-term or short-term to try outside the box?

I am sure there are many other points that can be added to this list. Once these questions are answered, it will become reasonably easier to reach out for better solutions.

 

Journey and destination are equally important for happier stakeholders

Means and ends. Both are important.

Delivering a product, by heavy processes and hierarchical structure is possible. At what cost? Possibly 2X or more than delivering through iterative agile processes.  End is product release, means are as important. Using automated tools, testing early and often, customer involvement during development all are not only effective means but also enjoyable. Here the journey becomes lively and also ensures smooth landing at destination.

Employees are happy as much as customers are. Attrition will be reduced. Referrals of new open positions will be easier to get from motivated and happy employees. This makes HR function work easier and enjoyable. So it is all the more beneficial to have excellent journey in product development. It helped all stakeholders who are not technical also.

Journey and destination are mutually complementing.

Environment for engaging work force is vital

Engaged workforce is created by grounding people’s principles. If the new (fresh graduates) employees get a feeling that the company they have joined is an extension of their college, they become engaged.

For the lateral hires, the welcome and the reception they get really have great impact. They look forward to settle down with help of existing teams, HR function, training function. Good induction and initial policies appraisal, et al make them feel they are getting equipped. Gradually after initial settlement, they will launch straight into their roles as per the expectations of the new company. More importantly there should be a culture of trying the innovation at work. Encouraging everyone’s though process and sharing.

Some of the exceptionally talented people who join these kind of pro-people company remain for very long time with the organization. Benefits will be mutual.

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.

 

CHATS (Changes Any Time Simplified)

Some thoughts on Gemba walks in IT industry.

Even though embracing and welcoming changes any time is a great concept in Agile, how many products / services have actually accommodated this?

Let us call this welcoming change any time as Changes Any Time (CHAT). There is a better effective way by ensuring the changes are not too much during development. This is more important especially at least for two sprints or so you should not change requirements. So that some stability is developed.  If the development team gets in touch with product team at customer side during requirement formation itself, it will be great. Joint Application Development (JAD) have been successfully used towards  this direction by IT companies. Here we take a step back  and involve even during product conceptualization with development / domain expertise from development teams to reduce or eliminate unwanted features getting in to the product backlog. Involving in scope development to arrive problem definition (Scope Driven Problem development) will simplify CHAT.  Then it becomes CHATS (Changes Any Time Simplified)

One among many companies

Systems thinking creates an aura across all levels in the organization. If successfully implemented all employees and stakeholders will resonate this spirit unconsciously. I have seen this in my personal experience also where people talk about their current and ex-companies and how they felt every aspect as being wonderful about their companies. ( yes you read it right, their companies and not the “companies they worked”).  There’s no correlation between the pay they earned and work they cherished. In a span of say 25-30 years of work experience, people feel that “oh that was the company that made me feel special”  They will remember the product, specifications, procedures and policies and many moments. These companies may not be necessarily in the late chronology of their career, it can be early too. But the memories got carried because of the emotions it brought on them.

Personally I had experience in a company where the senior most in HR said during offer “you can attend interviews on Saturdays too, we are five-day work-week-company”. It was a manufacturing one at that. Similar ethos were shared by senior technical people they said all things are informal, and no hierarchy here. Only performance counted. Be it canteen equal for everyone, one can pick up a smoke from one’s VP’s table and all travel same class and stay in same accomodation levels etc.

That is one among many companies.

 

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.

Create flow rather than de-bottlenecking

Flow is about ensuring value flow is optimized through bottlenecks, not necessarily debottlenecking. Because debottlenecking might create bottleneck somewhere else in the system. Therefore, Goal might me out of focus if the intent is debottlenecking.

Balancing the demands from the market with the value stream and throughput of any system is critical to get breakthrough improvements. This will prove success in the short and long run. We can’t really rule out any bottleneck in the flow, in case even if that happens, the system elements of the non-bottlenecks should de-prioritize their own tasks and subordinate their priority to bottleneck by helping hands to make the flow smoother along the bottleneck.

This is not easy to bring about in a larger established system. It takes some mindset change, commitment from the leadership and patience from people concerned.

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

High effectiveness and optimal efficiency = Remarkable solutions

Effectiveness is achieving the intended objective of the organization which will make all stakeholders happy.  Even if there is a slight delay in project deliverables, it will only affect immediate milestone in the short-term. Once the blocks and hurdles are carefully analyzed and removed, there will be all round performance of the product / solution in the long run.

Efficiency is ensuring productivity is very high and resources are utilized maximum to ensure more work is carried out within short time. In the world of complexities involving customer expectations, most probably the efficient systems will produce short-term outputs. In the long terms there will be defects emanating from earlier releases which will involve long rework and make the product / solution very costly by 3X or 4 X time than originally thought of.

Of Course there are remarkable products that are developed as a blend of high effectiveness and optimal efficiency. They are superstars, indeed

 

Velocity should also be aware of direction

Physics velocity is a vector quantity and is direction aware. Sometimes this “direction”, the objective of building the right product (or features) that will be really used / required by the customer / end user is not thought of.  This leads to building maximum features to achieve maximum velocity at the cost of building right product with very minimal or no defects.

If only velocity was fully embraced from physics :). Just my thoughts friends. Do you agree?

Velocity that is direction aware

Thinking tools and systems for win-win

Throughput significance in System thinking.

Long terms growth of any business is key as it determines the sustainability of the business.  Innovating by advanced thinking tool techniques like cloud diagram, current and future reality tree an organization can maximize effectiveness of its life cycle of delivery. By brainstorming the bottleneck that creates impediments to flow,  Thinking Tools facilitates identification and elevating the bottlenecks. Some practical tips that can aid speedier results will be :

  1. Create an environment of understanding Systems Thinking
  2. Promote and nurture psychological safety
  3. Empower teams and motivate them for innovation
  4. Avoid multitasking
  5. Provide focus and clarity
  6. Respect people
  7. Be the change ( of Leadership) that is expected from the team by leading as an example
  8. Make Win-Win as the objective

 

Build right product, right.

Building the product right follows building right product.

Since building right comes first, it would be better to start the product building at source. Yes right from customer perceiving the product theme,  software development organizations need to involve themselves. Quite possible that software organization vendors have been working with customer for long and understood their domain well. Also possible that there are some shifts in the customer organization at the senior levels / product domains. In this case software vendor would do well to suggest right features and good insights about the upcoming new products to them. The features, possible uses, user prospects et al can be some useful ideas that can come straight from vendors. This is cocreating right from problem space of product development.

Next phase of building it right will effectively follow by Agile development practices. This way Agile is extended beyond just the development areas toward wholesome product making.

System thinking is real product development.

 

Throughput is the prime metric

Throughput of the system is the real metric recommended by Theory of Constraints (ToC).  Velocities, defects, releases, effort, schedule and cost are some useful measures that are important for internal stakeholders. However focusing on them is confining and might lead to local efficiencies.

Instead focus on throughput of the system – that is producing a product or service. Throughput is directly related to the dollar value earned by converting the investments (inventory) through operating expenses into useful Goal units. These Goal units are as felt by customers and therefore all stakeholders.

Attune to TOC metric Throughput for current and future revenue realization

Embrace Agility and empower people

Agility is enabling and empowering. Hierarchy is command and control.

Empowered teams enjoy their challenges at work. Commanded teams get demotivated and somehow try to show their work as efficient and resulting in local efficiencies. Local efficiencies mean less alignment to the links and interfaces and compromise the overall effectiveness of the organization Goals

Agility is inspect and adapt. Structure is following the pre defined plan.

Agile methods provide Quicker response to market conditions, demands and fluctuations and ensure all stakeholders in the supply chain are happy.  Product becomes useful immediately after the release in short delivery cycles. Customer participation in product development results in right product is developed in the right ways. Quicker time to market enhances returns on investment for all stakeholders.  Following predefined plan leaves the product development with too much processes that inhibits growth particularly in changing requirement scenarios.  These days there are hardly any innovative products that do not undergo changes frequently.

Embrace agility and empower the people

Theory of Constraints – selective perceptions by organizations

Where to start applying Theory of constraints in Software organizations.

At Sales  planning with Senior Management level – Hmm, sounds good, ” we are too busy with current realities, will consider in future”

At Finance level, hmm ” Good concepts, however we can’t just have simple metrics, should tailor the TOC towards increased number of metrics, will think it over in next year”

At Operations (Development and projects team), ” Awesome principles, should try out in a small pilot project , we are running short of cost budget and schedule already”.

Quality Assurance and Process implementation team ” Amazing management model, let us add some resources after getting approval from management, to start the TOC journey”

Somewhere one or two persons who have read books like Goal and CCPM already started in their project and say ” We are happy at least we have discovered how to ensure flow and optimize the operations”,  “We have already seen some cost reductions in operations and making deliveries in advance satisfying all stakeholders” .  This is the group the senior management need to listen with open mind towards innovating in break through scale. Do you agree?

 

Value delivered by DoD stories

Theory of Constraints (TOC) perspective on Work units (Approximately stories in Agile) is beyond Definition of Done(DoD). DoD in most of the cases are good working stories / sprints iterations to complete software development and testing phases. Sound good. TOC takes slightly a step back and evaluates the value delivered by the delivered features and its conversion into revenues.

If the Product manager and Software Team ensure all working stories are delivered right, it will be good to see what happens even downstream of deliveries?  Do the product / features delivered completely used? Whats the percentage of features mostly used. If its less than 50%, then why don’t the product manager and Software Development team understand what is the market expectations? This can be done by cross functional reviews between Sales, Marketing Senior Management, Customer.  Development team should work closely with customer even during problem definition stage and not take the requirements and convert them into features. Well this requires mutual trust and confidence on capabilities, skills and expertise on both sides.

Thinking principles of Theory of constraints can be of great help if practised by experienced professionals to ensure maximum value delivered by the features.

Limit the work in progress for steady flow

“No matter what. Get the Velocity committed”, seems to be the tone of the Product Managers in some organizations as regards to Scrum teams KRA / Metrics. Though velocity in itself is good enough metric of the product development in scrum based models, will that alone suffice? May be or may not be.

Given the nature of the complex product requirements from the customers and customers’ customers in new product development, it is essential to complete the prioritized good stories to completion. It is okay (as per the spirit of Agile) to cut few stories to ensure rest of the stories are 100% meeting DoD requirements.  This is where the Lean development principle of limiting the work in progress items comes.

Once the nature of the first two sprints are clear and complete, velocity can be always improved from next sprints onwards. Taking too much pressure on the velocity from first sprint onwards which might lead to defective releases, will not only impact the vendor and customer work flows but also the end customers. The motivation of the product development teams will also come down.

Focus on completing prioritized stories in the first few sprints by limiting the work in progress. Then scale up velocity in following sprints. What is your experience?

Goal through inspect and adapt

Goal is the focus.

Inspect and adapt is for product development and delivery.

Goal is to make remarkable products / provide elegant solutions.

Inspect and adapt is to get moving with first set of releasing usable products.

Goal is the way we do things to satisfy the entire population in supply chain.

Inspect and adapt is responding positive to the market demands.

Goal is systems thinking, where whole is greater than the sum of its components.

Inspect and adapt is to reach the whole goal, embrace change.

Goal is making all stakeholders empowered and happy.

Inspect and adapt is giving confidence to everyone that WE are a team

Goal is to be making revenue now and then in future.

Inspect and adapt is to build just enough products in focus

Droplets, waves and Sea are Water indeed in union to produce the magnificent Ocean.

Appreciate divergence for a super convergence.

Right process approach is a win-win

Some of the Key reasons process implementation fails :

  1. Nil or scanty support from senior management: Senior management is busy investing time effort and money on sales, production and delivery. Production covers complete engineering aspects while delivery taking care of testing, releases and support aspects. Sales is pre sales + Engagement and customer satisfaction. Where does process fit in this premise?  ISO certification, CMMI adoption or any other domain specific certification aspects like PCI DSS or SOX or HIPAA or any other?  Even if it’s the case of certification, it is looked at by senior management as one time exercise where it can provide budget for cost and effort. Subsequent periodical assessment becomes less expensive and kind of integrated, is what the senior management thinks, for the right reason indeed.
  2. Business Process Excellent / Quality Assurance focuses too much on checklists and audit exercises pertaining to the standards and models rather than demonstrating the real ROI of adapting any model.
  3. Process is not aligned with Customer’s requirements and making it too much          towards complying with strict procedures and workflows.
  4. Good case studies / process assets are not captured articulating the values of process initiatives
  5. Lack of motivation for adapting process models. No rewards for good process        performance
  6. Once certified the system doesn’t look beyond for upgrades or scaling up.

These are some of my thoughts. What is your view / experience?

Systems thinking avoids wastes

Systems thinking avoids wates in any environment. Here we look ways that helps avoiding wastes in software.

Over estimated time and efforts : Teams thought process is calculate each and every team member’s individual tasks and add up the total. This is a gross mistake and contributes to lots of waste as unproductive time in project progression. How? Welcome to Critical Chain project management of Theory of Constraints. Calculate the total effort required for the project completion and add project buffer as a central buffer available to total project. This way not only the project progress is focussed, it also creates an atmosphere of system thinking among the team members and every one starts to focus on project rather than individual productivity. Scaled Agile Frame work (SAFe) have addressed this to a certain extent.

Kaizen-Kanban Keys of continual improvement

Yesterday’s post shared thoughts about how multi tasking could lead to decreased productivity in project management activities. We have also briefly touched upon how group reviews can help overcome burden of a project manager who handles multiple projects. Kanban diagrams and kaizen principles can be coupled to address the multi project multitasking challenges. While Kanban is a great tool in visualization of project milestones with clear visibility to all stake holders, kaizen is an improvement tool that provides continual improvement functions to key activities. Visibility to all stakeholders coupled with continuous improvement means projects and people perform progressively as they move along the milestones. In Agile projects the impact of the Kanban-Kaizen will be reflected in the improved velocities between successive sprints and releases. These tools in addition providing direct impact on productivity of projects that applies these, they collect the process assets and knowledge along the way. These lessons learnt will be key assets for the organization for learning and development for future projects

Group reviews avoids bad multitasking

Multitasking : Much used term in management especially in services sectors like IT. Theory constraints sees multitasking as an activity which mostly reduces the productivity. If a project manager has to run three projects simultaneously with three different customer domain (which is the case generally in SMEs) say retail, health care, BFSI etc he/she  will be mostly doing management of people deployment and the progress of deliverables. All the three customers will be equally demanding the deliverables w.r.t to agreed milestones, as per schedule with acceptance criteria for the quality (that’s the very reason the projects are given to the It vendors)

If the project manager is focusing on all the three projects, with tight deadlines from all of the, switching between tasks and projects will be tasking and will create much pressure on the project manager. This will lead to none of the projects are delivered on time or even if that be the case there will be compromise on quality or extra resources deployment. Any of these symptoms is an extra cost due to non value addition caused by bad multitasking. We are not talking here about a multi skill and trait a manager need to posses in terms of leadership, technical competency, managerial acumen or communication abilities. These are all multi skills which will be naturally used by an effective project manager during project management (as against multitasking).  Having special horizaontal groups like Subject matter expertise, advanced technology group, Software  Process Engineering group, Business Analysts, UX group and using their exprtise to do reviews at appropriate levels and phases will ease out the pressure from project teams. This is one way an organization will improve overall productivity which help teams avoid bad multitasking.

Just my thoughts. Please share your views on this.

System thinking helps superior products development

I have discussed about CTQ and CTC in this post about Agile development addresses Critical to Quality and Critical to Customer dimensions.

As Quality and Customer requirements have become more clear due to the collaborative nature of Agile and Lean Development, products are developed faster and better. No issues upto this. Another parameter along with ‘better and cheaper’ that needs to be inbuilt is cheaper (competitive context), this where the flow and systems thinking that need to be embraced within the organization and its customers and suppliers.

Theory of constraints (TOC)  offers Drum buffer rope, Critical Chain project management and Thinking tools to address this third critical parameter (cheaper = competitive) of any product. Processes can be automated to the possible and required limits. However Thinking process differs from project to project depending upon the many stakeholders involved. It takes domain, experience and System thinking skill sets to achieve the smooth flow . lean and TOC have their focus mainly on Systems thinking and on careful, patient and full application of these management models, super productive systems can be achieved.
Continue reading

Budgeting for success

Budgeting – for sales, production, inventory, finance, quality, testing, new initiatives, Research and many more functions / departments is done as per the context and the focus of any organization. Organization take into consideration factors like  revenue streams, cost of compliance, support and future business etc.

Best results will be accrued by reducing operating expenses  and minimizing inventories. inventory. Theory of constraints key focus is around these premises. While it is understandable in principle on reducing operating expenses  and minimizing inventories, in practice it is not very easy to achieve this goal. How can we make a positive difference in realizing these improvements? One way could be after identifying budgets for each and every function, the leadership should look at the interfaces and interplay between multi departments and then work out suitable budget booth in terms of cost and effort. To understand the interplay and interfacing activities, it is better to set up a small team by choosing good champions from each department and create one interrelationship maps between all the teams and leadership together. Then every six month this interface map should be reviewed and revised as per the current realities.

Now it will be easier for management to understand the effort and cost allocation and budget to the each team. After the allocation, the champions teams  can take their respective teams into confidence and impress upon them about details. This way organization will have more probability for smooth sailing as flow.

Team work between domains

Teamwork – When did we perform best and felt elated about reaching our targets / goals at work? Just think on these lines whenever there are challenges due to competition, complexities, changes, technical advancement or any change agent that is coming your way.  Perhaps the solution will come to us by deeply analyzing about our best performances in the  past , someone else’s best performance about how did they beat all odds to become successful in what they did.

Sometimes, you get ides and insights from external sources like domains completely unrelated to you. Keep watching Ted Videos, and other platforms both in digital and non digital spaces. I am sure it will throw a lot of new ideas that will be refreshing. Agile, SAFe, LeSS, PMI have all been inspired some way or the other from Lean Manufacturing, Toyota Production System, Systems Thinking, Supply chain domains. Now Agility have improved upon these models and mapped to IT environments by created great concepts like Scaled Agile Framework (SAfe) and impacted breakthrough improvements in the way software products / services are delivered. Not only this, Agile concepts have started giving back to manufacturing on the improvements and new thought processes where manufacturing gets benefited. This way the system of systems keeps evolving. Let us be attuned to Systems thinking.

Convergence is the key strength

Convergence of all sub system produces one super system called organisation.

Light getting dispersed through Prism produces brilliant colours like Rainbow. The White light sums of all the seven colors and shines forth brilliantly.

Sales, pre sales, account management, development, business analysts, testing teams, UX, HR, Facilities, Administration, Finance and Leadership all put together form a brilliant organization. We can’t say Red color is better than blue , green is better than yellow et al. All departments are components of a great chain, and the interfaces between them are links that binds the values of the organization.

If one or few of the interfaces / links get too much stressed out or lagging, rest of the teams and interfaces can get into huddle with the struggling interfaces and can offer their support to improve the working. This is self-organization in Agile, subordinating all activities to critical constraints in Theory of Constraints, Systems thinking in lean. Different  models, similar values.

Gemba Walks Evaporates cloud

Gemba walks by Leadership teams occasionally to the desks where action is happening will be a great boosting moral for the teams. However it needs to be performed without giving a feel like micro managing of teams. Some ways and thoughts on Gemba walks by senior management.

Visit to the real place and seeing teams putting their work , genuinely understanding if the teams need more support in terms of tools, training and helping hands in resolving any technical issues goes a long way in having empowered employees. Teams will not only be happy they will also go to the extra miles bracing any limitations on their way.

Gemba walks originally designed for operations place like shop floor reviews, we can use the spirit for motivating people to become empowered.  This way Gemba walks rings true with Evaporating cloud phenomena of Theory Of Constraints. (TOC)

Quality Assurance (process) key focus

Quality Assurance (Process QA) function in IT organizations are normally viewed as compliance and certification function.  What are the ways by which Process QA can get more attention?

QA should capture the best metrics that define the business and its growth dimensions. Typically Throughput of the product / services delivered by organizations are super effective indicator of the business and its progress.

QA should design the processes considering key critical success factor for maximizing the throughput of the organization. It will be better to have the Top down approach in identifying the business objectives and then deriving at the project level objectives. Measure team’s outcome and not individual’s output.

How are the Win4all factors integrated in formulating the throughput metric?

Does each and every department’s / program’s processes are focused towards attaining this Win4all?

Since QA has more visibility with most of the departments of the organization, they should proactively work with all teams and enable the entire system works towards achieving / exceeding organizational goal.

Avoid Creating an impression that QA is compliance function . Go to teams during normal working days. Don’t focus only during audits.

Being empathetic and understanding about Business processes: Each and every team might be different, make metrics and processes relevant to the team based on their contexts

Only measure Team metrics relevant to business

Share industry knowledge and latest trends through links, materials, webinars etc  to team.

Update your  technical skills of the core functions to a level where you get some useful inputs as to how best the team’s process can be tailored.

Appreciate good work always and don’t just restrict to raising non conformances.

Process should be enjoyable as the end product.

Co create innovation.

 

What’s in it for me? – harmonize all stakeholders expectations

What’s in it for me?

If me = Employer,  it will be employee productivity, employee billing capacity, employee developing himself / herself and the teams, employee loyalty, et al.

If me = Customer, it will be Faster, Better and Cheaper not in any particular order, it will be trust, trust about feeling confident that the customer data, design, requirements, proprietary assets are safe with vendor, it will be vendors help customer’s business grow

If me = Supplier, it will be good business, show casing of vendor’s capabilities that delights customer, repeat business and of course invoices getting paid on time, referrals and testimonials

If me = Statutory and Regulatory bodies, it will be good compliance to regulations and applicable acts.

If me = Project manager, it will be mile stone completion by teams, less attrition, cooperation and team development

If me = team member, it will be good work that satiates their technical appetite , good growth for them in the corporate ladder, motivation, work life balance et al.

Then we have other categories like research and development team, testers, finance, sales and marketing where we can derive the “whats in it for each one them” if they are equated to “me”?

How the enterprise understands all the “in it for me” considering all the “me personalities”  will determine the business in the long and short-term. There is need for creating total organization’s “in it for me” by combining all of the individual “in it for me”

Some of the awesome concepts like System thinking, Theory of constraints, Lean and Total Quality management either independently or in combination can improve the harmony of the organizations.  Great leaders have been able to demonstrate in all walks of lives, this super enlivening harmony and created lasting positive impressions.

 

Key considerations for new initiatives

Some key considerations for deciding to go with any initiatives to get maximum success.

  • Boosting Employee morale
  • Increasing the ROI to all stakeholders
  • Helping to get Decisive competitive edge
  • Believing in inside out approach
  • Doing it when size is relatively small and then sustain while scaling
  • Self driven in line with market trends
  • Improving the Automation efforts
  • Helping in scaling
  • Leading to Systemic benefits not local efficiencies

What are your thoughts?

 

 

Risks and opportunities – interplay

Risks and opportunities

Risk – has been in focus of Management for many years since initial industry years.  We had Quality control, Quality Assurance, Total Quality Management, Project Management et al . Each of these and many other management suits discussed and implemented Risk Management with reasonable success.

As regards  to Opportunity – its identification , nurturing them, taking organizations / units towards break through improvements have been discussed through Lean, Toyota production system (this is an exception in that it has been for many years) , Agile frameworks and some other models relatively  recently. Much less done in terms of implementation.

Risks and opportunities have been complimentary, opposites and mutually exclusive. Sometimes controlling risks will lead to opportunities. For example retaining great talents by managing attrition, leads to great products and in turn result in company’s growth.  Here identifying the attrition as risk and managing it served as a great opportunity (complementing activities) for business growth.  Automation of business processes and deliveries to a large extent improves productivity and cut the costs of labour / manual effort.  Here the opportunity is mutually exclusive of any risk. Keeping the stakeholders like customers, employees and suppliers in a balance of serving their best requirements could be sometimes be seen as reduced satisfaction among some group of the stakeholders. For example, if outsourcing takes major chunk of an organization’s activities suddenly, this will impact the employees count or reduce their contribution suddenly owing to business requirements.

IMHO it is a challenge for any organization to continuously innovate by bringing new changes in terms of technology, automation, management models while keeping the current work force happy and feeling motivated. One way it can be done is to leverage the premise of Global outlook recommended by System thinking principle of Theory of constraints. Involve people at all levels, make the operations flow smoother by managing critical bottlenecks.

What are your views?

Improving productivity by proactivity

Some ways to improve productivity and reduce non value added activities / wastes :

Use Agile practice of stand up meeting discussing three key questions :

what tasks are planned today,

what were the tasks executed yesterday and

what is the main bottleneck

Encourage group reviews – this reduce waiting time and avoiding duplicate questions from different people who might have same views. Quick response to customers and stakeholders, Complete team will be in sync.

Involve Senior management – to the critical decision and commitment for the programs on needed basis.

Learn, develop, test, relearn and again learn

Leverage common teams Create pool of teams / tribes – for domain, technology, security, innovation and communication. Leverage them for all projects

Evolve, change and adapt to not only technology but innovative thinking too.

Gemba walks and Thinking tools

Gemba walks principle has been successfully used in many manufacturing Industries. It means ‘the real place’. Taiichi Ohno from Toyota believed and leveraged these concepts to a great extent in Toyota.

Toyota believed that the activity is happening in the shop floor, operations area and not in conference rooms. This led to Gemba walks in production and operational areas and the executives were able to get direct inputs on machines, working, men and all their issues.

Using Five WHY techniques asking the right WHY’s during the Gemba walks produced brilliant solutions. The deep root causes can be identified and systematically eliminated by observing what is happening in the real operational floor. In TOC too, thinking tools like Current reality tree, conflict clouds (Evaporating clouds) are very useful in depicting the real picture of current problem. Cause and effects are categorized and analyzed in detailed steps and finally Undesirable effects are identified. These Undesirable effects are prioritized and treated using thinking tools like future reality trees and prerequisite trees etc.

Though the models Lean and TOC are called in different names, the central focus in both of them are  ‘the real place’ . Gemba walks are used in observing, identifying and eliminating the real harmful effects to produce grand solutions.

Bottleneck – neither over load nor starve

Systems’s view of any organization is like a chain connected by links. TOC sees the weakest link as determinant in deciding the strength of the chain.  Taking one step back we need to identify the weak links / bottlenecks and make them fit in the perspective of the entire chain.

If there are ten processes for producing a product / service, there will be a bottleneck process which needs to be regulated  to ensure the smooth flow happens in the production line. Suppose if process no 5 is a bottleneck, it will process the product line at lower rate compared processes 1-3, and that will leave the downstream processes 6-10 waiting with delays. These waiting times are waste (non value added process) and increase the cost of the product directly due to long cycle times. Inventory is also getting built up at process 5 that will have cost impact depending upon the product nature.  The aim of the system should be to ensure bottleneck is relieved of its inventory and waiting time. It should neither starve nor over accumulating the work in progress due to slow capacity.

People are good – all roles matter

We keep seeing leader vs manager debate in many social media platform, inside the company and other places. While most of them give a big thumps up for ‘Leadership’ with all the great qualities and attributes it truly deserve. This post I want to look at the Leader, Manager debate as a wholesome perspective. Any organization irrespective of flat or structured will have leadership team that will be a small fraction say around two percent of the whole company.  Some of the leaders have made it to the top by being excellent managers of their respective assignments.  So can we not think a manager to be a future leader, getting evolved continuously. Algebra need to go before calculus.  As most of the organizations need manager roles and few leadership roles, we need to have traits of both leader and manager in different combination at various roles and levels.  Whether a leader or a manager it would be great to be non judgemental, open minded and seeing the whole picture from wherever every one are placed. This way everyone one in the organization remain motivated and feel self confident in their role.

In a software application all layers (presentation, interface, database, server et all) matter. All roles are equally important right from business analyst, developer, UX engineer, tester, release administrator, QA etc. Sales and other support functions play a vital role in meeting customer expectations. Same way in an automobile hundreds of parts required for awesome performance, right from nuts and bolts to engine, gear box, wheels, electrical components etc.

IMHO best things will happen by having an open mind and being non judgemental. Happy Global optimization!

Lean practices for endorsement to great initiatives

Project managers and delivery teams always get concerned over what should be the minimum criteria for any project  to apply and comply with standards like ISO 9001(Quality Management), ISO 27001 (Information Security Management) or CMMI or any other standard per se?

While it is easier to be enforcing on any project regardless of their size and nature to follow standards completely, the stakeholders need to be  clear and convincing on enforcing these. QA folks, auditors, senior management / relevant stakeholders , if start insisting all teams be comply with x number of policies, y number of procedures and z number of templates without demonstrating the outcome / returns, any initiative be it ISO / CMMI / TOC / Lean will fail in the long run for sure. In service organizations there are cases like many simple maintenance or bug fixing projects that are executed. QA teams coming up with long checklists of “Do’s and Dont’s” covering 100+ specific and generic practices of CMMI and multiple controls from ISO 27001, will demotivate the teams and resources permanently. All initiatives need to start much before certifications. This can be achieved by designing the processes as “Just enough”, Lean and Agile. Over a period of time teams embed these practices using tools and would have become “the way we do things here”. Then certifications / initiatives will be easier, sustainable and successful. You get certified / assessed to certain standards / practices by endorsement and not by ‘conformance’.

What do you say?

You before I, TOC vibes

In my earlier post UB4I, I briefly touched upon how Agile development is pro-people and has ingrained team spirit in its working methods.

As I have also gained over few years experience in Theory of Constraints (TOC), I see there is a greater synergy of this UB4I (You before I) spirit.

In its Four pillars of ‘Inherent Simplicity’, ‘Every conflict can be resolved’, ‘People are good’, ‘Never Say I know’  TOC is replete with the great team / organizational phenomenon of working as a whole and for the whole.

Estimation is one area that is posing great challenges for large teams particularly in software  development. Many factors can be sources for incorrect and inaccurate efficiencies.  Complex requirements, too many scope creeps, market conditions influence  accuracy of estimates.  TOC helps here by focusing on only three basic metrics like Turn around time, Operating expense and Inventory costs.  Operating expense is defined as the money system spends to convert inventory into Through put.  Here the focus is only on the system throughput and not on individuals / project level.  Team will be highly motivated and will have solid clarity of the role and expectations from them to align to the system’s Goal. IMHO, I see this as inherent simplicity.

Agile and Lean software development focus on collaborative development and working. Greater visibility for all stakeholders, involving vendors right from requirement stage / product design stage, create a super positive environment for great product development and innovative solutions. Daily sharing of the progress of the release and sprints with customer and solving any issues / conflicts by shared understanding lead to quality products to customer and confidence to vendors. I see this as ‘Every conflict can be resolved’ principle of TOC.

Self organized teams, feeling of ownership and common goals in terms of stories to be burnt by team and its members, truly vibe with ‘People are Good’ pillar of TOC.

Systems thinking is one of key component of Scaled Agile Framework (SAFe). Typically many groups (some times called tribes) like Technical Architect, Domain experts, Compliance team and other types of subject matter experts work in harmony to produce innovative products and solutions. Here the matching principle of TOC is   ‘Never Say I know’, implying many teams and teams of teams work in cadence.

 

 

 

 

 

SIPOC for organizational policies

In identifying context of the organization , ISO 27001 / ISO 9001 standards recommend to look for external parties / internal stakeholders under common term called interested parties.

Let us try to understand these using SIPOC methods. Understanding the needs and expectations of interested parties – SIPOC way

Supplier Inputs Process Outputs Customer
Customers Functional, Non functional, Information Security, Legal and statutory requirements Request for proposal, Contractual requirements, Scope of work Agreed contractual requirements, features and needs statement, Statement of work Software Vendors
Senior Management Organizational mission, vision and policies Organizational policies, procedures, code of work, Key Responsible Areas. Codified procedures, statements and Roles and Responsibilities Employees
Delivery and support functions Expectations and roles statements Communication during project / functional induction and work activities

 

Task Assignments, Team management expectations, targets, etc Team members / employees

Learning and Development, a system’s endeavor

Learning and Development – feels better than training and development, with due regards to ‘Training and development’.

Any initiatives when started will go through pilot to programs. Samples / case studies of concepts will add more confidence and assets (knowledge based). So any principle / concept / paradigm gains more insights as much as it provides the knowledge to the user community when implemented. Similarly people who take training to participants pick up more insights on their own subjects. Every participant is the source of sharing knowledge when he/she asks questions / add views to the teachings of the trainer.

This is akin to “Never say I know” pillar of Theory of Constraints. Learner, learning and learned all contribute to System’s improvement.

Innovative problem solving methods

Problem : A two digit number. 10th place has value 3 times that of unit place. When the number is reversed it is 54 lesser than the original number.

Effective solution : —> 10 (3x) + 1( x) – 54 = 10(x) + 3x

Step 2 –> 31x – 13 x = 54

18x = 54 , x = 3.

Step 3 —> no is 93, reverse is 39 which is 54 less than 93.

Quick solution:

possible two digit numbers satisfying the condition could be :

31

62

93

on quick elimination we can see 93 starightway fits the solution.

However we cannot possibly work quick solution, if the question to be found are a multi digit say 5 digit or more in these perumutation / combination. Hence we need to write generic program / alogorithm that can be used for each problem as per the complexity involved.

That my friends, as regards problems of numbers or math involved. In reality when organizations are facing abstract problems about major decision like make or by, outsource or develop, offshore Vs onshore development, there very many different factors that come into play. It will take a combination of management models to work and solve. Some of the great models are Theory of Constraints specifically Thinking processes tools, Lean and Enterprise agility, TRIZ et all.

People are Good – a key pillar of Theory Of Constraints (TOC)

People are Good. One of the four pillars of Theory of Constraints.

How does project information flow from an Analyst to Sales to Program / Account Manager to Project Manager to Developer?

While in most cases Functional requirements, Non functional requirements (performance) do get transmitted along the organization levels till developer. Does the developer have Information Security related requirements for the applications he is supposed to develop in time? Does he have domain specific requirements? What about information related to legal and regulatory requirements that are required to be followed by development teams?

Availability of product information from all perspectives mentioned above will help the project team to meet the customer expectations to full extent. In some of the projects I have managed there were views expressed by developers / testers, that they would have carried out their tasks effectively had they known the complete requirements of product right from the beginning as regards to security, legal and any other non technical requirements.Surely team will do a great job in building righ product at right delivery schedule with right data available at right time.

Proactively eliciting technical and all other requirements by the project managers and sharing just relevant data about them to project teams will make the team feel confident. Confident teams will have high level of motivation and build excellemmnt products.

Trust the team, share relevant data. People are Good to go for the Goals.

Premise fit – TOC vs Lean

Complimenting premise of Lean and TOC:

Lean Theory of constraints
Muda – Non value added activity or waste

Example – Reworks, multiple check ins of source code

Constraint exploitation and subordination of non bottlenecks to the main bottleneck. Taking help from horizontal teams. Availing surplus efforts from team that can contribute
Mura – Inconistency Each individual teams having local goals / objectives for their projects / functions not relating to the oveall Goal of the organization
Muri – Excessive strains in the system Too many localized measurements that takes time and effort and ultimately not solving the system’s goal. TOC recommends only three metrics viz., Throughput, Operating Expenses and Inventory. These are directly related to Organization’s goal units. Any other metrics that do not map to Goals is waste that should be avoided.

Theory of Constraints – improvements by creating TOC culture

Improving the culture through TOC within organizations.

While the real big benefit is achieving the Goal of the organization concerned that implements TOC, there are many additional benefits that get accrued by some of the great concepts of of TOC.

In the Critical Chain Project Management, TOC advocates to use buffer at the project level by cutting down sizable individual task estimates. This will create a culture (if implemented in spirit and action) that will enjoy sharing their extra time/effort to the real bottleneck issues of the organization Goals. This culture is partly practised in Agile implementations by forming groups / teams who work at horizontal layers to all projects of the organization. These organizational groups contribute in multiple ways like tech reviews, automation, release practices, Quality Assurance activities for all the projects in scope. If core project teams itself start looking at providing project buffers rather than at individual levels, real breakthrough improvements will occur in projects that will slowly radiate towards organization as a culture. Leadership and senior management should appreciate and support TOC practices with patience to reach this level.

These are some of my views would like to hear from your experience on this.

 

Roles and Responsibilities (RnR). Complimentary or controlling?

Roles and Responsibilities (RnR). Complimentary or controlling?

During initial stages of any organization rather initial phase of any initiative RnR is really a great way to ensure people know what is expected out of them to get the ball moving.  once the game is moving to mid stage (like soccer), player (or people) are expected to offer hand to the other players (members) to move the ball (project) to the Goal post. So RnR should not be limiting after the initial phases.

Depending upon the team’s maturity RnR is mandated or allowed go beyond it. Developers can help testers if their tasks are over to help the testing team quickly cover all test cases. Similarly testers can sit during development phase with testers and help them to ensure the code is less buggy or zero buggy.

Same mindset goes with all teams, Sales and account management teams should understand the dev teams’ capabilities and should not over commit. Sales team should also communicate  complete requirements with dev teams like non functional, compliance and information security requirements.

Dev teams should involve sales / account management teams periodically in letting know of the progress of the product.

Communication and respecting people are cornerstone of successful product development.

Key factor – compliance or outlier

Data Points in trends like normal distribution determine the compliance vs outliers.  In Agile product development it is interesting to see and analyze the compliance vs outliers.

Estimation : Planning poker method – all scrum team members take their call based on their experience and judgement. So the Scrum master / PO decides the estimate value by consensus not by majority. Here outliers have more weight and will be important factor.

Sprint Planning : Prioritizing of stories is a collaborative effort between PO and DEV team/ Here the factor deciding the call is a common shared goal. Not outliers.

Skill / role matrix : Whether DEV and TEST teams will do their DEV and TEST tasks only or involve themselves in multiple areas if they have free time. Again in this case,  it is a new habit, may be. It’s a combination of compliance and outliers.

Product acceptance criteria and Definition of done – Clearly compliance

Review and retrospective – mix of compliance and outliers.

Trust builds in compliance

False positives in compliance

Clear articulation of compliance requirements and benefits need to be articulated  to development and non technical teams. This will result in dual benefit of compliance with less documentation. It can be ISO, CMMI or any regulation for that matter. Best still is to automate the compliance requirements by inbuilt pointers into Definition of done / checklists for the development and technical teams. If the project management tool can capture the compliance or otherwise aspect much better. Some thing like Audit trails can be run to find out compliance percentage.

If the teams understand compliance requirements clearly, they might even come out with innovative ways of building in compliance during complete SDLC stage. Trusting teams will go a long way in making compliance cost-effective