Home > kanban, visualization > Current Kanban Board of TargetProcess Project

Current Kanban Board of TargetProcess Project

November 18th, 2011 Leave a comment Go to comments

Here is the snapshot of our real TargetProcess production Kanban Board taken today (November 18). You can see what we are working on right now, what is in progress, what is in testing and what will be released soon.

Categories: kanban, visualization Tags: ,
  • Anonymous

    Sweet good to see – not using team
    Board ;)

  • http://www.targetprocess.com/blog Michael Dubakov

    Well, we will kick Board+ next year that will replace all other boards ;)

  • Anonymous

    That sounds like a
    Good idea , I keep flipping between the two at the moment can’t wait :)

  • http://www.targetprocess.com/blog Michael Dubakov

    @anadin:disqus Another team uses Teams Board mainly. I like Kanban, it has better information density and provides better high level view.

  • http://www.targetprocess.com/blog Michael Dubakov

    @anadin:disqus We will invite you to Board+ usability testing in ~3 weeks (prototype is in progress now) ;)

  • Anonymous

    I agree, just the team board has some nice things too so I use both but would love one choice.

  • Anonymous

    Fantastic! Look forward to it

  • Vladimir

    Immediately apologize for my English.
    The question is, how the board displayed bugs that were discovered during testing?Or do you go in some other place?

  • http://www.targetprocess.com/blog Michael Dubakov

    @ee04b6348c21a0fb5132b050676d37f7:disqus There are 2 types of bugs- Bugs found in production are equal to User Stories and displayed as a separate cards
    - Bugs found in testing are equal to Tasks and displayed in user story card as a number.

  • Gabezzz

    Can I ask how many people are in the group? Are you using pair programming? Are tester and developer roles differentiated or anybody can work on anything? Is volunteering used?Â
    That’s all. ;)

  • http://www.targetprocess.com/blog Michael Dubakov

    @5304a206ca4f6ee346ee5b0b1311e592:disqus We have 2 teams. This is the board of Core team. Core team consists of 8 developers, 3 testers, 1 designer and 1 automated engineer. Developers write functional and all other tests, testers do manual testing. Developers pair at will. Usually for complex features or activities. All workplaces are designed to work for pair prog. There is quite strict roadmap, but developers often propose important technical initiatives. We try to not accumulate technical debt and write perfect code :)   

  • Gabezzz

    Thanx for the reply!
    So Core team has 13 heros :) . Isn’t this group too big? I mean a daily standup meeting could last more than half an hour.Â
    I’m asking this because I can see from the board that you have 9 as WIP limit and it seems to much for me. We had a group of 7 and the WIP limit was 4, so this way at least 3 pairs (one with strong skills regarding the given task, the other without) were set up every morning and the different competences were transfered really rapidly. We had no testers and developers, we had just colleagues :) . What do you think about this setup?

  • http://www.targetprocess.com/blog Michael Dubakov

    @5304a206ca4f6ee346ee5b0b1311e592:disqus Our daily meetings last up to 15 minutes. Your setup is perfect, but testers usually have quite unique set of skills and attitude, they like to find problems, while developers have another mindset. Developers like positive scenarios :) I wonder whether it is possible to transfer this skill effectively from testers to developers. When we started TP, there were 6 developers and no testers. I should say quality was quite a problem for us. To be honest, quality is still a problem, even with 5K automated tests…

  • Gabezzz

    Yeah, I know this, it is called testing genome. :) To tell the truth, some guys who were testers, mainly (let’s say in 75% of their work) pick up testing tasks. They’re just better in that. But they can do anything if they want. Volunteering is important.Â
    Regarding quality: do you use TDD, automated build, deploy and test processes, continuos (nightly) regression? What about refactoring? Those can really improve quality. I exeperienced it.

  • http://www.targetprocess.com/blog Michael Dubakov

    @5304a206ca4f6ee346ee5b0b1311e592:disqus We use TDD (BDD in fact mainly), CI, Automated functional testing on Selenium (we even have 25 virtual machines to run all the tests in 20-30 minutes). Definitely we do refactoring. We are heading into Continuous Deployment in fact (deploy after the every commit), but that is quite long road to ride. You can check more detailed post about our dev. process http://www.targetprocess.com/blog/2011/04/our-development-process-1-5-years-later.html

    Now we are focusing on better feature toggling and fast recovery in case of a bug. Also we are moving into a single trunk development (we have branch-per-userstory strategy).

  • Gabezzz

    Ok, so you are really improving, congratulations!
    Just a story about automated testing: we had a product which was almost 10 years old this summer. It was not a web application, although it had a sophisticated UI. At the end of August the number of automated functional (end to end) test cases was about ten thousand (10000), including 1500 selenium ui cases. We had more than 20000 unit tests as well. Our regression was run every night for 3 versions of the product (3 branches under version control), under Jenkins, including all tests, 10000 fute and 20000 ut – this means almost 90000 tests / every night. It was a really huge system with lot of HW…but it worked! ;) And everything was automated: building, uninstall of previuos, install new build, reinstall test environment (update test code), running and the collection of the results.Â
    It took approximately 3 years to build up this system. And we still had a lot of ideas to improve…but not really much time.Â