Billion Dollar – Re-organization, structuring

When an Organization restructuring is required, it’s Required but that doesn’t mean that what was going good should be changed. The restructuring is just management change and removing ambiguous and redundant roles, but not restarting from scratch and impact your deliverable. Most of the managers, who can’t really speak of their scary picture at any point of time, once they are not impacted due to this re-structuring of Organization, try to prove themselves to their Managers by showing some killer instinct(sarcasm) of getting things done. Motivated people are key asset to any Organization and once you act because of your insecurity and over-ambitious nature, one kills long term deliverable and those people. IMHO, one needs to believe their ability and do the right things for long run, rather than short term projection. Noises are going to be there in Happy times as well as Hell times of economy, but one need to focus on right things which deliver right value at all times.
How insecure and threatened manager behave, I am quite accepting to this blog. Large Organizations might speak about getting into startups behavior like Yahoo, and others follow, but practically are all people ready for it!!! I doubt so..One can do marginal revenue optimization but if these multi-billion Organizations want value-exponential-growth, they need to have commitment to re-organize mentality of their people rather than watching their bottom-line band top-line growth. Things gonna flow automatically.

Mythical Man-month

I was going through Mythical Man-Month and loved this book. I could co-relate it with my past experience in IT industry and also wanted to share across some good quotes from this book.I would love to hear your thoughts and opinions on it too.

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you. Menu of Restaurant Antoine, New Orleans.

More software projects have gone awry for lack of calendar time than for all other causes combined. Why is this cause of disaster so common?

First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.

Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine’s chef.

Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

In many creative activities the medium of execution is intractable. Lumber splits; paints smear; electrical circuits ring. These physical limitations of the medium constrain the ideas that may be expressed, and they also create unexpected difficulties in the implementation.

Computer programming, however, creates with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified.

The second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.

When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.

In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing.

Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices–wait or eat it raw. Software customers have had the same choices.

The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save–burned in one part, raw in another.

Adding manpower to a late software project makes it later.

This then is the demythologizing of the man-month. The number of months of a project depends upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks. From these two quantities one can derive schedules using fewer men and more months. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men and fewer months. More software projects have gone awry for lack of calendar time than for all other causes combined. [pages 25-26; emphasis in original]

The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back.

Why aren’t defects fixed more cleanly? First, even a subtle defect shows itself as a local failure of some kind. In fact it often has system-wide ramifications, usually nonobvious. Any attempt to fix it with minimum effort will repair the local and obvious, but unless the structure is pure or the documentation very fine, the far-reaching effects of the repair will be overlooked. Second, the repairer is usually not the man who wrote the code, and often he is a junior programmer or trainee.

How does a project get to be a year late?… One day at a time.

But the day-by-day slippage is harder to recognize, harder to prevent, harder to make up. Yesterday a key man was sick, and a meeting couldn’t be held. Today the machines are all down, because lightning struck the building’s power transformer. Tomorrow the disk routines won’t start testing, because the first disk is a week late from the factory. Snow, jury duty, family problems, emergency meetings with customer, executive audits–the list goes on and on. Each one only postpones some activity by a half-day or a day. And the schedule slips, one day at a time.

For picking the milestones there is only one relevant rule. Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Coding, for a counterexample, is “90 percent finished” for half of the total coding time. Debugging is “99 percent complete” most of the time. “Planning complete” is an event one can proclaim almost at will.

20s-30s change the world

My study says that historically, people in 20s and 30s transform the world. Any kind of world changing innovations has happened by people in this category.

Marie Curie got her nobel prize at the age of 36 for research in radiation.
The major transformation of how the world looks today happened  when Thomas Edison was 22 years of age, when he invented electric vote recorder and at the age of 32, electric bulb was IN.

The second wave of Cloud computing’s seed was sowed by Herb Grosch when he was 32 years of age.
We all use smartphones today, and the first seed of smartphone goes back to Theodore Paraskevakos when he was 31 years of age.
No need to mention Orkut and then facebook.
So if you are in 20s/30s, high chances are that you are going to make a difference. Post that, you will be the one who will work on something innovated by someone. But Yeah, incubation shouldn’t die. It should be continual and progressive thing which should go on in case we missed world-changing innovation.

People leave their Managers – Is it so?

