Tag Archives: Scrum

How do you schedule tasks in a project?

How do you decide what tasks to schedule first: the complex ones or the easy ones? the short ones or the long ones? the risky ones or the sure-shot ones? Most often, this task sequence is determined by hard logic, soft logic, or some other external constraints. However, how do you decide when there are no such contraints?

If we look at the risk driving the project lifecycle and scheduling, then it is natural to expect high-risk tasks being tackled at the start just so that we are systematically driving down risks in the project and achieve higher certainty levels as we get close to the project. However, it seems inconceivable that someone will cherry-pick the easy tasks first and leave all high-risk ones for the end! Clearly, that is setting up the project for a grand finale of all sorts!

Project SchedulingCould complexity be a good measure then? What will happen if we take high complex tasks first? Surely, that will lead to tackling some of the most difficult problems first, and there might also be a high level of correlation between complexity and risk. So, taking this approach is also likely to significantly lower a project risks. However, not all tasks are created equal. It is likely that high-risk tasks not the longest, so while the project makes appreciable gains in lowering the risk, but doesn’t make a whole lot of progress.

Agile approaches, Scrum in particular, rely on driving the tasks that make biggest sense to the customer – tasks that deliver maximum value to the customer. However, there is no guarantee that this will help lower the project risks, or manage the schedule better. Similarly, Kanban helps manage tasks but doesn’t really spell out how they should be scheduled.

So, what is the best approach?

I read an interesting blog, The Art of the Self-Imposed Deadline, where I specially liked this one from the blog post:

3. Avoid the curse of the “final push.” Scope and sequence a project so that each part is shorter than the one that precedes it. Feeling the work units shrink as you go gives you a tangible sense of progress and speeds you toward the end. When you leave the long parts for last, you’re more likely to get worn out before you finish. Besides, if you’re “dead at the deadline,” those other projects you’re juggling will stagnate.

This seems like a very practical suggestion – often the tendancy is to ‘cherry pick’ while scheduling the tasks – we tend to pick up tasks that are favorite to people, or appear to be easier to take up. However, very often, we end up taking more time, and project gets delayed. If the tasks are scheduled such that big/complex tasks are scheduled first, that might mitigate lot of risk pertaining to last-minute issues (could be due to underestimation, or integration issues, etc.). However, I am not 100% sure that purely scheduling tasks on “longest-task first” basis is the best policy to lower risks in a project. Shouldn’t we be using a combination of top-risk items that are longest?

I haven’t used this approach yet, but seems like something to try. How about you – what’s your favorite way to schedule tasks?

Codifying Agile Skills or creating more checklists ?

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:

  1. Product: Agile teams must share a vision of what they are working to achieve; the business problem they are trying to solve.  When a developer understands the problem domain, they can help the Product Owner evaluate upcoming features.  Understanding of the product is the first step to creating a fully cross-functional team.

  2. Collaboration: Teamwork is the heart of Agile software development.  A truly collaborative team shares all its information freely.  They share their individual knowledge and skills by working closely with their teammates.  Teammates who fully rely on one another become much more effective as a whole, yet simultaneously increase individual skill levels.

  3. Business Value: The purpose of any software development effort is to create features that deliver business value.  A good Agile developer will focus on delivering that value.  They do not add complexity just to make their program ‘cooler’.  Instead they will base their work on business priority.  They produce a steady stream of running, tested software with real business value.  They will build only what is needed to solve today’s problem, knowing that building too little or too much is waste. 

  4. Supportive Culture: Any highly productive enterprise is founded in learning. Practitioners in an effective agile team view everything they do as an opportunity to learn. Every step is an experiment intended to make real progress, and to clear our vision of what to do next. We accept and embrace the fact that when a task is done, we’ll see better what we should have done. That helps us see what to do next.

  5. Confidence: Those on an Agile project strive to know the state of their code and the state of their project.  They do not share their work until they can prove it functions properly and is well designed and implemented.  They report progress based upon the actual rate at which fully tested features of real business value are being created.

  6. Technical Excellence: Developers understand, and choose from, many possible technical ways to satisfy business needs–choices that reflect a craft that balances design, use, and support.  They provide the technical underpinnings that enable us always to move forward at a steady pace.  They do this using principles of truly simple design, combined with a grasp of technical debt and the means to keep it under control. They use the best techniques for keeping the design under control without excessive work or rework.

  7. Self Improvement: An Agile team member seeks new ways of doing things, while keeping existing skills as sharp as possible.  They know that ours is an ever changing world and they strive to be prepared to take advantage of anything new.  They are both introspective and aware of what’s going on around them, be it in the team, or the larger business context. They will take action to fix things that aren’t right, and to help those who are in trouble. 

