Tag Archives: Lean

Dude, where’s my customer?

I am delivering this talk at the Lean India Summit, Bangalore, Nov 15-16. Ahead of my talk, this Q&A captures some of the key ideas behind the talk.

Abstract of the talk: Startups that operate under a stealth mode achieve over 90% failure rates. While they might have bright ideas, access to top talent, adequate funding, etc., they typically fail to accomplish their original objectives. A key reason behind such spectacular failure rates is premature scaling at each stage of the startup. In this talk, we will examine the mistakes that startups make, and what we can learn from the Customer Development model proposed by Steve Blank to improve better chances of survival and growth.

Q1. You mention that premature scaling at each stage of the startup leads to failure. What is the right time to start scaling for the startup? How can the startup course correct if they realize that they have started scaling prematurely?

A:   As Steve Blank says, a startup exists to search for its business model and not to execute it, I think the right time to scale is when you have ‘discovered’ the ‘business model’. What that means is that unless you have gone through Customer Discovery and Customer Validation process and turned your hypothesis into facts based on actual market feedback, you don’t really have any need (and hence the justification) to scale up.

Why Startups Fail

If you have started scaling prematurely, I think you should stop and introspect. Ideally, stop all other marketing and sales and other activities of scaling up the product development organization, and just focus on validating your initial hypothesis. One important point to remember is that sometimes having excess cash could force one to scale up, so avoid getting more cash than you really need!

Q2. There are couple of questions we asked one of our other speakers Wes Williams, which we think is relevant to your topic as well. Would like to hear your thoughts on this – a) How does the size of an organization impact its scalability? Would you need to think of a different scalable model for large sized organizations?

A: Large organizations have typically been cash-rich and hence were more eager to scale-up in the past. However, the harsh realities of today’s economic environment have forced them to be more conservative. I believe even the largest, most cash-rich organizations are thinking twice before scaling up prematurely. I know how hard it is in most product companies to get an additional resource even, so clearly, the old rules don’t apply so well anymore.

I would build a much shorter runway where I can demonstrate tangible results in terms of customer discovery and customer validation that allow me to pitch my case for incremental funding that is backed by solid data from the market. That way, my expenses and promised revenues are growing in tandem rather than making a wild promise about the revenue without a scientific basis and piling up a large expense plan in anticipation of revenues.

Q2. b)What do you see as the difference between scalability, flexibility and agility?

A: Agility is the ability to achieve (or exceed) the set goals by being flexible about how to accomplish them. Flexibility is the means to accomplish agility as an end-goal. Even there, let me correct myself – agility is not an end-goal. It is once again a means to accomplish the next higher-order goal, viz., create a successful business.

Scalability is very different, though an effective scalability might require them both. In traditional manufacturing, it was all about building something at a large-scale so that economics of manufacturing or production could become much more affordable. The problem is that accomplishing scalability invariably requires lots of sunk costs and irreversible decisions and might be fraught with risks if the underlying assumptions turn out to be false. Henry Ford was able to reduce car prices by creating a process that eliminated user customization (“you can have any color of car as long as it is black”) to create a standard one-size-fit-all car that could be mass produced to achieve unprecedented economics of scale. However to achieve such economics of scale, he had to pump in millions of dollars in manufacturing plant and a car design that might hopefully sell in the market. So, in manufacturing, mass production brings down prices, and hence, scaling up is good, but one needs to make sure they have the product that the market wants, lest they be stuck with deadwood!

In software, scalability needs to be understood differently from manufacturing. Presently, there are two key manifestations of scalability – one is scaling-up product development process across the organization, e.g., going outside a single scrum team and aligning to the strategic portfolio, etc. One such framework that attempts to integrate all organizational functions together is Scaled Agility Framework. The other one is scaling-up your software product or services, e.g., offering the app on all major OS versions of mobile or tablets, or offering the software in all languages, or offering the product in all geographies, etc. The first one is all about being internally efficient and reduce friction and hand-offs across different departments in achieving a seamless supply chain to ‘scale up’ your agility throughout the organization and not just limiting to software teams alone. The second is all about scaling up your product and services from the market coverage or product capability standpoint and is conceptually more akin to traditional notions of scalability. One needs to be pragmatic about market potential before committing to any such expenses that involve sunk costs or are irreversible in nature. To that end, the principles of agility are a must to establish early proof points about the real assessment of market potential.

