The Zen of Kanban

I'm using Kanban on one of the projects that I'm overseeing right now. It seems to be a perfect fit for this particular project.

Kanban came from the Toyota Production System (TPS). The idea is that you don't stockpile parts, they flow as you need them to the production line, minimizing your work in progress. If you want to read more about Kanban and software development, here is a good article.

On this project, the product owner had already pulled together some requirements before we stepped in. Our first step was to organize the requirements into a backlog and get him to prioritize the work. Then we asked him when he wanted the next release to be ready.

We did some high level estimates and then cut the backlog in half, saying we thought we could get through half of it by the release date. That was the first step to reduce our work in progress.

I have two developers on the project, so they each picked a feature from the top of the list and got working. They did some more requirements gathering, design, and build and unit test...keeping the product owner involved throughout the cycle. They then did a demo for the product owner, getting his approval that the work was done. At this point, these features were ready for final testing (by another group), and the developers picked more work to start on.

What has really made the Kanban approach work well here is that the team was small, the work could be timeboxed, and the product owner was involved and flexible about how the work was delivered.

Like Scrum, Kanban doesn't dictate specific software engineering practices. In this case, the developers are following some standard practices that we use on other projects and I have another team member doing code reviews as part of our QA process. The final testing is being done be another group in the organization and because that decision was made after the project got started, we don't have them looped into the Kanban approach. We are planning an iterative approach to testing, so they aren't waiting for all the work to be done before they start. We'll have to work on better integration of the testing approach on our next project.

So if you have a small project (maintenance releases work well) and want to try something different, consider Kanban. I've found that focusing on one or two features at a time make the team more efficient at getting the work done.

When to Multi-task

One of my LinkedIn Groups had a discussion this week about multi-tasking, sparked by an article in InfoQ. The article talked about the cost of context switching and some of the other costs of multi-tasking. There conclusion, which I generally agree with was;

Context switching between projects takes time and is a cost to the organization. The more projects involved and the more complex the projects, the higher the cost. By focusing on one thing at a time for a longer time period, individuals can work more efficiently.

So is there a time when multi-tasking is ok? The answer is Yes. Harvard Business Review had a recent article on this topic and they sited a couple instances when multi-tasking could help you.

One idea that struck a chord with me was to multi-task when you are stuck. If you're trying to solve a problem and can't make any progress, step away, go do something else, and come back with some fresh ideas. I do this a lot with work...if I feel like I'm not getting anywhere, I'll go get a cup of coffee, talk to a colleague, or even surf the internet for a few minutes. When I get back to the original task, I've come up with an idea that gets me past my roadblock. Next time you're stuck, try it.

Beyond Do's and Don'ts

Being involved in multi-cultural, cross-border projects is much more common these days than it was the past. So how has our ability to work effectively in this environment evolved in recent history?

I can recall the first project I had in a foreign country. I did what a lot of people did, I learned what you should do and shouldn't do in that country. For example, in an Arab country, it is considered impolite to shake hands with someone using your left hand (a "don't"). Similarly, in India, where it is common to eat with your hands, using your left hand to eat is also considered impolite.

So while learning the do's and don'ts will keep us from making a fool of ourselves, we need to go further to work effectively with these cultures. Some areas to focus on include;

• Problem solving - does the culture you are working in put more emphasis on facts or on logic/reasoning? Do they come at the problem from different angles or try to focus in on just one solution?
• Governance - how is power shared or controlled? Are people punctual or not? How do they approach risk?
• Relating - are tasks more important or relationships? Are individuals or groups more important? Are communications explicit or implicit?

Understanding the answers to these questions will help you understand how you should work with other cultures. If you know a culture appreciates explicit communications, you will know to get to the point rather than indirectly address an issue. So next time you are going to work with another culture, take the time to get beyond do's and don'ts.

Technical Debt

So I started a new program a couple of weeks ago. Typically I get involved with new clients and help them build their first set of business processes using our software. This project is different, the client has been using our software for a number of years and part of my job is to take of the operations/maintenance of a number of applications.

As my team started looking at these existing applications, they came across a lot of "technical debt." The applications were developed and enhanced by a number of different developers with different skill levels (some with low skill levels for working our our products). So we have a lot of code that's going to be hard to maintain and enhance.

It's a tough situation. The client uses a charge-back system to charge the business units for development, so we don't have money to just go in and completely re-factor an application, even if it needs it badly. On the flip side, both new enhancements and maintenance take longer because of the debt we've inherited.

For now we're going to have to live with it. We'll try to pay off the debt slowly by cleaning up parts of the code as we do our development or maintenance. I think the client is starting to realize the cheap solution for development wasn't necessarily the best.

Got a story to tell?

I started work with a new client this week. One of our conversations revolved around adoption of the program we were implementing. This is a pretty common theme in a lot of projects I work on, how to get people to buy in to your vision.

I came across an article on this topic on Harvard Business Review. One of the interesting recommendations of the article was to tell stories. As a former Navy guy, I have heard my share of sea stories. While entertaining, sea stories also had a lesson to teach. It was usually about how to avoid doing something stupid, exemplified by someone doing something stupid.

But stories can help in business as well. I often tell stories of how a previous client did something similar and what their outcome was. Sometimes, in spite of my best advice, I have had clients do stupid things. More often though, they stories are of success. The story drives a point home better than providing statistics or giving recommendations without any backing.

So what stories do you have to tell? How will your stories help you move your project forward?

A Brand Called You

I had an article published yesterday on Projects@Work on Seth Godin's latest book, Linchpin. I've been a fan of Seth Godin since he spoke at the PMI Global Congress more years ago than I want to think about. It was at the conference that I was introduced to Fast Company magazine as well.

From Fast Company's "The Brand Called You" to Linchpin, the focus has been on how you need to take charge of your future. So have you worked to refine your brand? You may be thinking that you don't need to because you work for a company and don't plan on becoming a free agent. Even if you do work at a company, you still need to think about your brand. As Godin points out, if you are just a cog, you can be replaced by a cheaper cog.

So where do you start? One good technique is to become the expert on something; be it project management, your company's products, or some technology. Then you need to get the word out that you are the expert and help people out. This is what Godin calls giving your gift.

As an example, I was one of the first people to get my PMP certification in the organization I was working in at the time. I started helping other people get a better understanding of project management. First, it was some half-hour "brown bag" sessions at lunch and eventually I put together a half day intro to project management for people in the department. This wasn't in my job description. No one asked me to do it. I did it because I was developing a passion for project management and I wanted to share it. People started to think of me as the guy who know how to run a project, and the big, high profile projects started coming my way.

So figure out how to brand yourself. What do you have to offer your organization? What problem do you want to be known for solving?

A good quote

A came across this...it's like the saying the race doesn't go to the swiftest but to the one that keeps on running;

“Nothing in the world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination are omnipotent. The slogan ‘press on’ has solved and always will solve the problems of the human race.”~ Calvin Coolidge