And the skill levels are:

  1. Learning: Individuals at this level have been exposed to a skill, but do not yet have firsthand experience with it.  This may come through reading or conversation, through a formal class or casual presentation at a local user’s group. A training course should provide at least this level of attainment.

  2. Practitioner: At this level, one has practiced the skill in a ‘safe’ environment.  They may have taken a course with hands-on exercises, or recreated the examples from a book.  The Novice level represents the first big step from abstract to concrete.  A wise organization will not let a Practitioner loose on their own.  They do not yet know what they do not know. They do not yet know what they do not know how to do. A training course with a sufficient hands-on component could provide this level of attainment.

  3. Journeyman: A Journeyman is known to possess the specific skill.  They have demonstrated a practical knowledge of the skill in various environments.  They can work on their own, or to increase the competence of a team.  A Team member of a lower skill level will learn from them, a team member of a higher skill level will recognize their expertise. One cannot be taught to be a Journeyman, one can only learn it.  Regardless of the skill category, maintaining Journeyman status, one must practice their current techniques and seek out new and better ones.

  4. Master: A Master must possess unquestioned competence in the particular skill.  They know it cold; it is second nature to them. But, it does not stop there.  To be accepted as a Master, they must also accept the additional job of bringing up the skill level of their team mates.  They do this in several ways. They serve as an example of proper practice.  If you want to know how it is done, observe a Master.  They partner with other team members and actively share their knowledge and experience. They seek out teachable moments.  When asked a question, they prefer to engage in a dialog that will lead the questioner to an answer, rather than making a pronouncement.

  5. Contributor: To be a Contributor, one must have added to our community’s understanding of how to practice our craft.   Contributors bring new ideas to light.  They develop and evaluate new techniques.  They are the silverbacks and young turks, who advance the state of the art.  They may be seen as today’s heretics.

I think this is a good effort to break-down the craft into little more tangible traits that developers need to acquire, thus making the body of knowledge available, one step at a time. Further, it is also refreshing to see things other than technical excellence being part of the Seven Pillars. I have long believed that Sociology should be part of the computer science curriculum now that software development is a serious team effort, and eventual success being largely influenced by human dynamics in the team than individual programming effort alone, howsoever supreme and important that might be.

However, all good things have a shelf life, and all good ideas become fertile grounds for next set of consulting and assessment industry to take-off (and Agile Skills Project makes no secret of its desire to support any effort to certify developers, even though they won’t officially endorse nor condemn any particular certification). I suspect it won’t be long before people will be certified on this (yet another!) 5-level scale of individual proficiency. Look at how successfully we have reduced Scrum to a series of checklist items in the so-called Nokia Test. Then there is this perpetual debate raging in the Agile / Scrum community on merits and demerits of certification, with everyone sort of nodding their heads that certification can’t guarantee competence, but even then everyone continues to offer some form of certification. I even suspect this might soon find its way into job descriptions. However, my bigger question is: will having a bunch of certified developers on your next Agile team ensure, or at least improve chances of success ? Are we unwittingly creating a class-hierarchy in Agile teams where developers will have to be of a certain class (or caste, if you like that way) to be part of the team ? How does one judge things like ‘Confidence’ or ‘Self Improvement’ ? Does high rating guarantee domain competence, or portability of skills? What is better in a 5-people team: 5 Masters, or 3 Masters and 2 Practitioners? Does someone at the skill level ‘Learning’ stand a chance to be in the team of ‘Contributors’ without adversely impacting the team productivity? Further, this is by no means an exhaustive checklist of critical success factors, and hence, chances are that people will fill up some checklists and declare themselves some 86% compliant (on some arbitrary and controversial scale) and their managers will expect the next project to be a resounding success. However, you and I know better than that :).

