Jeff Gothelf

Lean vs Agile vs Design Thinking

Notify me when the book’s added
To read this book, upload an EPUB or FB2 file to Bookmate. How do I upload a book?
  • Marie Halkjær Kragelundhas quoted7 years ago
    The delivery aspects of Agile get visualized, measured, and executed. In this situation, Agile “wins” because the (valuable) activities of Lean Startup and Design Thinking rarely find their way into the same tools as the Agile activities. The result of this is that this work doesn’t get treated the same way as delivery work. It marginalizes the effort and allows it to be cut in the event of a time or scope crunch. Team members, often asked to meticulously track their time and effort on delivery tasks, are left to find time for discovery work “in the cracks” of their calendar.
    To avoid this, product discovery work must become a first-class citizen of the backlog. It must be visualized along with the delivery tasks. It must be prioritized against them and assigned to specific members of the team. It must be tracked like delivery tasks, and the implications of the discovery work have to be taken seriously.
  • Marie Halkjær Kragelundhas quoted7 years ago
    Post success metrics in public places around the office, and show how progress is (or isn’t) being made against those metrics.
  • Marie Halkjær Kragelundhas quoted7 years ago
    Balanced teams choose the best parts of Lean, Agile, and Design Thinking and apply them as needed in a tight col
  • Marie Halkjær Kragelundhas quoted7 years ago
    To combat this tendency, reconsider how you staff projects. The atomic unit of planning for any project is the team. The team is made up of designers, software engineers, and product managers at the very least. There is no “engineering team” or “design team” at the project level. These balanced teams provide the expertise, perspectives, and skillsets necessary for all aspects of a project.
  • Marie Halkjær Kragelundhas quoted7 years ago
    . Do less research, more often.
  • Marie Halkjær Kragelundhas quoted7 years ago
    The reality is, teams can’t test every task in their backlog. In fact, they shouldn’t. There are assumptions in every backlog that are riskier than others. Prioritize these assumptions based on their perceived risk and their perceived value. Everyone on the team should weigh in on risk, because each backlog item may present a different type of risk. For example, an item may have technical risk associated with it. An engineer would need to provide that perspective. Alternatively, that same item may involve design complexity that is deemed high risk. A designer will give that point of view. Risk could also manifest as market risk—an opportunity to provide services to a tangential audience from your core. Product managers are particularly good at providing competitive and market analysis in this situation.
  • Marie Halkjær Kragelundhas quoted7 years ago
    3. Put the customer at the center of everything. The customer is the person who has to use the product. It’s really as simple as that. Without customers, there is no business. There is no team. There is no product. Agile, Lean, and Design Thinking prominently tout the supremacy of the customer in all activities. Yet, each methodology offers a different definition of who the actual customer is. While Lean and Design Thinking generally align on “the person buying and using the product” as the customer, Agile often refers to product owners or “the business” as the customers. If they’re not using the product, they’re not the customer.
  • Marie Halkjær Kragelundhas quoted7 years ago
    . Hold regular retrospectives. Retrospectives are the heart of continuous improvement. They are a regular opportunity for the team to consider their current practice, evaluate its efficacy, and determine how to progress. Many teams who claim to practice Agile don’t hold regular retrospectives. Initial retros are uncomfortable and often feel like nothing more than venting sessions. Even teams who hold these sessions regularly often generate so much improvement material that it feels like very little is actually getting better.
    At the end of each sprint, encourage your teams to get together for an hour, review what worked well during that cycle, what didn’t go well, and commit to improving one or two key things each time. Oftentimes this will feel awkward at first but, after a few retrospectives, teams begin to open up more freely and address the core issues hurting their collaboration
  • Marie Halkjær Kragelundhas quoted7 years ago
    . Work in short cycles. Software is complex and unpredictable. So are people.
  • Marie Halkjær Kragelundhas quoted7 years ago
    For example, here’s a small experiment to run with your team to increase their amount of customer exposure (a value lauded by Agile, Lean, and Design Thinking): Every two sprints, the entire team goes out, together, to observe customers using your product for a half day.
fb2epub
Drag & drop your files (not more than 5 at once)