Topic: Software Processes

Kanban for Bench Projects

Dietrich Kappe, Monday, August 31, 2009 @ 4:51 am

photo credit: alq666

As a software development company, we mostly work on client projects. Occasionally one project doesn't start right when another ends. In that short interval, we would like to work on something useful -- in house products, R&D projects, etc.. Unfortunately, we can't run these "bench" projects the way we run a normal project. We can't do two or even one week iterations, because some folks may only be on the bench for a few days. So, how do you apply these resources efficiently? Here are a few tricks we use:

1. Divide work into very small pieces -- no epic user stories!
2. Keep your technology as vanilla as possible to reduce the learning curve.
3. Use Kanban to organize the work.

What is Kanban? There's some good explanations of it over at Wikipedia and InfoQ, but just like Agile and the feedback loop, it helps to know the basic principles so you can figure out how it will work for you. From the InfoQ article:

A Kanban is a signaling device (usually a physical card in a clear plastic envelope) that instructs the moving or creating of parts in a "pull" production system, invented and developed as part of the Toyota Production System (TPS).

[...]

Kanban's aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. "Pull" means that the downstream workers withdraw or "pull" the parts they need from their upstream processes.

So, the basic principles are "pull" and minimizing "work-in-progress." Let's see how this applies to the bench.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Startups, Software and the Vision Thing

Dietrich Kappe, Tuesday, September 9, 2008 @ 4:44 pm

If you can dream it, you can do it.

-- Walt Disney

You have a great idea, an idea that is going to transform an industry. You've turned a venture capitalist's head with your presentation and now you just need a software development firm to translate your vision into reality. This is where the trouble starts.

If you move in startup VC circles, you see enough of these deals go sideways or never get off the dime. Investors see hundreds of thousands or millions of dollars plowed into software development without a usable product or service coming to light. Fingers are pointed; tears are shed. For every success there are a half dozen failures. Why is that?

In my experience it all comes back to that word, "vision" as in "translate your vision into reality." What the heck is vision? If you've ever cracked a book on software project management (or just general project management), there's usually a section about having a project charter and a vision statement. As a young developer I would wince and turn to the next chapter. After all, I thought, isn't vision the same thing as what you're going to build? Isn't scope or, more basically, a list of things your are going to build, the same thing as "vision?" Why blather on in consultant speak about vision statements when a more concrete and practical project description could be had?

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Managing vs Creating Test Data

Karthik Muthupalaniappan, Monday, July 7, 2008 @ 5:27 pm

This is my first blog post at Pathfinder. I m excited to be a part of the Pathfinder team and look forward to working on a number of different diverse projects. I had a tough time trying to decide what the subject for my first post was going to be.  I finally zeroed in on "Test Data Management vs Creation".

In one of my earlier jobs at a reputed insurance company's IT organization, We came across this problem that posed a big challenge. We were building a real-time policy servicing application. The problem was finding the right test data to test the application. The QA folks were spending so many man-hours trying to find the right test data or set-up test data. "Test Data Management" was becoming a big pain and was hurting the project badly in terms of time and costs. The solution?

"Test Data creation" was proposed a viable solution to this problem. The idea was to build reusable tools that would use the application to generate test data to suit the QA organisation's needs. These tools determined what the tester's test policy needs were, used the application services to generate test policies and provided them to the tester.  It was a great idea! The application that was to be tested was SOA driven which made it easier for this solution to work. I was a part of the team that worked on developing these tools. Some of the tangible benefits that everyone saw with this approach were:

• Life of QA became much much easier.
• Imagine the amount of time and money the company was going to save.
• The application was being tested repeatedly when it was used for creating the test data.
• Test Automation became easier.

The QA organization's mantra became "Forget about managing and reusing test data, create new test data the way you want it!"

• Digg
• Reddit
• del.icio.us

Comments (0)

Technologies and Platforms