Attrition is what most of the Managers and executives are concerned of, and most of the talk from typical Human resource guy goes around, People leave their Managers and not Organization. With my decade career where I have been into non-managerial as well as managerial role, it sometimes becomes hard to digest. With social media in place, I don’t think I can get better insight into ‘Why people leave an Organization, or so called Managers.
Every human being is unique and they got their own thought process before they think of leaving an Organization. Here is a talk about employee leaving Manager and there was some kind of survey done in one part of world, and here is some survey done in other part of world. Technically speaking, in any kind of attrition employee is indeed leaving their Manager  but I would like to hear from you, what you think about primary reason of someone quitting an Organization/Manager.

Focus and eliminate unnecessary stuffs

Hard times grooms you to what you are. One shouldn’t listen to the noise which comes in their business/work place, rather their mind should work as analytic tool and get information out of that noise and focus on it. Patience is the virtue and being naturally short tempered too, you shouldn’t lose your focus and patience. Any individual or an Organization get much recognized during hard times. Everything is merry-go-lucky in good times.

It’s hard when you are focusing on actual root issue to sustain that noise but take out time and notify right people about things going on. Do not retaliate because that kills momentum. Noise is important for growth as it gives you feedback but how you take it is more important. Strong ethics make you stronger during hard times and poor ethics is revealed during this time.

Finally, If you are asshole, you are one to create enough noise to save your ass, and if you are good ass, you will create noise with relevant information 🙂

Ideas, Innovation and Incubation

Most of the Organizations talks about having their people come up with ideas, to innovate and incubate to help reduce cost, increase revenue, improve processes etc. History shows that much of incubation happened during crisis, so should Organizations be making crisis like situation to people to get them on their toes to incubate and come up with ideas. Necessity is mother of invention, so create that phase where people have to think that it’s necessary to do something or just fade away..

Agile Testing – You can’t win 3rd world war with First World War weapons and strategy.

Are we yet ready for testing in Agile? The industry is talking about agile development, but how many of us have equipped our self to live in the world of Agile? Are our resources (people and lab) ready for this? Do we really release tested product every iteration? You can’t win 3rd world war with First World War weapons and strategy.

Agile testing is all about delivering business value required by customers at frequent intervals. Depending upon complexity of the project, the intervals can be defined. It can depend from two weeks to four weeks. If we compare this to standard V-model or Waterfall model, it is indeed very short timeframe in which we are delivering *a value* to the customer. Who wouldn’t love to have a workable solution to their problem in such a shorter time frame? The key challenge is how we ensure quality of this deliverable. Irrespective of what model one follows to stand by the commitments, QUALITY CAN NOT BE COMPROMISED.

So how do we ensure that with the same team and tools we followed in previous model, we attain at least same or better quality? Agile states that testing is not a separate phase but works in conjunction with software development. This gives us opportunity to do quick testing of our functionality built because developer makes sure that the feature they are developing is doing what it is supposed to do and tester makes sure that how customer is going to use this feature works like it should do.

Here tester’s time can be utilized in not testing the stuffs which developer has coded because it is developer’s responsibility to ensure quality of that code. Tester’s job can be well utilized in doing end-to-end testing of the feature, ensure Real world use cases are working as desired, ensure performance and scalability. So how can we do this in such a shorter iteration cycle?

Once you start thinking of entering into the world on agile development, one need to question if their resources- people and tools are well in place for Agile. Switching over to tools like code crow or rally and following daily scrums doesn’t ensure that the output required out of following agile gets achieved. We need to be able to deliver solution to customer problems every iteration and just following this process doesn’t help. These tools and processes are for making sure that development cycle is faster but what all things we need to equip our team with to ensure that it is indeed faster.

Before we start with agile development, we need to take a step back and think “Am I having right kind of weapons in place to win this battle?”

ð   Do I have dedicated automation lab in place, which make sure that I don’t really have to worry about regression testing and don’t end up doing much of hardening phase.

ð  Is my current team in well positioned – technically and logistically, to deliver quality release? Are developers in mindset of doing testing and testers in position to write quick automation test cases to have faster and quality deliverable?

ð  Have I provided sufficient lab resources to my development team for doing continuous builds and tests to ensure that their code doesn’t break things?

