Improve Your Process Using Kanban

Kananban was developed in the late 1940's by Taiichi Onho at Toyota to improve Toyota's production process. It is important to note, this had nothing to do with software, it was all about managing Process and Work. This post will explore using lean principals and Kanban to manage a team's process.

The Problem

Before we offer a solution it is worthwhile exploring what problem we are trying to solve. Teams and the people who work on them are very busy and over worked. They have too much to do in the normal work week. This causes them to work many additional hours just to keep their heads above water.

Teams are also juggling many things at the same time. Many people are proud of their ability to multitask. Although acceptable in small quantities, multitasking can actually lead to lost productivity ¹. It is easy to have so many spinning plates that some are bound to fall and break.
We are faced with so may things to do, we often do not know what to work on next. This causes teams to work on items that may not be that important. Our items get lost in a blizzard of work and we feel lost. This causes a lot of waste.
We are so busy, that we often do not take the time to improve. We feel we are so busy this is not possible. This causes us to get mired down in our same old way of working.
As teams move toward an end goal the progress is also lost in this blizzard. Like a blinding snow storm,there is not transparency into what the team is doing and how it is progressing toward a goal.
It very competitive out there. It is critical for teams to work at peak efficiency. They need to know What is needed and when it is needed. They need to eliminate waste, have a transparent process that helps teams know what is going on and have a way to learn and adapt in a way that does not take lots of time.

The Kanban Solution

Our Diagram below depicts a simple Kanban Board.

We uses a set of Columns that define the workflow of our process. In this example, it is very simple. The workflow moves from left to right.

A set of Cards identify what we need to do. The cards are in priority order, the most important cards are at the top of the list.

It is best to have a card identify an outcome that has value. This is better that a set of tasks. For example Desk ready to ship is better that Order Desk.

 A Constraint identifies the maximum number of cards allowed in a column. In our example, we only allow 3 cards in the doing column.
It is very easy to setup a Kanban board. A good place to start is a whiteboard and post it notes. There is also free software that can easily setup Kanban boards, Please see our Agile Tools for Delivery section for details.

Why Do This

Using Kanban forces us to put some thought into our process. By defining a set of Columns we define our workflow. By adding Constraints to a column we are acknowledging we have limited resources and have agreed to finish what we start before moving on to other things.

A set of Cards identify the things that need to be done and the priority they are needed. All of this is transparent for the whole team to see. This allows the team the see what is going on at all times and adapt where needed.

Regular meetings should be conducted to review the work and adapt to change.
For an working example please see the Process Improvement with Kanban section of our Roadmap to Agile.

Learn More

What is Kanban

Introduction To Kanban

Just-in-Time - Philosophy of complete elimination of waste

Some Remarks on the History of Kanban

Lessons in Agile Management: On the Road to Kanban (Book)

1. Debunking the Myth of Multitasking

Why a Chicken Farmer is Like a Corporate Re-Org

A chicken farmer is driving down the road in a truck. All of his chickens are comfortable sitting on their roosts in the back of the truck. They are happy and content in their place. They know the chicken next to them and they quietly cluck away doing their work. (cluck, cluck, cluck ..)

Every now and then, for no apparent reason, the farmer pulls to the side of the road and stops the truck. He walks to the back and opens a door. He gets a baseball bat and bangs on the side of the truck.

BANG BANG BANG

The chickens squawk loudly and fly off their comfortable perches in all directions. Some fly out the door but most of them settle down on a new perch.

Now, the chicken next to them is different. The perch is different. They are uncomfortable and do not know what to make of their new surroundings. There is an uncomfortable clucking noise in the truck that is not as content as it was before. (CLUCK! CLUCK! CLUCK …)

Eventually, the chickens settle down as they get used to their new surroundings. They get used to their new roost and the chickens next to them. After some time, they go back to doing exactly what they were doing before, again content.  (cluck, cluck,cluck…)

Until the next time.

Remember, job security is the skills you have, not the company you work for.

Scaling Agile - What does this even mean?

I have been thinking about this topic for some time. A tweet from @MooneyDev asking for my thoughts on an article written by @jbandi prompted me to write this article.

Mr. Bandi’s article, Why I Don't Believe In Scaling Agile to the Enterprise, makes some very valid points.

I spent the first twenty years of my career as a developer and architect. In the past eight years, I became a delivery manager and project manager. I embraced the points in the Agile Manifesto. I also found the tenets of Extreme Programming, Scrum and Kanban compelling because of their simplicity and came to understand how they can be used to deliver software solutions.

Recently, a popular topic is “how to scale agile”. A number of solutions have been offered, SAFe being one of the more popular solutions. This solution and others have generated some criticism in the development community.

