We all know about Best Practices in Software Development: Why do we see them only in power point presentations?

Have you ever thought about this? Everyone today in Software Industry knows the best practices in Software Development. Agile is no more a buzz word today. But, why do we see them, hear them only from some consultant’s presentations (either during a start of a project or when a project is in trouble). Don’t take me wrong. I also do consulting quite often and I also prepare presentations 🙂

Why they are never implemented?
I guess there is no single answer for this. I believe there are multiple aspects to this problem.

90+% of the time, a project is sized without proper analysis (from few liners of requirements to a few page requirements to few days analysis). Why does it happen? If you are in a services company and if you don’t do it, one of your competitors will say i do not need this initial exercise and get the project. If you are in a captive firm, always there is this feeling, I know it better.

Even doing the initial analysis has time and money associated with it. Then irrespective of whatever is the proposal, there is always a negotiation and the age old trick of reducing cost is the same. Cut the testing effort. Reduce some %age in development effort and we are good.

Reason, the priorities for different people are different at each stage. Money is the most important thing in the Business. For a services company, getting a business is important. For a sales person bookings are important. For a software company reducing cost is important.

This reducing cost, is it done using some parameters? In a RFP response, even though a company might be well qualified, but if their cost is high, the contract goes to the company which is quoted less. This evaluation, do they always happen analysing multiple parameters. Do we do ROI Calculation to take a decision? Not necessarily.

Agile has given a new way to look at things. The IRON Triangle has been reversed in Agile. True, but what we didn’t understand is that the IRON Triangle didn’t disappear. It will not till the time we this business. Scope, Time and Cost are proportional to each other. If there is a change in the scope then Time and Cost increases proportionally. Because the Triangle has been reversed, we are not completely out of it.
Agile - Inverted Triangle
Let me explain with some examples:
If we do not have time to write requirements (In some form of Minimum Marketable Feature, User Story, Use Case or XYZ…), When will we move to capturing acceptance cases per requirement? If it is all about time, then this may require an additional person which in turn translates to Money. If we do not even capture requirements, capture acceptance cases, how can we think about doing Accpetance Test Driven Development or Specification By Example?

If you need to write Unit Tests, whether you want to agree or not, you are going to spend some additional time (Pure agilists may say its not going to increase time. But, in reality it takes some additonal time). Time translates to money. If we are still following the age of trick of cutting testing efforts, how do you expect this to be followed? If we do not have an understanding of the scope completely, given an estimate, in my opinion there is no way in the world you will do all this.

Take the example of Continuous Integration , You need to have build integration, maintain your builds and integrate your tests and run it everyday. Building, Maintaining have some effort involved which again translates to time and money.

If we are not in a position to do Continuous Integration, how will we do Continuous Delivery? We are talking about an utility which will take the build, automatically deploy it in an environment and run the test cases and say your code is working?

The point which I am trying to make here is any effort has time & cost attached to it. You cannot do 101 things with whatever limited budget and resources you have. Implementing these best practices has some work involved and it has to be considered within your scope.

There is no Free Lunch.
Agile - Schedule, Cost and Scope
To start a project, it takes years. But the moment we are in, the schedule pressure kicks in. Scope Creeps, Team changes, additional integration happens. We continue to add Technical debts. Because of the schedule pressure, we continue to ignore them. Our product owners do not understand the meaning of technical debts, design debts etc. etc.  We become either ignorant of all the issues knowingly or unknowingly. Teams becomes frustrated to fix, add features but continue to work on the same code base.
Because of all these, we are promoting a community who knows what it means, but don’t want to implement them.

Have you not seen these implemented in some place?
Yes, I have seen this implemented in some of the projects in my own experience. Companies like Thought works are doing it. I have seen this implemented in some small companies. I have seen an implementation of a Continuous Integration Server written by set of people 10 years back and they are still working on FoxPro. But, the point is they have spent considerable amount of effort in that, which in turns translates to money.

Secondly, it is about making it as an organization culture. If you look at how Thought works, Google and other companies have done it, they all have brought it inside their DNA.

