manage well

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?’ »

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 ?’ »

I just completed first draft of this paper for business review magazine of a city college of business administration. If it gets selected for publication, you will get to read the full paper on this site . Here is the abstract:

Toyota’s pioneering work in automobile production systems continues to be among the most profound and radical departure from conventional thinking since the times of Henry Ford, and has led to unprecedented cost efficiencies and quality improvements for them. For long, it was thought to be a Japanese expertise – one that could not be duplicated by non-Japanese people, or outside Japan. However, subsequent to Womack and Jones’ pioneering works, “The Machine that Changed the World” and “Lean Thinking”, it has not only been adopted outside Japan, its universal principles are also finding huge acceptance in other sectors and service industries throughout the world.

However, any process is only as good as the people involved in it and their thought process behind it. Toyota’s production system is not only about how the production flow is organized – it includes fundamental aspects of professional ethics and work culture that are deeply ingrained in their thinking. These so-called “Toyota Traditions” serve as the guiding light for managers and employees alike and continue to remain relevant as ever. They also are ubiquitously applicable in almost every stream of management.

Continue reading ‘Toyota’s Wisdom for Tomorrow’s Managers’ »

Continue reading ‘What is the Inventory of your Software Development project ?’ »

There was a question on the group Scrum Practitioners on LinkedIn if “…implementing Scrum as a whole should be our goal or would you use aspects of the Scrum methodology to realise an agile culture change ?”

Looking at the disproportionately large number (with an increasing trend) of posts on popular mailing lists on Scrum and Agile software development, I am alarmed that most energy and thought is being spent on figuring out “how Agile you are”, how should the user stories be worded, and whether one uses planning poker or not ? I mean…does it really matter whether you use ‘deal hours’ or ‘story points’ whatever that means ? If your team members are not speaking out ‘impediments’ in daily scrum…come on…that was the case in good old days also…expecting that Scrumifying the process will make everyone speak up honestly, do their job on-time and love thy neighbors is little too much of wishful thinking in my honest, brutal and uncharitable view. 

Scrum exists to serve its master, which is Software Development and not the other way round. So, implementing Scrum can never be the goal by itself (isn’t that where we went wrong with the CMMs and the ISO9000s of the world ?). Timely delivery of on-specs and high-quality software is almost always the goal. Anything that helps in that direction is a only a means towards that goal.

Continue reading ‘Is Scrum serving your Software Development, or the other way round ?’ »