Posted on January 28th, 2014 in Agile, Kanban, Scrum by siddharta || 1 Comment
When teams start doing agile, one of the first impediments they usually run into is the inability to complete stories quickly. In Scrum that can result in stories spilling over sprint boundaries, whereas in Kanban in results in really long cycle times.
Do you have this problem?
Here are five ways to complete user stories faster
- Have smaller user stories: When you have smaller stories, developers finish stories earlier and testers can start testing them early. This way, testers dont get a big story to test later on. So, think hard about whether the stories can be further decomposed into smaller stories.
- Multiple developers work on the same user story: Don’t assume that only one person can work on a story. Look at your tasks and see if different developers can work on different tasks of the same story, so that it will be completed earlier. Also, dont assume that only a single person should work on a task. Sometimes it is helpful to pair multiple team members together to work on a single task.
- Automate some functional tests: When developers work on the development, testers can write automated functional test scripts during that time. Once development is complete, the actual testing time is reduced because you can just run the automated tests instead of manually executing each test case. As a bonus, over time you the improve the automated regression suite.
- Multi-skilling: Testers helping with simple coding tasks, and developers helping with test case execution are two ways multi-skilled teams work better. See how you can bring this capability in your teams.
- Co-located teams: You will be surprised how much time can be lost in communication between team members who are not co-located. Emails going back and forth over a period of two or three days is a big waste of time. By seating the developers and testers next to each other, a lot of wasted communication time is saved, and more can be completed.
Not all the above approaches are suitable for every team or every situation. The team needs to look at all available options and decide which is the best way for them.
Posted on August 6th, 2013 in Kanban, Lean by siddharta || No Comment
I recently did a short mini-webinar for SolutionsIQ on the topic of slowing down to speed up. The webinar is based on the systems thinking principle that local optimisations can sometimes be bad for the global system.
Often times in agile, we look for process improvement at the delivery team only. This is fine in the early stages when the team is the bottleneck in the process, but after about 8-12 months they stop being the bottleneck. At that point, it makes more sense to look at the rest of the system, rather than focusing on the delivery team alone.
See the video recording of the webinar below:
Posted on June 23rd, 2013 in Infographic, Kanban by Divya Sornaraja || 25 Comments
Posted on November 12th, 2011 in Agile, Kanban, Visual Management by siddharta || 1 Comment
Following up on a twitter discussion, Pawel blogged about alternative kanban board designs, and showed an interesting board with columns indicating priority and stickies on a card to indicate the tasks to complete. This motivated me to search for pictures of the board we used back when we first adopted agile process. Pawel says that exposure to “standard kanban boards” has meant that everyone has ended up with similar looking boards. I think to an extent that is true. This board was designed in 2005, much before there was a kanban method, and it doesn’t really look like a kanban board you would see today. In fact, I wouldn’t even call it a kanban board as it has no WIP limits or pull. It’s more of a team board visualisation.
Continue reading ‘Visualisation in Board Design’ »
Posted on September 7th, 2011 in Agile, Kanban, Tool by siddharta || No Comment
A lot of people doing agile want to use an agile tool for a vague notion of “tracking stuff”.
- That their execution will somehow be more “efficient” if a tool is used
- That by spending a little bit (or lot) of money, it can replace the time and hard work required to get agile to work
- That they can forget about process and do some other work
Well, if these are the reasons for using a tool, then I can confidently predict right now that your tool investment will fail.
There are many, many valid reasons to use a tool – where the tool can make a difference you could not do without it. But let’s be clear – all these reasons depend on your individual context, they do not universally apply for every team. Which is why you need to think carefully about your needs in a tool.
Continue reading ‘Do you really need an agile tool?’ »