manage well

Prior to the industrial age, the world was essentially an agrarian and a trading economy. Production methods were often a craft and top secret, fiercely protected within a family and handed down from a master craftsman to his sons, and with no machinery for mass production, pretty much every product was handmade and unique, perhaps also customized, for its intended user. Industrial revolution made mass production and rapid movement of goods possible, and among other things, catapulted Britain into forefront of global economies. Gutenburg’s printing press was perhaps the first mass production system built by man. Subsequent inventions like harnessing of steam power made railways possible, spinning machines, and other advances in iron founding and chemicals pushed the envelope. However, a lot of these advances were limited to Europe and even more within the UK, which thrived on these advances and became the economic (and imperial) superpower well until the start of twentieth century.

However, by the start of twentieth century, America too woke up to industrial advancements and contributed to some of the most important advancements that still continue to touch our lives. The pioneering work by Eli Whitney on ‘interchangeable parts’ on his now classic cotton gin introduced the concept of modular design, followed up by Frederick Winslow Taylor’s groundbreaking work on scientific management led to the concepts of standard work and division of labor  (even if somewhat questionable and controversial in today’s context) and created the foundation for Henry Ford to envisage a mass production system with a moving assembly line where finished goods could be assembled from standard parts by semi-trained operators, e.g. Ford’s most famous Model T car in black color (“Any customer can have a car painted any colour that he wants so long as it is black”).

In essense, a production run, say in an automative parts production or even a car assembly line, is the repetition of a process that produces similar (or similar-looking) objects. Once the ‘process’ is ‘designed’, the job entails repeating the process till the desired number of objects have been produced. Clearly, the faster you produce those objects, the sooner you can put them up in the market for sale and start getting money. The more you produce, the more you are able to amortize the capex, and get lower per unit price over the long run. Intuitively, if you have to produce objects that are exactly alike in properties, shape, size, color or any other physical attributes achieved by the production process, you can ensure that your production machinery will need to be ‘programmed’ once and re-used several times later. So, if you run the paint shop (which seems to be the largest bottleneck in terms of time in a modern production setup) and need to produce purple colored chasis, once you set the process, stock the paint to desired levels, you are pretty much all set. Now imagine if you have to produce first 200 cars in purple, then next 30 in wine red, then next 70 in pearl white colors. Surely there needs to be some way (manual or otherwise) to alter the production process to suit such job order. Similarly, instead of producting 300 sedans, if you have to produce a mix of automobiles – say, 50 SUVs, 50 compacts, 150 sedans and 50 hybrids, your process will have to be different from the one that just produces 300 sedans in a single production run. While the customer desires options (don’t we all?), the manufacturer incurs additional time, money and resources in creating such options. From the manufacturer’s point of view, producing each piece exactly similar as the last one makes such great economic sense that he can create huge economies of scale made possible by principles of mass production. It simplifies the machine (and machine operations) required in plants, it standardizes the components required, there is no downtime to alter the production process, people don’t have to be retrained every now and then on different type of products, and all this make the entire production process very ‘controllable’ from throughput and quality perspective, and hence highly predictable. Elaborate statistical charts can be created based on prior experience on how much time it takes for a given production run, how much men (and women) and materials are needed to meet a given production target, and what levels of quality can be achieved based on statistical experiences. 

Continue reading ‘Why are we in this mess?’ »

What is worse then an anarchy ? You might say that is the absolute abyss, but I think blind allegiance is even more dangerous (and that includes following the letter but tweaking the spirit – things like ‘creative accounting‘ or its parallels in every field). Anarchy at least allows for things to become ‘better’ in order to survive – whether it is the idealogy, resistance, or even musclepower, or any other ills (and hopefully at some point, social forces of constructive destruction take over). But in a land where unquestionable compliance and blind allegiance rule the roost, IMNSHO, is like a terminal patient off the ventilator support. When people are on their deathbed, they don’t regret things that they did but much rather the things they did not do!

In project management, life is no less colorful. We have process pundits (read “prescription police”) shouting from the rooftop with a megaphone on how heavens will strike them bone dead with lighting if they ever as much as strayed from the ‘standards’. When projects are being postmortemed, we don’t often ask what or why the project did something that they did, but why they did not do things that they did not do. And quite often, you find answer in the map itself – because the map did not factor-in those conditions that were actually encountered on the terrain, the blind followers just followed the Pied Piper and danced their way into the river of death. What a terrible waste of human talent.