What is this culture all about?
When you are habituated to a set of things, doing things in certain way, it becomes a culture. Again, I am not talking about 1 or 2 teams implementing in a 100,000 member company. I am talking about doing it as a whole.

Why is it important to do it as a whole? So that everyone in your company is in the same page. Your sales guy will not give gyan to reduce the testing effort. You do not have to argue on why it takes a longer time to hire a talented resource (I am sure you understand what I am saying here).

So, what are your suggestions to implement all these?

  1. Communicate the effort and cost involved in bringing all these practices. All these in Writing. Get an Approval or Disagreement in Email, before initiating the new project.
  2. Get the right level of leadership at all level (Program/Project Manager, Product Owner, Architect etc…). Understand that it’s not easy to get the right level of leadership. You cannot add people whoever is available. It requires a much more level of filtering.
  3. Start any project with a decent set of requirements. Track the requirements and document changes (I am not talking about bring our old Change Control Board here). Whatever we do, at the end of day we should know how much have we spent for any particular work and to track that you need to know what you have done in the project.
  4. Start the project with couple of resources who can implement all these practices (may be couple of sprints). Slowly add new members to the teams who can fit with your culture. When they come in, make sure they understand the culture and adapt to it. It becomes a habit. If someone is not culturally fit, do not hesitate to move them out.
  5. Slowly introduce additional practices.
  6. Track Technical, Design Debts. Prioritize them. If you don’t pay your debts today, you will end up paying them after sometime with interest.
  7. Review the 7 Software “-ilities on a regular basis. Not just at the time when the project is in trouble. Invest in tools which can help you get better statistics.
  8. Make sure you review with your stakeholders about the practices and efficiency of these practices throughout the project.
  9. Make changes as needed.

The whole exercise requires one thing. You need commitment from all your stakeholders on what you are doing and the willingness to spend.

Can these be done in Fixed Cost Projects? Agile Gurus (Ken Schwaber and others) have mentioned that fixed bid projects are always the way to get to lose-lose situation. If reducing cost is the only thing you are looking for, all these will definitely not work.

Finally, we are not in the business of making popcorns. How to make the best popcorn could be done in 7 steps, but not software development. In this whole business, every project is complex in its own nature. There can be no bullet points.

Doing all these, can they guarantee success? May be, but at least you will be in a better position with your code base. May be decision of getting to a “Look-a-Like” Migrations can be delayed for another 5 years.

Till all that happens, the best practices are always going to be only in presentations (at the start or end of the project).

Happy Learning!!!


Do you have the right product owner with you?

Most of the product companies have a role called Product Manager (or Vice President, Product Development) who is responsible for the Product Management Functionality.

Typically a Product Manager in a Software Product Company is responsible for
1. Defining the product strategy and Road map. Typically Product Manager’s Conduct Surveys, analyze the current trends of the industry/competitors and decide the road map for the Product.
2. Visualize the Product, Delivering Requirements in Some Format (PRD/MRD/Use Cases/User Stories), Prioritize the Features, Release Planning, Write the Acceptance Criteria.
3. Working with external third parties to assess potential partnerships and licensing opportunities etc…
4. Taking care of the Pre-sales Demonstrations, Meet Potential Customers, Run beta and pilot programs with early-stage products and samples.

When a new software development initiative is made, the Product Manager typically will be made as the Product Owner for the New Product Development (Could be a rewrite of the old product or a new Product).

Even though the Product Manager is responsible for Defining and developing the requirements, most of the times it takes the last priority. Meeting Potential Customers, helping sales team (apart from the strategic planning) becomes more priority than writing requirements. Product Manager’s time is very hard to find and development teams has to wait for his availability. Its justified by the business that we need to have more business so that we can accommodate all these development etc…

After working with product development companies for all these years, this question has come to my mind some time back.

Who is the right person for the Product owner role? Can a Product Manager be the Product Owner? Is it possible for the Product Manager to play both the roles and add value?

In my opinion, a Product Manager cannot be a Product Owner. If you have a Product Manager as the Product Owner, you will definitely understand what i am talking about. I am sure, you are working on one-liners as requirements.