I think these are highly contentious issues that could further create more checklists and thus degenerate a good intent into a big mess.

The best way to use this tool will be to self-use it and set personal targets to acquire higher levels of competency as one goes by. Any effort to use this as a yardstick to measure and compare individuals is, IMHO, against the basic ethos of a human endeavor, let alone software development. So, shun the checklist-driven software development. 

Do you follow Project Management ‘religiously’ ?

Project Management is perhaps one of the most fiercely debated and grossly misunderstood disciplines in the software field currently, hence let me throw in a disclaimer first: if you are a small team of experts and/or people well-known to each other (e.g., have worked together as a team earlier), and situated in a collocated fashion, doing a lot of ‘creative work’ that can’t be very ‘accurately’ scoped, let alone managed; you probably will find ideas of formal project management a huge overkill (on time, effort, money and might even seem to stifle creativity), and you might be better off considering ‘lightweight’ methods like Agile Project Management / Scrum in the context of software development (well, nothing stops you from deploying pieces of Agile / Scrum in a non-software context – it is based on common sense after all). Small projects, small teams can afford to define a process that exploits the tailwind:

  • A small and collocated team means more direct interaction among team members and lesser management overheads in formalizing project communication (e.g., project status reporting, team meetings, etc.). This reduces the time it takes to collate, transmit and share important project information and also decreases the possibility of information distortion or confusion. A small team means there is high signal to noise ratio in team communications, is also leads to a better utilization of time spent in transmissing, receiving or digesting communication. Further, to schedule any event, one can always convene impromptu meetings around a whiteboard or around the coffee table without worrying about people’s already double-booked calendars or finding a place large enough to fit the team for the next meeting, and so on.
  • Having a group of experts means there is low(er) need for managerial supervision and people are generally ‘hand-picked’ for their knowledge, skills and abilities that could typically be ‘mutually exclusive, collectively exhaustive’. This ensures tight interdepency and very high mutual respect among team members. There is lesser ‘competition’ among team members and everyone knows that “united we stand, divided we fall” which fosters teambuilding.
  • For a small project, a large swing in any of the project constraints (time, cost, scope) could seriously and irretrievably impact the project in a downward spiral. If the work is new to the team, it could spell bigger trouble, especially if there is no way to do mid-course corrections. Executing projects in an iterative fashion helps shorten the feedback loop and give a chance to make necessary corrections to improve its ability to stay on-course and eventually hit the target. Additionally, if there is a customer involvement on these short iterations, the quality and value of these feedbacks could improve substantially lest any decisions are made that are hard to change if required.

However, if your project is anything more than a handful of people, takes more than a few months and entails issues like external dependencies with multiple vendors and ISVs (Independent Software Vendors), substantial technical and managerial risks, subcontracting / co-development, etc., you probably might improve chances of success using a formal project management methodology like PMBoK or PRINCE2 than without it. Agilists will argue and disagree with me that Agile / Scrum is not suited for large projects, but if you are new to Agile as well as to large projects, you might want to consider all options and associated risks – don’t believe in what worked for others, it might or might not work for you (remember the golden rule – we are all different), and your company might have a different set of constraints and tolerance to performance. 

The size, complexity, criticality, and risk profile of a project, and organizational appetite for project risk and uncertainty, and organizational culture would generally determine the level and need of management control required, and hence one must always right-size the project management methodology based on the context. Both, PMBoK / PRINCE2 and Agile methods evolved in response to challenges seen in executing projects successfully. While PMBoK / PRINCE2 took the approach that projects most often failed due to lack right levels of management oversight, planning, execution and control; Agillists felt the key reason was the fundamental nature of software being a ‘wicked problem‘ that just could not be managed using an obsolete waterfall model of developing software – it needed a better way to develop software in short iterations with very close-knit self-managed teams.