Q3. The Customer Development Manifesto suggested by Steve Blank mentions that “A Startup Is a Temporary Organization Designed to Search for A Repeatable and Scalable Business Model”. In your experience, how much of scaling is good for the organization? At what point does the startup need to pause and introspect on whether to scale any bigger, or to look for some other way to scale?

A: There is some very good data from Startup Genome Project that captures such data points. While I think such guidance is very comprehensive and highly relevant for all startups, it must not be construed as universally applicable. Take the data as a guidance and question before committing any fixed expense item whether you really need it at this point? To me, it is not any different from how one would commit to such expenses in their home or even as a group manager in a company.

 

Customer Development model provides a framework to systematically validate all hypothesis before going out and scaling up the startup prematurely

I meet so many entrepreneurs who build a large team – VP of Sales, VP of Marketing and even 8-10 developers before they have built a serious product to market! If you follow Steve Blank, he is very unambiguous in his guidance – during customer discovery phase, it should only be the founder of the company to validate the ‘leap of faith’ hypotheses, and no one else! I also find that sometimes getting funding early in the day could make people scale-up prematurely and that’s just as bad.

Is there an alternative to scaling up? Yes, first off, build an MVP and keep your expenses low. A key thing about the MVP is that you must aim for selling the MVP as a means to validate your Business Model – freebies don’t give the proof point that you need to turn your hypothesis into facts. Once you have a reasonable confidence backed by solid data about customer validation, then you might be better-placed scaling up.

Q4. Could you talk a bit more about the Customer Development model proposed by Steve Blank and how you are going to extrapolate from this model in your talk?

A: Traditional startups, for example during dotcom, were known for the so-called ‘stealth mode’ development where they could work for an extended period of time, often away from public glare or any meaningful form of real-world customer feedback. However, we now know such a model is fraught is too many risks. It is the Hail Mary pass of entrepreneurship! On the other hand, Customer Development model is a highly scientific approach to entrepreneurship that recognizes the need to have real-world market data before going out and building the product. In today’s time and age, technology and consumer preferences change at warp-speed, and it is no longer realistic to build a product with a long-lead time. The worst thing that can happen is to build a product that no one wants! This might appear as poetic exaggeration, but the world is literally full of such experiments. Think of McDonalds Pizza or Colgate Breakfast Entrees or Frito-Lay’s lemonade or hundreds of such products – they were all created by highly successful companies that definitely knew what it took to built new products. And yet, they all failed. Why? Because essentially, they built something that the market didn’t need. Surely, they must have done market research throughout the lifecycle, but clearly they missed something much more fundamental – product development is not simply developing a nifty idea but also entails a parallel cycle of customer development, especially in new markets. Customer Development model is one such model that helps figure out what and how to do to do customer development – whether one is a true-blue startup or a brand-new idea in an established company.

Q5. New research by Harvard Business School’s Shikhar Ghosh shows that 75% of all start-ups fail. In your experience, generally what must the remaining 25% be doing right?

A: One thing we could be safely assured they are doing well is that they are listening to early feedback and adapting to it rather than going out and building the complete product or service based on untested hypothesis. And to be able to do such adaption both effectively and efficiently, they are using short iterations where they are able to give functional products in the hands of the customers so that they can get some valuable customer feedback. Popularly known as an MVP (or a Minimum Viable Product), it allows a high degree of prioritization of features from users point of view, and an agile development process that allows creating rapid iterations of high-quality and well-test features.

