Lean Thinking

The image and metaphor we like to convey a key thinking mistake and opportunity is the sport of relay racing.

 

Consider the relay racers standing around waiting for the baton from their running colleague. The accountant in the finance department, looking aghast at this terrible underutilization ‘waste’ indicated in some report, would probably mandate a policy goal of “95% utilization of resources” to ensure all the racers are busy and ‘productive.’ Maybe—he suggests—the runners could run three races at the same time to increase “resource utilization,” or run up a mountain while waiting.

 

Funny…but this kind of thinking lies behind much of traditional management and processes in development and other domains.

 

Of course, in contrast, here is a central idea in lean thinking: Watch the baton, not the runners

Results

Results… are the outcome of a process. What we want are good results from a controlled process because they will be repeatable. Bad results from an uncontrolled process simply mean that we’re not doing our job. Good results from an uncontrolled process…only mean we’re lucky. Today, a bad result from a controlled process just says that we’re stupid: We expect different results from doing the same thing over again.

Four Men

It chanced upon a winter's night, Safe sheltered from the weather,
The board was spread for only one, yet four men dined together.
There sat the man I meant to be In glory spurred and booted.
And close beside him to the right The Man I am reputed.
The Man I thought myself to be his seat was occupying,
Hard by the man I really am who to hold his own was trying.
And all beneath one roof we met, yet none called his fellow brother,
No sign of recognition passed ... They knew not one another.

 

… Author Unknown

Product Transitions or problem transitions

As a PM responsible for enhancements or maintenance of a product, that has been recently acquired by your org. You need to think twice before making any commitments. During an acquisition, in most cases the potential revenue or profit that can be generated takes precedence over the technical or engineering aspects.

The engineering team gets to have a look at the product from under the hood, only when it gets transitioned, and they are proclaimed to be responsible for the same in the future.

 

It is the PM’s core responsibility to check on the following before making any commitments on maintenance or enhancements.

 

a) Ensure that all of the necessary source code and rights to use / modify the same is available

b) Ensure availability of engineering & User documents,

c) If any third party components are used, check that the required licenses are available and support contacts are established

d) Allow for the engineering team to look under the hood, and get a good grip on the same.

e) Allow for the QA team to check on the quality and confirm that behaves the way it was expected, or whatever is mentioned in the user guides and marketing brochures are actually true

e) There will be push from all stakeholders requesting for updated product with fixes or enhancements at the earliest.

f) Resist the temptation to make any commitments (wishful thinking never helps)

 

If you are pushed to commit, indicate all of the above as risks of high impact and shout as loudly as possible (in writing), it’s ok if nobody listens to you, as long as you have evidence that you did shout.

A Case for Reqmnts. Engg. Group

If Organizations have a Process Group, Program management Group, Systems engineering group… why not a Requirements engineering group.

 

If projects are subjected to Cost and schedule over runs, one of the top causes for the same can be attributed to Poor Scope definition. So is it not imperative that organizations give due importance towards Collecting requirements and Analyzing them. (Thus enabling successful projects)

 

This would require specific skills set which would include VOC collection, interviewing, facilitating brainstorming, negotiating, and knowledge on latest technical advancement. A bit of domain understanding would be an added advantage.

While the above set of skills are about collecting information, the next set of equal importance is about the ability to clearly communicate the same in written form.

This requires the understanding of different visual representation and appropriate use of such options which include, use case scenarios, flow or process diagrams, sequence diagrams, data dictionaries etc.

Topics for Articles

Planning to write two articles in the next few weeks,

 

The first one will be about “managing Integration Projects” This would be based on experiences related to a) Projects involving procurement of a Sub-component or service from an external vendor, b) Joint development with external organizations or vendors as part of a larger solution or c) multi-site development for a software product.

 

The Second one will be about the “importance of scope definition”. Attributing most of the Quality problems in software to poor scope definition. I will discuss on the reasons for poor clarity on scope, or the difficulties associated with capturing the scope, and what can a PM do to address such scenarios.

QA Perceptions or end user needs

During the software development process, we come across situations where the team would brainstorm on how the end use would use a particular feature, or the steps the end user would do to get a certain task accomplished.  In most of the cases these small details cannot be validated with the customers. In such instances, The Developers take help of the QA personal (as an end user representative). Often the QA team has a different perception as against the developers. Then usually the Implementation happens in accordance with the QA recommendations.  

 

I tend to wonder these days, if we are developing the product according to the QA Team members’ perceptions or what the end user requires

 

unit Testing / Code Reviews

Every individual developer who writes code has an obligation to ensure that the code satisfies the needs, that it was intended to serve. Other then the stated need, an implicit assumption is that it is robust enough. The Developer needs to review or test his piece, to ensure that.

 