In my opinion the Product Owner is Responsible for the following.
Product Owner is a person who owns the development of the Product. He / She own the Iterations or cycle period, available for the team when required. Primary responsibility is to write stories or requirement in some format and work with the developers and testers to define the acceptance criteria for the stories. He / She should understand technology a bit, so that he will be in a position to understand the technological constraints. Once a feature is complete, the product owner should spend time in verifying the feature and provide his acceptance.

If the Product Owner you have is not doing all the above, its time to look for a new profile. Finally, your whole development team is dependent on this person and his time is more important for the development teams.

Some useful Pointers
Agile Product Owner Vs Enterprise Product Manager
The Product Manager – Role and Responsibilities
How to be THE ULTIMATE Agile Product Team / Agile Product Managers and Agile Product Owners Living Together in Harmony

Happy Reading!!!

Iterative Development, Manual Testing and Frustrations

When i started my transition to iterative development (from Traditional) six years back, my core focus was on how to get the development work into the iterative model, make the developers understand the challenges, accept the reality and work on. We have conducted sessions to developers, what is agile design and how to write code which can adapt to changes.

Over the years, we have spent more time with developers and not with test engineers. I failed to understand the impact of manual testing on iterative development.

The objective of an iteration is to deliver a working software every 2 weeks (or 3 depending on your iteration cycle).

A well-planned iterative project starts from the expectation that people (developers, users, executives) are not very good at figuring out how they will actually use the product, estimating costs, prioritizing features, or anticipating the problems they will actually encounter during development. It is designed to help us manage the risks associated with errors and omissions in our assumptions and estimates.

Even though we start with this expectation that things are going to change very often, i have seen test engineers getting frustrated over the period of time. I have heard test engineers saying the process is not disciplined, there are no process at all and finally agile development doesn’t work for us etc… etc…

I was wondering about this problem for some time before i realized the potential reasons for their frustrations.

We all are human beings. If i write a Statement of Work (SoW) in the same format for few times, i really get frustrated. So, i change the format, i try adding new content etc. The same applies to a test engineer as well. If someone sees the same application every week, test a new content + content previously developed for a long time, the job really becomes monotonous. Above all this, you have the changes coming to a feature working and tested earlier. Whenever there is a change, there is a possibility that the previously working content has a new bug, gets into the testing cycle, fixes and testing cycle.

The other point is that, as a human being, if you start seeing the same application for a long time, your eyes are tuned to your application. Your eyes are used to this. Every time a new build comes it looks the same.

In a product development environment, I am sorry to say this, the efficiency of the testing goes down over a period rather than improving.

When the frustration mounts up, test engineers make the wrong enemies, lose the respect of the wrong people, and cut themselves off from opportunities to address serious, chronic problems in software development.

Reference: XP, Iterative Development and Testing Community

I am not talking against test engineers here. I have discussed this with multiple test engineers and i understand their frustrations. The objective of this post is to talk about the issues with Manual Testing in an Iterative development.

Ok, you talked about the Problem. What is the solution for this?
Let us take a scenario where the there is a feature being developed in a particular iteration. When you demo the Product Owner realizes some changes, so you add them to your backlog. It again gets into whenever that particular change gets prioritized. Now you are working on some other requirement and realize that you need a change in a feature which we developed few months back… This cycle never ends (especially in a new product development).

If we are doing manual testing, the manual test cases also has to change whenever the requirements changes. What i realized is, as the product development moves forward in the development life cycle, these manual test cases go out of sync, irrespective of the effort you put in.

Ah!!! Yes, the kind of changes that is brought inside a new development, its very difficult for the test engineers to keep up the pace and update the test cases. Secondly, Development is dominated by developers. They talk to the Product Owners regularly and if there is a change, they update the feature accordingly. Thirdly, Test engineers keep seeing this for a very long time. No human being can have the motivation to change things 100 times (in a specific feature) over a period of 1 year. So the answer you get is, the requirements kept changing, so we thought its better to update the cases once you get a stable version. And then, it never gets updated.

Do we blame Test Engineers for this? No. As a human, its very difficult to have that kind of motivation to keep test cases in Sync every time.

