Tuesday, December 28, 2010

Kanban - Part II

Yesterday we had a brain storming session on what kanban would look like for the team.  I must say it generated a ton of good conversation.  Here are a couple of key points that I remember.

Someone mentioned that a team of testers could spend a majority of their time in the design phase, especially facilitating the development of Cucumber scripts.  It was suggested that one tester each week focus on this area and rotate the responsibility each week.  Another suggestion was to pair a tester and developer for each story.  The primary premise discussed was that if effective Cucumber scripts are developed then further down the process testers would know what to test even though they did not participate in the design phase.

Another key point was with respect to the current defect backlog.  How do we keep the defect backlog from building?  The team concluded that we need a dedicated swim lane in the process dedicated to fixing defects.  Dan Anderson shows in his book a good example where X% of the capacity is dedicated to defect resolution. 

What happens if a story is full of defects?  The conclusion was that the story remains in the process and is not released.  Since the team is inspecting the process daily, they can make adjustments to provide potential solutions.  One approach might be paired-development practices which provides real time training and retrospectives on what is happening with the story.  The ultimate conclusion is that if the team only got one story deployed each week they were adding incremental value to the business.  This should not happen often, but the bottom line is that it is OK to tweak the process on a daily basis and focus on deploying high quality valued features.

The one scary piece that we did not resolve was dealing with complexity.  Occasionally an Epic story comes into the team's backlog.  During the design phase we should be able to dissect and break the Epic into smaller stories, but the concern became how do we make sure the stories get implemented in the right order and that all of the stories that comprise the whole get assembled, tested, and deployed.  Adjusting for complexity will be a fun challenge, but a challenge never the less.

We talked about buffer zones and capacity limits.  We have no clue where to set the capacity limits.  It was suggested that we minimize the WIP so that we can gain confidence in the process and trust in the quality of the features being produced.

I must admit I am excited about this approach.  I know we will fall flat on our face a couple of times, but we will get up, collaborate, and continuous improve the process.

Stay tuned for Part 3.  We plan to walk through some real scenarios.

Friday, December 24, 2010

Kanban

I am wide awake Christmas Eve day at 5:20 AM.  I should be sleeping!  Instead I am reading a book by David Anderson, Kanban.  Why as a tester am I reading Kanban?  Well one of the teams I work closely with is about to implement kanban in 2011 as an attempt to improve their process.  So I ponder how does test have to change on order to fit into this paradigm.

I am not even going to attempt to describe kanban in this post, but I do want to convey I get a bit excited when I see the first step David Anderson recommends for moving to kanban.  He says the first step is to "Focus on Quality".  As a tester you have to like hearing those words.

I also agree with these points.
  • Both Agile and traditional development approaches to quality have merit.
  • Code inspections if done right can improve quality.
  • Collaborative analysis and design improve quality. I believe testers should get involved early in the process!
  • Using design patterns improve quality.
  • Use of modern development tools improve quality.
As pointed out in the book all of these things improve trust and confidence in the process.

The team using kanban will be doing weekly releases.  They have been doing weekly releases, but development and test cycles were taking four weeks (2 in development and 2 in test).  The product owners were not getting their new features in a timely manner.

In December the team has been focusing on reducing the backlog of defects and discussing the implications of kanban.  In my opinion, the biggest fear of this change is coming from the testers.

I contend there is nothing to fear.  A story will move through this flow:

Idea > Design > Work in Progress (code, unit test, code review, automation) > acceptance test > final test > production

If there are 10 stories in the pipeline and 5 testers.  Then a tester is responsible for 2 stories.  Testers should be able to test 2 stories in a week.  Right?  OK it does depend on the size of the story.  The fear comes from the regression test phase.  My philosophy is automate regression tests where possible and focus on Exploratory Testing.  If testers cannot get over their fear perhaps any manual regression testing should be focused on the area(s) of highest risk.

I predict that the process will be bottle-necked in two areas.  The first bottleneck will be in design.  As part of design the team will be writing Cucumber tests.   Through collaboration the cucumber tests will make sure everyone is understanding the feature and testers will know what to test early in the process.  This process will take time.

I believe acceptance testing will go fast, but the second bottleneck will be the final testing phase.  Unfortunately testers are still focused on "Perfect Software".  I contend that the testers will have to implement test strategies that can be completed in 1-2 days.

I am looking forward to seeing this in action.

The extremely nice thing about kanban is that you know your pain points because you see them on the flow chart.  More importantly kanban expects you to change the process in order to remove the pain points.

Over simplification?  Maybe!  As Larry the Cable Guy might say "Git R done"!

I am definitely looking forward to this challenge in 2011.  I would welcome any comments from testers who are actively doing kanban.  I suspect there are not many.

Sunday, December 19, 2010

Waterfall vs Agile

This past week Lanette Creamer posted on her great blog some statements with respect to her current team.  She implies that Waterfall teams are better at communication than Agile teams.

I would contend that the methodology has little to do with it.  You take a motivated and well spoken tester like Lanette, then combine other motivated members to her team and you will get good communication.

Motivated people make communication happen.  I will go one step further and say good communication makes for successful projects.

I have worked on waterfall, v-model, and agile projects.  If given the choice I will choose agile.

With waterfall and v-model I always found the massive amounts of documentation, document review, and the cumbersome process of reviewing changes to the documentation to be tedious.  In my opinion at times the process hindered communication.

With agile, lean, or Kanban we are afforded the opportunity to learn from our mistakes and quickly change the process.

But as to Lanette's point, agile projects can only be successful with excellent team communication.

So everyone who would like their projects to be successful sharpen your communication skills.