Without getting my loyalties needlessly divided betwen the two of these approaches, I believe there are merits in both the thoughts. I refuse to believe that any non-trivial project can be managed by piecemeal iterations that give no commitment whatsoever on the overall project performance, nor give any method to assess if the overall project is indeed on the right track (so, even if first few iterations are achieving the desired ‘veolcity’, what is the guarantee that subsequent iterations will also move at the same pace?). On the other hand, doing an iterative development is highly intiutive and very effective way to learn from past experiences to plan next steps, especilly on any non-routine project that is full of unknowns and assumptions. To me, these represent ‘mix-and-match’ ideas that one should pick up and apply wherever required, without getting baptized to the school of thought. I find most process wars have taken the disproportionate dimensions of falling just short of religious wars – you have to belong to one of the camps, and must talk evil about the other camp to be seen as a law-abiding corporate citizen of that camp. In life, we borrow ideas around us – our housing society, professional volunteer society we volunteer for, our kids playground, gardening, home improvement, nature, science, religion, other cultures…without necessarily converting to another faith or religion or society just because we like an idea that we want to borrow. So why should that be required in project management methods ???

I think this process war will be won by pragmatics. Those who take a position on extreme ends of the continuum and insist on always applying a particular style as the panacea might be in for a complete surprise because no two problems were created equal. A prudent approach is to evaluate all options and then decide which is the best response to a problem, as opposed to blindly follow a project management approach ‘religiously’.


Do you follow your project management aproach ‘religiously’ ?

Blame your “flaccid developers” and your “flaccid customers” for your poor quality products !

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.

The primary habits that hinder us are flaccid developers and flaccid customers who believe in magic, as in:

Unskilled developers – most developers working in a team are unable to build an increment of product within an iteration. They are unfamiliar with modern engineering and quality practices, and they don’t have an infrastructure supportive of these practices.

Ignorant customer – most customers are still used to throwing a book of  requirements over the wall to development and wait for the slips to start occurring, all the time adding the inevitable and unavoidable changes.

Belief in magic – most customers and managers still believe that if they want something badly enough and pressure developers enough to do it, that it will happen. They don’t understand that the pressure valve is quality and long term product sustainability and viability.

Have you seen these problems? Is your company “tailoring” Scrum to death? Let Ken respond to your issues and questions!

Ken will describe how Scrum addresses these problems and will give us a preview of plans for the future of the Scrum certification efforts.

Here are my observations and thoughts from this synopsis:

  • line 2: what does “when waterfall is no longer in place” mean ? So, when waterwall was still in place, there were no issues ??? Somehow, one gets a feeling all the problems came to light only when Waterfall was “no longer in place”…so, why not get waterfall back in its place 🙂
  • line 5-6: In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint ? …in every Sprint ?….now, wait a minute….I thought  Scrum project did not have any of these problems because there were no inadequate practices and tooling issues. And you certainly don’t expect to find such issues in every Sprint, or do you ?
  • line 7: OK, so now we have an official reason: “flaccid developers” and “flaccid customers” for all ills of the modern world. Wow! I am not sure if that is the best way to build trust either with teams or with customers by fingerpointing and squarely blaming them…without giving them a chance to even speak for themselves. And I thought Srcum was cool about trusting developers, not fixing blame on individuals, interacting with customers…but flacid developers and flaccid customer ??? Does it get any better than this ?
  • OK, I will probably agree ‘unskilled developers’ in the context of building an increment of product in an iteration, but what the hell is an ‘ignorant customer’ ? Try telling a customer that you are an ignorant customer…Scrum or no Scrum, you are guaranteed some unsurprising results ! And which Customer paying through his nose waits for the “slips to start occurring” ? In these tough economic times ?  
  • Is your company ‘tailoring’ Scrum to death ? I thought there were only two shades of Scrum – either you did Scrum-per-the-book or you did not. Since Scrum is the modern-day Peter Pan which refuses to grow up, we have only one version of Scrum to play around with, and unless some group of people decide now Scrum can grow to the next version (perhaps more because of commercial interests than anything else, whenever that happens). So, how can one ‘tailor’ Scrum – by any stretch of imagination, that is NOT Scrum. I mean, that is not allowed ! Right  ? So, why are we discussing it and wasting time – we might actually be acknowledging and unknowningly legitimizing that there is a secret world out there where Scrum can be ‘tailored’ and still be called Scrum ! That is sacrilege !

