The Digité Fountainhead

Scrum --> Kanban = Scrumban or Kanban? Lessons at Lean Coffee

noreply@blogger.com (Mahesh Singh) — Fri, 25 May 2012 20:26:00 +0000

At Digité/ Swift-Kanban, we had a great visit to the LeanSSC (now Lean Systems Society) last week in Boston. Having been in the market for just about a year, it is heartening to be recognized and even be told that we are considered one of the top 2-3 Kanban tools that are out there.

An exciting part of the conference was our announcement of our support for Scrumban (or Scrum features) besides our support for both iOS and Android tablets. Those who came to the booth and saw a demo really loved our embedded support for release/ iteration planning, time capture, burn-down/ burn-up charts and all of the other new features we demonstrated during the show. Someone from a competitor’s booth next to us in fact said we were pretty much the first Scrumban tool in the market, a possibility we had considered and talked about, although somewhat hesitantly!

The labeling of Scrumban was a matter of some discussion – both at the booth but more interestingly at the Monday (or Tuesday) morning Lean Coffee session organized by Jim Benson, where I posed the question – Scrum --> Kanban = Scrumban or Kanban? In other words, when a Scrum team uses Kanban to improve their processes, is the end-result that they begin using a combination of Scrum and Kanban (Scrumban) or do they essentially start using just Kanban for software development? Luckily for me, this question got the most votes and ended up being discussed for quite some time.

There were some great people at the table besides Jim - Jason Montague, Jabe Bloom, Alexei Zheglov and Joe Campbell amongst others and multiple opinions emerged around the table. Most people felt that it would really depend on the team. The more mature the team, the greater likelihood that they would be able to get away from the “constraints” of Scrum such as using the time-box – and thus just be using a Kanban process. By implication, the less mature or less ‘self-organized’ teams would continue to use the time-box within the overall framework of Kanban. Thus they would be using a Scrumban process.

A second perspective was that most teams might use Scrumban as a transition phase before moving over completely to Kanban, giving up the time-box and to a more continuous delivery model. (I should clarify that while the time-box was the main feature of Scrum being discussed, other aspects of the difference between Scrum and Kanban were also discussed.)

Finally, someone who joined towards the second half of the discussion added a third perspective – that if the purpose of Kanban was to help you improve what you are already doing, it is perfectly possible to believe that they may come out of that experience with a “better Scrum process”!

An added point that I wanted to get everyone’s vote on was whether Scrumban was a valid term that described either a transition or a longer lasting phase of a team using both Scrum and Kanban. Most people around the table agreed that it was a valid phrase to use. All in all, it was a great discussion and a learning experience – and I look forward to reactions from other prospects and customers of Swift-Kanban for further validation or repudiation of the premise!

Looking forward to the LSS13 in Chicago in April, 2013!

Mahesh Singh

Co-founder/Sr. VP - Product

Kanban – Evolutionary or Revolutionary?!

noreply@blogger.com (Mahesh Singh) — Fri, 04 May 2012 00:49:00 +0000

One of the key benefits that David Anderson, the renowned Kanban thought-leader and father of the Kanban Method for software development (as well as Advisor to Digité) highlights about Kanban is that it is evolutionary and not revolutionary. That is to say, it does not introduce a humongous new set of processes in an organization and cause massive disruption like traditional methods have tended to do.

There is no question that Kanban does not introduce a “big bang” new set of processes and rigor in an organization, with a whole new set of procedures to be learnt, guidelines to be followed, new documents/ deliverables to be created to show compliance. In fact Kanban needs an existing process or methodology so that Kanban can be applied to improve that process! In itself, Kanban is not a software development or project management methodology, as David clearly points out.

However, going by our own experience as well as that of many of our customers Kanban does introduce several small changes that can be considered revolutionary! These changes – while not difficult to understand – might be considered extremely challenging – downright revolutionary! - to get used to and implement in a way that truly brings out the essence of Kanban and enable teams and organizations to reap the real benefits of Kanban.

Can you Pull?

While it is easy for everyone to understand the concept of Pull, I suspect it may not be understood just how hard it may be to implement and practice. Most organizations are used to a somewhat hierarchical/ directive approach to deciding who works on what in any given situation. Be it software project tasks or normal business function activities, managers are all too used to ‘telling’ their subordinates what to do – and for their part, employees are far too used to be ‘assigned’ work. We live in a classic Push world. In a significant – majority? – fraction of workplaces, employees bemoan the manner in which they are assigned work (after all why is Dlibert so popular?!), yet, left on their own, employees will look to managers to help them decide what work they should do next. In a ‘good workplace environment”, managers will regularly sit down with subordinates to understand what work they can be given or can take on, before assigning work. This probably comes closest to being Pull.

Kanban turns the whole thing on its head – and asks people to “Pull” work – assign it to themselves – ONLY when they have bandwidth to work, actively discouraging multi-tasking. I can just see middle- and senior-management gasp in horror at the implications of this. Not only can they not “TELL” their subordinates on what to work on next, they can’t even tell them to do 3 things at the same time! Subordinates, on the other hand, must face their own demons. “How do I decide what to do? I am paid to work that I am told to! Someone better tell me quick!” Even in knowledge industries, especially in top-down, hierarchy-conscious societies or where a lot of young (immature) people are part of the workforce, team members may be reluctant to exercise sufficient independence and free thought in order to grasp the new power they have in their hands with “Pull”.

Having come to and settled in the US from a not-so-long-ago-socialist India, I believe this may not be as much of a problem for Western/ American managers/ employees (although Dilbert is an American creation!), who have long been used to having plenty of choice in almost every aspect of life – and being able to ‘pull’ from a set of choices, as it would be people in developing/ socialist countries long used to government/ public sector driven choices – be it for automobiles (Ambassador or Fiat?) or toothpaste (Colgate or Binaca?) or jobs (Doctor or Engineer?). However, that is perhaps a topic for another blog post!

Pull, if not revolutionary, is definitely a huge mind-set change – and needs all the support it can get from the management and the teams to make it work. Management must encourage teams to take the necessary decisions to pull work. Team members must step up the challenges and the responsibility of standing by their Pull decisions. This, I suspect, takes some getting used to – and for Pull to start working in the Kanban sense of the word.

Thinking out of the (Time) Box

Everyone loves goals, objectives, deliverables and deadlines. “Tell me what I need to do and by when, and then watch me do it!” Financial Years and Quarter, Project milestones, Phase-Gates, Releases, Iterations, Sprints – time-boxes all. Then along comes Kanban and says one word – “Cadence”! Can you imagine the frenzy this must create in the minds of people trying to grasp this simple, yet elegant, concept?

Some of the common concerns I have heard -

“How can I understand what my team is doing, if they don’t tell me what they will deliver by when?!” Managers’ own ability to drive their teams without the 2 crucial crutches - scope and time-box – is severely impacted. Managers must go through a tremendous reorientation to understand that even though the planning mechanism that a release or sprint or a project deadline provided, through the use of cadence and other mechanisms, they can still plan for significant events in their business, yet relieve pressure from teams and actually get them to perform better!
“Unless my current iteration is complete, I do not want my team to look at work in the next iteration!” The need to control what the team members are doing to the extent of not letting them get an early start on the next set of work may be rare, but it is there!
“As a product company, how can I show my customers my product and release roadmap, if we don’t have defined iterations and releases?”

The mindset change required to get past this type of thinking requires enlightening everyone up and down the chain, including customers! But the benefits are there for all to see. At Digité, we have been able to do it for ourselves as well as for our customers – and in the process winning high praise for our responsiveness and speed of doing great product features.

How can I let go of my capability to W(H)IP?

We have all thrived on the ability to multi-task. We have all touted the ability to do so. We have exhorted our colleagues, especially our subordinates, to “just handle” stuff thrown their way. And at great cost – in terms of quality of work, time taken to complete it and in sheer dollar cost. And yet a vast majority of teams and managers continue to practice it. Kanban changes all that. It beings into sharp focus why multi-tasking is not good for the individual or the team and that limiting the amount of work being done at a time actually improves throughput and quality.

In many organizations, it just kills managers to get used to actually limiting the amount of work their subordinates will do at a time – and to prioritize the work for them so they can do so effectively! It actually forces the managers to face the reality that their teams cannot handle all the work dumped on them, and it can be a shocking experience to learn that by limiting WIP, their teams may actually produce more, better! But to get to that stage requires them to believe, to take the plunge and over a period of 3-6 months actually get to observe that. It is not easy because it is so – revolutionary!

I hate to say this – but I am stuck!

A picture is worth a thousand words – we have all known that. A chart or a report communicates the status of a project better than a detailed text report – we get that too. But Kanban make our work visual in a very different way. It not only helps you communicate how work is to be done, where it is at any point in time, where are the bottlenecks – and finally what (and who) might be stuck or blocked!

As technical people, we thrive on complexity and challenge. We love to solve problems – without asking for help. We hate to give bad news to our team members, our bosses, our customers! Kanban says – ditch that – and tell EVERYONE as soon as possible that you are stuck – and your work is blocked! In the most visual way! Not only that, by doing so – you are also doing the unthinkable – you are asking the entire team to swarm and help you get unstuck!

Yet suddenly, Kanban is helping us communicate to business stakeholders or customers that there are problems. But work is progressing. And is getting delivered. In line with the priority that they set!

So, yes, Kanban is evolutionary. It does not bring about disruptive process changes that many processes and frameworks have done in the past. Yet, with due apologies to and full credit to David, it is revolutionary as it strikes at fundamental management and organizational principles, turns things upside down – and makes for a more transparent, more open, more able to experiment type of an organization that is far more prepared to succeed in today’s business environment.

Like I concluded at the talk I gave at Agile India 2012 conference in Bangalore earlier this year, I believe Kanban is evolutionary in the right places and revolutionary in the right places!

Mahesh Singh

Co-founder/ Sr. VP - Product

Digite, Inc.

Lean Software Development

noreply@blogger.com (Ravish Patel) — Wed, 28 Mar 2012 05:18:00 +0000

Originally published on: http://msdn.microsoft.com/en-us/library/hh533841(v=vs.110).aspx

David Anderson describes Lean Software Development as follows:

Introduction
Lean and Agile
Lean Beyond Agile
Defining Lean Software Development
Values
Principles
Practices

The term Lean Software Development was first coined as the title for a conference organized by the ESPRIT initiative of the European Union, in Stuttgart Germany, October 1992. Independently, the following year, Robert “Bob” Charette in 1993 suggested the concept of “Lean Software Development” as part of his work exploring better ways of managing risk in software projects. The term “Lean” dates to 1991, suggested by James Womack, Daniel Jones, and Daniel Roos, in their book The Machine That Changed the World: The Story of Lean Production[3] as the English language term to describe the management approach used at Toyota. The idea that Lean might be applicable in software development was established very early, only 1 to 2 years after the term was first used in association with trends in manufacturing processes and industrial engineering.

In their 2nd book, published in 1995, Womack and Jones[4] defined five core pillars of Lean Thinking. These were:

Value
Value Stream
Flow
Pull
Perfection

This became the default working definition for Lean over most of the next decade. The pursuit of perfection, it was suggested, was achieved by eliminating waste. While there were 5 pillars, it was the 5th one, pursuit of perfection through the systemic identification of wasteful activities and their elimination, that really resonated with a wide audience. Lean became almost exclusively associated with the practice of elimination of waste through the late 1990s and the early part of the 21st Century.

The Womack and Jones definition for Lean is not shared universally. The principles of management at Toyota are far more subtle. The single word “waste” in English is described more richly with three Japanese terms:

Muda – literally meaning “waste” but implying non-value-added activity
Mura – meaning “unevenness” and interpreted as “variability in flow”
Muri – meaning “overburdening” or “unreasonableness”

Perfection is pursued through the reduction of non-value-added activity but also through the smoothing of flow and the elimination of overburdening. In addition, the Toyota approach was based in a foundational respect for people and heavily influenced by the teachings of 20th century quality assurance and statistical process control experts such as W. Edwards Deming.

Unfortunately, there are almost as many definitions for Lean as there are authors on the subject.

Lean and Agile

Bob Charette was invited but unable to attend the 2001 meeting at Snowbird, Utah, where the Manifesto for Agile Software Development[5] was authored. Despite missing this historic meeting, Lean Software Development was considered as one of several Agile approaches to software development. Jim Highsmith dedicated a chapter of his 2002 book[6] to an interview with Bob about the topic. Later, Mary & Tom Poppendieck went on to author a series of 3[7,8,9] books. During the first few years of the 21st Century, Lean principles were used to explain why Agile methods were better. Lean explained that Agile methods contained little “waste” and hence produced a better economic outcome. Lean principles were used as a “permission giver” to adopt Agile methods.

Lean Beyond Agile