A point often made is that solutions like SAFe are “cashing in” on agile. I agree with this point to some degree. However, this is not new. The IT world is littered with good ideas that have been packaged and sold as solutions.

Another point often mentioned is that agile is mostly common sense and any group of very smart and highly motivated people will succeed using agile. There is no doubt that this is true as well. 

We are asking the wrong question

In my opinion we should not be asking how or if we can scale agile, we should ask how to scale people.

When considering large teams we are facing the bell curve. We need to figure out how to deliver software solutions when hundreds of people are involved. Smart and motivated people would probably be successful with any process. We need to be successful with average folks.

In my opinion, the traditional waterfall approach is not a solution. Pascal Gugenberger wrote an interesting article titled The Waterfall Accident where he points out that Winston W. Royce, the father of the waterfall approach, never intended for it to be a once-and-done, single pass approach.

So, in order to scale people to successfully deliver software, we need to observe the available options around us and carefully select solutions knowing that there is no silver bullet.

SAFe has some attractive options as do other frameworks and approaches. Every firm and situation is different. How do we select the right option?

Open Agile Adoption

I have found the Open Agile Adoption approach offered by Dan Mezick attractive. This approach book-ends a set of iterations with open space meetings. In these meetings, any member of the team is free to post suggested break-out-sessions they feel are important. Attendees are free to attend any meeting they choose. If something is important, folks will attend. 

Every member of the team is invited to attend including executives. This open and free communication enables the team to figure out what is best for them. Typically some flavor of an agile practice is used but the team sorts this out.

These meetings are facilitated by true Servant Leaders who help the team see the path.

I head Dan speak at a user group meeting and I am eager to try his approach on a future engagement. I believe the team knows best the

approach. Leadership is required to help them find the way.

In conclusion

There are firms who have large staffs who need to successfully deliver software. We need to figure out ways for these large firms to be successful. Many approaches have been tried over the decades and we are improving.

The internet has exploded over the years and, clearly, this demonstrates we are learning from our mistakes. I believe that the textbook waterfall methodology is no longer a consideration. Some flavor of agile is. We just need to figure out the details which has always been a challenge.

Agile and Geographically Separate Teams

It is common these days to have delivery teams who are geographically separate. This may occur because offshore resources have been selected for cost saving purposes or simply because teams are split across a region or country.

Scrum calls for co-located teams and the Agile Manifesto embraces face-to-face communication as the most efficient way for teams to communicate. There is no argument with this point. However, when teams are geographically separate, we need to find a compromise.
This article provides techniques for increasing the direct communication for teams who are geographically separate. This includes a mix of technical solutions and meeting logistics.

Be as Face-to-Face as Possible

Coordinate important meetings to include the whole team whenever possible. This approach requires additional costs because travel and lodging are required. Sprint and Release planning meetings benefit from having the whole team in the same room.
If the largest number of people are in a single location with a few other team members in other locations, use the main location for the meeting to save costs.
Schedule happy hour meetings to allow the team to get to know each other and to increase morale.

Use Video Conferencing Equipment

If teams cannot attend meetings in person, use Video Conferencing Equipment. This also has a cost associated with it but the benefit is worth it. This is best utilized when a team member operates a camera at each location. As people talk, the camera is pointed at the speaker. This really improves communication because body language is apparent and people are more likely to participate.
Teams can also collaborate using a whiteboard. Simply point the camera at the board so remote teams can participate.

Rotate Offshore Teams

This approach involves rotating a portion of an offshore team to the project site. For example, a member of the development team from India would spend a period of time onsite with the US team. This approach provides the offshore resource with valuable insight into how the US team operates and allows the remote person to get to know the team.
Later, when the offshore resource returns to India, valuable experience returns with him.
There is definitely additional cost associated with this approach. It is best to decide on this approach before an offshore partner is selected. During price negotiations, this point can be raised. Typically, a blended rate is a solution so the cost of the travel may be accounted for. This blended rate approach usually has a minimal cost effect on the project budget.

Use Technology to Reduce Friction

It is common for agile teams to work together in a shared space. This allows issues to be handled quickly as they come up. Since everyone is in the same room, this is easy. Of course, when teams are split, this is not possible.
Instant Messaging tools like Skype or Lync offer some solutions. Advise the team to Instant Message a person when a question arises. Screen sharing are also available on these tools, so it is almost as easy as huddling around a computer together to collaborate.
These tools also support groups of users. In one of my projects, we setup a DevChat group that the whole team were members of. When any questions arose, they were posted to DevChat. Anyone on the team who had an answer posted it back to the group. It was a very effective communication mechanism.

Keep Scrum Teams Together