Sounds Very Primitive. Huh. Check out any development projects which are been under development for the last 1 year or so. You will be very lucky, If you could find even one project where test cases are always in Sync.

In Summary, following are the challenges that needs to be addressed.
1. Keeping the documentation (Requirements, test cases etc…) up to date.
2. Communicating the changes to all members of the team.
3. Ensuring that the changes are tested completely.
4. Ensuring that the changes don’t break the existing features which are working.

If you have gone through every agile software development book, article, blog post they all talk about Automation. Ok, if everyone has mentioned Automation then why are we not automating.

We have started Automation of the user interface quite some time back. We have done extensive work using WaTiN (for Web), Microsoft UI Automation Library 2.0/3.0 and Windows Messaging systems for Windows applications and MSAA for Automating Office based Applications.

Ok, you have done Automation extensively. Then why are you even talking about this post?
First thing, the automation work which i have talked about are all done after the feature is completed or we get to a release status. Meaning, they are not done as part of the iterations.

Why? Because the common mindset is that the feature will change over a period of time. Even if i make it run now its going to change and i have to change my test cases again (Same as Manual test cases).

What is the solution for this problem? How do i make sure that my requirements, Acceptance criteria and Test Cases are always in Sync? Is it first of all possible.
Yes, its possible. The paradigm is moving towards Acceptance Test Driven Development.

What is Acceptance Testing?
Instead of focusing the testing on what every click in the application is doing, the focus is moved towards whether the system is behaving what the customer is expecting.
1. It defines how the product owner wants the application to behave.
2. It enables the developers to know that they’ve satisfied the requirements.
3. Helps us build the right software.
4. Can be run automatically by anyone at anytime.

Ok, Sounds good. But how does it solve the Problem of Synchronizing?
Specification by Example/Executable Specifications and Agile Acceptance Testing to our rescue.

In his book Bridging the communication Gap, Gojko Adzic says Agile Acceptance Testing revolves around the following five ideas:
1. Use real-world examples to build a shared understanding of the domain.
2. Select a set of these examples to be a specification and an acceptance test suite.
3. Automate verification of the acceptance tests.
4. Focus the software development effort on the acceptance tests.
5. Use the set of acceptance tests to facilitate discussion about future

Tools like Concordian or Storyteller or SLIM helps you capture requirements as tests. They are captured in a WIKI format using examples. Testers along with customers define the acceptance criteria for the tests. Developers write the test fixtures to make the tests run.

Acceptance Criteria to Tests definition.

Another advantage here is that, when customers define the tests, the tests are defined in a way how the end users will be using it rather than the system integration scenarios. These can be written in the language which everyone can understand.

How do they really work?
From Concordian’s Documentation
Specifications are written in simple HTML. Developers instrument the concrete examples in each specification with commands (e.g. “set”, “execute”, “assertEquals”) that allow the examples to be checked against a real-life system. The instrumentation is invisible to a browser, but is processed by a Java/.NET fixture class that accompanies the specification and acts as a buffer between the specification and the system under test.

These tests can become part of your build process and can run every night. If there is a change in the requirements, the tests will fail. Requirements needs to be updated with examples , there will be a change in the acceptance criteria and tests need to be updated. In this way, the requirements and test cases will always be in Sync.

Acceptance Testing Frameworks enables customers, testers, and programmers to learn what their software should do, and to automatically compare that to what it actually does do. It compares customers’ expectations to actual results. When we actually work on something like this, the documentation will be always live.

Gojko Adzic, in his post Anatomy of good acceptance test says, in order to be effective as live specification, acceptance tests have to be written in a way that enables others to pick them up months or even years later and easily understand what they do, why they are there and what they describe. Here are some simple heuristics that will help you measure and improve your tests to make them better as a live specification.

The five most important things to think about are:
1. It needs to be self explanatory
2. It needs to be focused
3. It needs to be a specification, not a script
4. It needs to be in domain language
5. It needs to be about business functionality, not about software design

Following a practice like the above, helps us always complete what is expected. It also leads us to a Done stage every iteration. The documentation is always live and one can understand the functionality even after 6 months or 1 year.

