Category Archives: Software Development

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,

2. Lean Thinking, Womack and Jones, pg 276

Some ‘universal truths’ of software development


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:

  1. Good methodologies  are never at crossroads
  2. “One size, fit all” doesn’t fit any size
  3. Every good thing has a shelf life – and everything was good once
  4. Good engineers and great teams make a bad reference point for future estimations
  5. There are no pre-conditions to performance – especially when you are a manager
  6. People don’t just want to make good software – they also want to build a career alongside
  7. Nothing is new – especially the outside world is far more evolved than we believe
  8. A poor workman blames his tools – and a fool with a tool is still a fool
  9. Software development is not the goal – solving the problem is always the goal
  10. All silver bullets are made of clay
  11. A shaky take-off is better than not starting at all
  12. Best engineers self-train
  13. Project planning is a misnomer – but do it anyway
  14. Leadership is just another name for the response to a stimuli – and hence nobody has a monopoly over it
  15. Not everyone constantly working overtime might be a project’s best friend
  16. Most crisis managers were responsible for that snafu in the first place
  17. Invest in rookies – they will surprise you and everyone else

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

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.

I once worked on a product in Digital Set-Top boxes that had teams in Belgium, Netherlands, India, Ireland and US and even though some might argue, thre was no way we could have done that project in a single location, and the major reason was not cost arbitrage alone. We all knew how difficult it would be to coordinate among so many locations, how difficult it would be to ensure that architectural integrity is maintained, interfaces stay consistent, and so on. Yes, that is real world. We were some 60+ engineers combined in all those locations. Could we go back to our company and tell, you know what, our software development process doesn’t support multisite work and we get cold sweat just thinking of what a nightmarish experience this would be – how about putting us all in a single location because that’s what we know ? Theoretically, one might do this, but I think the company has hired me not so that I could replay obvious excuses to them, but show my knowledge, skills and ability to manage complex problems like these. Precisely the reason I am in this job – if those real world problems were not there, would there be a justification for my role ? So, I would perhaps be better off doing as best a job as I can. The first thing that I might want to do is to acknowledge the real world.

That brings me to a very fundamental idea – what is real world ? is there a universal definition of real world, or is your real world different from mine ? is there a universal process that can heal all type of problems in the real world (whether there is only one real world, or multiple real worlds) ? why should we always think that a process must be macho enough to be able to solve all type of real world problems ? when no one man or woman can claim to know it all even in one domain, why is it that we want to project our process as Mr. Perfect Process that acts like a silver bullet for all types of targets ?

Which of the ‘real worlds’ does your software team live in – an ‘ideal real world’ or a ‘real real world’ ?

How Agile Practices address the Five Dysfunctions of a Team ?

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…

Read the full article here.

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



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. 





Applying Little’s Law to Agile Project Management – Part 2

Second part of my article on exploring how Little’s Law related to the Agile Project Management just got printed in PM World Today. Here is the abstract:

Little’s Law[1] states that inventory in a process is the multiplication of throughput and the flow-time[2]. In first paper[3] of this two-part series, we took an every-day example to discuss Little’s Law at length. We also briefly looked at the implications of Little’s Law for manufacturing and for software development. In traditional manufacturing, there is a strong emphasis on plant capacity utilization as a core driver in cost management[4]. 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[5], thus having high economic implications. Inventory is also identified as one of the seven wastes in Lean[6].

 Traditional software development has evolved from the days when requirements were fairly well crystallized, and the customer was willing to wait for the release while development teams went about developing the software and delivering only when everything was done. This often meant waiting for the working software for several months while development costs were accumulating. Today, thanks to a sleepless world of global competition, there is a business need to deliver software to the customer as early and as often as possible. Among other things, this also helps keep the development costs in check. This ‘development cost’ could be construed to as the ‘inventory’ in a software project, for it represents ‘work-in-progress’ just like the raw material represents locked-up capital in a manufacturing plant. However, there is neither a systematic concept nor consistent awareness of ‘inventory’ in software project management, and hence software development community has not benefited from the learnings from its more robust and more scientific cousin, the Lean Manufacturing. Agile software development has tried to solve similar set of problems from another perspective, at times even borrowing from the Lean concepts, but incidentally, there is a significant parallel between the two of them.


In this second part of this paper will explore in details how Little’s Law is not only conceptually akin to the Agile way of software development and project management, how well its mathematical principles could be used to understand and improve financial performance of a software project using Agile philosophy.


Read complete paper in English

[3] Applying Little’s Law to Agile Project Management, Part 1,

[4] Pharmaceutical Manufacturing: Cost, Staffing and Utilization Metrics,!OpenDocument

[6] Types of Wastes targeted by Lean,

Applying Little’s Law to Agile Project Management

My article by this title got published in PM World Today, Nov 2008 issue. Here is the abstract:

Little’s Law states that inventory in a process is the multiplication of throughput and the flow-time. While this seems intuitive, it helps us establish a mathematical relationship between basic factors that govern performance of a production process: arrival rate (or the flow-time or the cycle time), manufacturing lead time (or the throughput) and the inventory present in the system at any point of time (or the work in progress). The law has been found to hold good as long as these three parameters represent long-term averages of a stable system and they are measured in consistent units.

