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!!!

Advertisements

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!!!

Getting Started with Kanban Software Development

We have so far looked at introducing Kanban systems and what are different things that has changed. Ok, now let us get into the actual thing.

I am new team who wants to do Kanban. How do i get started?

Following are the steps which i will do for my teams to get started with the Kanban Process.
Step 0 : Identifcation and Definition of Minimum Marketable Features and building the Backlog queue : Without this, no process or system works. It makes the product owner work. i know, this might look very basic, but i am sure most of us work with that the backlog ready even for some period of time.
Step 1: Define and visualize your process : Kanban is about the Visual Task board. You have to decide how the process will work and how do we move items, what is our SLA at every stage and how do we accept a feature. I am not sure, whether you have used a Task board in Scrum. In my teams we have used a Scrum Task board which helps in Navigating items from one step to other. Kanban Task boards are bit more detailed. It defines a limit of WIP per Stage, SLAs per Stage, Definition of Done per Stage.
Step 2: Limit work in progress (WIP) : This is the most important thing i learnt from Kanban. Just reducing the number of items in progress, will help us get to the done as quickly as possible. Also, the team completes a feature and moves to the next one, which makes sure that we are developing features which are absolutely required and not wasting time. Eventhough, in Scrum it restricts the number of items being developed per sprint, it doesnt restrict how many can be in a workflow state any point of time.
Step 3: Promote the new model. Pull – Don’t Push – Pull model is new to the team (atleast not every team is used to it).
Step 4: Measure the Lead Time : Lead time is the average time to complete one MMF, a.k.a “cycle time”. Measuring the average time to complete one MMF will help in understanding what it takes for the completion (To Avoid Complacency, Set the Right SLAs in Stages)
Step 5: PDCA (Plan Do Check Act): Pay attention to the work that is flowing through your system – or more importantly, the work that is not flowing – and fix the problems in the system. This is perhaps the single most under-utilized principle in just about every agile methodology in existence. So many teams and managers are begging to be told what to do and how to do it, so that they don’t have to think and don’t have to take responsibility for the process and its problems. If the work is not flowing and SLAs are not met, Task board has to become Red and the whole team has to focus their attention on the item which is not flowing before completing any thing else.

In a nutshell, Kanban is just a scheduling system. The way it works is, Team pulls a feature from the Backlog Queue, complete the development, testing, acceptance and ships it as soon as it is done. Then the team moves to the next one, the Backlog Queue, complete the development, testing, acceptance and ships the feature. Work is shipped as soon as it’s ready, and the team only works on one (Queue Length) at a time.
Reference URL:
Kanban Systems
How to get started with Kanban Software Development
Happy Reading!!!

Kanban : Changes

We looked at what has changed in Kanban in the previous post. Let us look at those changes and viewpoints in detail.
#1. Time-Boxed Development is Out
When i transitioned from a Traditional approach to an agile approach (Scrum), the most important thing we all learnt is following Time-boxed iterations.
Let us look at the benefits of Time-boxed iterations.
1. Shorter Feedback Cycle. Other than feedback, In an outsourced environment, demos at the end of every 2 weeks (my iteration cycles were 2 weeks) provided lot of value adds. My clients saw the productivity every 2 weeks which gave them confidence, which in return helped us build the trust.
2. Software Development is also like music (based on Rhythm). When we all know how much we could achieve in a specific period (we will have our Rhythm).
3. Estimating items for a short period of time was easier than for a longer period.
And now you are saying Time-boxed Development is out? You must be crazy.
You’d still find the “heartbeat” of regular cycles in a team following Kanban — at least if they’re doing agile right you should. The only difference is the cycles aren’t used to plan and commit to stories any longer.
Why so?
1. First, there are quite of bit of overheads (as seen by people) for every sprints.
2. The other thing which i found is a problem is that writing stories which can be estimated. Atleast to my knowledge, i have not seen Product Owners following all the INVEST principles and writing stories.
In reality, Kanban introduces the term cycle periods (instead of sprints/iterations).
Differences between Iterations and Cycle Periods:
1. You do not use the cycle period for planning, estimating and committing stories.
2. Cycle Times are Scope Bound (similar to the Spiral Development Model) rather than Time Bound (XP/Scrum).
#2. Stories are Larger and Fewer
Scrum recommeded us to write smaller Stories (i am sure most of us has read this book User Stories Applied from Mike Cohn which talked about the Invest Principles).
There’s a lot of good reasons for wanting to write smaller stories.
1. It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.
2. It’s easier to plan with smaller stories.
With big stories
a. Stories that might take weeks for a developer to implement
b. It becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks.
c. It seems that only a couple stories fit
d. There’s often room for half a story, but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.
But nothing comes free in this world. If you write smaller stories, product backlogs become bigger and more difficult to manage. If you analyze the Product Backlog, it can easily be into the range of hundreds of stories. Prioritizing, managing, and planning with this sort of backlog will become very difficult.
Product owners are often asked to break down stories to a level where a single story becomes meaningless (Business Stories -> Developer Stories -> Tasks). To keep track of what’s meaningful (to them and other stakeholders), one often need to build a track of how many stories per feature etc which becomes a maintenance nightmare.
Hence, the notion of stories are larger in Kanban.
This works well if you are not having distributed development teams. But if the teams are distributed, having an Epic Story has its own disadvantage (Requirements understanding, communication overhead etc..)
#3. No Estimation
Agile methodologies (Scrum) introduced a new way of estimation using Story Points and new way of communicating how much can be achieved via Velocity.
If we go back to the basics, the main reason why we estimate is to be able to plan releases and to be able to prioritize.
1. When we know the size of a feature, it’s far easier to prioritize based on how much one can accommodate.
2. Velocity helps in planning how much can be delivered in a Release.
3. Task based estimation at the sprint level helps in deciding the appropriate load (Resource Levelling) and helps the teams to commit on what’s possible.
Now, we are saying that there will be no estimation.
I was talking to a colleague (who moved to Kanban) sometime back about the estimation and he mentioned that most of the times we were not able to meet our own estimates and sprint planning every 2 weeks is not helping them scale.
One reason, for the above is that the features or stories are not estimable. Team is not able to exactly decide. And since, we do not have a time bound sprints in Kanban (Its Scope bound), there is no point in estimating. It works in a Pull model, where the team members completes the task and moves to the next one.
So, the next question comes is do we still need to plan releases and prioritize? Well, yes of course. So Estimating the product backlog with a size will definitely help the release planning team to decide how much can be achieved. We may not use the velocity, but like use some estimation principles to know what can be achieved.
How about task level estimates? No. Since there is no commitment on the tasks in a specific duration (Iterations), there is no need to do this.
Okay, will there be any disadvantages? Well, we will look at it at a different section
#4. Velocity is replaced by cycle time
I am not going to spend talking too much about this. I will talk about the reasons later in a different post.

Reference URL:
Kanban Development Oversimplified
Kanban Estimates
What will Kanban bring to your offshore Projects?
Happy Reading!!!