In recent years, Lean Software Development has really emerged as its own discipline related to, but not specifically a subset of the Agile movement. This evolution started with the synthesis of ideas from Lean Product Development and the work of Donald G. Reinertsen[10,11] and ideas emerging from the non-Agile world of large scale system engineering and the writing of James Sutton and Peter Middleton[12]. I also synthesized the work of Eli Goldratt and W. Edwards Deming and developed a focus on flow rather than waste reduction[13]. At the behest of Reinertsen around 2005, I introduced the use of kanban systems that limit work-in-progress and “pull” new work only when the system is ready to process it. Alan Shalloway added his thoughts on Lean software development in his 2009 book on the topic[14]. Since 2007, the emergence of Lean as a new force in the progress of the software development profession has been focused on improving flow, managing risk, and improving (management) decision making. Kanban has become a major enabler for Lean initiatives in IT-related work. It appears that a focus on flow, rather than a focus on waste elimination, is proving a better catalyst for continuous improvement within knowledge work activities such as software development.

Defining Lean Software Development

Defining Lean Software Development is challenging because there is no specific Lean Software Development method or process. Lean is not an equivalent of Personal Software Process, V-Model, Spiral Model, EVO, Feature-Driven Development, Extreme Programming, Scrum, or Test-Driven Development. A software development lifecycle process or a project management process could be said to be “lean” if it was observed to be aligned with the values of the Lean Software Development movement and the principles of Lean Software Development. So those anticipating a simple recipe that can be followed and named Lean Software Development will be disappointed. You must fashion or tailor your own software development process by understanding Lean principles and adopting the core values of Lean.

There are several schools of thought within Lean Software Development. The largest, and arguably leading, school is the Lean Software & Systems Consortium, which includes Donald Reinertsen, Jim Sutton, Alan Shalloway, Bob Charette, and David J. Anderson. Mary and Tom Poppendieck’s work stands separately, as does the work of Craig Larman, Bas Vodde[15,16], and, most recently, Jim Coplien[17]. This article seeks to be broadly representative of the Lean Software & Systems Consortium viewpoint and to provide a synthesis and summary of their ideas.

Values

The Lean Software & Systems Consortium published its values and principles at the 2011 Lean Software & Systems Conference[18]. It lists the following values:

Accept the human condition
Accept that complexity & uncertainty are natural to knowledge work
Work towards a better Economic Outcome
While enabling a better Sociological Outcome
Seek, embrace & question ideas from a wide range of disciplines
A values-based community enhances the speed & depth of positive change

Accept the Human Condition

Knowledge work such as software development is undertaken by human beings. We humans are inherently complex and, while logical thinkers, we are also led by our emotions and some inherent animalistic traits that can’t reasonably be overcome. Our psychology and neuro-psychology must be taken into account when designing systems or processes within which we work. Our social behavior must also be accommodated. Humans are inherently emotional, social, and tribal, and our behavior changes with fatigue and stress. Successful processes will be those that embrace and accommodate the human condition rather than those that try to deny it and assume logical, machine-like behavior.

Accept that Complexity & Uncertainty are Natural to Knowledge Work

The behavior of customers and markets are unpredictable. The flow of work through a process and a collection of workers is unpredictable. Defects and required rework are unpredictable. There is inherent chance or seemingly random behavior at many levels within software development. The purpose, goals, and scope of projects tend to change while they are being delivered. Some of this uncertainty and variability, though initially unknown, is knowable in the sense that it can be studied and quantified and its risks managed, but some variability is unknowable in advance and cannot be adequately anticipated. As a result, systems of Lean Software Development must be able to react to unfolding events, and the system must be able to adapt to changing circumstances. Hence any Lean Software Development process must exist within a framework that permits adaptation (of the process) to unfolding events.

Work towards a better Economic Outcome

Human activities such as Lean Software Development should be focused on producing a better economic outcome. Capitalism is acceptable when it contributes both to the value of the business and the benefit of the customer. Investors and owners of businesses deserve a return on investment. Employees and workers deserve a fair rate of pay for a fair effort in performing the work. Customers deserve a good product or service that delivers on its promised benefits in exchange for a fair price paid. Better economic outcomes will involve delivery of more value to the customer, at lower cost, while managing the capital deployed by the investors or owners in the most effective way possible.

Enable a better Sociological Outcome

Better economic outcomes should not be delivered at the expense of those performing the work. Creating a workplace that respects people by accepting the human condition and provides systems of work that respect the psychological and sociological nature of people is essential. Creating a great place to do great work is a core value of the Lean Software Development community.

Principles

The Lean Software & Systems community seems to agree on a few principles that underpin Lean Software Development processes.

Follow a Systems Thinking & Design Approach
Emergent Outcomes can be Influenced by Architecting the Context of a Complex Adaptive System
Respect People (as part of the system)
Use the Scientific Method (to drive improvements)
Encourage Leadership
Generate Visibility (into work, workflow, and system operation)
Reduce Flow Time
Reduce Waste to Improve Efficiency

Follow a Systems Thinking & Design Approach

This is often referred to in Lean literature as “optimize the whole,” which implies that it is the output from the entire system (or process) that we desire to optimize, and we shouldn’t mistakenly optimize parts in the hope that it will magically optimize the whole. Most practitioners believe the corollary to be true, that optimizing parts (local optimization) will lead to a suboptimal outcome.

A Lean Systems Thinking and Design Approach requires that we consider the demands on the system made by external stakeholders, such as customers, and the desired outcome required by those stakeholders. We must study the nature of demand and compare it with the capability of our system to deliver. Demand will include so-called “value demand,” for which customers are willing to pay, and “failure demand,” which is typically rework or additional demand caused by a failure in the supply of value demand. Failure demand often takes two forms: rework on previously delivered value demand and additional services or support due to a failure in supplying value demand. In software development, failure demand is typically requests for bug fixes and requests to a customer care or help desk function.

A systems design approach requires that we also follow the Plan-Do-Study-Act (PDSA) approach to process design and improvement. W. Edwards Deming used the words “study” and “capability” to imply that we study the natural philosophy of our system’s behavior. This system consists of our software development process and all the people operating it. It will have an observable behavior in terms of lead time, quality, quantity of features or functions delivered (referred to in Agile literature as “velocity”), and so forth. These metrics will exhibit variability and, by studying the mean and spread of variation, we can develop an understanding of our capability. If this is mismatched with the demand and customer expectations, then the system will need to be redesigned to close the gap.

Deming also taught that capability is 95% influenced by system design, and only 5% is contributed by the performance of individuals. In other words, we can respect people by not blaming them for a gap in capability compared to demand and by redesigning the system to enable them to be successful.

To understand system design, we must have a scientific understanding of the dynamics of system capability and how it might be affected. Models are developed to predict the dynamics of the system. While there are many possible models, several popular ones are in common usage: the understanding of economic costs; so-called transaction and coordination costs that relate to production of customer-valued products or services; the Theory of Constraints – the understanding of bottlenecks; and The Theory of Profound Knowledge – the study and recognition of variability as either common to the system design or special and external to the system design.

Emergent Outcomes can be Influenced by Architecting the Context for a Complex Adaptive System

Complex systems have starting conditions and simple rules that, when run iteratively, produce an emergent outcome. Emergent outcomes are difficult or impossible to predict given the starting conditions. The computer science experiment “The Game of Life” is an example of a complex system. A complex adaptive system has within it some self-awareness and an internal method of reflection that enables it to consider how well its current set of rules is enabling it to achieve a desired outcome. The complex adaptive system may then choose to adapt itself – to change its simple rules – to close the gap between the current outcome and the desired outcome. The Game of Life adapted such that the rules could be re-written during play would be a complex adaptive system.

In software development processes, the “simple rules” of complex adaptive systems are the policies that make up the process definition. The core principle here is based in the belief that developing software products and services is not a deterministic activity, and hence a defined process that cannot adapt itself will not be an adequate response to unforeseeable events. Hence, the process designed as part of our system thinking and design approach must be adaptable. It adapts through the modification of the policies of which it is made.

The Kanban approach to Lean Software Development utilizes this concept by treating the policies of the kanban pull system as the “simple rules,” and the starting conditions are that work and workflow is visualized, that flow is managed using an understanding of system dynamics, and that the organization uses a scientific approach to understanding, proposing, and implementing process improvements.

Respect People

The Lean community adopts Peter Drucker’s definition of knowledge work that states that workers are knowledge workers if they are more knowledgeable about the work they perform than their bosses. This creates the implication that workers are best placed to make decisions about how to perform work and how to modify processes to improve how work is performed. So the voice of the worker should be respected. Workers should be empowered to self-organize to complete work and achieve desired outcomes. They should also be empowered to suggest and implement process improvement opportunities or “kaizen events” as they are referred to in Lean literature. Making process policies explicit so that workers are aware of the rules that constrain them is another way of respecting them. Clearly defined rules encourage self-organization by removing fear and the need for courage. Respecting people by empowering them and giving them a set of explicitly declared policies holds true with the core value of respecting the human condition.

Use the Scientific Method

Seek to use models to understand the dynamics of how work is done and how the system of Lean Software Development is operating. Observe and study the system and its capability, and then develop and apply models for predicting its behavior. Collect quantitative data in your studies, and use that data to understand how the system is performing and to predict how it might change when the process is changed.

The Lean Software & Systems community uses statistical methods such as statistical process control charts and spectral analysis histograms of raw data for lead time and velocity to understand system capability. They also use models such as: the Theory of Constraints to understand bottlenecks; The System of Profound Knowledge to understand variation that is internal to the system design versus that which is externally influenced; and an analysis of economic costs in the form of tasks performed to merely coordinate, set up, deliver, or clean up after customer-valued product or services are created. Some other models are coming into use, such as Real Option Theory, which seeks to apply financial option theory from financial risk management to real-world decision making.

The scientific method suggests: we study; we postulate an outcome based on a model; we perturb the system based on that prediction; and we observe again to see if the perturbation produced the results the model predicted. If it doesn’t, then we check our data and reconsider whether our model is accurate. Using models to drive process improvements moves it to a scientific activity and elevates it from a superstitious activity based on intuition.

Encourage Leadership

Leadership and management are not the same. Management is the activity of designing processes, creating, modifying, and deleting policy, making strategic and operational decisions, gathering resources, providing finance and facilities, and communicating information about context such as strategy, goals, and desired outcomes. Leadership is about vision, strategy, tactics, courage, innovation, judgment, advocacy, and many more attributes. Leadership can and should come from anyone within an organization. Small acts of leadership from workers will create a cascade of improvements that will deliver the changes needed to create a Lean Software Development process.

Generate Visibility

Knowledge work is invisible. If you can’t see something, it is (almost) impossible to manage it. It is necessary to generate visibility into the work being undertaken and the flow of that work through a network of individuals, skills, and departments until it is complete. It is necessary to create visibility into the process design by finding ways of visualizing the flow of the process and by making the policies of the process explicit for everyone to see and consider. When all of these things are visible, then the use of the scientific method is possible, and conversations about potential improvements can be collaborative and objective. Collaborative process improvement is almost impossible if work and workflow are invisible and if process policies are not explicit.

Reduce Flow Time

The software development profession and the academics who study software engineering have traditionally focused on measuring time spent working on an activity. The Lean Software Development community has discovered that it might be more useful to measure the actual elapsed calendar time something takes to be processed. This is typically referred to as Cycle Time and is usually qualified by the boundaries of the activities performed. For example, Cycle Time through Analysis to Ready for Deployment would measure the total elapsed time for a work item, such as a user story, to be analyzed, designed, developed, tested in several ways, and queued ready for deployment to a production environment.

Focusing on the time work takes to flow through the process is important in several ways. Longer cycle times have been shown to correlate with a non-linear growth in bug rates. Hence shorter cycle times lead to higher quality. This is counter-intuitive as it seems ridiculous that bugs could be inserted in code while it is queuing and no human is actually touching it. Traditionally, the software engineering profession and academics who study it have ignored this idle time. However, empirical evidence suggests that cycle time is important to initial quality.

Alan Shalloway has also talked about the concept of “induced work.” His observation is that a lag in performing a task can lead to that task taking a lot more effort than it may have done. For example, a bug found and fixed immediately may only take 20 minutes to fix, but if that bug is triaged, is queued and then waits for several days or weeks to be fixed, it may involve several or many hours to make the fix. Hence, the cycle time delay has “induced” additional work. As this work is avoidable, in Lean terms, it must be seen as “waste.”

The third reason for focusing on cycle time is a business related reason. Every feature, function, or user story has a value. That value may be uncertain but, nevertheless, there is a value. The value may vary over time. The concept of value varying over time can be expressed economically as a market payoff function. When the market payoff function for a work item is understood, even if the function exhibits a spread of values to model uncertainty, it is possible to evaluate a “cost of delay.” The cost of delay allows us to put a value on reducing cycle time.