Little’s Law has its origins in manufacturing, but it also very relevant to a project manager in non-manufacturing setup. An in-depth understanding of Little’s Law will help a project manager to improvise on critical ideas in scheduling project activities to minimize the risk of schedule variance, improve accuracy of tracking and provide more usable status reporting.

In this first paper of the two-part series, we will explain what is Little’s Law using an example, and conclude with what it means for manufacturing and for software development. A second part of this paper will explore in details how Little’s Law is not only conceptually akin to the Agile way of managing project, how well its mathematical principles could be used to improve project management using Agile philosophy.

Read complete paper in English.

What is your Software Development Religion today ? And where does the Customer fit in that ?

The Swiss Army manual says: When the map and the terrain disagree, trust the terrain. However, in software industry, there seems to be an unending effort to make sure the terrain is retrofitted so that it looks much more like the map in hand ! So, I have modified the Swiss Army saying to suit the reality in the software development community as: When the real-life and bookish process definition differs, it clearly shows you have not understood the bookish definition, and hence you must change the real-life until it looks like the bookish definition and then trust the bookish definition.

Statutory Health Warning: Reading this blog post further could be bad for health, especially for those who love the process vocabulary more than the process intent, see the means more clearly than the ends and anyday favor the established processes of the day even to solve newer class of problems that clearly require fresh thinking lest they end up shaking the establishment. Author takes no material responsibility for anyone proceeeding from this point beyond and suffering serious health problems because of the radical views presented in this blog.

The conventional definition, popular understanding and state of practice of Software Quality is seriously flawed. They have created a very lopsided perspective that adherence to certain standards is Software Quality, howsoever hard- or soft-baked those standards be. On one hand of the rather colorful spectrum are the die-hard process zealots who won’t stop short of anything less than an ISO, CMMi or the likes and on the other end of the spectrum are the neo-rebels who believe anything Waterfall is bad and unless anything is Agilized, it ain’t good enough. On the innumerable discussion boards that I subscribe and listen to, completely petrified to speak up lest be asked my credentials to back up my anti-establishment views, I find more productive hours being lost on what should be the exact definition of a ‘product owner’, what should an ‘iteration zero’ be better known as, and whether you pass the Nokia test or not. I find the neo-rebels falling in the same honeytrap that they once so detested and fought tooth and nail – compliance over creativity. I see more mail threads getting fatter and longer because there are linguistic differences that probably should be settled so that practitioner’s camp can have peace after all, but where is the Customer in all this ?

We are probably forgetting that software came first, the generic notion of Quality came much earlier and everything else is only a recent model that some wise men and women have put together – and is likely to change with time. In fact, if that doesn’t change, there is something seriously wrong. So, there is a shelf life associated with Waterfall, and there is a shelf life associated with Agile as well ! Granted that Waterfall has had a rather long-tail that simple refuses to die (much to the chagrin of agilists), and so is Agile likely to have, but the fact remains if the software community stops innovating at and after Agile, it is not just bad enough for Agile – it is bad enough for the entire industry for the wheels of innovation and continuous improvement would have come to a grinding halt. 

I believe quality is not about how much the goods or services that a manufacturer or a service provider produces confirms to requirements. They are also not about whether it is achieved using Waterfall or Agile, whether CMM or ISO, whether done in-house or oursourced, or qualified using random testing or automated testing. Quite frankly speaking, I couldn’t care less if it was done by a bunch of social misfits or comforming cousins as long as I get what I want. But in all the noise and the alphabet soup of neo-processes, I think “what customer wants” isn’t audible much these days.

So, what really is quality. Well, to me, Quality is THAT differentiator in a product or a service that

  • makes me drive a few extra miles just so that I could buy or experience something I really like even when other, relatively cheaper options are available nearby. (=sarcifice time, effort and comfort to get something I value)
  • makes me choose one over other even when, everything else being rather equal, the one I choose might be costlier but not exorbitantly priced. (= availability of other altarnatives, freedom and ability to choose what I want)
  • makes me patiently wait in a line for my turn to come (=sacrificing my comfort to get something that I believe it worth it)
  • makes me pick up a product blindfold (=blind trust, but not trust blindly; reliable everytime)
  • I can recommend to my friends and family (=what is good enough for me is good enough for people I care)”

When I view quality from this perspective, it becomes very easy to substantiate what I said earlier – who cares what process was used, where the software was written, which language was used and what metrics were collected as long as I got what I wanted ? When one is willing to take a customer-centric view of software quality like this, the choice between Waterfall or Agile is only a matter of what class of problem we are trying to solve and what is the best-proven technique to address that situation. There are no permanent ideologies nor permanent religions – you must be flexible to choose what suits the problem at hand, rather than view it from a fixed-focus lens and try to ‘retrofit’ the problem to your software development religion.