ð  Are my testers out of the mindset of testing just features and concentrate more on problem solving testing mindset, i.e., working on bigger picture?

LET YOUR ENGINEER DO ENGINEERING AND NOT MEETING

 While speaking to many of my mates, who are like me into IT and others into manufacturing, power engineering etc, one thing which I found to be common is that most of them involve their much of the time at work in meetings. The different meetings have one thing in common – they don’t have goals defined for that meeting. Some meetings are called by Managers because they need to be updated on project releases, some are called by manager’s manager because they need to be updated on project and some are called upon by clients, because they also need to be updated on project.

Some meetings are required for some technical discussion between engineers which is well understood. Provided there is value out of meeting, it’s fruitful to have it, rather than playing this e-mail chain. Manager’s job is to cut down on all unnecessary meeting for their engineers and let them do their job – engineering, a better engineering. If as a manager, you are not able to make a call for whom to be included in a meeting, and then you are not enhancing productivity but creating a big hindrance in your project delivery.

I was surprised to know that more than 30% of most of engineer’s time goes in those meetings where they are not required. If you look at your estimate of project delivery time, that’s huge cost associated with it. There are many different smarter way to get updates and it’s really not required to have multiple meetings for getting it. If rhythm of an engineer working on a task breaks, it takes him equal time of that meeting to again get back from where (s)he stopped.

I remember reading one article which mentioned how much Steve Jobs was sensitive about having right people for a meeting and would like to mention that here. Nothing is as bad as unstructured, unproductive and uninspiring meeting. If there is one person also who comes out of meeting room saying what a crap meeting for this – you have wasted that one person’s time and in my opinion, have wasted your Organization’s resource.

So, next time if you have been called for a meeting, where you think you are not fit for it, take a bold step to call that Organizer and know why you have been included in that meeting, and if you are the Organizer, ask yourself if you need each and every person whom you are calling for meeting. It’s also worth to refer this on how meetings are organized in google.

KNOWLEDGE MANAGEMENT IN SOFTWARE ENGINEERING

KNOWLEDGE MANAGEMENT IN SOFTWARE ENGINEERING – QUALITY MANAGEMENT

The soft stuff is always harder than the hard stuff – Roger Enrico, Vice Chairman of PepsiCo

Knowledge Management is not something new thing in any part of the industry. This goes back to thousands and thousands of years when learned men used to write manuscripts about their experiences and learning so that it could be drilled down to their disciples and to the rest of the world seeking knowledge.

Why do we need Knowledge management:

Let us start from a very small scenario where as a manager someone is handling a core piece of project, which is a part of large program meant to be aligned with corporate strategy. You have a bunch of highly experienced and talented engineers who are part of the team making things happen. One fine day, one of the lead who owns a critical piece of development comes in and says that he won’t be able to continue with the Organization due to some or the other reason and you have no way to stop that guy. Bizarre situation!! He was the one who knew in and out of the project and code and now you will have to find someone who can quickly fill up his shoes without crossing the deadline. To make the matter worst, you don’t have any knowledge management tool in place.

The situation could have been mitigated if there would have been a knowledge management in place. This could have been in any of the forms – structured documented code, detailed information about project and knowledge gained with experience by the person, lesson learnt – what to do and what not to do, regular brown bag session in the team which would have made each and every person be aware of different things which each and every team member is doing, recording it and having it in database.

This was just an example on staff attrition front. What about when Organization is devoted to continuous learning process. So, you are having offices across the globe and you need to have a particular work transferred to some other location due to strategic requirement? With no knowledge management in place, how much time and effort will it need to get complete transition done. This could be horrifying.

What more can we get from having an organized knowledge management in place? Well, that can be one of the things which can be a very useful attribute in employee engagement. They will feel rejuvenated every time they get kind of information they are looking for and anytime when they are seeking to learn new things which might be in their focus area.

PRESENT CHALLENGES OF KNOWLEDGE MANAGEMENT:

Most of the software companies now do understand the importance of having knowledge management in place, so that their workforce are educated on their project, on the project they are virtually part of and on something which they are not involved in. They emphasis on having proper write ups about project, their technicalities, problem areas, resolutions, customer feedback. They have social networking in place like wiki, chatter, share point, confluence in place which is used for informal and formal collaboration. So, where is the problem when most of the companies do have things in place? The knowledge is lying in multiple tools and in different forms for anyone to get in one go!! I need to get basic or advanced information about one domain or technology and I don’t know where it might be available and I end up searching everywhere across in my network for the tools I know. If I don’t know if SharePoint is also a tool used by my Organization, I miss out on some information. Social chatter might have my kind of information but those communication happened months or years ago and I end up investing my time in searching those.