With some work items, the market payoff function does not start until a known date in the future. For example, a feature designed to be used during the 4th of July holiday in the United States has no value prior to that date. Shortening cycle time and being capable of predicting cycle time with some certainty is still useful in such an example. Ideally, we want to start the work so that the feature is delivered “just in time” when it is needed and not significantly prior to the desired date, nor late, as late delivery incurs a cost of delay. Just-in-time delivery ensures that optimal use was made of available resources. Early delivery implies that we might have worked on something else and have, by implication, incurred an opportunity cost of delay.

As a result of these three reasons, Lean Software Development seeks to minimize flow time and to record data that enables predictions about flow time. The objective is to minimize failure demand from bugs, waste from over-burdening due to delay in fixing bugs, and to maximize value delivered by avoiding both cost of delay and opportunity cost of delay.

Reduce Waste to Improve Efficiency

For every valued-added activity, there are setup, cleanup and delivery activities that are necessary but do not add value in their own right. For example, a project iteration that develops an increment of working software requires planning (a setup activity), an environment and perhaps a code branch in version control (collectively known as configuration management and also a setup activity), a release plan and performing the actual release (a delivery activity), a demonstration to the customer (a delivery activity), and perhaps an environment teardown or reconfiguration (a cleanup activity.) In economic terms, the setup, cleanup, and delivery activities are transaction costs on performing the value-added work. These costs (or overheads) are considered waste in Lean.

Any form of communication overhead can be considered waste. Meetings to determine project status and to schedule or assign work to team members would be considered a coordination cost in economic language. All coordination costs are waste in Lean thinking. Lean software development methods seek to eliminate or reduce coordination costs through the use of colocation of team members, short face-to-face meetings such as standups, and visual controls such as card walls.

The third common form of waste in Lean Software Development is failure demand. Failure demand is a burden on the system of software development. Failure demand is typically rework or new forms of work generated as a side-effect of poor quality. The most typical forms of failure demand in software development are bugs, production defects, and customer support activities driven out of a failure to use the software as intended. The percentage of work-in-progress that is failure demand is often referred to as Failure Load. The percentage of value-adding work against failure demand is a measure of the efficiency of the system.

The percentage of value-added work against the total work, including all the non-value adding transaction and coordination costs, determines the level of efficiency. A system with no transaction and coordination costs and no failure load would be considered 100% efficient.

Traditionally, Western management science has taught that efficiency can be improved by increasing the batch size of work. Typically, transaction and coordination costs are fixed or rise only slightly with an increase in batch size. As a result, large batches of work are more efficient. This concept is known as "economy of scale." However, in knowledge work problems, coordination costs tend to rise non-linearly with batch size, while transaction costs can often exhibit a linear growth. As a result, the traditional 20th Century approach to efficiency is not appropriate for knowledge work problems like software development.

It is better to focus on reducing the overheads while keeping batch sizes small in order to improve efficiency. Hence, the Lean way to be efficient is to reduce waste. Lean software development methods focus on fast, cheap, and quick planning methods; low communication overhead; and effective low overhead coordination mechanisms, such as visual controls in kanban systems. They also encourage automated testing and automated deployment to reduce the transaction costs of delivery. Modern tools for minimizing the costs of environment setup and teardown, such as modern version control systems and use of virtualization, also help to improve efficiency of small batches of software development.

Practices

Lean Software Development does not prescribe practices. It is more important to demonstrate that actual process definitions are aligned with the principles and values. However, a number of practices are being commonly adopted. This section provides a brief overview of some of these.
Cumulative Flow Diagrams

Cumulative Flow Diagrams have been a standard part of reporting in Team Foundation Server since 2005. Cumulative flow diagrams plot an area graph of cumulative work items in each state of a workflow. They are rich in information and can be used to derive the mean cycle time between steps in a process as well as the throughput rate (or “velocity”). Different software development lifecycle processes produce different visual signatures on cumulative flow diagrams. Practitioners can learn to recognize patterns of dysfunction in the process displayed in the area graph. A truly Lean process will show evenly distributed areas of color, smoothly rising at a steady pace. The picture will appear smooth without jagged steps or visible blocks of color.

In their most basic form, cumulative flow diagrams are used to visualize the quantity of work-in-progress at any given step in the work item lifecycle. This can be used to detect bottlenecks and observe the effects of “mura” (variability in flow).

Visual Controls

In addition to the use of cumulative flow diagrams, Lean Software Development teams use physical boards, or projections of electronic visualization systems, to visualize work and observe its flow. Such visualizations help team members observe work-in-progress accumulating and enable them to see bottlenecks and the effects of “mura.” Visual controls also enable team members to self-organize to pick work and collaborate together without planning or specific management direction or intervention. These visual controls are often referred to as “card walls” or sometimes (incorrectly) as “kanban boards.”

Virtual Kanban Systems

A kanban system is a practice adopted from Lean manufacturing. It uses a system of physical cards to limit the quantity of work-in-progress at any given stage in the workflow. Such work-in-progress limited systems create a “pull” where new work is started only when there are free kanban indicating that new work can be “pulled” into a particular state and work can progress on it.

In Lean Software Development, the kanban are virtual and often tracked by setting a maximum number for a given step in the workflow of a work item type. In some implementations, electronic systems keep track of the virtual kanban and provide a signal when new work can be started. The signal can be visual or in the form of an alert such as an email.

Virtual kanban systems are often combined with visual controls to provide a visual virtual kanban system representing the workflow of one or several work item types. Such systems are often referred to as “kanban boards” or “electronic kanban systems.” A visual virtual kanban system is available as a plug-in for Team Foundation Server, called Visual WIP[19]. This project was developed as open source by Hakan Forss in Sweden.

Small Batch Sizes / Single-piece Flow

Lean Software Development requires that work is either undertaken in small batches, often referred to as “iterations” or “increments,” or that work items flow independently, referred to as “single-piece flow.” Single-piece flow requires a sophisticated configuration management strategy to enable completed work to be delivered while incomplete work is not released accidentally. This is typically achieved using branching strategies in the version control system. A small batch of work would typically be considered a batch that can be undertaken by a small team of 8 people or less in under 2 weeks.

Small batches and single-piece flow require frequent interaction with business owners to replenish the backlog or queue or work. They also require a capability to release frequently. To enable frequent interaction with business people and frequent delivery, it is necessary to shrink the transaction and coordination costs of both activities. A common way to achieve this is the use of automation.

Automation

Lean Software Development expects a high level of automation to economically enable single-piece flow and to encourage high quality and the reduction of failure demand. The use of automated testing, automated deployment, and software factories to automate the deployment of design patterns and creation of repetitive low variability sections of source code will all be commonplace in Lean Software Development processes.

Kaizen Events

In Lean literature, the term kaizen means “continuous improvement” and a kaizen event is the act of making a change to a process or tool that hopefully results in an improvement.

Lean Software Development processes use several different activities to generate kaizen events. These are listed here. Each of these activities is designed to stimulate a conversation about problems that adversely affect capability and, consequently, ability to deliver against demand. The essence of kaizen in knowledge work is that we must provoke conversations about problems across groups of people from different teams and with different skills.

Daily standup meetings

Teams of software developers, often up to 50, typically meet in front of a visual control system such as a whiteboard displaying a visualization of their work-in-progress. They discuss the dynamics of flow and factors affecting the flow of work. Particular focus is made to externally blocked work and work delayed due to bugs. Problems with the process often become evident over a series of standup meetings. The result is that a smaller group may remain after the meeting to discuss the problem and propose a solution or process change. A kaizen event will follow. These spontaneous meetings are often referred to as spontaneous quality circles in older literature. Such spontaneous meetings are at the heart of a truly kaizen culture. Managers will encourage the emergence of kaizen events after daily standup meetings in order to drive adoption of Lean within their organization.

Retrospectives

Project teams may schedule regular meetings to reflect on recent performance. These are often done after specific project deliverables are complete or after time-boxed increments of development known as iterations or sprints in Agile software development.

Retrospectives typically use an anecdotal approach to reflection by asking questions like “what went well?”, “what would we do differently?”, and “what should we stop doing?”

Retrospectives typically produce a backlog of suggestions for kaizen events. The team may then prioritize some of these for implementation.

Operations Reviews

An operations review is typically larger than a retrospective and includes representatives from a whole value stream. It is common for as many as 12 departments to present objective, quantitative data that show the demand they received and reflect their capability to deliver against the demand. Operations reviews are typically held monthly. The key differences between an operations review and a retrospective is that operations reviews span a wider set of functions, typically span a portfolio of projects and other initiatives, and use objective, quantitative data. Retrospectives, in comparison, tend to be scoped to a single project; involve just a few teams such as analysis, development, and test; and are generally anecdotal in nature.

An operations review will provoke discussions about the dynamics affecting performance between teams. Perhaps one team generates failure demand that is processed by another team? Perhaps that failure demand is disruptive and causes the second team to miss their commitments and fail to deliver against expectations? An operations review provides an opportunity to discuss such issues and propose changes. Operations reviews typically produce a small backlog of potential kaizen events that can be prioritized and scheduled for future implementation.

There is no such thing as a single Lean Software Development process. A process could be said to be Lean if it is clearly aligned with the values and principles of Lean Software Development. Lean Software Development does not prescribe any practices, but some activities have become common. Lean organizations seek to encourage kaizen through visualization of workflow and work-in-progress and through an understanding of the dynamics of flow and the factors (such as bottlenecks, non-instant availability, variability, and waste) that affect it. Process improvements are suggested and justified as ways to reduce sources of variability, eliminate waste, improve flow, or improve value delivery or risk management. As such, Lean Software Development processes will always be evolving and uniquely tailored to the organization within which they evolve. It will not be natural to simply copy a process definition from one organization to another and expect it to work in a different context. It will also be unlikely that returning to an organization after a few weeks or months to find the process in use to be the same as was observed earlier. It will always be evolving.

The organization using a Lean software development process could be said to be Lean if it exhibited only small amounts of waste in all three forms (“mura,” “muri,” and “muda”) and could be shown to be optimizing the delivery of value through effective management of risk. The pursuit of perfection in Lean is always a journey. There is no destination. True Lean organizations are always seeking further improvement.

Lean Software Development is still an emerging field, and we can expect it to continue to evolve over the next decade.

Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003
Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010
Womack, James P., Daniel T. Jones and Daniel Roos, The Machine That Changed the World: The Story of Lean Production, 2007 updated edition, Free Press, 2007
Womack, James P., and Daniel T. Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2nd Edition, Free Press, 2003
Beck, Kent et al, The Manifesto for Agile Software Development, 2001 http://www.agilemanifesto.org/
Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002
Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003
Poppendieck, Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006
Poppendieck, Mary and Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009
Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997
Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009
Sutton, James and Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers, Productivity Press, 2005
Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003
Shalloway, Alan, and Guy Beaver and James R. Trott, Lean-Agile Software Development: Achieving Enterprise Agility, Addison Wesley, 2009
Larman, Craig and Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008
Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison Wesley Professional, 2010
Coplien, James O. and Gertrud Bjornvig, Lean Architecture: for Agile Software Development, Wiley, 2010
http://www.leanssc.org/2011/05/leanssc-vision-values-and-mission-1-0beta/
http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs

-- David Anderson

Originally published on: http://msdn.microsoft.com/en-us/library/hh533841(v=vs.110).aspx

Effort Tracking with Kanban

noreply@blogger.com (Mahesh Singh) — Wed, 08 Feb 2012 18:33:00 +0000

Software development using Kanban principles has not focused on Effort Tracking (though there hasn’t been a strong position against the same). At Digité, we were practitioners of Iterative Software Development. As part of this process, we emphasized on Daily Effort Tracking (time filing) for several reasons: A) Since we have geographically distributed teams, it helped us get a sense of what happened without chasing individual team members or asking people to send an email with their update. B) A lot of effort based metrics could be accurately computed and relied upon (especially if you have come from the ISO/CMMI world!). For example, we knew how much time was spent in product work (enhancements) vs unproductive work (rework) and see if the trend was in the right direction. We knew how much time was required for essential tasks that were not functionality accretive, like, performance tuning, stack upgrades, etc. The list can go on…

We adopted Kanban about 18 monthsback but continued with this practice. We tweaked it a bit to: A) Dedicate 2-3 minutes every day on filing time before signing off for the day (we strongly discourage Weekly Time filing) B) Use the previous day’s timesheet report as the basis to cover what was done the previous day across the team (no memory jogging required) in the Daily Status Call. It takes less than 3-5 minutes to discuss this for a team of 10. The rest of the daily call is focused on discussing what will be done today, team goals and specific issues.

One common criticism is the accuracy of such data that can be used for further analysis. However, once the team realizes that people are discussing and looking at this data daily, the accuracy and seriousness creeps in without any follow-up or persuasion.

Kanban focuses on cycle time and throughput (and associated metrics like wait time/ blocked time/ etc.). However, combining actual effort data with cycle time helps get the following additional benefits:

a) Compute the actual effort to complete work of different kinds – defects, user stories of different size (S, M, L, XL, XXL), etc. A sample of our data is below:

b) Publish variance between estimated effort and actual effort to help the participants of the estimation process ee-baseline their “gut-feel” benchmark. We estimate using Planning Poker and hence, the above input helps making future estimates more accurate. As you can see from the sample snapshot below, some of the estimates are quite “off” the actual.

c) Improve throughput – Combining the estimated effort with actual data on past effort for similar cards, you can get a better idea of how many parallel threads one should split the card into so that the cycle time can be reduced. For example, if a new user story is estimated as a XL size, and the team’s Planning Poker estimate is 30hrs, we know that this is against our past trend. Past trend tells us 55 hrs. So, either our estimation bucket is wrong or we are missing something in our “gut” estimate.If this suggests re-estimation and the revised estimate is 50hrs and our desired cycle time is less than a week, we know we must break it into 2 smaller scope (size) cards.

d) It also helps estimate how much time we need to reserve for “other” work buckets – leave/ paid time off, training, engineering tasks like performance, refactoring, etc. and budget for that. A sample data snapshot is enclosed for our team:

This means that at an aggregate level, for our team, close to 50% of the capacity can be earmarked for product enhancements (user stories). However, going by the trend of the last quarter, we can budget close to 70% for the same!

e) Understand if the amount of effort spent on “rework” (Internal Defects + Customer Defects) is improving or deteriorating (thereby pointing towards the need for training, resource upgrades, etc.).

In short, without any significant additional effort or being intrusive, one is able to collect additional data points for better planning and forecasting. These data points are very helpful in aggregate planning and forecasting (beyond what is on the board today or in the backlog).

Sudipta (Sudi) Lahiri
Sr. VP - Engineering and Professional Services

Using Swift-Kanban for customer portfolio management

noreply@blogger.com (Masa K Maeda) — Mon, 23 Jan 2012 18:44:00 +0000

My business focuses on lean-agile coaching, consulting and training, not on software development services, and I successfully use Kanban to manage my customer portfolio.

It is untrue that Kanban is only good for software change management work. Many people new to Kanban have this misconception mainly for two reasons. One is because Kanban started in a change management team at Microsoft. The other one is because David J Anderson declared that Kanban is a method for change management in the organization and that statement can be misinterpreted. What David meant with that is Kanban helps you bring positive change to your organization. Although the original Kanban description is around software it is actually context free. There is a very popular book entitled Personal Kanban by Jim Benson that I invite you to consult.

Getting back to the main subject of this blog. I have been using Kanban for years to manage customer-facing and business-facing activities. The customer facing activities Kanban board has one swim lane per customer for easy visualization of the activities with each customer and to avoid making mistakes on which customer a given activity is for. Each customer has its own backlog, which we make visual as the first column on the board. The other columns are Ready, Execute (doing/done), Customer verification, and Completed columns. The WIPs for each customer are different and in agreement with the customer needs and my resources. The figure shows our Swift Kanban board for one of the countries where we conduct business. In addition to making remote communication easier, a huge advantage we have with Swift Kanban is that it allows us to resort the lanes up and down to indicate level of priority and activity (we used the smart lanes feature to accomplish this). That is, a lane (a customer) bubbles up if the our level of activity with that customer and its priority increases and bubbles down if the activity/priority decreases. That way if we will not be doing any work with a customer for a while its lane is "out of the way"; and it is still readily available to resurface at a moment's notice. We also count with a swim lane called "other" for general work that has to do with potential customers when the relationship hasn't matured yet to the point of earning a dedicated lane.

Our classes of service are

Business task
Business appointment
Business partner / associate task
Fixed delivery date
Immediate

Intangible tasks are business-facing and are, therefore, on a separate board.
Cheers,
Masa K Maeda

Kanban and the Focus on Fundamentals

noreply@blogger.com (Mahesh Singh) — Tue, 27 Sep 2011 23:17:00 +0000

(Previously published in the DJ Anderson Associates sponsored eBook - Quotable Kanban)
Our Kanban journey began early in 2010 when we decided that we would build a product in the Kanban space that would address some of the basic issues we saw our prospects face in adoption of Agile methods such as Scrum and XP within their organizations that were historically used to doing waterfall or iterative or some hybrid Agile method that combined more than one type of processes.

While the presence of established competitors was a strong reason to look beyond the ‘popular’ Agile methods, we also felt a strong appeal for Kanban existed because of its focus on 3 key fundamentals:

Evolutionary change
Improvement of existing processes
Engineeringrather than Management processes

We have seen numerous organizations and teams take on large (revolutionary) process improvement initiatives – be it 6-Sigma or CMMi or even Agile. We have seen them become consumed with “the task of process improvement” over and over again. As a result, while there is improvement in the interim, in terms of consistency with which a process is followed in the team or the organization, the overall magnitude in terms of the time, effort and cost, of making the transition becomes huge and management begins to question the benefits! Kanban, with its promise of evolutionary change, with one stroke, takes care of this fundamental issue. It allows teams to take on only those aspects of change that they can comfortably handle.

Secondly, with an evolutionary approach, Kanban necessarily tackles current processes in an organization and helps improve them, rather than force a range of new processes on it. This is fundamental to understanding how Kanban can be applied not just to traditional software processes – but also to popular Agile processes such as Scrum and indeed, to non-software processes – bet they within IT or in general business functions such as Sales or Marketing or Legal! So besides being attractive to software teams, their pull for non-software teams, presented us with a much bigger opportunity, which we are already starting to see materialize!

However, the one aspect of Kanban that excites more than others is that it forces teams to focus on the “engineering” or the “delivery” processes rather than the “management” processes. This is where, I feel, Kanban truly distinguishes itself from its ‘competitors’, if one may terms them as that. Through the use of statistical control charts, Kanban helps teams identify their normal performance and their deviations from the normal – the outliers. Rather than advise teams to simply do better documentation or better management or better reviews, it encourages teams to do better root-cause analysis – and attack root causes for poor performance – be that better or more specific testing, better development or design practices or better collaboration and requirements elicitation from customers. And in doing so, I believe Kanban shows itself to be far more effective than any other framework to start making incremental, lasting improvements in the final quality of the product or service being delivered.

Far too often, after initial gains have been realized through ‘traditional’ Process Improvement initiatives, teams start to question the extra overhead of ‘following process’ and wonder ‘what is in it for them’. With Kanban, these teams are much more likely to realize lasting gains through evolutionary, (incremental) improvements to basic existing delivery/ engineering processes and measuring their own performance in a much more meaningful manner.

Mahesh Singh

Co-founder, Sr. VP – Product

Scrum Bangalore - Scrum, Kanban and Pecha-Kucha!

noreply@blogger.com (Nitin Ramrakhyani) — Sat, 11 Jun 2011 04:13:00 +0000

I recently participated in a local Scrum event in Bangalore and shared my experience in trying to implement Scrum and later Scrumban within my current organization. I have shared the slides below.

The event was hosted by SAP in their campus and had a keynote speaker who shared the information about Lean/ Scrum implementation @ SAP and how they are trying to transform the entire organization to a newer or “lean” way of software development.

It’s great to see such enterprises adapting to this new wave of software development. It will encourage a lot of other companies to try out such methodologies and share their experiences/ learning. The event had more than 40 participants from various companies like Mindtree, Aricent, SAP, Cisco etc.

There was an interactive talk from David Putman, a UK based consultant, and Srikanth Tadipatri. Both are currently helping the Tesco India team to move to agile development and they shared their experiences on various topics/ issues related to scrum implementation.

The other 4 presentations, including mine, were in a "Pecha-Kucha" format ( a Japanese style, where a concept is presented in 6 mins, 20 slides, auto-timed for 20 seconds) themed around 'Scrum: Success Stories'.

My talk was about our experience so far in implementing Scrumban – a combination of Scrum and Kanban and how it is helping us to work more effectively. It is hard to summarize the experience of over 2 years in 6 minutes (Pecha-kucha style is supposed to save people from 'Death by Powerpoint' ;)), but I hope I was able to put my points across.

Here's a link to my presentation, do check it out and feel free to contact and we can discuss in detail.

Participating in LSSC11: Lean on the Rise

noreply@blogger.com (Nitin Ramrakhyani) — Thu, 02 Jun 2011 03:52:00 +0000

Digite participated in the recently completed LSSC11 (Lean Software & Systems Conference 2011), an event focussed on Lean Software Development, in beautiful Long Beach, California.

It was a great experience for me. The conference had a varied set of topics from Lead development, Kanban, CMMi (1 day), Risk Management, Systems Design, Kanban games etc. It was amazing to see this level of change, innovation and creativity in the Lean community and adoption in the industry. Companies and individuals are continually making effort to apply new and improved techniques and tools to the way they have been working and bring about greater productivity, quality and efficiency.

Digite is proud and privileged to help lead this change! Since we were one of the sponsors and had a booth at the conference, I couldn't attend all the sessions I wanted to, but that was a small price to pay for being there! Sessions were organized in three parallel tracks, and almost all of them were simply great, so there was no way but to miss out on many of them!

A quick summary of my Learnings/ observations from the conference:

All the keynotes in the conference were simply fantastic. I specially liked the Keynote by Chet Richards on 'Fundamental Secrets of the Universe'. He shared many anecdotes from his Marines background and spoke about John Boyd and his OODA loop, which are very interesting and has a lot of applicability to the software world.
Another great talk as by Joshua Kerievsky on Sufficient Design. I liked his observations on 5.x Development death cycle, explaining the state of many products, which become almost dead (with very heavy technical debt/ defects) by the time their 5.x versions come out. And how the "Resume-based development' attitude from the technical folks make one choose heavy design, even for simple requirements. His guidance - one should make design choices based on multiple criteria and most of the time, a "Sufficient" design is good enough to go, than doing very complex design.
I also loved the talk by Inbar Oren on “Who’s Afraid of the Big Bad Wall – Visual Management and Gemba Walks”. He talked about the impact of visualization and how Kanban boards almost replace the need for any manager to get an immediate status, without participating in a daily standups. Here's a link to his blog with slides.
The talk by Don Reinertsen on Cost Of Delay was also great. It is a very powerful concept and can be applied to all situations. While not always easy to quantify, it is a great way to prioritize all work!
Frode Odegard’s presentation on “Beyond Lean Value Streams: A Systems Approach" was another good one.
There was also a Tools track where many tool vendors (including Digite) showcased their Lean/ Kanban tools. It was interesting to see alot of innovation happening in this area. We got some good response, as well as feedback for our Kanban tool - Swift Kanban (www.swift-kanban.com).
There was also a Games track where attendees could play the Kanban game developed by Russel Healy. It's a great game for understanding the Kanban basics.
Here are a couple of other blogs/ links related to the experience @ LSSC11. They are definitely worth checking out to see what's happening in the world of Lean/ Kanban :-)

Overall, it was a fantastic experience for us. We got to meet some great people including industry thought-leaders, our own customers and prospects, all in one place. Lean/ Kanban is definitely emerging as a powerful mechanism to scale Agile at the enterprise level and to help organizations dramatically improve how they work.

Nitin Ramrakhyani,

Sr. Product Manager, Digite, Inc.

Agility Redefined

noreply@blogger.com (Sudi) — Mon, 30 May 2011 05:42:00 +0000

There is an enormous amount of discussion and literature (in the Software/ Application Development circles?) about different processes (or methodologies), their pros and cons, their challenges, etc. While these articles are right in their own way, in most cases, they preach adoption and acceptance of one process. However, the fact is that rarely does a “one size fits all” approach work for anything – why would software be any different?

Interestingly, most software/ IT organizations are also trying to adopt one methodology across the organization. They bring “gurus” who espouse that process, run training programs and campaigns and try to mould the entire organization in one direction. They try to bring in common practices (positioned as best practices), common metrics (to compare performance of team or individuals) and common reports (while almost all status reports contain the same kind of information, have you see any 2 organization status reports look the same?). Over time, the organizations gets so consumed by this style of thinking that the people forget – who is it for? Will this help the project that I am executing?

Since I have been working in the domain of software development for the last 20+ years, I have come to realize that the focus of any organization needs to change to what is appropriate for the project. As a Project Manager, I should be able to:

1. Select the base methodology that fits my need as closely as possible: How can I select the right methodology for my project based on the nature and circumstances around my project? What are those attributes of a project that can help me decide the right development model for their project? Can a measurement criteria or guideline be defined for this?

2. If need be, identify key principles of various other methodologies that I would like to adopt: Are their principles of one methodology that I can “blend” with another methodology because they make sense for my project? So, for example, can I use a Kanban board for a Waterfall project? While the two may look to be at the opposite ends of the spectrum, my question is: why not?

3. Identify principles of my base methodology that I definitely don’t need: Are their principles of any methodology that I most definitely do not want to follow? For example, if my requirements are unclear and I am not convinced about a big bang estimate, can I start the project without a detailed estimation cycle?