When possible, keep scrum teams together as a single unit. For example, if an offshore team is being used to contribute to a project, it is better to have a single scrum team offshore than to split the team between multiple locations. This allows the single scrum team to gain the co-location benefits. 

Time Zones

Different time zones are a major contributor to team friction. When questions arise and some of the team are sleeping, there is an impediment to progress.
An obvious solution is to schedule some overlap hours when the whole team is available. To make this easier, select offshore vendors who are located in regions where the time difference is less of an issue. South America is becoming  a popular offshore region just for that reason.
It is also important to have a local resource on call from the offshore team. This should only be used in an emergency and only if the offshore team will be idle because of some situation.
I have seen times when the whole offshore team was idle for a day because a server needed to be re-booted. A call to the on-call person would have saved a lost day of productivity.


Geographically separate teams do make it more challenging for teams to work together, but it can be done using technology and some structure changes.

Learn More

• How Rally Does Distributed Meetings - There are some very good points in this blog post.
• Logitech Conference Cam - This is a $250 conference solution. 
• Use Skype to Improve Team Communication -  My blog post on using Skype Groups.
• Using an Agile Software Process with Offshore Development - Blog post by Martin Fowler is very good. This should be read by anyone considering offshore teams.

How Rally Does ... Distributed Agile Meetings

How Rally Does ... Distributed Agile Meetings

Some Considerations for Cross Functional Teams

The typical goal of forming Cross Functional Teams is to compose a team with a set of skills that are individually balanced and that meet the needs of the Product being developed. In Scrum, the term Team refers to the folks delivering the product. Scrum specifically mentions that there are no specific roles for Developers, Testers, Business Analysts, UX Designers or any other typical IT role. The team is cross functional and each person can pitch in to work on any activity that is necessary to complete the sprint.
In Sprint Planning, there is typically no consideration for individual capacity. The team commits to the stories for the sprint. This article explores some of the real world situations that arise when teams have specialized skills.

 

Specialists Exist

It is a fact that people in the IT field specialize in areas they find interesting and fun. Some people choose to become a Database Architect, User Experience Designer, QA Tester and so on. We need to respect these career choices people have made.
However, we can advise people to broaden their skills and grow their market value. For example, a Tester could be motivated to also learn coding skills that may be used in automated testing and development. A UX Designer could be convinced to broaden his skills and do some front end development. Whatever agreement is reached, it must be win-win.

 

Planning

When specialists are part of a team, they need to be consulted in the planning phase. From a timing perspective, the sequence of the tasks necessary to complete a story needs to be planned. Discuss this with the team and reinforce the cross functional aspect of scrum.

Icon

A person on a scrum team should be available to perform any task they are qualified to complete.

When we consider the above statement, we can begin to review our options. Testers can be involved in authoring User Stories and Acceptance Criterion. They can also work with developers and author unit tests.
BA's can help develop test scripts and help test the stories as well. Developers can help with requirements and testing. The goal is to spread the skills across the Sprints so the individual capacity of a team member is not a factor when planning.

 

Capacity

When the skills of the team are balanced, individual capacity does not need to be considered in Sprint Planning. If this is not the case or if there are tasks that only a given specialty is qualified to perform, we need to consider individual capacity. For example, if we have one Database Architect on our team and he is the only one who can do database work, we need to be sure we do not overbook him when we plan.
Some tools have capacity planning built in. The screen shot below is Rally's capacity planning approach.



If your tool does not support this capability, you will need to use spreadsheet magic.

 

General Advice

Regardless of the skill composition of the team, the following points are worth considering:

• Individuals on the team should not be allocated to other projects. There are many studies¹ that show how inefficient task switching is.
• The team succeeds or fails together.
• The team decides on the details for executing the sprint and is Self Organizing in that regard.
• The team should sit together in one large open work area² with easy access to whiteboards, projectors and small rooms or pods for small team meetings.

Read More

• Scrum and Cross Functional Teams vs Specialists (Conversation Thread)
• Question on Cross Functional Teams in Scrum (Conversation Thread)
• The Scrum Team Role (Blog)
• The Unreasonable Effectiveness of Cross Functional Scrum Teams (Blog)
• How can an agile team be truly cross functional when team member have different skills sets (Blog)
• Balancing Team Needs and Functional Lines (Blog)

Footnotes

1. The Cost of Task Switching - Human Task Switches Considered Harmful (Joel on Software),  The Multi-Tasking Myth (Coding Horror) , Is Multitasking More Efficient? Shifting Mental Gears Costs Time, Especially When Shifting to Less Familiar Tasks (American Psychological Association)
2. Agile Work Areas - Team Room (Blog Martin Fowler),   Team Room Article (Agile Alliance),  Team Room Article (Mountain Goat Software),  Microsoft Team Room (Video)