I always hate marketing messages that overpromise miracles, offer snake oil, belittle the intelligence of people, ridicule people…why can’t people simply stick to facts and figures ? Why don’t we talk in a non-intimidating language that encourages people to look up to what is being talked about ? And in the context of current subject, I doubt Scrum community is going down the right path if its next target is developers and customers. One of them does the work and the other one pays for it. Who gives us the right or the data to talk about any of them, in absentia ? Customers are customers, and even if they are irrational, they are still the customers, and whether paying or not, they alone are going to decide how they will behave. Yes, we might not like it, but is ridiculing them as ‘ignorant customers’ going to turn things into our favor ? Other industries like retail, hospitality, transportation, etc. have millions of years of collective experience in managing customers, yet they never break the singlemost cardinal rule of customer service: the customer is always right! And the first chance we software developers get to explain a poorly designed or a bad quality product and rightaway we blame the customers for it ! As if that is not enough, we then look inwards and blame the developers ! GREAT !

I think I will just develop software without blaming anyone else for my mistakes and limitations 🙂 

PRINCE2 handles Project Tolerances better

Most project management frameworks and methods advocate (and actually require) ‘point-estimates’ in planning and scheduling. By ‘point-estimates’, I mean there is a ‘hard number’ that seems to be etched in stone, leaving with no ‘tolerance’ or ‘leeway’ for the project manager and his team. Even though we all understand that estimates are never point-estimates (and hence the project commitments are never a point-commitment), we still expect a firm estimate (and consequently a firm commitment) from a project manager.

For example, a given feature must be required by 23-June, but there is no recognition of the fact that 23-June might still be a couple of months away, and several things could go wrong or could change meanwhile thus affecting the validity of this date. In real-life, there are always tolerances, some allowable, some acceptable, some tolerable and some simply unacceptable. This is not limited to schedule along, but also apply to cost, quality, scope, project benefits, etc. In some cases, the tolerances are defined, for example for the project scope, requirements might be prioritized as ‘M-S-C’ (or Most, Should and Could). In a previous organization I worked for, we had a great system for prioritizing all product requirements as ‘A’ (for current version), ‘B’ (implement if time is available) or ‘C’ (long-term requirement, but is being identified right now just so that designers and developers are available of how the system will evolve over time – so that, hopefully, they could build their designs futureproof). However, most product managers are unwilling to commit to such tolerances (or atleast unwilling to acknowledge existance of such scope tolarances), perhaps fearing that development team will straighaway prune down the list to bare minimum ones. Hence, in most organizations and projects, there seem to be two sets of commitments: one set is for the customer and one set is for the team. The one for team are the more stringent ones, but in the heart of the hearts, upper management knows that not all of them will be achievable and hence makes a little less stringent commitment (perhaps a more realistic one !) to the customer, thereby cushioning themselves against Murphy and the real-world. The project team slogs over months, often spending long nights and weekends alone in office just to try and meet the set of commitments that have been given to them, hardly ever realizing that there is another set of more realistic commitments that perhaps don’t acknowledge the cost of their commitment and efforts the team members are currently paying.

Agile methods, and Scrum in particular, take a major step forward and acknowledge that long-term plans are prone to later-day variations (and thus a waste of time and effort for all practical purposes) and hence favor short iterations to minimize the possibility of a project drifting or overcommiting itself to impossible deadlines due to such wild and optimistic estimates for long-range plans. But, it goes a little too far by simply accepting a world where no project tolerances are recognized, let alone identified for a project or its iterations. When a team member comes back and informs that he needs more time to complete a task than originally estimated, it simply makes suitable changes in the sprint burndown chart without placing an upper-boundary condition on how much off-estimation is permissible? As per the revised commitments, if the engineer is able to complete the task in the current sprint, well and good, but if for some reason, he is not able to complete, you simply push it out to the next sprint. It may not be necessarily bad, but definitely doesn’t place any upper-bound on the allowances available to a project team, and hence might not find good favor from upper management or product management in the long run.

PRINCE2 not only legitimizes the existance of tolerances at project level, it also allows a project to inherit a portion of those tolerances at stage plans and team plans at various stages thus giving a reasonable and mutually-agreed upon leeway to project manager and team managers to use those tolerances to manage the projects better (than, say, worrying about some 2-day delay that they can’t avoid or not able to meet a scope requirement because some peripheral feature can’t be met in given time). The mere act of legitimizing project tolerances creates a healthy understanding among all stakeholders that in real-world, there will be variations in future due to factors that might not be known or understood fully, or might simply change over time. A prudent project manager might not restrict himself to his current project management framework, and might want to look at what PRINCE2 has to offer in this regard.