In other words, I should be able to build a process that is right for the project, right for the people in the project, right for the stakeholders for the project. If you are in a services business and need to give a fixed price bid to a prospect/ customer, you cannot say then that I cannot do it because my process does not believe in big bang estimation. If you are working in distributed teams or with outsourced teams, you cannot say that I will not write detailed requirements because my process does not want me to do that.

Agility is all about being flexible, being able to adapt, fast! Translated to software development, it means:

1. Understanding different methodologies, their strength and weaknesses.

2. Having a tool to help implement different methodologies with relative ease.

3. A minimal layer of commonality across methodologies that can serve organizational needs for reporting/ aggregation without being a liability on the project. As idealistic we may want to be, it is important to recognize that organizations will want some mechanism to get a feel of project progress. That cannot be completely different across projects/processes.

4. Leaving the final decision to the Project Manager as to which methodology they want to use for their project.

5. Assist the Project Manager in adapting to his/her “desired” methodology, quickly.

I would like to know how you go about deciding on the ‘development process’ for your project. Let me know if you agree or if you feel otherwise.

Sudipta(Sudi) Lahiri
Sr. Vice President – Engineering & Professional Services

Join the Kanban Conversations!

noreply@blogger.com (Mahesh Singh) — Mon, 21 Mar 2011 23:29:00 +0000

It has been an exciting 3 weeks since we launched the GA release of Swift-Kanban. Clearly, Kanban for software development and IT teams is being seen as the elusive weapon that promises to take Agile to the enterprise. From the volume of queries and the common themes of the inquiries, it is clear Agile practitioners know what they are looking for and will be demanding the right solution to help them make the transition to being an Agile enterprise.

Three key themes are emerging, which we find very interesting and are excited to learn more about through our interaction with our Beta users as well as prospects who are in discussions with us after the GA release:

Kanban for Distributed Teams

One of the most common reasons we are hearing when we ask why, is that the organization has distributed teams around the country, indeed the world - and simply cannot work with a physical board. In spite of time zone differences and multiple locations, these teams have managed so far by getting onto conference calls at the same time - and comparing notes and providing updates in prolonged interactions! With a Kanban tool, while these meetings may not go away (at least initially!), they get a powerful tool that visually communicates the same status of the project or a specific work-item and of course the entire project. That in itself is a huge benefit when teams have hitherto struggled with text reports/ email updates!

Kanban tools in conjunction with other Tools

Clearly, while Kanban tools provide significant efficiencies in project operations, projects continue to use a variety of tools including requirements management tools, testing tools and integrated development environments. Most of our interactions are helping us educate how potential Kanban practitioners propose to use these tools in an integrated fashion. With our extensive experience in integrated Agile ALM, we are certainly able to share our experience with existing customers; at the same time, we have learnt a lot about the possible integrations we may need to provide for a full solution. Irrespective of whether it is used on a development or a maintenance or a IT Helpdesk type of a activity, these integrations will ensure that not only does work flow smoothly within the Kanban board, but also outside of it!

Kanban and "Other Methods"

Kanban is not a software engineering method; however, it would appear that many organizations are approaching it as a software engineering method - be it against a traditional waterfall or iterative method or an agile method such as Scrum or XP! To us, it is clear that irrespective of the overall methodology being followed, Kanban provides a way to visualize "project operations" workflow and smoothen the flow of actual work. Thus, we are sure organizations will use a combination of software engineering, project management and operations processes that help them optimize throughput and increase output quality. This is fully in line with the principles of Kanban, that says that each (self-organizing) team must define the process that best works for them!

Our Kanban journey began more than a year ago and has just become much more interesting! We are having regular discussions with our early/ Beta customers. With David Anderson as our Advisor, we also launched the David Anderson Webinar Series and have seen a tremendous response to that. Come join us in these conversations and help us learn how we could better help you scale Agile in the Enterprise!

Mahesh Singh
Sr. VP - Product, Digite, Inc.

Agility requires greater Discipline. Are you ready for it?

noreply@blogger.com (Sudi) — Thu, 24 Feb 2011 19:15:00 +0000

For long, we have heard complaints about Waterfall, CMMI, etc. The complaints vary from too much process to too much documentation to too much overhead, etc. The fact is that like everything else that has been around for a while, the spirit behind these standards/ certifications/ methodologies has been diluted over time. I know of instances where tons of backdated documentation is generated before the day of the CMMI audit! Much worse, we have all heard of instances where certificates are “bought” out.

However, if you leave aside the negatives that creep into anything that’s been around for some time and focus on the real principle of it, you will realize that the complaining is not so much about too much process/documentation, etc.; it is about being told to do something in a “disciplined” manner. Software is creative and good developers don’t like being told “This is our standard and you will only do it this way!” It is like telling my daughter who is solving her arithmetic problem to write all the steps. She thinks it is boring and a waste of time; I think it helps her from making careless mistakes. Now, reconcile! Today, few developers write their program blueprint on paper before they start hammering on a keyboard. Modern day editors have discouraged the need for such time tested practices.

Agile got lapped up because it was pitched as lightweight methodology. The point it did not emphasize was – less documented process demands you (the developer) to be more disciplined. Unlike the Waterfall/CMMI methodologies that put a strong focus on review, feedback, corrective action, rework, etc., Agile focused on getting the job done (right) in short time buckets. So, everyone has to develop code as per the standard. Everyone has to be well trained. That is the only way to keep “technical debt” down. Is it easy? No…. it is a lot more difficult. Remember the open book exams in our colleges? I used to dread them compared to the regular exams!!

Now, we are talking about Lean, generally believed to be even lighter than SCRUM. Well, guess what… what is not being said is that it will need far greater levels of discipline on behalf of the development team. How else do you make sure that what everyone is pulling from the queue and working on will finally coexist together in the expected manner? The methodology does not highlight the benefit of “show early and often to get feedback from the customer”. So, a Project Manager now has to have the discipline to make frequent releases and solicit early feedback from the customer. The need does not go away just because the process did not highlight the need.

In summary, the lighter the tool and methodology, the greater is the (maturity and) discipline needed from the development team to be successful; else, it will not all come together when you want it to and in a manner you want it to.

A “part” solution to this desire (to get away from doing extra steps for the sake of process compliance or documentation) can be software engineering tools, ALM tools and development methodologies that help develop generate some of the documentation and structure in the background as the developer continues with his main work – development. Tools that help analyze code for memory leaks or code complexity or generate documentation fit that space. ALM tools, that build complete traceability from requirement to code without a developer going through a painful process to do so manually, fit that space. TDD methodology fits that space. A combination of all these, working coherently (which is far from anything in the space today), can really help focus the team on development and help partially reduce the demand on “developer discipline”. That is what the Development community will embrace.

Sudipta(Sudi) Lahiri
Senior Vice President, Engineering and Services

Is Agile ALM on SaaS for you?

noreply@blogger.com (Mahesh Singh) — Sun, 06 Feb 2011 11:14:00 +0000

In the last 2 years, Software-as-a-Service (SaaS) as a delivery model for corporate applications has found a significant amount of support. In the aftermath of the 2008 economic crash worldwide, there has been a surge of interest in exploring the SaaS model for a variety of reasons – mainly around reducing up-front investment typically associated with on-premise license purchases (operating expenses vs. capital expenses), ease of getting up and running, the ability to opt-out if you didn’t like the software, and several others.

At the same time, customers were cautioned about the key issues to keep in mind while adopting the SaaS, such as:

Peripheral applications, that did not touch core business activity/ processes, such as HR, CRM, Payroll, etc. were easier to deploy on SaaS, rather than core applications.
Even if applications were deployed on SaaS, they would need integration with other enterprise applications, whether in-house or SaaS, and customers would do well to evaluate SaaS vendors for the capability to integrate with other applications/ providers
Even if applications were available via the SaaS model, associated implementation effort such as user training, organization change management, data migration and interfaces with other apps remained. Thus it would be a mistake to assume that SaaS would significantly reduce implementation effort and costs.
Application security, scalability and performance; and vendor track-record (longevity, number of paying customers, financial strength) were other factors to look for.

Where is SaaS being adopted the most?

Common wisdom was that SaaS applications would typically be adopted by Small and Medium enterprises since they are usually more cash-strapped than Large Enterprises. However, in an interesting research article published by Saugatuck Technology Inc., a well-known SaaS research services provider based in Westport, CT, in September 2010, it appeared that SMEs were "much more likely to still be learning about SaaS - and to not have SaaS plans in place".

Based on responses to several key questions, shown below, it would appear that only 24% or SMEs had implemented or were implementing SaaS applications against 43% of LEs!

What Apps are most Likely to be on SaaS?

Clearly, the peripheral vs. the core argument made a lot of sense. Customers would be much more likely to trust an external service provider to manage corporate data that was not critical to its core business. At the same time, they would be much more likely to outsource apps that were not core to the business.

In a recent article, CIO.com refers to a detailed Forrester research that finally acknowledges that not all software will be successful on SaaS! Among others, it says Application Development software is successfully finding its way on SaaS. Our experience with project management software is the same!

At Digite, we have found substantial interest in our Agile ALM products in both SMEs and LEs and we have a healthy mix of both. Given our customers' focus on collaborative software development using geographically distributed teams, both our on-premise (but web-based) and SaaS offerings have found widespread acceptance. Given the global trend of distributed technology teams, this is hardly surprising!

It would be great to hear of your perspective on which applications have worked on SaaS and which haven't.

Mahesh Singh

Sr. VP - Product

When is a project too small or too short for ALM?

noreply@blogger.com (Mahesh Singh) — Fri, 21 Jan 2011 20:59:00 +0000

Someone recently asked that question in a community forum. Their own answer was - 'Never'. There are 3 aspects of this question that I can think of and respond with while agreeing fully with their answer.

Application Lifecycle Management (ALM) is an Activity

To my mind the phrase Application Lifecycle Management naturally means managing the lifecycle of an application. An application’s life begins humbly – with a request from a user or a customer, which fights for its survival amongst scores of similar requests. Once it wins, an application – however small or large – gets implemented/ developed to meet that request. Once deployed, an application has a life, the length of which is determined by a number of factors such as TCO and conformance to changing business requirements. The moment these factors weigh against the application, out it goes, upended by another request to replace that application!

A specific project which deals with an application - its selection/ prioritization, its development or implementation, or a making an incremental maintenance release of that application - is inherently 'part of' that application's lifecycle management, however short or small. So, the question itself becomes redundant from that perspective. Organizations are executing projects (that deal with applications) as part of that application’s lifecycle, whether they realize it or not!

ALM is a category of Tool(s)

From an Application Lifecycle Management tools perspective, different vendors have taken a different tack. While some have focused on purely the development or software engineering aspects of it, others have taken a broader meaning which includes the portfolio and project management aspects of managing an application's lifecycle. Still others have included a process-management aspect as well, that allows organizations to define processes for different aspects of the application lifecycle management, and use those processes in an integrated and standardized manner throughout the application lifecycle. Depending on the nature of the project, it will consume some or all of these aspects of ALM tools.

Various analysts such as Gartner, Forrester and IDC see it similarly; IDC actually has graphic that defines ALM as a combination of all three areas identified above. At Digité, we believe in that same vision. Thus, Digité provides a set of tools that allows our customers to manage the entire lifecycle on Digité or using a combination of ALM tools that Digité integrates with.

ALM is (part of) Organization Culture

A lot depends on an organization's culture, their approach to workforce productivity and quality, and what some of their key performance parameters are. Organizations focused on multi-geography/ department workforce productivity, Total Cost of Ownership of an application, and quality will typically consider any project to be part of ALM rather than see it in isolation. Every organization that understands the true nature and breadth of application lifecycle management will agree.

It would be great to hear some more perspectives!

Mahesh Singh

Sr. Vice President - Product

Digité Participates in Agile Coach Camp 2010

noreply@blogger.com (Mahesh Singh) — Thu, 20 May 2010 06:09:00 +0000

Digite recently sponsored a team at the Agile Coach Camp (Goa, India) organized by ASCI (Agile Software community of India) where a good number of agile coaches and practitioners from various leading organizations and cities of India met in an open space format, to discuss various Agile coaching and implementation issues, as well as share notes on various flavors and practices of Agile being implemented in different organizations.

We started the conference with one-minute lightening talks from each one of us, on the topics which we wanted to be covered during the conference. We later wrote the topic on post-it slips and placed it on one of the open time-slots for discussion and came up with our own agenda board for the day.

Below is a gist of some of the key topics from the above list which we sequenced into multiple tracks:-