It allows the testers to collaborate more with the developers and they can actually move the dull work out of their plates. It also will eliminate the frustration from the test engineers about requirements not captured or changes not been communicated.

In an ideal world, you need to complete the features developed and get to a done stage in 2 weeks (or within the sprint length). In a realistic world, may be a 1 week stabilization for a 2 weeks iteration is not a bad idea. Finally, i do not want things to spill over to further iterations and not want to call them as done.

If you are doing a Framework development, the challenge how do i do this for a Framework? In my opinion, you are developing this framework to solve a problem with a domain/vertical. Build your requirements/acceptance criteria/cases for the specific vertical than for the framework. Why? A Framework alone doesn’t provide any business value. Implementing the framework for a vertical is what brings business and that’s where we should have our focus.

In case, if we do not do this, can we still be successful? Can you expect a high level of testing efficiency after an year or so? By God’s Grace, it is possible. But there is no guarantee. If you are a manager and want to provide any predictability with the product quality towards the end of cycle, then you would definitely need to implement Automated Acceptance Testing in your projects. Else, be prepared to hear the word DejaVu from your manager 🙂

Happy Reading!!!

Kanban in 24 Hours

Can a process model be mastered in 24 hours? My answer is No. Then you may ask, why this title? I was thinking of writing a master post, which will link all my posts about Kanban and i thought Kanban in 24 hours could catch people’s eyes. Hence this title. I am sorry, i am not going to give any shortcuts. I sincerely believe there is no shortcuts to a place worth going.

I have summarized my learnings/experience with Kanban in the following posts. Its my attempt to capture what i have learnt/read. I may/may not have captured everything i wanted to. But, i guess its a good start.

There is so much written about Kanban and I have provided the reference URLs which i have referred to while blogging these posts.

Kanban Posts Summary
Introducing Kanban : Post introducing Kanban.
Kanban – What is it all about? – Kanban in a Nutshell
I am currently doing Scrum. What is different in Kanban? – Talks briefly about what is changed in Kanban.
Kanban – Changes : Talks about the changes in Kanban Software Development in detail.
Getting Started with Kanban Software Development : Talks about how to get started with Kanban Software Development.
Kanban Taskboard : Talks in detail about the Kanban Taskboard.
Kanban – FAQ : Summarized my learnings in a FAQ format.
Kanban – Summary: Summarized Kanban as a Software development Process and linked to a post which talked about implementation challenges.

Kanban – Must Read Links
Kanban Development Oversimplified
Kanban System for Software Engineering
Waterfall, Lean/Kanban and Scrum by Ken Schwaber
Kanban Systems
Kanban Applied to Software Development: from Agile to Lean
Visualizing Agile Projects using Kanban Boards
Useful Links about Kanban
Kanban, Flow and Cadence
Kanban in Software Development
The Kanban Story

Road to Mastery
It took me couple of years as a practitioner to master agile/iterative development. I liked the Road to Mastery model which James Shore has Proposed in his book The Art of Agile development.
1. Follow the Rules (Apprentice)
2. Break the Rules (Journeyman)
3. Ignore the Rules (Master)
I guess, when it comes to Kanban, i am at Stage 1 (Apprentice).

Happy Reading!!!

Kanban – Summary

Kanban systems helps in achieving better process control (keep continuous flow while limiting WIP) and
better process improvement (Make the flow visible). A Kanban System manages the flow in a way which allows the Product Backlog, time-boxed Iterations and estimations can be eliminated. Kanban provides transparency into both the work and the process, showing how work is passed from one group to another and thereby improving understanding and teamwork. This helps teams to organize themselves more effectively and provides senior management with the visibility required to govern effectively. Improved flow and quality shortens lead times, which in turn improves performance and predictability.

There are two key things which i definitely like in Kanban.
1. Getting to Done. Since the team will work in one MMF and only one MMF, you will always get to Done stage. Most of the times, the development gets stuck because the requirement is not clear. Such things will be highlighted at a very initial stage of development here.
2. Task board: Even though the Task board concept is not something new, Kanban Task board highlights issues when things are not flowing from one stage to another. You have a way to highlight that something is stuck and you can hope that the management and everyone’s attention will be moved to the task cards that are not flowing.