So what should the developer check for?

 

Input validation

Any piece of code usually has some kind of an input, either through a UI, or as parameters for the function/ method or Data that is read from a file, db or some temp memory location.

is the value within the expected min/max limits, is it null, is it one of the expected values(in case of enum), is it numeric / alphanumeric / allowed special characters, is it the incoming data too big that it does not fit into the expected data type size limitations. Is it in valid format? (For example dates, regular expressions) 

 

Valid Comparisons

Any comparison between two variables, x==y needs to checked if x & y are of compatible data types,

mode of comparison is also an important consideration, equals, less then, greater then, like, which is the appropriate one to use, based on the requirement or circumstances. has less then been used when less then or equal to is more appropriate, or is equals used, when like is more appropriate, ensuring that the condition being checked will return both true / false and is the correct set of statements under true / false or is it reversed. These are the kind of questions to ask oneself

 

Loops & Conditions                                         

All kinds of loops and associated conditions such as select / case, while, for loop, will need to be looked at to check if, either the first element or last element may be left out, or the possibility of overshooting the no. of elements, problems due to the index (starting from 0 or 1), conditional checking such as < or <= which is the correct one? Proper use of break or continue to ensure that exit from loop happens, a default else or a default case, in case of a switch or a select case statements. another item not necessarily of the same category is recursive functions related problems, which need to be looked for.

 

Assignment - type mismatches

When the language being used allows implicit conversion among data types, there is a possibility of wrong assignments, a variable declared as a string might be assigned a number, date etc. but when reading from that variable and converting back, you will tend to get errors related to data type mismatch. when creating a variable of date/ time and assigning value from another input variable, then format, related issues may crop up especially when supporting I18N, 04/11/2008 may be interpreted as 11th April or 4th Nov, need to be watchful of such possibilities.

 

File and DB Access points

Another important area is proper closure of connections and freeing up of resources, in case a file is opened and read, has it been closed and the memory assigned been properly disposed. this applies on similar lines to Database connections also. Are the db objects such as record sets closed, if not, this may result in unwanted row level or table level locks. Resulting in a wait for ever, until the process is killed.

the same applies to files too.

 

Standards & Consistency

From a readability perspective the code can be checked for naming conventions, proper indenting, correct and relevant comments etc. well structured, preferably with an header indicating the purpose, and where this piece fits in the big picture.

 

 

Exception handling

In all of the above scenario's of failure conditions, having a mechanism to capture those exception cases, and logging that information for debugging purposes, and throwing a meaningful application defined error / exception message back, is important, during a review process we could check if all of the important areas where possibilities of exceptions are high, have the relevant mechanisms to catch them.. btw, this can be handled as a separate topic in some future discussions (possibly... not probably J )

 

 

I guess taking care of these, should make the code good enough, and ready for integration with other parts of the system.

Types of Integration (problems)

Integration can mean a lot of different things. But for our know-how we will stick to the scenarios below (for now).

 

Projects can be of many flavors; I have come across a few like the ones described below, let us dwell on the details of the advantages and Risks involved in each of these scenarios separately.

 

Project Management Related

 

Multi – location Development

 

The Multiple modules that form part of the Product may be developed by team members who are working from different geographical locations.

The main challenges faced are related to Time differences and Cultural differences. Good Clarity on expectations of Quality of the deliverables from each of the teams, having realistic timelines considering the local culture and calendar are key to satisfaction here

 

Procurement of Components

 

The Project may involve using a third party component as part of your product or service, You will usually base this decision on the fact that it is cheaper to buy then build it yourself, or you do not have either the competency or the time required to build.

The main challenges here are related to licensing the product, rights to re-distribute, future support availability, maximizing the utilization, in lieu of the price paid. Etc. There are cases where the vendor is asked to make a few changes or customize the components to your needs.  The Key here is to ensure that the vendor will continue to exist in the future, will be capable of providing timely support, and the procured components meet your quality expectations.

 

Joint Development

 

Two or more organizations may want to leverage each others strengths to capitalize on a market opportunity that requires them to work together to create a solution. This is the most tedious for the PM to manage, This includes the challenges in the above two scenarios, and also the added responsibility of qualifying each of the Individuals deliverables and the solution as a whole. Other bottlenecks may include revenue sharing, and agreements on providing technical support to customers. If not handled proactively, problems arising at installed locations can be tossed around as not my problem, or it’s on his side of the fence.

 

 

Technical Issues      

 

Data Mapping

 

