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 || No Comment
Posted on June 6th, 2013 in News & Updates by siddharta || No Comment
We just released a small new feature to the board functionality. You can now add a column policy or definition of done to a column, and it will show up on the board.
Just enter the details when configuring the board columns. Once you do that, an icon will appear on the board and you’ll be able to hover over it to see the column policy or definition of done.
Posted on April 14th, 2013 in Tools For Agile by siddharta || No Comment
One of the main reasons why Agile tool adoptions fail is not because of a lack of features or not enough reports, but something much simpler — “informal requests” that come in which never get tracked. This is not so much of an issue when you have a “strict” agile process where the product owner or equivalent is the only one through which all requests come in. But for many teams, requests come in to team members via email, via phone calls or even just someone going to a team member and making a request directly.
None of these informal requests ever get added to the backlog simply because it is too much of an effort for team members to open a browser, go to the server, log in, and fill up a form. As a result anywhere between 10%-30% of the actual work that team members do might not be tracked. Worse, it is sometimes unimportant work that ends up taking the time of a high priority task.
Compared to other tools, Tools For Agile makes it very simple to add cards to the backlog, but we can go a step further and make it braindead easy. Read on to see how.
Continue reading ‘Solving the “informal request” problem’ »