Q6. If I am part of a start up like organization, operating within a giant organization with its set business models and processes (that are also required to keep the big brother organization up and operational), how does one navigate the plethora of subsidiary business groups like facilities, infrastructure, HR, etc. to enable a lean start up mode for my particular group?

A: No easy answers here! In fact, history has repeatedly shown us that the more successful an organization is, the more it is difficult to get a radically new idea going. No wonder why Sony, the undisputed leader in Trinitron technology, completely missed the Plasma and LCD display bus (before eventually joining the LED display party, even if if a bit late) or the Internet leader Google who has never quite figured out its social strategy (well, some might argue that with Google+, they do have it, but that’s one point of view). So, traditional methods of pitching an idea and expecting the upper management to bless might work in theory, but I wouldn’t rely on them.

Over year, I have found one approach that perhaps works much better compared to anything else – skunkworks. If you are truly passionate about the idea, let that passion help you ‘recruit’ other co-creators (always remember – it takes a village to raise a child) and then put your spare cycles to build a prototype to demonstrate your idea. If you are not willing to take risks and spend days and weeks in even trying the idea, why should you expect that the management will give you budget for it? It’s like going to bank asking for money, whether to buy a house or to build a company – they want you to put down some money first in the form of your contribution or a guarantee, and the logic is same – if you are not willing to take any amount of risk behind your idea, why should others do it?

Java language came out of skunkworks at Sun. And so did the first Apple Macintosh. I have seen several good ideas come out like this in large companies, though I don’t think anyone can guarantee skunkwork projects. However, on a relative basis, it is much better demonstration of the power of your idea (compared to a powerpoint deck) and your passion that might improve your chances of getting the necessary organizational support to take your idea to its next leg of journey.

Q7. Finally when is it the right time for an organization to realize that it has grown too big to be in a startup mode anymore, and might need to revisit its way of working to adapt to its current size?

A: This might be the next million-dollar challenge and I wish I knew the cookbook answer! Unfortunately, we build the bureaucracy one day at at time and before we realize, we have built an impregnable wall of self-preservation that blunts any attack on status-quo. We don’t realize it because it is like slow-boiling the frog. Initially it looks innocuous and we tend to trivialize it, until one day it becomes so huge that we can’t get rid of it even when we try so hard!

I think an organization has stopped being a startup when people stop complaining and simply give up on you, when no one volunteers and there is generally a diffusion of responsibility, when people build territories and silos, when we are intolerant of failures and anything perceived disruptive, when people want to join because of the perks of the company rather than the challenges they can work on and the impact they can create, when more time is spent in waiting for decisions rather than learning from actions following implementing those decisions, and so on…

Q8. Who is the target audience for your talk? Only startup organizations?

A: Anyone who is undertaking a new endeavor under conditions of extreme uncertainty.

How Lean thinking improves productivity in software 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.

In the simplest form, we can call a process or an activity productive if it creates an output higher than its input. Though the input and output are often in two different and inequitable currencies, we are still mostly able to compare them. What that means at a conceptual level is that:

  • If Output < Input, we can say that the productivity is low
  • If Output > Input, we can say that the productuvuty is high
  • If rework is high, we can say that the productivity is low
  • If rework is low, we can say that the productivity is high 

These are highly generic views of productivity that most of us understand, but unfortunately they are not very usable to understand the factors that impact an output to become low, or the rework to become high. Developers might give one view, and testers might give another view as to why the output is low. There is no common vocabulary that can explain at a fundamental level what is it that is causing the productivity to dip. Context-specific variations (like differences in programming environment, percieved differences in complexities, developer competency, tester efficiency, etc.) might be too many to be usable to form any meaningful conclusions.