How do you handle project tolerances ?

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, http://www.pmworldtoday.net/tips/2008/nov.htm#6

[4] Pharmaceutical Manufacturing: Cost, Staffing and Utilization Metrics, http://www3.best-in-class.com/bestp/domrep.nsf/Content/013881AE1866865385256DDA0056B517!OpenDocument

[6] Types of Wastes targeted by Lean, http://www.epa.gov/lean/thinking/types.htm

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 ?

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

Software Architecture Club: 10-Aug-08 / 2nd meet


We had the second meeting of SAC last Sunday, 10-Aug. This time, we had five attendees, and except for Venkatesh and Tathagat, the other three came for their first meeting: Venkat (Philips/NXP), Bhaskar (Software AG) and Rafi (Alcatel-Lucent). As there were new members, we diligently invested a good amount of time on coffee, socializing and digging out old connections 🙂

Venkat shared his perspective from the semiconductor world, and how the software on chip is not only leading to high complexity of software, but also demanding higher performance. Venkat and Tathagat shared experiences from a previous product they worked on together (Digital Set-top Boxes) and how incorrect / bad architecture choices led to significant challenges for the product performance.Rafi brought in the perspective of how the principles of architecture can be applied in the context of existing product – and given that most products continue to get evolved, enhanced and extended, it perhaps is a very valid discussion point for SAC. If any of the SAC member is interested to lead a discussion on this topic, it would be greatly welcome.

Venkatesh, Tathagat, Bhaskar and Venkat engrossed in a discussion

Venkatesh, Tathagat, Bhaskar and Venkat engrossed in a discussion

On one of the points regarding adoption of Agile methods, Tathagat mentioned he is re-reading Fred Brooks’ “The Mythical Man-Month” and Chapter 5 of that book is a very relevant discussion on ‘Aristocracy vs. Democracy’ of having an elite group of software architects. There has been a previous discussion on this in SAC, perhaps unfinished in some sense, that could be continued to explore this topic further and understand the various issues involved in it better. Not that we must conclude this topic one way or the other, but we might be able to explain the issue better given a much broader understanding of the issue. Venkatesh explained certain nuances about daily Scrum meeting, which led to interesting exchange of thoughts. He was promptly requested be the bridge between Agile community and SAC and keep enlightening us with more thoughts on this subject, including through his own blogs on this subject. Venkatesh also shared thoughts on ‘incremental architecture’ based on a workshop he had done for a group at Philips sometime back. Venkat mentioned that the concept was well received by the project team. 


Bhaskar making a point

Bhaskar making a point


Bhaskar brought the perspective of enterprise software, and the challenges thereof. Tathagat asked if Bhaskar would like to lead a discussion on this topic in one of the future sessions. Bhaskar to confirm. 

Venkat and Rafi listeing to Venkatesh (not in the picture) explaining the 'why' behing daily Scrum meetings

Venkat and Rafi listeing to Venkatesh (not in the picture) explaining the 'why' behind daily Scrum meetings



Rafi suggested we should share more web resources and reading list among member to help come at a good set of resources on the subject. I would request all members to contribute their efforts to come up with a good source of knowledge resources on this subject. It was also suggested to all members that Google groups allows a wiki-type functonality to create pages and edit / develop them collaboratively. Though it is not a full-blown wiki functionality, at this point it could still serve us well. For example, interest groups on Embedded, Web 2.0, Enterprise Software, etc. could be some themes, while topics such Reading List, Certifications, Adoption of Agile methods, etc. could be some of the global discussion threads that could continue. Tathagat renewed his request for shared ownership of the discussion threads on the forum to make it most effective. To that end, any member of SAC is most welcome (and encouraged) to start any of the discussion topics !

The next meeting is planned on 13-Sep (Sunday), 10am. Venue will be confirmed later. The idea is to start more focused technical discussions from the coming meeting onwards. All ideas are welcome. If you would like to lead a discussion, let us know ! 

PS: Photo quality is not so good, thanks to Blackberry, but at least that will put faces to some of the names.