One of the really nice things with physical cards is that you can easily annotate it with stickies and other things such that the story card conveys a huge amount of information right at a glance.
For instance, lets say that one feature requires having a conversation with Bill. This is not a formal task that you want to track, but its just a kind of ad-hoc reminder on something that needs to be done.
Doing this with physical cards is easy! Just take a small sticky, write “Talk to Bill” on it and slap it on the story card. Done!
You’ll never forget with the sticky right there on the card. When you’re done, take out the sticky, tear it up and throw it away.
This simple operation can become extremely complicated with an electronic tool.
That’s the kind of problem we always grapple with.
How can we make the board as simple, visible and flexible as a physical board, but retain all the functionality that electronic tools excel at?
Creating Ad-hoc notes in Silver Catalyst
So here is how you can create ad-hoc notes in Silver Catalyst and get them to display on the card in the board.
It’s very simple really.
Just go to the project settings and add a new custom field as shown below. Lets call this field ‘notes’. Set the type to text.
And…you’re done!
Now if you fill up this notes field, it will appear on the card on the board. Just like the image below.
Over the last few months I’ve noticed one anti-pattern come up again and again. This anti-pattern is very common in the agile community, but now its jumped over to kanban as well. It’s the dreaded local optimization.
One of the slides from my talk at LSSC was about multiple projects being developed in parallel. (Slide 15)
Background
This was when I was working at Innvo Systems, around 2004-05. The company had got one round of venture capital financing and we were about 20 people strong with one acquired product. We were looking for another round of funding and the pitch was to use the money to scale fast, update the current product to latest standards and complement it with a complete suite of products (3 in all). The pitch worked, we got funded and the race started to scale as fast as possible and build up the suite.
Within a few months, the company scaled from 20 people to a peak of about 50. Around 30 were to be involved with the new product development roadmap, and were split into three teams.
Work on each of the products proceeded in parallel.
What we expected
When we first started out, the plan was that each of the products would be completed in about 12 months. So we would then have a complete suite ready to take to market.
What actually happened
What actually happened was that we were too few people to build three major products from scratch. With three teams, each of the teams ended up being understaffed. In addition, all the experienced folks were divided up among the teams, leaving each team with predominantly the new hires. A substantial portion of time of the experienced folk was spent getting new hires up to speed on the specialized domain.
The end result was that all three teams limped along and it took a lot longer than expected for the complete suite to be finished.
Lessons learned
Instead of working on all products in parallel, it would have made more sense in committing all efforts to one product. When it was complete, the team could have moved on to the second product and later the third product.
By doing this we would have got one complete product out much sooner. We could then take this product out to market and start booking revenue right then, without having to wait for the other products.
Further, it would have made more sense to have one solid team, rather than four understaffed teams. One team of about 15 might have worked out better than three teams of 10. A bonus would be that we could then put all the experienced people in this one team and thereby reduce the ratio of new hires to experienced people. This would have reduced the ramp up time before the team got productive.
One team, Sequential projects
Multiple teams, Parallel projects
One solid complete team
Each team is understaffed and short of resources
Best team members work together
The best team members are divided up
Specialists are first class members of single team
Harder to manage specialists common to multiple teams
New team members rise up to the level of other team members
Experienced team members need to step down to the level of other team members
Silver Stories has an Enterprise Kanban board to track the flow of MMFs from the story tree. In this screencast we explore the functionality of this board. In the process we show how Silver Catalyst can be linked up to execute upon the backlog created in Silver Stories, and the expand-collapse pattern for enterprise kanban boards.
Silver Stories allows you to create flexible team configurations. Have multiple initiatives that are executed by the same team? Have one initiative that is executed by multiple teams?
Check out this video to see how you can handle this in Silver Stories
One of the really nice things with physical cards is that you can easily annotate it with stickies and other things such that the story card conveys a huge amount of information right at a glance.