Lean thinking offers a more specific understanding into the wastes that typically make a process costlier (in terms of time or effort or both) than what it ought to be. Lean identifies seven types of wastes in a manufacturing setup. These wastes are known to introduce avoidable wastes, and Toyota pioneered a production system and an organizational culture that seeks to sysmetically eliminate root causes behind these wastes. Software practitioners, led by Mary and Tom Poppendieck, have investigated borrowing from Lean thinking into software development in last couple of years. Let’s examine how Lean encourages eliminations of following seven types of wastes in software development, and how they individually impact productivity of a team:

  1. Overproduction: Implementing a feature is an irreversible decision that takes lots of time and effort from the product engineering team, and delivery of a feature must wait until the next release cycle (whether the big-bang release in conventional software development, or the next real shippable release in agile development). If there are extra features in a software that remain unused because they are not of high priority but the engineering team is anyway spending effort to develop and test it, it is probably lowering the productivity of the team that could have used its effort elsewhere to develop other important features. The customer is also not benefiting from such overproduction of features, because he not only must wait for the desired features to be delivered, he must also pay the delivery team for those unimportant features that are not being used.
  2. Inventory: Anything that has not yet been delivered to the customer is work-in-progress (WIP) or inventory. The higher the inventory in a system, the higher is the number of resources locked-up and unavailable for any other activity. Even the work that has been completed but still sitting on the shelf is an inventory that is not creating any tangible value either to the team or the customer. If there are too many requirements yet to be implemented, it involves doing requirements analysis, design, development and testing without any of that effort being delivered to the customer, and hence increasing the work in progress and thus lowering the productivity at a business level. Even if a critical feature has beem completed, but it waiting simply because several other not-so-important features must be included alongwith in the next release, it is also adding to inventory because that important feature is not immediately delivered to the customer.
  3. Extra Processing: If the software is implemented in a complex manner that requires extra processing (e.g., a design that requires more storage, or duplicates data or code needlessly, etc.), it is either increasing the effort required to develop and test the software, or increasing the usability complexity, or both. Either ways, it is lowering the productivity. However, the opposite of extra processing is not smart programming, which might solve the problem in short run, but create maintenance problems in the long run.
  4. Motion: If the information is not readily available to the engineer, he/she has to spend unnecessary and avoidable time and effort that it takes to fetch the required information (which could anything – clarification about requirements, latest design specs, or locating the correct module from another team for integration, etc.), thus effectively lowering the productivity.
  5. Defects: Any defect that is passed on to the customers requires the engineering team to once again open up the code and spend effort to fix the problem. Since no new output is generated in this process, and the only output is fixing the functionality that should not have been broken in the first place, the net productivity over the entire product engineering lifecycle gets impacted adversely.
  6. Waiting: Perhaps no other project resource is as irrecoverable as lost time. Brooke’s Law reminds us how difficult, if not impossible, it is to recover delay from a project. Waiting for any resource for any reason creates unpredictability in software development apart from creating activities of zero or low output, which again reduces the productivity.
  7. Transportation: Handoffs are perhaps a Fordism legacy to the waterfall development where a team of business analysts would complete their work in isolation and handover the specs to dev team. Dev teams in turn would work in isolation and pass on the software to test team for testing, and so on. If all these teams are working in silos, such practice of working in isolation would often result in information distortion (or loss) down the stream, which could result in missed requirements, misunderstood requirements, unclear design, and so on. All these will eventually require extra (and unplanned) effort to implement the right functionality or fix the broken functionality, thus lowering net productivity over the entire engineering lifecycle.

 

As we can see, analyzing wastes in software development using the Lean thinking provides us a technology-independent and function-neutral view of the inefficiencies of the software process that can be used to achieve substantial improvements in productivity of the teams. None of these ‘attack’ an individual for lower productivity, and only look at the systemic deficiencies that must be eliminated for a team to perform at higher level.  However, of what possible business value would be the process of elimination of such wastes if we can’t picture ‘before’ and ‘after’ ? It is extremely important to assess the state before and after introducing a change – how else do we know if our efforts are yielding the desired results ? So, measuring the productivity in some absolute numbers is like the feedback whether an improvement is happening in the right direction (or not).

Lean thinking or not, do you measure productivity of your software teams? If yes, what for, and if not, why not?

What is a Lean Enterprise ?

 

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”.

