I have been working with Scrum for last 3 years time and I came across the concept of Kanban while going through the on demand course list of PluralSight. During my carrier I have heard about Kanban and wanted to learn more about it. After following through the on demand course got to understand that with Scrum we are using some concepts of it such as task boards. But I got to know that it is also ideal for managing your personal work as well under the concept called Personal Kanban.
So I thought of using Kanban to manage my personal work to increase the productivity than usual. I decided to go ahead with this because it is quite hard to keep track of the work items that came to me. Sometimes I even end up in missing one or two work items.
With Kanban we need to do two things.
1. Visualize the work
2. Minimize the work in progress
By doing this we can increase the value flow.
So I was desperately need of some mechanism to keep track of my daily work both official and personal work. So I initially used a physical board with some sticky notes as my experimental Kanban board. Bellow is my Personal Kanban board.
This was my personal work tracking Kanban board for about six months. It helped me a lot to keep track of my day today work and the best part was I never missed any work item at all.
Also I used “T-Shirt” sizing to prioritize the work (XL, L, M, S). This helped me to visualize my work and always I managed to keep 3 items in the current ongoing work. I didn’t add any other task to the in progress list until I complete at least 1 item. Even if I want to add any other high priority work I can see what Items will be affected. Above all I was able attend to more work items per day.
Actually I did this when I was working from home for an Australian employer. This was my first experiment with Kanban and believe me apart from all the benefits that I got, it is actually fun and you can enjoy what you are doing. Also when time progresses you get motivated when you see the progress and you will instinctively add more work.
Under this topic I’m going to discuss another issue which I came across, i.e. the team is not ready and/or not used to automated testing. Due to the rapid delivery cycles automated testing is vital for agile practices. I’m saying this because if you try to implement manual testing during two to four weeks sprint the QA team will have a loads and loads of unfinished testing at the end of the sprint which will be carried to the next sprint. This will not end up in single sprint unless you add more resources or allocate a separate sprint to catch up, you will always fall behind. The only feasible solution is to implement the automated testing. If it is new to your company then implementation is one of the tedious and most difficult tasks, but failing to introduce this will be a challenging task for the QA team to keep up with the bug list during shorter sprints. It is worth to take an early decision on the implementation of the automated testing. Ideally there should be a framework for this which will ease the writing of automated test scripts during the sprint. If not then it will consume the project time if we would start from the scratch. So do not include this step in the project unless you have experts and the knowledge in this area. That is if you are planning to implement agile then make this decision as early as possible and allocate couple of developers and one or two QA members to get the automated test framework done, because it is a worth of an investment.
During my work as a Project Lead I had to work on planning the sprint. One of the current projects that I was leading used Agile with Scrum Methodology. So at the end of each sprint I had to conduct planning sessions for the next sprint. Planning Porker was introduced in the planning process and it was really fun when it comes to the planning.
Our planning sessions became more entertaining and above all the Planning Porker made the end results successful, which is at the end we have estimated the User Stories very successfully. There are many Planning Porker methods and we used the one from Mountain Goat software. The card deck contained the following values: ?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity. We also used a check list against the to determine the relative complexity of the user story (back log item).