So, what is your Software Development religion today ? and where does the Customer fit in that ?

PS: This post happened in response to a question on my favorite Q&A forum – LinkedIn.

Whatever I know about Scrum, I learnt from my sixth-grader son, and Scrum can too !

Scrum offers a fresh approach of software development. However, the philosophy itself is not entirely new. It has been around in various disciplines for quite some time, and it is only now that the software community has woken up to it. I found an everyday example of my sonss full academic year as a great way to explain Scrum to someone new to it.

My sixth-grader son (“Scrum team[1]) has a bag full of books (“Product Backlog”) that the teachers (“Product Owners”) must complete in the given academic year (“Project Schedule”). There are various subjects (you may call them sub-systems, component or modules if you like), and each subject has one or more books, each having several chapters (“Sprint Tasks”). To a great extent, the books don’t change in the middle of an academic year, though some of the factual contents could (for example, when his session started, Pluto was still the ninth planet of our solar system, but that changed a few months back !). The academic year works on a fixed-end-date planning and the holiday schedules are announced for the entire year in advance and the exact exam dates are announced using rolling-wave planning. To that end, there is a very well laid out plan for the entire year.

However, there are always unexpected changes that happen from time to time. Last month, my son got selected to represent his school at the city-level declamation contest. That meant him skipping some classes, and going out on a school on the competition day. He also had to skip an exam. However, all these “changes” were handled by the teachers with extreme professional finesse and personal touch, with him being given extra time to complete the classwork and homework, and letting him write the exam. I personally feel Scrum takes a rather rigid stance on accommodating in-cycle change requests because in real-life, there are always such unavoidable things that gatecrash and must be addressed in the same timeframe without de-prioritizing any of the existing commitments. In this particular case, could I have told my son to skip the declamation contest because his monthly unit tests were more important, or told the teachers that he be allowed to skip the exams ? I think Scrum 2.0 might address such real-world issues.

Some other known patterns of requirement changes include the scrum team (i.e., my son) getting overenthusiastic and volunteering for every second task like preparing for sports day, or annual day, or chart on Global Warming – essentially things that offer a lot of distraction from the core project activities, and take up lot of unplanned effort out of the sprint without really contributing to the tasks to be accomplished (“Sprint Goals”). This is real-life, and as we all know that when well-intentioned plans go haywire, Scrum or no Scrum, we must sit down and slog over the long evenings and weekends. In self-created situations like this he is getting used to his favorite quotation that I told him sometime back “Life is unfair, better get used to it[2].

Instead of an annual exam alone as the only and final way to assess his learning, the teachers give him and other students monthly (“4-Week Sprint”) unit tests (“Sprint Backlog”) and in the final annual exams, test the entire knowledge (“Product Regression Testing”). So, there are a set of chapters that become part of the sprint backlog in each sprint, and get tested towards the end of every sprint, which are, of course, the monthly unit tests. The schedule of monthly unit tests can’t move (“Fixed-Duration Sprints”) – so, if the given chapter (an item from the sprint backlog) is not complete, the teacher will skip that and put on the top of the next sprint backlog. Some months have more holidays, some have less, and some have school annual functions and other events, so the sprint backlog (and consequently the “Velocity”) is adapted based on net usable time available in a month (“Product Backlog Item Effort”), but the sprint is always four-weekly.

The child comes home every month (for that matter, every week if not every other day) with new knowledge and skills that he can directly apply in real-life (talk about “shippable software”).

At the end of every month, evaluated test papers are sent to parents (the “Scrum Masters”) for review. If the performance is not good, they go have a discussion with the teacher on their child’s performance (“Sprint Retrospective Meeting”), and some of those improvement items become input for next evaluation cycle (“Product Backlog Item”).

Every six-months (so, there are two in an academic year: a mid-point and the second as an year-end), there is a comprehensive assessment of child’s overall academic, extra-curricular and social performance. The class teacher prepares this based on evaluated and observed feedback from other teachers for every child and sends to parents. Not sure what is the scrumology for that would be, but the one closest is “Sprint Retrospective Meeting”.

Daily schedule involves checking classwork and homework, both in class with the teacher (“Product owner”) and with the parent (“Scrum Master”) and various issues related to performance and progress are discussed (“Impediments”). There is a special class of scrum masters in this model, known as “mothers” who always seem to have the right burn-down chart in their minds whether the child agrees with it or not. The daily meetings are quite “standup meetings” by themselves especially when Sprint Goals are not being achieved, if you know what I mean 🙂

PS: Towards completing this article, my son came over, read the contents, asked what Scrum was, but approved the article. But he was not very happy that his contributions were not acknowledged anywhere in the article. So, I hereby thank my wonderful son Chanakya Varma, soon to be eleven this October, for his efforts and a lovely and tough time he gives to my wife and I. Son, you are a great example of how a Sprint Team should behave, especially during tough times, one of them definitely being asking your Mom to help you out.

[1] Purists might disagree with the definition of one boy as a scrum team, but those who have been parent of a sixth-grader will know it better !

[2] Quote by Bill Gates