The mechanism of the lean enterprise is also very simple: a conference of all the firms along the stream, assisted by technical staff from “lean functions” in the participating firms, to periodically conduct rapid analyses and then take fast-strike improvements actions. Clearly someone must be the leader, and this is logically the firm bringing all of the designs and components together into a complete product…However, the participants must treat each other as equals, with muda as the joint enemy.”

How does one create a Lean Enterprise ? How does that happen in a software organization ? Let’s explore this subject in the coming few weeks…


1. What is Lean, http://www.lean.org/WhatsLean/

2. Lean Thinking, Womack and Jones, pg 276

Toyota’s Wisdom for Tomorrow’s Managers

 

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.

It is this author’s firm belief that by merely adapting Toyota’s Lean Production System, one can’t transform a normal organization to a Lean Enterprise. Alongside the changes in process, one must pay adequate attention to adapting the mindset behind Lean culture as well. With that context, I have analyzed and interpreted some of the Toyota’s Traditions that are most relevant in context of tomorrow’s manager in this paper.

Stay tuned for updates on this.

This is the festival season, and kids have holidays. I am also off to a short holiday. Festival greetings, and enjoy the winter holidays. See you soon. 

What is the Inventory of your Software Development project ?

 

Traditional software development follows a quintessential Waterfall model. Among its many limitations, originally discussed by Winston Royce in his 1970 classic paper “Managing the Development of Large Software Systems” and many more thereafter, it also forces a build-up of ‘work-in progress’, or inventory of unfinished work that has not yet been delivered to the customer, and even if it has been presented to the customer, it doesn’t add value until the final working software has been delivered. I define ‘value’ here as originally defined by Womack and Jones in their classic ‘Lean Thinking’, “…The critical starting point for lean thinking is value. Value can only be defined by the ultimate customer. And it’s only meaningful when expressed in terms of a specific product (a good or a service, and often both at once), which meets the customer’s needs at a specific price at a specific time”.  

 

Agile software development, as originally envisaged in the Agile Manifesto, aims to address several of the challenges faced in a Waterfall-type of software development by working on shorter delivery cycles using only a subset of requirements at a time. This subset of requirements (“Sprint Backlog” in Scrum) is prioritized by the customer or customer’s representative (“Product Owner”), so at the end of this short delivery cycle (“Sprint”), the customer gets ‘potentially shippable software’ having exactly those features that add ‘value’ to her. Frequent delivery of working software also has an additional impact on reducing ‘inventory’ levels in a software project, however, Agile doesn’t specifically address how is improves it over traditional software development. We can use concepts from Lean manufacturing to understand and explain inventory build-up in a software development, and how Agile practices help us manage them better compared to the traditional software development practices.

 

Little’s Law states that inventory in a process is the multiplication of throughput and the flow-time. In traditional manufacturing, there is a strong emphasis on plant capacity utilization as a core driver in cost management. However, a high plant capacity utilization requires (or rather leads to) high inventory to ensure the production doesn’t slow down for want of raw materials. High inventory in turn leads to a low inventory turnover, signifying poor sales, thus having high economic implications. Inventory is also identified as one of the seven wastes in Lean. I have discussed the concept of inventory in a typical manufacturing process and how Little’s Law can be used to analyze mathematical relationship between inventory, manufacturing lead time and cycle time in my article “Applying Little’s Law to Agile Project Management – part 1”.

 

In software development, inventory can be thought of as the development costs that continue to be incurred while the development activities are underway. Only when a successful delivery has been made and accepted by the customer, the development team can realize its developments costs, and free-up the ‘inventory’. Until such time, this ‘inventory’ accumulates and remains locked-up.

 