Why do we get stuck with methods so much that our result-orientation takes a back seat ? I think there might be many answers, but some that deserve merit:

Continue reading ‘Our methodology is 100% pure, our result is another thing!’ »

Did you check out the Agile Skills Projects yet ? It seems to be a new and interesting initiative to “… establish a common baseline of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices”.

They talk about Agile Skills Matrix that has seven essential skills, or the Seven Pillars, organized into five skill levels.

Seven Pillars include:

Continue reading ‘Codifying Agile Skills or creating more checklists ?’ »

I just read a book titled “The eMedha Paradigm – A Project Manager’s Billion Dollar Odyssey” and felt terribly disappointed and shocked.

The author paints a make-believe world in which a sadist CEO does insider trading and makes his kith and kin richer, while his technically incompetent, control-freak and sexually-deprived project manager has a field day sinking the project. The team spirit is in tatters but because of the three-year job bond, they can’t leave their jobs just yet. Sales has promised to deliver the project in 1/3x time period, and now the customer is shouting from the rooftop on grand promises that remain grossly unmet. In short, all real-world ills happening in all permutations and combinations at the same time. While this might not be entirely implausible, I am yet to find such a worst-case view of real-world. This is such a picture-perfect scenario – can you think of anything else going wrong in this ?

The best is yet to come. An honest professional at the client side, Kalpana, with no significant credentials in getting a team out of such worst-case mess enters the scene, thanks to her scheming manager, and gets an anynomous mail from one of the team members on what all ails the project. While she is enroute India thinking about it at 40,000 feet mid-air, she has an encounter. Not a small encounter mind you, but The Encounter. God and his heavenly assistant (literally and figuratively, we are made to believe) Kamayani is an expert in some non-descript technique known as ‘eMedha’ that has the potential to transform any toddler into a veteran project manager. Even though these techniques are so obvious (or so the author would have us believe), for some reason our knight in the shining armor Kalpana doesn’t know these old tricks, and needs divine intervention to bestow that commonsense in her.

Continue reading ‘Are you solving the wrong project management problem ?’ »

Cockroaches just love projects. Several projects have loads of them, but most projects have at least a few of them. Software projects are notorious for breeding cockroaches that are not only hard to spot, they are harder to exterminate. They are a project manager’s worst nightmare, and despite our collective advances in project management theory and experience, we still are answerless in face of collective might of those otherwise innocuous-looking pesky little creatures that simple turn the best laid out plans and intentions into history.

What are these cockroaches ? I am not referring to the ugly kitchen pest that refuses to die (it is rumored to be the only living form with capability to survive a nuclear fallout), but the Cockroach Theory, defined as:

Continue reading ‘Does your project love cockroaches ?’ »

This is an interesting update on software trends:

A recent survey of more than 6,000 senior-level business leaders and software development executives found optimism for higher IT budgets and a preference for outsourcing, agile methods, and enterprise applications. In the survey, sponsored by software consulting firm SoftServe, 60 percent of respondents reported increases in 2009 IT development budgets, despite the uncertain global economic climate. Some 26 percent indicated that budgets had increased by more than 10 percent over 2008. Some 38 percent said they use some type of software development outsourcing. Of those, 67 percent used locations in India, followed by the emergence of Ukraine, China, and other Eastern European countries.

Continue reading ‘Software trends survey…’ »

 Large teams might be inevitable in certain large endeavors, but there are several benefits of small teams. A small team can build and maintain a strong culture and a character that gets better with time. Small teams quickly learn the invaluable skills in teamwork and interdependence that lead to higher efficiencies while ensuring that individual team members don’t end up competing against each other but rather collaborate on the common objectives. Small teams also mean small egos

One of the biggest motivations of making smaller teams is to provide higher levels of transparency and task accountability to individual team members. A large team tends to hide inefficiencies, both of its structure and of its people. One particular problem in a large team is the problem of “social loafing” – something that is perhaps best described in this poem by Charles Osgood:

Continue reading ‘Addressing the issue of “social loafing” in large teams’ »