So there can be two challenges – No knowledge management at all or having too many unstructured, unorganized knowledge management.

In the most ideal condition there should be one and only one tool to manage knowledge but that is something practically not possible in all Organizations. The reason can be client’s requirement and funding, historical reasons of shift to different knowledge tools, privacy contracts with end customers etc. In case of having multiple tools floating across in the organization for maintaining knowledge base, company can come up with indexing search from single point from where these knowledge articles are accessible and in case of any privacy documents where it cannot be made accessible to all, point of contact can be updated. This would help your people to reach out to right people for guidance rather than wasting time and effort in finding right people for that.

Employee development through effective knowledge management:

We briefly talked about employee engagement in need of knowledge management in earlier section. Most of the Organizations strive towards having a nimbler team who are effective enough to take on challenges as and when it comes. The dynamics in software world is just like molecules; it is vibrant and to survive and exponentially create difference in world, you need great team members. They should be ‘Jack of All trades and adaptive to be Master of one chosen’ at that point of time when requirement comes. We know that being learned is not a fortnight achievement. It is gradual and continual task. Either you have an option of hiring right kind of skillset people after investing some months in searching for them at some extra cost or to groom your existing people to be ready for these times. If you opt for latter part, you end up in creating trust of your existing people and also in saving costs for your Organization. Why does an employee look for a change of a company? Out of many reasons, the most obvious thing is that they have been doing same work for years and as a manager, you have been also in a comfort zone in having a person work as subject matter expertise in one field. The question is, is that what any Organization wants? One technology is going to fade away and next going to take it up. No organization is going to have a person for what they have done in past, but for what they can do in present and more importantly in future. Grooming your employees to be ready for future is what having knowledge management in place do.

KNOWLEDGE MANAGEMENT shouldn’t work in SILO

 

Until now we have mostly focused on how we can make best use of tools to get knowledge management in place. In my opinion, knowledge management is just not limited to having it stored in a place and let your people make use of it. It is also more about how much you let your people interact and share knowledge. In a large organization, you will hardly find a person on one floor interacts with a person on another floor until and unless some work related matter comes. Though they might be working on same project but they are glued to be working on technology for which they are termed as subject matter expertise. Now this is the kind of situation where a manager should break this barrier and create a mentor-mentee 360 degree model in organization. There should be continuous program where different people meet each other and share their knowledge across. Most of the time it doesn’t happen because people tend to think that for the technology or field they are marketed as SME will be lost, leading to their importance getting lesser. If you look around your work place, how often have you seen such people rise in their professional career? They might get benefit for short period of time but in long run they are going to be stagnant or collapse. For each individual to grow, they need to impart knowledge and get knowledge. This also helps in making a motivated and charged up team, which of course makes a better work environment to work in.

HOW DIFFERENT IS KNOWLEDGE MANAGEMENT in Agile Model?

I remember the days when agile was hardly talked about and most of the software companies used to talk about V-model and most of the projects were still following waterfall. These models were rich with respect to procedures and people used to work days and nights in documenting the things rather than working more on building right software. ISO auditors and CMM auditors were rich on demand and they used to keep on asking some audit related questions for which again some documentation was required. Not all the problems can be resolved with procedures and so came agile model – to solve complex problems. Agile model is more about tacit and socializing knowledge management. When one is working in an agile model, it is highly expected that each and every team member keeps on socializing during development. It is also very much possible that Chinese whisper becomes as knowledge sharing style in that development cycle and thus comes in different tactics to be followed when working in agile. You can’t really devote numerous man hours in documentation and the way to still have knowledge management in place is to have disciplined agile model in place. You still need to have your research documented, does better code, with understandable comments in place, have more and more recorded demos in place for each and every stuff you do and share it across in your knowledge management tool.

If these practices at minimum are not in place, it is highly possible that your agile model is going to fail. You might be able to deliver the product but may not be able to have quality supportability around it and thus project failure.