In traditional software development, there is no concept of interim releases to the customer. Some teams might provision for a proof of concept or a prototype, but most often, they are only meant to work under ‘test conditions’, meaning they are not fit for deployment in real world. At best, they give a feel of what it likely to come out of the development lab at the end of a generally long development cycle. In that long cycle, it is possible that some requirements become obsolete, or get clubbed with some other requirements, or just get de-prioritized. In effect, a ‘BRUF’ approach often might end up the team with a software built to original specs, but unfortunately for them, the customer’s view of the world has changed while they were busy developing the software in isolation. So, the ‘effort’ that doesn’t add to ‘value’ also becomes part of an already bloated inventory of development costs. Mary and Tom Poppendieck have discussed the subject of ‘inventory’ in software development in great details in their seminal work on Lean Software Development. They have taken a much wider view of the inventory, while I have limited my discussion in this article only to the development costs.

 

When we use Agile practices, we work on a prioritized subset of requirements for each increment, and at the end of each such increment, we deliver a working software (not a prototype) to the customer. The customer is in immediate position to test-drive the delivery and come back what any necessary changes that could be incorporated in the very next increment. At the end of each such successful increment that delivers ‘value’ to the customer, it is possible for the development teams to realize their development costs, thereby resetting the inventory levels to zero before starting the next increment. I have discussed this scenario taking a near-real-life example in my featured paper “Applying Little’s Law to Agile Project Management – part 2”.

 

Conclusions

Agile software development is a radical approach to improve productivity in software development teams while improving the value delivered to the customer by using shorter delivery cycles (and a lot of engineering practices, though not discussed in this article). Using Agile practices, it is possible for the development organization to create ‘value’ for the customer and also manage its own inventory levels. This is true for ISVs, or services companies working for a customer. It is also equally applicable for start-ups that often work for a prolonged gestation period in a ‘stealth mode’ and their only performance metric during that phase being the notorious ‘cash burn rate’. In today’s tough economic times, virtually every firm is trying to reduce its cash cycles, and Agile software development just provides one more financial incentive by reducing the inventory and shortening the cash cycle. 

 

 

 

 

Is Scrum serving your Software Development, or the other way round ?

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.

I would take whatever is applicable and makes sense to MY business situation – which is a unique combination of:

  • my organizational maturity +
  • organizational culture +
  • type of problem being solved +
  • management style +
  • … +
  • another one hundred and one reasons that must be analyzed before prescribing a one-size-fit-all solution.

To that end, I will not stop at Scrum but explore other Agile methods, Six Sigma practices, Lean principles, Kaizen philosophy, TOC / Critical Chain..even borrow from CMM / CMMI and ISO…and…why not…the good old Waterfall (sometimes, the old wisdom is not so bad after all !)….just about anything under the sun that makes my business look better. In fact, for more complex problems, I might look up to other industries like construction, shipping, logistics, etc. to see how they solve such problems and learn from there. After all, my business is far more important than an academic satisfaction of having implemented a one hundred percent bookish definition of Scrum without knowing whether it is working for me or not, and completely depriving myself an opportunity to know if there are better ways to solve my problems.

Scrum doesn’t have the monopoly over good software development practices. If we all started blindly following Scrum in toto, there won’t be any better solutions to newer problems. There must be a healthy effort to question Scrum practices and make continuous improvements in it instead of treating it like holy scriptures which can’t be challenged.

My prescription for myScrum test would not to measure it by inputs (i.e., do you do 2 week or 4 week sprints, are your specification complete before the next iteration, etc.) but as follows:

  1. Are your new practices improving employee motivation ?
  2. Are your new practices improving team productivity ?
  3. Is frequent software delivery improving customer satisfaction ?
  4. Are you able to accommodate late requirements with increasing ease ?

I think if you can answer all of these questions in affirmative, you have a winner in your lap – doesn’t matter if it doesn’t measure up to the ‘stringent’ criteria of Nokia Test or some other activity-based assessment of your software development religion. You don’t even need to call it Agile or Scrum…just call it Photosynthesis, Metamorphism, Evolution, Oxidation…whatever you feel like…after all, your Scrum should serve your software development needs, rather than you serving Scrum.

Is Scrum serving your Software Development needs, or the other way round ?