Problems with Agile adoption in large organizations: - Agile implementation in a smaller organization (product or services) is still relatively easier than larger enterprises. The challenges grow manifolds as one tries to scale the agile implementation across others projects being executed in the organization. The objective of this discussion was to share experiences on such challenges and the approach taken while scaling the Agile implementation in a larger enterprise.
Do we need a process to define Process? <Sarcasm>:- It was an interesting take on various organizations trying to complicate a simpler (and agile) approach to Agile software implementation by introducing waterfall-like processes and standards which the projects need to follow to claim their 'Agility', thus making Agile Development lose its core values. One of the practitioners shared how he had been asked to come up with an 'Agile Compliance index' metric, on which all the projects can be measured for the level of 'Agile' practices they are following. Again, how much such metrics can represent project success is subjective and we brainstormed on various ways by which this can be tackled.
'Agile Tools': Role, Trends and what to expect in future? : - We proposed this topic to understand the role of Agile ALM (Application Lifecycle Management) tools in helping the teams solve some of these challenges. The software market is full of such web-based agile project management tools which offer various features promising the organization the magic potion of being called 'Agile' from Day1 of its implementation. But are these tools helping the teams do their jobs better? What are the expectations of the senior management from an Agile tool? How aligned and integrated are these tools with other systems and processes that are being followed by the organizations since so many years? Is the cost of implementing such tools justifies benefit derived from it? We had some interesting perspectives which I'll share in the subsequent posts.
Is Product Owner Mandatory for Agile Teams? What happens if there's no Product owner? :- Again this was a pretty interesting topic on the role and need of a "Product Owner" in the Agile team and who can wear this hat if there's no formal product owner in the project.
Pragmatic Agile: - Are we sacrificing delivery for agility? This track was conducted in a pretty interesting format where each one of us proposed a hypothesis of a good 'Agile' practice to be followed in projects and someone else in the group took an opposite stand to debate over it. This has been neatly summed up by one of the fellow practitioner, Vivek in his blog post.
Agile Metrics: - Having agreed that an agile way of working doesn't require too many tracking metrics, but the top management needs to be informed and updated by some means that the project is going on as per the commitment or not. This is more applicable in services organization and is often is linked to various other aspects like appraisals, costing, etc. How then to measure the success or failure of an agile project? It was a pretty interesting discussion and hence it calls for a detailed post.
Role of engineering practices in agile development: - The major part of an agile development and its success often constitutes of the underlying engineering practices being followed in the project. One can count on a number of practices being propelled as an 'Agile' practice (read a list of such practices collated by Naresh on his blog here). But how and to what extent do these practices impact the success of an agile project?
Experiences and learnings in Acceptance Test Automation: - Should the entire suite of acceptance test cases be automated? Is exploratory testing still as relevant, knowing the thrust of Agile on automation. Most of the practitioners shared their personal experiences on this and brainstormed on the best approach to be taken.
Measure ROI of Implementing Agile? :- This was a pretty interesting track where we discussed various 'measurable' metrics which can be tracked to showcase the value of implementing agile software development methodology over other traditional approaches. This has been again summed up by Vivek here.
There were a few more discussion points…but those that I have listed above are the ones I could remember or read out from the above image captured from a digital camera. Guess we can't rely much on gadgets beyond a point and should take concrete notes. ;-)

Overall, it was a great learning experience but by the end of the camp, with numerous discussions on various issues, we almost wondered if we had learnt new solutions to known problems or had just became aware of many more problems and perspectives on the solutions we thought we knew. Maybe it was bound to happen when we had a mix of coaches with different experiences and skills. And I guess real learning from such camps happens gradually as one comes back to the daily grind and reflects on the issues discussed and perspectives gained.

I'll delve into some of the above topics in detail in my subsequent posts.

Nitin Ramrakhyani
Sr. Product Manager & Agile Coach
Digité, Inc.

Product Engineering depends on ALM Lifeline

noreply@blogger.com (Mahesh Singh) — Mon, 05 Apr 2010 04:59:00 +0000

(ALM for Developers Series)

If there is one team that epitomizes the 'Structured Chaos, Unstructured Innovation' mantra, it is the Digité Engineering team! Our daily churn across different engineering streams of new releases, maintenance and Patch Releases, as well as responding to Support and field issues are all done in a day's work! As Director, Engineering at Digité, my job is to make sure we are all pulling in the same direction!

Life before Digité

Before we built our product, in the early 2000's, we used a variety of tools – and in some areas, no tools – as we managed the myriad activities in each month and quarter! Tracking work on email, MS Office, Lotus Notes databases, Remedy and VSS was the norm. But every night, I would spend at least a couple of hours figuring out where we were and if my developers were really done with what they said they had done. Developers would themselves spend considerable time during the day on a variety of 'follow-up' and status update tasks and wasted between 20-30% of productive time every day. Digité 2.0 changed all that – and since then, life has eased up while Digité itself, now at 6.0, has become our 'lifeline'!

Integrated Release Planning and Execution

For planning each Release, Product Management, Engineering and QA start reviewing our Backlog – available through our integrated Requirements Management, User Stories, Customer CRs and Defects – for prioritization and scoping. Once the scope is finalized, we group the various work items into Iterations/ Sprints and start with the first one. In the mean time, we also have Management review and approve the scope, using our integrated workflow. A far cry from the old days of the release planning nightmare!!

In each Iteration (typically, we may have 3-4 Iterations per release), work gets planned as Minor or Major Enhancements. For major enhancements, we use Digite's Work Package module. All tasks associated with each enhancement are planned using either Digité's STaRT scheduler or our integration with MS Project. Developers get their work items and Tasks as their To-Do list within their Eclipse environment, which is also integrated with Digité. From scoping to work planning to allocation and execution, it's one smooth process flow.

Developers work primarily within Eclipse. When checking in code in Subversion, each developer links the Digité Work Item/Work Package for which they did the change and establish the traceability. Digite's Subversion integration helps a Reviewer to examine all relevant changes of a particular Work Item using the traceability links established all through the development lifecycle.

Completed features are given to QA. QA manages the full test cycle using Digité's Test Management module comprising of Test Scripts/Units and different Test events. All defects identified in each test event are logged in our Defect Tracking module, traced to the relevant work items and routed to developers for fixing using Digité. The developer gets these in their Eclipse To-Do list as well! Similarly, automation scripts running every night also generate defects, which are also tracked using Digité and routed to developers in Eclipse.

Once all iterations are done, the release is shipped to Support and Product Management – who also do cursory testing and review Test Results online to ensure the Release meets their Requirements! Ultimately, that is what Quality is all about!

End-to-end Visibility

With such an integrated execution platform, it really ensures that every stakeholder of the release (Executive, Product Management, Engineering, Release Management and QA) looks at the same view of the release status. This helps us achieve timely delivery of our releases without execution conflicts. Steady tracking of key development parameters has helped us reduce Defect Leakage by 66% over the last 3 years while developer productivity has gone up by anywhere from 35-65%.

No wonder that Digité it has become our 'LIFELINE'. It is just not possible to envisage life in Engineering without such a platform!

Chirag Kapadia
Director, Product Engineering, Digité, Inc.

What is the Vision – Agile or Agility?

noreply@blogger.com (Mahesh Singh) — Thu, 11 Mar 2010 15:20:00 +0000

Induction into Agile

My introduction to the Agile world goes back about 3 years. Charged with the new buzz of Agile, a team at Digité attended an Agile workshop conducted by a local Agile/ Scrum trainer.

The first part of the workshop was really very exciting where the coach educated us on the Agile Manifesto. In the second half, we learned of various Scrum characteristics. At the end, the coach made a remark – 'You will be an Agile Organization only if you follow ALL of the Scrum methods described in the workshop'.

This didn't go down too well with the attendees. We started to discuss how we would adopt Agile in Digité. The change was going to be significant. We operate from three different locations – so getting people together in a room was not possible. Further, 'Paired Programming' was not feasible mainly due to cost constraints. At that time, our regression test cycle was a manual (and hence huge) activity before delivering each release to customers. Not to mention all the typical 'change management' challenges for overhauling existing systems and processes.

When co-workers asked about it back in office, most of us termed Agile as 'Star Trek'– all great, but fiction - not designed for software company like ours!

Reality bites – are we Agile?

Over the next several months, egged on by Management, we adopted some elements of the Agile methodology successively. The Product Management team was the first to move. Instead of working with perceived value of features, we started to rank order the Product Backlog. The Engineering team started to plan releases in multiple monthly sprints as well, ensuring a phased delivery and the ability to accommodate changes through the release lifecycle. The QE team was next in the queue, with Test cases automated and a nightly build available for testing.

At the same time, we retained many elements of traditional planning. We were committed to scope and timelines of each major release and there was no moving back from it. All the major software design and architecture decisions were taken during initial Release planning itself. We continued with formal 'Review' processes for code review to ensure code quality. Time tracking was also a key requirement and continued as is.

When posed with the question, "Was Digité Agile?", I was never a 100% sure. Many customers I have spoken to clearly indicated that their methods are a combination of Traditional and Agile. While they abstracted from the "good parts" of Agile, they did not give up on what worked well for them all these years using traditional methods.

Agile or Agility?

Recently, I attended another Agile conference where David Hussman presented a session on 'Doing What Works Over Doing What You are Told'. David, an Agile coach for a range of companies, presented diverse and real-life views on Agile.

His thrust was – most of the organizations have mastered the art of software delivery after a number of iterations. If organizations have developed a certain way of working over the years, they don't have to necessarily scrap it all to adopt Agile. Agile manifesto is not prescriptive; it's a set of simple principles that teams should aim for. There may be various methods to become Agile, but being Agile didn't mean we'd to follow them all!

This certainly resonated with what our customers were telling us. Agile has great positives; however it also has challenges – for certain type of projects and organizations. For project sponsors, Agile projects lack visibility of final scope. There is no up-front planning of who will work on what. Large/ distributed teams have been slow to adopt Agile. This is where Agile ALM tools such as Digité, which enable both Agile and traditional methods, are helping significantly.

Overall, the message is loud and clear – our customers want Agility, where their customer requirements are being met better, faster and cheaper!

Rahul Vedak
Sr. Product Manager, Digité, Inc.

How ALM Tools Can Help Key Software Processes

noreply@blogger.com (Mahesh Singh) — Mon, 01 Mar 2010 03:02:00 +0000

In a recent exchange, I was asked what the typical ALM tools do to address three key challenges around process improvement and compliance in software/ IT organizations, and more specifically, what we at Digité do about them. I felt these would be of interest to others as well, so here is a summary of that exchange.

Effort Estimation

Most tools lack any (effort) estimation capability and most estimates falter. This is one area that remains a challenge for most organizations and application/ software projects are notorious for not meeting their original effort/ cost/ time estimates.

Our experience at Digité has shown that there is very little standardization in the use of estimation methods, except perhaps the bare minimum use of Function Point Analysis, so it is not easy to select any specific methodology and incorporate into the tool. However, the fundamental problem that I believe we (as also most PPM/ ALM vendors) help resolve is of helping our customers build historic data, one of the most common reasons for poor estimates. By using Digité across the organization, our customers capture process and project data and help successive projects do better in terms of estimation. We do have specific but basic functionality around capturing Phase level estimates and then automatically assigning to WBS tasks - which the PM can then tweak as needed.

Standardized Measurement Systems

We believe that ALM tools are at the front and center of solving this problem – that's where work happens! So ALM tools are the ideal candidate to be the measurement system in a software/ IT organization. Through Digité's integrated combination of Process Governance, Project Management and SDLC functionality, we provide all projects a consistent method of data capture across all phases of the project and across all types of projects - be it development, maintenance, implementation, etc. So, every activity in the project is codified, and reduced to a WBS task or a workflow step - and baseline, plan and actual effort against all project work - whether planned or unplanned - gets captured against these tasks/ workflow steps. These then get rolled up based on the WBS hierarchy or by the metrics/ reports that use that data to provide a variety of metrics from quality, defect, earned value, variance and so on.

Different organizations have differences in the way they may measure even a simple metric like Defect Density or Defect Leakage; large organizations may have that problem even across business units! However, using a system like Digité, they are able to standardize the measurement and reporting.

Compliance to Process

Compliance to a process is the biggest issue that our customers deal with - and I sincerely believe that is where we at Digité provide very unique functionality that no one else provides. Digité's integrated Process Governance module has what we call the Universal Process Framework (UPF). This is a flexible framework that allows you to define CMMi/ 6-Sigma, PM-BoK or other framework compliant process templates (PTs) easily and flexibly for different types of projects that you do.

Each PT is a combination of the project WBS, various functional processes (workflows) like requirements management, defect tracking, test management, etc. (depending on the process or project type), deliverables, phase gates, roles, process artifacts, etc. These create what we call 'actionable processes' – the critical component missing in most process improvement initiatives that automatically convert process definitions to project work-items. When the process template is used to create a project, all of these become available to the project team. As the team does its work, the process automatically gets followed! Very little 'extra' work needs to be done to follow the process and project managers/ teams love that!

If you have any insights to share, we'd love to hear from you.

Mahesh Singh

Sr. Vice President, Product

Challenges in Time Accounting in Software Projects

noreply@blogger.com (Sudi) — Tue, 02 Feb 2010 18:43:00 +0000