At its core, productivity for a software team (often wrongly termed as programming productivity because software development is much more than mere programming) looks like a great idea. In its simplest form, it compares output of the team (amount of useful and usable software created, amount of unnecessary rework done, number of defects produced, etc.) to the input (time, effort and resources invested in producing software) factored-in by the uniqueness of the given software  endeavor and other external environmental factors (complexity of the software being produced, impact due to team sizes, nature of team spread and its familiarity with the problem at hand, problem domain, and so on). Unless you are willing to discount software development as a non-business critical activity undertaken purely for the labor of love that should not be ‘measured’ lest it dilutes the very ethos of software development as a creative cognitive endeavor, one might agree, albeit reluctantly, that some measure of how well we are doing is clearly in order. Can you think of a single business activity where such a measure should not be done?

In last few decades, researchers and statisticians have tried to create quantitative measures of productivity. However, due to an often unilaterally percieved inherent ‘uniqueness’ of every software endeavor, practitioners have consistently rejected such measures contending that there are either far too many assumptions in its definition and far too many variations in practice, or both. Instead of focusing on the ‘vital few’ commonalities, it is only unfortunate that practitioners have virtually rejected productivity measures in all forms by considering the ‘trivial many’ differences. What could have gained the industry by considering a big-grain definition of productivity was unfortunately lost because of focusing on decimal-digit precision of productivity measures.

In this blog, I will discuss the subject of productivity from a conceptual plane, and explore how Lean thinking helps us understand it little better by establishing a correlation between wastes in software development and productivity of the team. Lean thinking is much more than identification and elimination of the seven types of wastes, but I will only take up the issue of wastes in this blog.

Continue reading ‘How Lean thinking improves productivity in software teams?’ »

Agile thought movement has been around in different stages of evolution (and not to mention, different vocabulary from different preachers and schools of thought) from 1960s – perhaps it always co-existed with its better-known but half-effective cousin, Waterfall, all those decades without ever becoming a mainstream / preferred method of solving complex problems. Declaration of Agile Manifesto in 2001 was a watershed event, and the body of literature that has grown since then is simply mindboggling. There is a huge experience base on various Agile methodologies and methods that seems to be gaining firm ground globally every single passing day.

Divide and Rule

There can’t be any doubt that the fundamental idea to approach a problem in smaller pieces is great – it is logical, it is result-oriented, it is economical and it is highly intuitive. After all, the Imperial British conquered half the world by their brilliantly cunning doctine of ‘divide and rule’. It allows the human mind to focus on what is ‘visible’ here and now as opposed to worrying endlessly about the entire length and breadth of the problem which may never ever be crisply definable, or might require a disporportionately large amount of time (and effort) to clearly define it – by which time it is quite likely that the problem might have undergone changes due to natural ageing or changes in environment around it, or an improved clarity into the problem has given rise to another thought process about its solution, or both. Frankly, none of them is bad in the sense it is always better to know more clear definition of the problem or a more clear definition of the solution. The only problem is that it takes an inordinately large amount of time to reach there, with no mechanism to know if what is being considered will actually work as envisaged. While executing, one could encounter several more unknowns on the way that force changing the laid-out strategy. However, when you slice the problem in meaningful increments, you allow the solution to grow, one slice at a time. Of course, you still need to have the strategy to accomplish the top-level vision – but the working plans must not attempt to address that entire strategy in one single-pass. There must be a mechanism to (a) breakdown a problem into meaningful slices that (b) can be accomplished individually and incrementally to (c) make a definitive progress towards the eventual goals (d) without unduly front-loading the progress by later-day uncertainties. Agile encourages establishing a beachhead and then reinforcing it, slowly and steadily as opposed to landing in the middle of a battlefield and getting fired at from all directions. As a concept, this is splendid.

Continue reading ‘Why Agile doesn’t sell with Management ?’ »

This is the text from a recent announcement for a course by Ken Schwaber on “Flaccid Scrum – A New Pandemic?” (text underlining is mine):

Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.

Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.

Continue reading ‘Blame your “flaccid developers” and your “flaccid customers” for your poor quality products !’ »

Yes, you read it right…when are you planning to fail ?