When sharing information between two products, The data representation and Semantics of one product will not be the same as the other product. Identifying these dis-similarities and resolving them in mutually acceptable terms is always going to be a pain. A lot of Integration related problems arise from this mis-match if not captured during Requirements and Design stages.

 

Module or Component Interfaces

 

When the parts of a solution are developed separately, either in-house or procured, as and when these parts need to gel or work with each other. Interface mis-match issues crop-up resulting in a lot of re-work and schedule slippage to get the pieces to work in unison. Clarity in communicating the problems to the concerned teams, and getting it resolved will take multiple interactions. Geographically dispersed teams and working with teams outside the organization can further strain to the developers

 

 

This is not an exhaustive list of categories; just a few that I have come across in the last couple of years.  I will explain further details of problems and solutions related to working with external organizations and joint development in a separate article.

 

 

                                                                                     

 

                                                                                    

 

                                                             

Integration - Convergence

While the simplest of integrations may involve a straight forward Data transfer between two backend Data stores,
Next on the line can be a need to update multiple data stores, and then of course, do it real time.
Subsequent scenarios may involve transformation of data to cater to the semantics and the idiosyncrasies of the destination systems.  
You will come across entities or their attributes that does not have an equivalent entity on the destination. You will also come across Need to have some mandatory entities created in the destination store, when the source has nothing equivalent to send across.
Further there can be workflows triggered based on incoming data, and of course the workflow themselves may enable data changes across multiple systems

 

So what, why should I be concerned?

Well unfortunately or fortunately, I have had the opportunity to work on programs which involved Integration between such disparate systems.
We have had successes and failures along the way, with a horde of factors contributing to those results.
It makes sense to reflect on what I learnt and summarize for future.

I will probably take a couple of weeks… to gather my thoughts.

nuggets from Paulo Coelho

When we sense that the time has come for a change, we begin -- unconsciously -- to run the tape again, to view every defeat we have experienced until then.        "And, of course, as we grow older, our number of difficult moments grows larger.  But, at the same time, experience provides us with better means of overcoming those defeats, and of finding the path that allows us to go forward.  We have to play that second tape on our mental VCR, too. "If we only watch the tape of our defeats, we become paralyzed.  If we only watch the tape of our successes, we wind up thinking we are wiser than we really are. "We need both of those tapes."

5 essential tasks of a PM

1. Satisfy the Customer

2. Meet the Requirements

3. Deliver on Time

4. Deliver within budget

5. Keep the team Happy

Schedule vs Quality

I had an experience this weekend, that is an important lesson

Here's what happened
My vehicle service was due for sometime, and since I had to travel to Mysore over the weekend.
I decided to get the vehicle serviced on friday.I gave the vehicle (with no major complaints) at the service center for a regular service witch is done every 5k kms, I have been doing this for the last 4 yrs at the same service stn.following a similar routine i called up the center at around 5pm asking about the status of the vehicle to indicate the i would be there in an hour to pick the same

On this fateful day, the supervisor at the other end, responded that there was some nagging problem and he had not yet been able to diagnose the cause, and requested me if i could pick the vehicle the next day evening after he had it fixed. That news was something i had not expected, so I shot back on the phone, telling, I really need to go to mysore this weekend, and If the problem was not very major, I would still like to take the vehicle for the weekend and give it again to fix the problem, sometime mid of next week.

The Novice Supervisor, who was slightly hesitant agreed to my request and the got the vehicle ready in the next hour and promptly delivered to me the same day evening. I picked up the vehicle, and the alignment of the wheel seemed slightly imperfect, the steering wheel showed a tendency to veer towards the left slightly. I ignored that and decided that i would give it back for service sometime later and get it fixed.

The next day I started my trip to Mysore, with my family, but now the steering problem started intensifying
as i got farther away from home. thats when we decided to turn back and return home, my family did travel to mys. in the public transport bus and i headed straight back to the service station

I happened to meet one of his more experienced peers during the second visit, and he commented, "I had advised him not deliver the vehicle if he was not confident but the customer insisted that he wanted it for the weekend and he unwillingly obliged"

As i write this piece, the above comment from that experienced supervisior, keeps ringing in my ears. How often have i been in such situations in my own profession, in fact on both sides of the fence

There have been umpteen no. of times when we have unwillingly delivered to customers, and got it back indicating that there is major flaw (which we were well aware of) and yet times i have also requested delivery of product from my team, and they have obliged unwillingly.

Looking back after today's experience, I realise that i happen to be somewhere between the Novice and expereinced supervisor, and hope today's episode will keep reminding me of the importance of Throughness of the product as against the deadline

SCAMMPERR - Look for Alternatives

Substitute, Combine, Adapt, Magnify, Modify, Put to other use

Eliminate, Re-arrange, Reverse