Time Management has always been a much talked about subject of management. Jim Rohn said “Time is more valuable than money. You can get more money, but you cannot get more time.” Yet, software engineering has always understated the importance of time. In most organizations, time sheets are filed casually. I don’t know of too many developers who can honestly say that they file time accurately.

As I tried to analyze the problem from my own experience, I have realized that there are two parts of this problem. Firstly, managements don’t appreciate the importance of time accounting. Beyond project costing or billing, few know what to do with it. The second reason problem is the TGIF syndrome! When it is Friday EOD, the last thing that you want to do is spend time at 6pm recalling what you did on Monday morning and then painstakingly file time for the right task/activity. Often, you realize that the task/activity that you worked on is not on your screen! So… what happens? You file your 40hrs (whether you worked 30hrs or 50hrs) wherever you can. Result: Garbage In, Garbage Out.

Digité Enterprise functionality lays significant emphasis of Time Accounting. Done right and done daily, it is a 5 minute task. Accurate time accounting has multiple benefits – it helps people understand how they spent their day (could be a problem for some). It helps Project Managers understand where their people are spending more time than what they should. The list can go on.... however, the biggest benefit is that when used on a daily basis and filled accurately, it does the job of progress reporting and status reporting automatically! How?

Assume a task is planned to take 10hrs. By filing time on the task for 8hrs and then saying that only 50% of task is complete OR that you need 8 more hours (either of which is possible in Digité Enterprise), you have told your manager that your task is now estimated to take 16hours and its % progress is 50%. When this happens across the entire team, I bet that it saves your Project Manager at least an hour every day (depending on team size). He/she does not need to talk to people to find out what an individual was doing, how much more time it will take, how much progress it will take, etc.

However, if this functionality is not well understood, it has the potential to make your life complex too. In Digité Enterprise, time can be filed on tasks as well as Project Items (Defect, Issues, Risks, etc.). Digité Enterprise architecture is based on principle that projects that are planned by work decomposition (WBS) will file time against the tasks/activities in the WBS. On the other hand, projects that are executed with Project Items primarily will file time on Project Items. For example, a Development Waterfall project will file time on tasks. However, a Production Support project will file time on Project Items. Mixing the two will inevitably lead to confusion, inaccurate metric generation, etc.

Take a simple scenario: In a simple Development project, one would have a Testing activity(ies). Testing activities lead to Defects being filed. So, if you now file time on the Defect, what are you filing your time on – time to execute the test case that found the defect OR time to log the defect OR time to fix the defect? If someone files on the Defect and on the Testing activity, how does the system avoid double counting of the same?

To avoid such confusion, Digité Enterprise built its solution with the understanding that the time used to test and identify/log the defect will be filed in a Testing activity. Similarly, the time taken to fix the defect will be filed in a Defect Fix/Rework activity. WBS projects will not file time on project items.

Now, consider a Production Support project where you are doing help desk tickets. In such projects, it becomes important to track how much time a specific ticket is taking and to be able to monitor the productivity of people who are working on these tickets in the different stages of the workflow. Obviously, there is no planned task for each ticket because you don’t know how many tickets you will get ahead of time. To handle such projects, Digité Enterprise allows you to file time on Project Items like Defects, Tickets.

Accurate time accounting is critical for all IT organizations - not just for EV and Quality metrics, but also for internal/ external financial accounting, costing and chargeback purposes as well; getting it done has been a challenge for long. We believe that with Digité's Time Accounting capability, we have helped our customers take a big leap towards achieving that.

Digité Goes On the Cloud!

noreply@blogger.com (Digité, Inc.) — Tue, 19 Jan 2010 10:55:00 +0000

At Digité, we have been a web-based application right from the start. Before Cloud, before SaaS, there was ASP – and our initial product launch was as an ASP – Application Service Provider. As luck would have it, a majority of our customers preferred to host the application 'on-premise' and simply wanted to buy the license from us. This worked very well for us – because it gave us invaluable experience in a variety of areas, from the challenges of implementing an enterprise software across the organization, to testing the software for the scalability and robustness needed for a deployment such as Infosys, our largest customer, with a 100,000 users on a single Windows/ SQL Server based installation of Digité Enterprise.

Over the last 8 years, we have implemented Digité at Corporate IT, IT Consulting and Services as well as ISV organizations. And, amongst the many lessons we learned, we picked on two – the challenges an organization is trying to overcome by implementing a solution such as Digité – and the challenges an organization goes through trying to implement an enterprise solution like Digité.

Structured Chaos, Unstructured Innovation

Our customers are in the business of developing or maintaining or implementing software – in-house or third party, custom or off-the-shelf. This is hard work that usually involves defining requirements and building or assembling software solutions that meet those requirements. This is by itself a tough job; introduce geographic, cultural, logistical and technology barriers of today's global economy, and the job becomes tougher by several magnitudes. Our customers have seen the value that Digité provides by giving them a flexible, easy to use, lightweight and cost effective mechanism to quickly get organized in their development processes so that they can get on with the far tougher job of building great software! Over the last 8 years, we have been amazed over and over again at how our customers' teams have innovated to build great software to delight their own customers, internal or external. And we have learned from those experiences. Key amongst them – that people don't want to reinvent the wheel. If someone has already done it, reuse and build on top of it! And two, keep things simple, yet comprehensive enough. "Just enough process" is a recurring theme.

The Small Matter of Organizational Change Management

Implementing ANY enterprise software is not easy; implementing Digité Enterprise – which pretty much touches everybody in a software/ IT organization, can be even tougher. When you are coming off a culture of using email, spreadsheet and some basic project management software, the job of moving everyone to a somewhat standardized way of doing things – managing projects, building software, measuring progress – can be daunting. More than technical learning challenges, more than software challenges – quality, integration, migration, performance, etc. – people simply have a hard time doing something they have been used to doing one way to a new, even if better, way. Yet, in spite of conventional wisdom, an overwhelming majority of our customers have succeeded in meeting this challenge through a combination of process, scope control, phased implementation planning, management buy-in, user buy-in, and more. More often than not, two of the key ingredients to success have been to keep things simple – and to aim for speedy, short cycle-time implementation milestones. The resulting success and the perceived (and real) progress of the implementation itself provides a positive reinforcement which further propels further implementation!

Digité SaaS - Solutions as a Service

Agile ALM or Application Lifecycle Management has become a force to reckon with, especially in the Global Delivery Model. Most technology companies – small or large – are trying to leverage distributed resources and teams to deliver their products and services. With the events of late 2008 and 2009, interest in SaaS applications has made it a viable business model once again. We believe that we MUST share with our customers, especially the Small and Medium Business enterprises, the lessons we have learned over the last 8 years in Digité with respect to overcoming the 2 challenges discussed above. Digité's Agile ALM on SaaS is our new service that aims to do precisely that.

Please come check us out at www.digite.com/saas. If you like what you see, please contact us at sales@digite.com!

Mahesh Singh

Vice President - Product

Digité Improves Quality – of Life!

noreply@blogger.com (Digité, Inc.) — Thu, 26 Nov 2009 10:28:00 +0000

(ALM for Developer Series)

As a Testing manager in Digité, I am perhaps best placed to share Digité Enterprise's impact on my team's and my work.

Prior to using Digité, we used to manage our test inventory in Excel sheets – which is how a lot of organizations and teams still manage their test repository. These were multiple sheets that were organized module-wise. Test results were similarly tracked in Excel and we would depend on a combination of filters/ pivot tables in Excel to help us identify the failures, resubmit them for execution, etc.

Simpler and More Accurate Manual Testing

Since we moved all our Manual Test Inventory from Excel to Digite, life has become simpler. Earlier, for any regressing test cycle, it was difficult for a team lead to consolidate the test status when our test suite was divided across 20 testers. At the end of the day, they would have to chase everyone to mail back their testing status, find out how many defects were identified, calculate pending test cases and then redistribute the same so that testing could be completed on schedule.

With the Test inventory automated in Digite Enterprise, the Team Lead can just execute a report to gather the status. The report gives them the current testing status, number of pending cases, number of failed cases, number of defects identified in the system, status of those defects and when are they expected in the next development cycle.

Effective Test Automation

Further, we also track our automated test case inventory in Digité Enterprise. As the automation team makes progress automating manual test cases, the test cases automatically get excluded from the manual testing cycle using a simple filter in the product. Earlier, this was tracked in Excel by my team leads for automation and manual testing. Maintaining consistency of this information by checking Excel files manually was complex and time consuming. Further, these would never tally because they would be done at different points of time and data was dynamic. Now we have ability to get all sorts of reports – module-wise failures, priority-wise failures, tester-wise defect identification, etc.

Leveraging Integrated Application Lifecycle Management

Managing the overall testing would have been very difficult without Digité Enterprise. Test case development starts early in each release we plan, right after Product Management delivers the Use Cases/ User Stories for the release. The QA team develops the Test Cases for each Use Case, automatically linking them via Traceability. The Test Cases are jointly reviewed by Product Management, Engineering and QA for each release and approved.

With 3,000 QTP Scripts and around 1,500 business functions, we track over 7,000 manual test cases (sanity, smoke and detail test case) in the automated test repository. Product changes and their impact to automation testing assets are tracked through CRs in the automation project. We track the product branches on which this change is applicable. With our Subversion integration, every change is directly reviewed in Digite Enterprise.

Automated Tests run every night, and the results are available for analysis the next day. After completing root cause analysis of all failures, product defects are filed in Digité's Defect Tracking module. A report gives us an assessment of how well the nightly automation ran. A number of metrics are automatically calculated to give the nightly test trends across a month, last run's defects - product and automation scripts defects, script failures (false alarms and genuine), current status of product defects and the number of script failures due to the product defects, by module.

Significant Productivity and RoI

In the last 2 years since we moved our entire Testing process to Digité, our manual testing team has shrunk from 10 to 3, while we have kept our Test Automation team stable. Our test repository has added from 14000 to 19000. That is a huge jump in productivity and a significant ROI in the last 2 years.

Ashwini Lalit
Manager – Quality Engineering, Digité, Inc.

Nasscom Product Enclave 2009, Bangalore

noreply@blogger.com (Digité, Inc.) — Sat, 21 Nov 2009 12:42:00 +0000

In an indication of the growing ranks of software product/ engineering companies in India, Nasscom – India's premier software industry association – organized its 3^rd Annual Product Enclave, in India's Silicon Valley – Bangalore. I was there to represent Digite there along with my colleagues. The theme at this year's conference was "Positioning to Win" – and underscored the need for software companies to establish their brand globally through innovation – both in product and marketing – and thought-leadership.

At Digite, we understand the importance of this. Being a leading-edge software startup is not the best place to start establishing a brand. But meeting and working with pioneering customers and partners, as we have done over the last 8 years, has been an incredibly rewarding experience – and well worth the trip on the leading-edge! In the coming year, Digite plans to roll out some pretty innovative initiatives both on the product and the marketing fronts, all of which will unfold here in our blogs and websites over the next several months. The Product Enclave was a good venue to hear some of the industry luminaries validate our initiatives through their thoughts and ideas.

This year's event had Guy Kawasaki of Garage Technology Ventures, Rajesh Hukku, former CEO of i-flex Solutions (now Oracle Financial Solutions) and K. Ganesh from Tutor Vista, among others. Guy Kawasaki was, as usual, brilliant – both in ideas and oratory! Some of the points he made for small/ start-up technology companies -

Build what you want to use
Niche Thyself – Jump the curve and Create the new curve
Pay no (or very little) money for Marketing, Tools, People
Instead of sucking up, suck down/ across
Use Twitter – fast, ubiquitous, instantaneous and FREE
Give people value constantly and once in a while earn the right to sell
Put everything in the cloud (pay less for infrastructure)
Ship than test
Forget the VC
Don't let the Bozos grind you down

K. Ganesh, CEO of Tutor Vista keeps it simple. Tutor Vista is an incredible virtual tutoring success story with 20,000 students (just 20 times more than what the VCs thought was ever possible!) and 5,000 teachers that used simple yet effective techniques such as on-line 24x7 live chat and getting 15-day free trials establish credibility. Inspiring story that! Rajesh Hukku's story of i-flex and its trials and tribulations and the 'roll-up your sleeves and make it happen' attitude that lead to its success is a great example of innovation on all fronts – product, marketing and overall leadership.

To sum it up, I will borrow from one of the panel speakers from Tejas Networks who spent 25 years in the US before recently moving back to Bangalore. He said "the environment in Bangalore (read India) is very exciting, perhaps as much as anywhere in the world, the ecosystem is getting there and the time is ripe for innovation and products to happen". Therein lies the opportunity for product companies.

Breakaway opportunities uniquely present themselves in the curves; and races are won or lost in the curves. At Digite, we are uniquely positioned to address a new set of challenges in the area of globally distributed software development and application lifecycle management with curves like Agile and Lean methodologies already upon us. It promises to be an exciting 2010!