In the world where insatiable hunger for ‘success’ is an obsessive-complusive disorder (OCD), we don’t think of ‘failure’ much. It is shunned, scoffed at, systematically eliminated (or mitigated, at least), avoided, bypassed, ignored….everything but embraced with open mind and open arms. All management ideas are directed towards the age-old wisdom of “if you fail to plan, you plan to fail” and not on something like…”what won’t kill you only makes you stronger”. All project management philosophies are centred around safeguarding the projects from any possible failures…but has that stopped projects from grand failures? Every risk management action is towards making the project safe from failing…and yet we still see so many projects biting the dust, struggling for survival. Failure appears to be a social embarrassment that is best avoided at dinner table conversations. New-age enterpreunership, especially in Internet world, has helped a lot to eliminate the stigma that eventually comes with people associated with any well-known failure, but in everyday lives, we still continue to play safe, rather extremely safe. Of course, I am not talking about breaking the law and driving without seat-belts on or driving in the middle of the road jeopardizing everyone’s life. I am talking about thinking like Fosbury and challenging the established way a high jump is done – even at the risk of failing because what you are about to propose hasn’t been tested and certified to succeed. I am talking about taking those small daily gambles that strenghten you when they fail. I am not interested in those small daily gambles that are supposed to strenghten you if they succeed – honestly, they don’t teach you anything. In fact, those small successes might limit your ability to reach for higher skies because you remain contended by those sweet-smelling early successes. In my view, people who don’t want to risk gentle failures must prepare themselves for grand failure !

The word ‘fail’ is such a four-letter word that is evokes very strong emotional responses. In an achievement-oriented society and success-intoxicated corporate culture, fear of failure drives people to seek safer havens. When choosing what subjects to take in college, we ‘force’ our children to take the ‘safest’ subjects – they are the subjects that have maximum job potential ensure maximum longevity in job market. (I agree that ‘force’ is not the right word here, but it is not in its literal sense that I use this word here. The ‘force’ can come from parental expectations, societal pressure, peer pressure, ‘coolnees’ of a job, perks of the job, etc.). Traditionally, they have been Engineering and Medicine and anything else that ensured a government job (in India, and I am sure every country has had its own fixations at different times). So, the foundation to seek safety from failure gets laid right at the start of one’s career (well, in my view it is erected right after birth and we are still curing it by the time we start our careers, but that’s for another blog post). After graduating, there is once again a massive derisking operation: find some company that has a ‘big’ name (even if one is doing a fairly mechanical job there). Basically, trade any hopes or ambitions to do something new and creative in life with rock-solid jobb safety in a mundane assignment! As a rookie, you then become a link in this enormous chain where your job is dictated by the volumes of SOP (Standard Operating Procedures) that trade your urge to experiment / innovate with a higher ‘percieved’ safety of the given process. The logic being: this is the way we know it has been done before, and since it worked the last time, we expect it will always work and hence this is the standard procedure. Wow !

Continue reading ‘When are you planning to fail ?’ »

A Lean Enterprise is defined as “a business system for organizing and managing product development, operations, suppliers, and customer relations. Business and other organizations use lean principles, practices, and tools to create precise customer value—goods and services with higher quality and fewer defects—with less human effort, less space, less capital, and less time than the traditional system of mass production.”[1]

Womack and Jones describe Lean Enterprise in detail as follows[2]:

“The objectives for the lean enterprise are very simple: Correctly specify value for the customer, avoiding the normal tendency for each firm along the stream to define value differently to favor its own role in providing it. …Then identify all the actions required to bring a product from concept to launch, from order to delivery, and from raw material into the hands of the customer and on through its useful life. Next, remove any actions which do not create value and make those actions which do create value proceed in continuous flow as pulled by the customer. Finally, analyze the results and start the evaluation process over again. Continue this cycle for the life of the product or product family as a normal part, indeed the core activity, of “management”.

Continue reading ‘What is a Lean Enterprise ?’ »

Over the years, I have had the good fortune of stumbling upon several universal truths of software development. that have stood the test of time. While some of them were gratefully borrowed from other more competent professionals, several of them have been earned first-hand

I offer them here for your critique:

Continue reading ‘Some ‘universal truths’ of software development’ »

There was a highly charged discussion on real colocation vs. remote colocation on one of the mailing lists. I think the number of posts far exceeded 100+ and eventually there were more emotional and personal arguments than any meaningful real responses. Finally, the original poster left the group, people who were left on the group were in introspection + justification mode for a day, and life seems to be slowly returning back to normal on that list.

