Post a Comment On: Steinn (Stan) Jónsson's Tech Talk

Last week Agile netið organized a remote seminar with Henrik Kniberg, award-winning keynote speaker and author of multiple Agile and Lean books.  The seminar was held at the Grand Hotel in Reykjavík, where around 10 Icelandic Agile enthusiasts gathered to remote connect to Henrik via Skype and Google Hangout.  We listened to Henrik talk about lessons learned at one of his recent projects and then had a long Q&A session, where we got to ask him all sorts of Agile and Lean related questions.  Despite an initial technical hiccup with poor sound quality the event was very enjoyable and informative.  Here are some of my take-aways. Basically random tips from the discussions that I found useful. [Image] If you need to explain to someone the benefits of limiting work in progress when running Kanban, use a traffic jam analogy: When there are not that many cars on a given highway, everything runs smoothly and we have a lot of cars running through the highway. But as we add more cars on the highway, basically everything starts slowing down to a jam and we have fewer and fewer cars that are able to drive the highway to the end.  The same thing happens in Kanban if we don't put WIP limits on our queues. Starting more tasks actually causes us to end up finishing fewer. [Image] If you ever need to sell to management the need to pay off a technical debt and refactor some legacy code: print out the longest class, tape the pages together and bring it with you to a meeting!  When you show up with a 5 meter long paper strip, showing some monstrosity of a class, people have an easier time visualizing the problem. When running a Scrum team, think about establishing a rule that each team member that completes a user story needs to ask the team if he can help out with a story that is already in progress before he is allowed to start work on a new one.  That encourages cooperation and limits work in progress, increasing the likelihood that we have fully completed stories at the end of the sprint, as opposed to stories that are partially done.  If our sprint backlog is 10 stories we would much rather have 8 fully completed stories at the end of the sprint than 6 completed stories and 4 partially done. According to Henrik, research has shown that incorporating QA into your agile development teams (testing continuously) saves on overall time spent in testing and bug fixing.  Meaning that if you test and bug fix as part of each sprint, as opposed to doing a large round of testing at the end of the project followed by a lot of bug fixes, you save time.  One reason for this is that when it comes time to fix a bug the code is still fresh in the developer's mind.  Also the continuous QA feedback encourages developers to deliver higher quality code.  This is visualized in the following illustration from Henrik's slides: [Image] Size doesn't matter.  According to Henrik having the team categorize user stories into small, medium and large before implementation is not very useful.  At the end of his project he calculated actual times spent on user stories and found out that it actually took about the same time on average to implement a story that had been categorized as small as it took to implement a story that had been categorized as medium. When you are on a large project that comprises multiple teams, try doing finger voting to assess the overall confidence that the project will get delivered on time.   Basically, in weekly meetings ask team leads to hold up fingers on one hand representing their confidence that their team will get the required work done on time.  Where 5 fingers mean "definitely", 4 fingers mean "likely", 3 fingers "it's a gray line", two fingers "probably not" and one finger means "no way".  Track this on a weekly basis.  If you get few fingers in the air, you know you have a problem that needs to be addressed. Try to make your development teams cross functional.  Each team should comprise all the skills required to fully deliver a feature (e.g. graphics designer, front-end developer, back-end developer, DBA, tester).  If a resource is needed at least 50% of the time put him on the team.  Make sure everyone has a home team, even though they might be outsourced to other teams from time to time. To check the health of a Scrum team use the Scrum check-list.