BM Raghunath
Vice President, Business Development, Digite, Inc.

Do ALM Tools benefit the Developers?

noreply@blogger.com (Digité, Inc.) — Thu, 12 Nov 2009 23:06:00 +0000

(ALM for Developers Series)

Recently, I got asked this question by a prospect – a large bank's SEPG head. Their exact question was – How does Digité help with the developer experience? Clearly, Application Lifecycle Management (ALM) tools have made the life of the PMO, the SEPG, the Quality group, the Project Managers and the executive management better. But how do they benefit the folks doing the actual development?!

Here was my response to them about specifically what we, at Digité, have done to improve the life of the Development Team – the Business/ Functional Analyst, the developers and the testing team.

Digité's Unified Inbox automatically collects all the tasks and artifacts that a team member needs to work on, sorted by project, priority and urgency. No more time wastage in search and follow-up to figure out what work they are supposed to do next!
Digité's integrated set of products ensure that there is minimal wastage of effort in learning the tool itself, in navigating from one tool to another due to an integrated UI and a single repository, other than the code repository.
Our Requirements, Change and Test management features enable Business/ Functional Analysts, Testers and users collaborate continuously to identify, build and manage requirements use cases and test cases collaboratively. They work on individual requirements, decompose them online, baseline and review them; and track any changes to them throughout the development lifecycle. For the Agile practitioners, Digité provides User Stories and Iterations to plan, prioritize and build their user stories in iterations assigned to specific releases.
Digité's Integrated Traceability ensures that developers understand a software requirement along with other related items – user requirements, change-requests, test cases, documents – all thru a single integrated view – so that they can work with a holistic understanding of the business. Similarly, the developer's ability to view a defect holistically – through viewing associated failed test case(s), the related software/ user requirements, etc. means that a developer gets a full understanding of what failed, why it may have failed and do a full impact analysis – thus ensuring that the developers do an effective job of fixing the defect. This prevents a significant amount of rework and ensures a much higher level of initially delivered quality and conformance to requirements.
Our Eclipse/ Subversion/ CVS/ VSS adapters ensure that navigation between the developer's environment and Digité is minimal – and developers and testers can focus on doing their work rather than managing their work. Within Eclipse, they get to view all of their tasks and other work items and are also able to post their effort to Digité Timesheet without leaving the Eclipse environment.
If tracking effort is important to you, you may like this. Our customers report that their developers take anywhere from 30 minutes to 2 hours each week (!) to update their timesheets. We provide an automatically populated timesheet and integrated time-logs available alongside each work item for immediate update as soon as a developer completes working on it.

All of the above have resulted in anywhere from 20-35% direct impact on developer productivity and equally importantly, 45-60% improvement in initial quality of product delivered and overall organizational productivity.

At Digité, we use our product for pretty much everything we do – as Sudipta, our VP of Engineering and Services, explained so well in the previous blog post – Are you still without an ALM Tool? I can't tell you how many times our team members have given us feedback about how convenient and time-saving it is for them to use Digité for managing their own development/ implementation work!

In the coming days, our own team members from our Development, QA and Product Management organizations – will tell you, in their own words, how they see the impact of Digité on their own work and indeed their lives.

We would also love to hear from you about your experience using Digité or any other ALM tools in terms of Developer experience and productivity.

Mahesh Singh
Vice President - Product

Are you still without an ALM Tool?

noreply@blogger.com (Digité, Inc.) — Mon, 09 Nov 2009 19:45:00 +0000

Many of our customers ask the question - why have ALM tools not become a project necessity? Why are they not more “visible”? Are you one of those still wondering if YOU need one? Let me give you some real data from our own example using Digité Enterprise to help you decide.

Our code base is 1.4M LOC, certified on 2 databases, 2 app servers on 2 Operating Systems. That means 8 stack combinations, ignoring that we run on both IE and FF. Further, because we have many customers on old versions of the product, we maintain a minimum of 3-4 maintenance branches at any point of time. So, if you fix a defect on one branch, you have to replicate that across all other branches. How many hands-on people do you believe would be required to maintain this application with a steady flow of enhancements? If you did not know our head-count, I would suspect that your answer would be ‘around 40-50’. We do it with an average of 15 FTEs! If one has to look for productivity examples, I cannot think of anything better than that.

We maintain our Backlogs on the tool, we rank them and estimate them and then, depending on the capacity, determine how much we can do in the next release. That just defined our Release Scope! In all my past 20 years as a software/ application delivery professional, that process has taken 4-6 weeks! We do it in a couple of days.

Once our Release Scope is defined, we execute our enhancements using workflows.

Our test cases, manual and automated, are all online. They are defined module-wise and graded on their importance. Depending on the impacted modules in the Release, we identify our scope of regression testing with a few clicks.

Test execution and defect tracking is all in the system. We don't have to maintain long lists in spreadsheets trying to build pivot tables on status, resource-wise, age, etc.

Our customers file issues that we convert into to defects or enhancements. Once again, we do our impact analysis on the system, review it on the tool with comments and then, assign it for coding and testing using workflows. When we commit our changes (we use SVN), we identify the defect or enhancement it is for and completely traceability is established automatically.

My experience is that organizations handling an application of this size would have 3-4 Technical Leads managing a team of 30-35 FTEs and a full time Manager. We have less than 1FTE playing the role of a Release Manager. We meet once a week for 2 hours. That is the extent of Project/Program Management that we do. The rest is all online...

My CEO gets his full dashboard on the system, real time. No multiple versions from different managers, no data manipulation, no dedicated operations staff preparing Excel/Word reports on Friday evenings or over the weekend.

The results: we have made a release every quarter for the last 2 years. We have slipped once by 3 days. We have brought our defect rates down by over 30%. Of course, we have built a great team but without one integrated tool, we would have been in a mess, doing a lot of rework!

So, if you are not on an ALM tool, get on one! In 6-9 months, you can’t imagine building software projects without it. How many times do you handwrite a letter anymore?

Sudipta Lahiri
Vice President – Engineering & Professional Services

Is PPM enough?

noreply@blogger.com (Digité, Inc.) — Mon, 26 Oct 2009 19:41:00 +0000

I have spent a lot of time over the last 10 years discussing or working with a large number of our customers who have moved away from the ‘traditional’ methods of managing software projects to a more centralized and “institutional” method. An overwhelmingly large number of these companies have evaluated Project Portfolio Management (PPM) tools as their first option for moving away from their disparate solutions, which usually would be a combination of MS Project on the desktop, email, spreadsheets and a lot of hand-waving!

The promise of PPM tools is enticing. From the capability of management dashboards that unambiguously tell you whether projects are in Green, Yellow or Red status, to being able to smoothly make Fund/ Kill or Go/ No Go decisions about a project that is not exactly meeting its objectives, the case for PPM appears crystal clear. Who would not want such capability?

The reality however has been somewhat different for a number of companies.

Can I really trust my PPM dashboard?

In other words, is the data reliable? How is it being collected, collated and consolidated? Is there a reliable process behind this? Are basic steps such as estimation, time tracking and baselining of projects in place?

When organizations and project teams attempt to move away from managing projects using office productivity tools and other point solutions, they are not just switching tools, they are very often changing fundamental processes of how they work and how they manage their work. PPM tools demand a significant level of data reliability – which translates to process maturity – at the ‘operational’ level; to ensure that all aspects of project effort are being looked at, all the project deliverables – not just tasks but various deliverables and work items - from requirements to documents, from test scripts to defects – are being considered in computing the ‘real status’ of projects. This means that execution/ operational level processes need to be in place and automated so they can feed reliable data to the PPM solution.

A lot of PPM efforts have resulted in failure due to this fundamental problem of lack of automation at the operational level of project teams and the lack of project team buy-in. Application Lifecycle Management (ALM) tools that include or integrate with PPM/ Process Governance tools can much more effectively help in this regard.

Where do I file my time for this issue?

One of the basic challenges of project planning tools such as MS Project is that they are great at project planning but not at managing project execution. While PPM tools have ensured that some of the earlier challenges of over-dependence on the lone project manager have been taken care of, they still do not take care of resolving such basic issues as tracking effort on unplanned work.

It is humanly impossible for a project manager to put down every last bit of work as part of their WBS. On the other hand, filing time in a common “Miscellaneous” task means losing visibility to where 15-20% of the project effort might be being spent, so that one could plan better in the future! Very often, PPM tools miss out on all the effort being spent on unplanned work in projects and thus relying on incomplete data for providing management status update.

Integrated ALM tools help by focusing on the project team and making them more productive rather than just providing a dashboard for senior management which may not be fully reliable.

Why are so many defects still open?

Have you run into these questions – “Is that project really green? Or did the PM omit to take into account the large number of unmet requirements?” Or, for that matter, “Is the testing task really completed? Then why are all the defects still open?”

The ability to drill down into a project’s ‘real’ status is most important for portfolio management teams. PPM tools by themselves, do not and cannot provide this visibility and still continue to rely on the abilities of the project manager and project teams to ensure that they collect data from all sources and tools manually before providing that update.

ALM tools with integrated PPM capability make the project managers far more effective by one, providing the PM a comprehensive view of the project and in fact, proactively alerting them of potential red-flags; and two, by dramatically reducing the overhead of collecting data from myriad sources and putting it all together for status reporting, resulting in as much as 40-55% increase in Project Manager productivity.

Where is the final revision of the requirement??!

The value of a single repository for all project artifacts cannot be measured. Having managed projects directly and indirectly for over 20 years, I have seen project teams struggle with the simple task of managing all the information and artifacts - requirements, change requests, documents, issues, defects, test cases, deliverables - related to their project across a combination of email, portals, network directories, configuration management systems and team members’ desktops – resulting in horrendous loss of productive hours and project delays. Just to be able to go to a single place for all of that – makes team productivity go up by as much as 20-35%! PPM tools do not address this crucial business need; and thus do not contribute to mitigating the very factors that lead to project failure.

I believe PPM tools are great management tools for executive decision making. However, they do not focus on or deal with the operational processes that need to be in place so that PPM tools get reliable data. In order to have a good executive information system, it is imperative that the operational processes are cleaned up and automated through a good set of execution/ operational tools. In the world of applications, products and software, ALM tools do precisely that. To have a good PPM implementation, ALM solutions are not only necessary but are also a pre-requisite!

Mahesh Singh
Vice President - Product

Collaboration in Requirements and Change Management

noreply@blogger.com (Digité, Inc.) — Tue, 29 Sep 2009 08:28:00 +0000

The topic of Requirements and Change Management continues to spark enthusiastic debate and discussion amongst the software community. And for obvious reasons!

I was talking to an industry analyst recently – and he himself drew attention to the fact that software requirements are so hard to do, unlike a bridge or a tunnel or building - where requirements were so much easier to define. Absolutely!

Yet software teams and organizations continue to pay scant attention to this critical discipline that is responsible for the failure of such a high percentage of software projects. A recent study and analysis done by IAG Consulting (http://tinyurl.com/dldfwb) had these (not so?) surprising findings:

Companies with poor business analysis were 3 times more likely to see their projects fail!
Bad project requirements can result in up to a 60% hike in project costs, and
For a $3m project with poor requirements, companies would pay an average of $5.87m!

The study concluded that projects and organizations where Business and IT worked collaboratively on requirements were much less likely to see cost and time overruns than those that did not.

The Software Engineering Institute (SEI) has determined that projects that spend up to 60% of the overall effort in Planning, Requirements Analysis and Design have dramatically lower cost and schedule overruns compared to projects that spent that level of effort in Coding and Testing.

This should be fairly obvious - after all, if you don't know what you have to build, how can you build it well? Yet, software professionals, teams and entire organizations continue to suffer from this lack of focus on up-front requirements definition and ongoing requirements management. There is also no doubt that requirements will change - for a variety of reasons. Managing the changes to the requirements on a continuous basis and keeping an eye on the impact of these changes on project budget and contract dollars is what project managers must do all the time.

While the importance of granular requirements management, project managers and business analysts have been hampered by lack of technology support to enable that. Traditional requirements management tools have been too complex, too expensive and too stand-alone to be effectively used. Thankfully, however, a new generation of ALM tools that provides lightweight, web-based, fully-integrated functionality have changed that landscape. One of the most important capabilities these tools provide is collaboration.

Collaboration between business and IT, between customer and service provider, between marketing and engineering is key to ensuring that all stakeholders on a project stay in agreement on precisely what requirements need to be delivered by when. At the same time, it helps both sides objectively decide when requirements change, why they changed, whether they are justified and if they are budgeted for.

The importance of collaborative and ongoing requirements and change management cannot be over-emphasized. After all, in the definition by quality guru, Phil Crosby,

Quality = Conformance to Requirements

I would love to hear from you how you are tackling this significant challenge – whether in-house or in an outsourced situation.

Mahesh Singh
Vice President - Product