Challenges in Implementing Kanban
I was thinking about the challenges in implementing this in an offshore setup. I found a related article. I just changed the introduction content a little bit.
Following a Kanban process will force us to challenge some ingrained habits.
The idea of limiting the amount of Work in Process (WIP) in a step may sound good, but actually submitting to limits is challenging the first few times . In an offshore setup, there may be a tendency to focus on how much time is spent working or how many tasks an individual is completing.
Kanban forces us to face these measurement systems and correct some of the flaws they drive into our processes. Rather than measuring how hard an individual is working in a single step, we measure how well we deliver through the entire process.
Rather than measure how many hours an individual is working, we can measure how many hours of work we have removed from the process.
Where the old measurement system is asking why we aren’t piling up more work in between development and QA, Kanban is forcing us to question how we can improve the throughput or decrease the rework rate.
Ingrained habits are difficult to change and if you are not a product house and in a services unit, it requires a change at the organization level.
Reference URL
Applying Kanban
Happy Reading!!!

Kanban – FAQ

This blog entry is an attempt to summarize my learnings in a FAQ format. There are certain questions for which i do not have an answer and may be i will learn as we do more and more of this development.
Can Kanban solve all my development problems?
In reality, no process model will solve all your development problems. It depends on how you structure your development. Kanban is no silver bullet.
In my opinion, the most important value Kanban Process model adds is the Taskboard. If something is not flowing from one stage to other, the cards becomes RED and everyone has to attend this. Your management (if at all they look at, will also come to know that something is not moving). If your management (Senior, Program, Project and Product) teams are insensitive to this, then i do not think its going to help.
Do i need write requirements in detail?
My answer is you need to definitely write requirements. Level of detail depends on your teams. Any Process model (whether its traditional or agile) requires the product management team to write requirements. If your Product owners are busy doing things other than writing requirements, then no process model in the world can help.
Also, its very important to write the Acceptance Criteria for the specific feature.
Should the requirements be in a User Story Format?
In Kanban, we call the requirements as Minimum Marketable Feature. It can be in User Story Format or Use Case Format or Plain Old Reqsuirements Format. The thing which you should take care is completing this feature/story should add some business value.
How do i bring Technical Stories in the Backlog Queue?
I do not have a straight forward answer as i am still learning. What i assume is that, you will be developing the technical functionality to achieve some business functionality. So whenever you are working on the specific feature, the technical story will be broken down into tasks and taken for development.
Why cant we have the Technical Story as a MMF?
Since completing this will not add any specific business value, i do not see a reason why it needs to be developed seperately.
In scrum, we used to break a user story into smaller stories. What happened to that concept?
If we break the stories into smaller pieces, there are couple of issues which we need to handle.
1. The Backlog becomes very big and it becomes very difficult to maintain
2. Completion of the smaller stories itself doesn’t add any value. You need to have a track to complete all the smaller stories which would make the full version.
How do i Prioritize and Schedule MMFs from the Backlog Queue?
At any point of time, the team is going to work on only one item. If that is the case, we have to have a reliable method of picking the next item. Sometimes the work has a natural order and more-or-less picks itself. Other times, we have a backlog of things to choose from and have to make a decision.
I found an interesting link where he talks about the prioritization of MMFs.
Perpetual Multivote
What kind of projects are best suited for Kanban?
With my current knowledge, i feel that the ongoing development work will be right one for Kanban. In an Ongoing Development, we are not developing anything from scratch. You will be working on next version releases and hot fixes and i feel Kanban will perfectly fit this.
I was talking to a client sometime back, where he mentioned that they release every 2 weeks. Since their application work on Click Once based Deployment, everytime there is a new version every one using their system is going to get the new version. In my opinion, Kanban will perfectly fit here where you develop something, complete the acceptance and release it.
SaaS/PaaS Models could be another place where this could work perfectly where you will be running one single code base for multiple instances.
Why do you think Kanban may not be the right for a new development?
Well, i have my own reasons for it. I work in a Offshore development setting, where i do not see dedicated engineering team very often. New Projects will always come in a Fixed Cost mode and i am not sure how we could map this development process to the new development. May be we could, but at this point i am not really sure about this.
Do we still have a Product Owner in Kanban?
Yes, I do not think it will change. We will have one Product Owner.
Do we still conduct standup meetings?
Yes. We still conduct Standup Meetings. Standup meetings are not status meetings. The team will be asked if the board accurately reflects what is been under development. The team will be asked if there is anything that is slowing down or stopping throughput (impediments). After these two questions are answered by the team, the stand-up is over.
Ok, In Kanban, People say there are no estimates. Then how do you really track? Do i have to wait till the development team shows some mercy on me?
Cycle Time, is the time between when the team starts working on an item and when the item is delivered. This metric becomes a key management metric to reduce variability in the system, make reliable commitments, and provide insight into whether improvement efforts are delivering expected results. Cycle Time is easy to capture. When a card is pulled into the first work queue – enter the date on the card next to Start. When the card is moved to the last queue, enter the date on the card next to Finish. Cycle time is Finish Date – Start Date. At the end of the week, when you pull cards off the board, capture the cycle time for each card into a spreadsheet or whatever tool you are using for tracking.
In other words, you measure the typical time it takes to complete an MMF (“Your wait from this point will be XXX days.”), from start to finish, and extrapolate to various points in the queue. Since MMFs can vary in size, this is a rough projection, not a commitment.
Total Cycle Time = Number of Things in Progress / Average Completion Rate
Some useful references
Kanban and When will this be done
Kanban Systems
If the team isn’t estimating or planning with fixed time-boxes, how can it make reliable commitments?
I found the answer for this question in this blog entry Kanban, Flow and Cadence.
A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”
The time-boxed iteration is one form of cadence, which couples planning, review and release together. A kanban system de-couples these events and allows them to have separate cadences, as well as adding two additional ones. Throughput is the amount of output of a process in a given period of time, and Cycle Time is the length of time to complete a process. The relationship between the two is:
Throughput = WIP / Cycle Time
Throughput allows forecasting of future capability, without needing to specify what might be delivered. Cycle Time allows commitment by becoming an SLA with the business (see Kanban Commitment). Where the size of work varies, from large new features to small fixes and change requests, then a classification of MMFs can enable a range of cycle-times. Both Throughput and Cycle Time can be charted and trended, in a similar way to XP’s Velocity, as a means to encourage the team to improve. A Cumulative Flow Diagram can also make visible how the work is flowing through the system and highlight bottlenecks.
For longer term forecasting, a quarterly planning cadence focusses on quarterly goals and objectives. MMFs can subsequently prioritised to meet those goals and objectives. A regular release cadence will build up trust that the team will work to its full capacity and throughput.
Other cadences, are daily stand-up meetings, and regular retrospectives and Operations Reviews as described by David Anderson. Some teams are using a Retrospective Kanban to signal when a retrospective is necessary, and I have already blogged briefly about Kanban and Retrospectives.
The consequence of Cadence is that commitment and reliability is achieved though measurement as opposed to planning.
How do i handle bugs?
If you are following agile, then you have to complete the bugs, before you call the feature as done. Incase, if the bug is found after the feature is marked complete/or from the production house, then it has to be scheduled as a new MMF. If its Critical issue that needs to be fixed immediately, then it goes into the Emergency List Queue and takes the highest priority.
What goes into the Emergency List Queue?
Typically, any fixes that goes as part of the Hot fixes, any Production issues will be part of this. The team strives to finish urgent items quickly, and they try to keep the slot empty and available at all times.
Why does typically everyone suggests to have the backlog queue limit as Seven?
Basically, the idea is that any human being can remember only a maximum of seven items. So, its suggested that you have only Seven as the Queue Limit.
How many items can be under Work in Progress?
When i started i had this confusion of how many features can be under WIP. If you are following Kanban, then you can have only 1 MMF under WIP. There could be multiple development tasks for the current MMF under development. Set the WIP Limits for these tasks at different stages.
We used have something like Definition of Done in Scrum. Does Kanban also suggests the same?
Yes, In Kanban you have DoD (Definition of Done) defined at every stage and you verify that before pulling it to the next stage.
When will a Task card become RED and why does it have to become RED?
When a task is not flowing from one stage to another within the SLA defined, the Task card becomes RED. When its RED, the objective is that there is an impediment (Items are not flowing) and everyone will have their focus there.
If you are using the manual task board, then its very important for the Leader/Manager to keep a track of all this. In our teams, we have automated this, so if the task is not moving then the Task Card becomes RED automatically.
What are measures of success in Kanban?
1. Increase in throughput
2. Decrease in cycle time
3. Work in Progress does not include defects
What are the Metrics captured?
I am still exploring this area. I do not have much information at this point. Following are the items which came into my mind immediately.
1. Average Cycle Time
2. Median Cycle Time
3. Touch Time : Amount of time spent working on any one thing.
4. Weekly Throughput = TIP/cycle time
5. Cost Per Feature
6. # of Critical and Blocker bugs not resolved
7. # of bugs not verified
What is ideal Queue Size for each stage?
Queue sizes are subjectively derived based upon team size, and Median cycle time. Each queue has one slot for signaling a thing is finished and ready to be pulled in to another queue.
Its upto the team to decide what is the ideal queue size at each stage.
Example: MMF Could be 7; Development could be 5 and QA could be 2
I am still exploring this aspect. Will update as soon as i have more information.
We used to Sprint Demos at the end of every Sprint. In Kanban, there is no fixed iteration length. Do we still do Demos?
We call it as Tradeshow. Could be scheduled every month.A Place to demo what features have been released since the last tradeshow. This is to celebrate success of working software in production. People may wander through the area, getting demonstrations from the Developers who are responsible for completing the features. Its an opportunity to view the accomplishments of other team members, stakeholders, and anyone else who cares to look at the great things being produced by the team.
How do you handle Retrospectives in Kanban?
There is no hard fast rule on when to do a retrospective in Kanban. Typically once in a month, the team will analyze this process and determine if improvements need to be made. Example of items to be reviewed are operations, teamwork, and product development process.
How do you Visualize Work in Progress?
Using Cummulative Flow diagram. Cumulative Flow Diagrams show the relative amount of Work in Progress for each stage (or queue) over time. Variations in the gap or bands represent bottleneck situations and typically occur due to overrides in the work in process limits. The amount of work in process is also a predictor of the remaining cycle time.
Reference URL : Cummulative Flow Diagram

