• Issue 43 - December 17, 2015

    For the final issue of this year, I’ve selected the best of articles from last 42 issues. All the best. Let’s get back to it in 2016.


    How to Scale Organisations Without a Power Hierarchy?

    How to empower people in an organisation without creating a wild-west? You’ve probably heard that Zappos (the famed online show retailer which was acquired by Amazon) pay $3000 to anyone who wants to quit the company during their first 4 weeks. They have sustained this model for years. How to create a very flat organisational structure which is not free-for-all? Can we get rid of (too many) layers of management?Is it possible to get rid of hierarchy and achieve growth in a cut throat commercial environment?



    SAFe or LeSS? Which One and Why?

    How to scale? Is SAFe (Scaled Agile Framework) really safe? Or LeSS (Large Scale Scrum) really more? Nokia is not the aspiring example it used to be, but SAFe and LeSS both grew out of Nokia, one way or the other. How did these evolve? What’s the difference? Here it is.


    How to Eliminate Dependencies, and Reduce Waste?

    SAFe (Scaled Agile Framework) suggests using an all hands-on meeting to plan a release train which consists of several sprints. A usual side effect of following this or similar techniques is that the teams will end up with several dependencies on other teams. It gets messy.  Delivery takes longer than it should. It’s bound to happen when program level people allocate work to teams. So how to deal with dependencies? Simple. Eliminate as many as possible. Here’s how.


    Why Depending on Your Scrum Master Can be Toxic?

    Many teams depend on their Scrum Master to solve problems. Scrum Masters become addicted to the helplessness of their teams. Once this pattern gets set, it’s very difficult to break. Consequently, the teams don’t get empowered. It’s toxic. Here are 4 tips to help you avoid this trap.



    How Does the Most Profitable Toyota Factory Work?

    Well, with a lot of manual work, and without a lot of computers. Yes, that’s correct. Toyota only automates dangerous work and the work that involves heavy loads. All other work is done by humans, because humans can improve the way they work. This is a fascinating account of a factory which produces 40000 vehicles, without a lot of automation, with 6000 employees. And yes, they do stop assembly lines there. This article is from 2008, but Toyota works to a 50 year plan, so they’d only have improved the process by now.



    How to Deal With Disruptive Team Members?

    Do these sound familiar, ‘this ain’t gonna work’, ‘I don’t care’ or ‘this will not work’. These are signs that you have a team member who’s a jerk, or a slacker or an eternal pessimist. Or a combination of it. These behaviours will bring the whole team down over time. How do you deal with these personality traits? Here are some ideas.



    Is This Time for Scrum to Die?

    Giles Bowkett says it’s time for Scrum to die. He has some concerns to say the least. Ron Jeffries looks into the case put forward by Giles, and provides a powerful counter narrative. A must read.


    Scaling Agile @ LEGO

    You’ve probably participated in an Agile-themed Lego game at some point in time. Wouldn’t it be cool to know how Lego, the company, have scaled their Agile initiative? How have they managed programmes and portfolio based dependencies? What people at various tiers have felt about the scaling effort? What’s “mount stupid”, and how to avoid climbing up one? Here’s a tall Henrik Kniberg gave regarding scaling Agile at Lego. (PDF)


    What Do Hamburgers and User Stories Have in Common?

    Both have layers. Both are modular. Both can be trimmed down to a slimmer version, or both can be served in gigantic heart-attack-on-a-plate manner. Though some would say that making a healthier and slimmer version of a burger is easier than splitting a huge user story into many smaller ones. Goijko uses hamburger analogy to slim down user stories.


    Why 100% Utilisation Mean Less Productivity

    Your computer is at its productive best when the cpu and memory are utilised 100%, right? No, of course not. Everyone knows that. So is your team at its productive best when all the team members are utilised 100%? How do we improve productivity without worrying too much about utilisation?