It’s issue number 100. To celebrate Issue number 100, here are most read pieces from those 100 issues.
We’ve seen how Agile helps us deliver increments of value in a rapidly changing market. Agile is good for dealing with complex problems. Running a business tends to be complex, given the highly competitive and rapidly changing business environment. How about using Agile to run a whole business? Here’s how a consultancy firm has been running the entire company using Agile techniques.
Over the last twenty years we have been rather successful at getting Agile to work with a single Team. Nowadays, we want to use Scrum with tens or even hundreds of teams, and an overly simplified approach to scaling might introduce big problems. While, scaling Agile has become its own industry, as more and more enterprises want the benefits that Agile can promise. You can tell by the number of papers, talks, trainings and certification programs around it. What to watch out for? Read on (pdf).
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.
Imagine a very healthy Agile team. What does it look like? How would you identify that this team is in a great shape, and has covered a lot of ground on its improvement journey? How would you know while the team over there is at beginner level, and has a lot of work to do? A visual indicator would be very useful. Here’s a model that they use at Spotify to help them identify team health at a glance.
How do you devise an effective product strategy? What is the foundation of your product strategy? How do you balance business goals, your unique value proposition and key features? And how does market dynamics fit into this? Roman Pichler describes how it all comes together.
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.
Though both are scaling frameworks, SAFe and LeSS target two different local optimums. Does SAFe really aim to reduce bureaucratic control enough to move the organisation away from the traditional optimum or does it only try to optimise the existing organisation by creating Lean-Agile programs? Doe LeSS inherently reduce the bureaucratic control? A very interesting perspective.
How to foster a culture where real creativity thrives for decades? Creativity Inc. is one of the best books I’ve read during last year. It’s the story of how Pixar was founded, how it became a wonderful hit-creating machine, and remained so even after the Disney acquisition. How does physical environment set the tone? How to set a vision? Most importantly – how to provide feedback without spoon-feeding solutions, and without sounding overbearing? Steve Blank provides an excellent summary of the book.
How do we turn the traditional “Leader-Follower” culture found in most organisations into “Leader-Leader” behaviuor? How do we begin to embed the capacity for greatness in the people and practices of an organisation? How can a leader enable this and decouple his own personality while doing so? Here are a few lessons from a US Navy Submarine Commander.
Whether you think about your prioritised features or changes leading to good user experience, it is pure speculation until validated. Continuous discovery means an backlog where everything is considered. Whether it’s speculation or hypothesis. Continuous validation means that the user experience is validated for each release, rather than up front. But this sounds like an expensive exercise, for teams with very large budgets. How about the teams on a very tight budget? Here’s a case study on how a small team on a tight budget achieved this.
What’s the right question to ask. Is it, “when can the development teams deliver the product?”. Or is it, “when does the business really need it?”. And business needs mean when can we start generating real value with the product. Business needs should drive schedules, engineers need to create solutions which fit within business schedules. Here’s a model take takes into account the cost of delay to help us plan better.
You run continuous integration and have automated test. But, some of the tests exhibit both a passing and a failing result with the same code. Puzzling. That’s flaky test. There maybe many reasons for this, i.e. concurrency, relying on non-deterministic or undefined behaviours, flaky third party code or infrastructure problems. But how do you deal with the flaky tests? And how do you eliminate those? Here’s how teams at Google do it.
Lengthy, 50-page requirements or long Product Backlogs are not reliable ways of conveying all the subtleties of a digital product. Readers quickly get bored and even worse, misinterpret what is written. Prototypes expand each user story into a tangible part of a system. If user stories express task-level goals, then prototypes can help us see the horizontal feature set (breadth) and vertical feature set (depth) required to fulfil each story. Here’s a practical guide to quick hands-on prototyping technique.
Your product may already be obsolete. You may not know that, yet. Product people need to be acutely aware of all the different technological shifts happening in the industry and consistently ask ourselves if and how these things actually affect us? This is not just some dry strategic exercise. If you don’t do it your business could die an awful lot quicker than you expect. Here’s what to watch out for.