Following are some of items which i am still finding answer.
1. UI Designers in my company are shared across projects. How do you reserve time from shared resources and handle them in Kanban?
2. What are the work in progress limits for each step of your process flow? (Eventhough i had posted my answer for this, still have some more work to do in this)
Happy Reading!!!

Kanban Taskboard

In Kanban everything revolves around the taskboard. Let us look at it in bit more detail.

A Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else.

What does a typical Kanban Task board contain?
1. MMFs
2. Development Process
3. Emergency List

Kanban Planning Board

The Left most corner of the task board will display the backlog queue (list of MMFs) along with current MMF that the team is working. The order of this backlog queue can be changed at any time by the stakeholders. This queue is strictly limited in size. A small backlog is good because it limits the amount of time an MMF can wait, which prevents them from getting stale.

The team only works on the top MMF in the queue. Stakeholders can add, remove, and move the other MMFs in the queue as much as they want, so long as they don’t exceed the queue’s size limit.
In the middle you have the Development Process Area (WIP) (Analysis, Development, Automation, Acceptance, Done) which will have the tasks put up for the current MMF.

What comes here depends on the development process you have. Say for example, you might want to have only 3 columns in your board (Not Done, In Progress, Done) and add tags (Analyze, Test, etc…) to your card. Finally this is completely upto you (how you want to have your process)

Finally, have an Emergency List which will make an entry to Development process.

Reference URL:
Kanban Board Basics
Kanban Kickstart Example
Kanban Systems
Kanban board for Lean Software Development
Completing the Kanban Board with Queues, Order Points and Limits

Happy Reading!!!