I think the discussion lost its fizz because of several reasons, but I feel most of us are still living in a denial mode as far as remote work is concerned. Just because we have Agile Principles that ‘favor’ colocation, there is no good reason to justify that as the means to colocate the teams, come what may. My argument is don’t suboptimize the whole in order to superoptimize the parts. So, if I were a carpenter on contract to build a house and only knew how to use a hammer, it would amount to me demanding that every door and window be made using only the hammer whether the house needs that or not, and whether that suboptimizes the house construction or not. I look at life this way: if you are lucky to have an ‘ideal real world’: small, colocated teams, than by all means, go Agile in its full spirit. However, if higher business imperatives make your business remotely located in multiple locations, then you can’t be pushing your tool just because that’s your comfort zone ! A customer doesn’t care what process we use internally as long as he get what he wants and when he wants at the right price point he has in mind. To a large extent, the same goes for your management also. They might recognize that you can improve your development productivity 2X (or whatever is the going rate) but let’s be honest. How much time and effort does the software phase consume in the overall product development ? Obviously that number varies depending on the type of system being built, but even in 100% software-only products, there is a reasonable (and quite often, significant) amount of time and effort that must be consumed by non-software teams. If we assume software teams are consuming 40% effort on a systems project, and by distributing work, the organization is getting a 2X improvement (without being judgemental about the type of ‘improvement’, let me just say this is a result of availability of talent at the right price point that is able to deliver the work within desired quality). Now, even if Agile practices are able to bring a comparable 2X improvement, that is probably only affecting that 40% of the development effort to become 20% but at the cost of colocating everyone which means the cost of overall project might double in the worst case, going up from 100% to 200% ! So, if that is the way an argument for supporting Agile adoption is made, I won’t be surprised if there are no takers. This ostrich mindset reminds me of the Swiss Army manual – if there is a discrepancy between map and terrain, trust the terrain.

A far better approach would be to first understand what is an organization’s constraints and expections in distributing the work to remote teams. What benefits are being expected, and are actually being accrued in reality by doing that. Once done, that is a great starting point to have the debate on how best we can make distributed teams more productive – so, it is nomore a question of pure faith vs. pagan. It is a question of what is the best way we could help teams in the given context. The idea is not to challenge why real world is so ugly and try to facelift it because the mirror won’t like it, but to accept the real world for its face value (surely, healthy debate on why it is so is always welcome in any organization) and find or make the mirror that will do best possible justice to the real world.

Continue reading ‘Which of the ‘real worlds’ does your software team live in ?’ »

Since times immemorial, ideas, objects and experiences of grand stature and lasting economic, social and emotional value have been created by men and women working together in teams. Granted that some extraordinary work in the fields of arts, philosophy and sciences was done by truly exceptional individuals, apparently working alone, I suspect that they too were ably supported by other selfless and unsung individuals (in the backoffice, perhaps) who all worked together as a team. Right from the great wars, social upheavals, political resistance, empire building, freedom struggles and forming of nations and protecting its borders to the creation of majestic wonders such as Pyramids, Taj Mahal, Eiffel Tower, Statue of Liberty, Sydney Harbor Bridge or the London Eye and many more, each one of them owes its creation and existence to teamwork. Of course, the scope of teamwork doesn’t exclude simple, mundane and everyday things that are extremely important even though they never make a headline: an activity as routine as tilling the fields, or planning a picnic or even a family function, all involve a team. 

With such profound impact teamwork having on our everyday lives, it is only natural to expect that output of a team is directly impacted by the quality of its teamwork. Unfortunately, this doesn’t happen by having right intentions alone, or by leaving it to chance. Quite often, it doesn’t even happen ! Quality of teamwork is impacted by various factors such as motivation levels of individual team members, levels of trust among team members, clarity of purpose, uniform understanding of the goals, lack of resources, poor communication among the team members, and so on. Thus, it comes as no surprise that appropriate investments must be made to make the team click. However, most often, team dysfunctions affect a team’s performance seriously jeopardizing its ability to perform effectively, any state of art processes or tools notwithstanding. Most software managers lack the ability to detect such deeper sociological smells, thus are unable to deal with its impact. Any superficial response to such problem only makes the task harder to deal with. 

In this article, I have analyzed the team dysfunction model proposed by Patrick Lencioni in his wonderful book, written in the form of a fable in a business setting, The Five Dysfunctions of a Team – A Leadership Fable. In his model, called The Model in the book, he has identified five dysfunctions of a team that affect team performance. These five dysfunctions are not really independent, but interrelated to each other, and build on top of one another…

Continue reading ‘How Agile Practices address the Five Dysfunctions of a Team ?’ »