Tag Archives: Agile
It’s MAD to Use Discovery to Justify the Solution
Have you ever had an executive, a board member, or some other high-ranking person tell you what to build? How were you able to stand up to them? And keep your job? Decreeing the solution happens with such regularity that my Product Owner course is designed to mimic the situation.
It’s MAD to Put All Work Through Discovery
I was sitting with a team when their manager came in and asked, “Hey. Are you guys finished with this feature?” The Scrum Master responded, “We haven’t even had time to even begin the discovery on it yet.” The manager looked surprised and said, “Oh, OK. Would you let me know when I can see it?” and walked out. It really surprised me as the feature seemed trivial and so I asked, “What do you need to learn about this? It seems really straight-forward.” “You’re right.” he said, “We could just build this. But we don’t want to.”
It’s MAD to Have a Separate Discovery Phase
Here we are with another Misadventure in Agile Discovery (MAD). This one pairs well with the first misadventure, the separate discovery team. Even when that mistake is corrected and a balanced team is working together through discovery and delivery, the team may decide to spend some time furiously creating a slew of new ideas.
It’s MAD to Have a Separate Discovery Team
Diving deeper into the first item on the list of Misadventures of Agile Discovery (MAD), let’s look into the problem of having a separate discovery team. Let me start with a couple of stories.
Misadventures in Agile Discovery: Top Ten Common Mistakes
I’m going to admit something to you as an Agile coach. Clients that I work with make mistakes, and I can’t prevent them all. I don’t even try to.
Consequences of Thinking, Fast and Slow on Teaching
Here’s another post in the series of how the book Thinking, Fast and Slow has made an impact on me. This time, I’d like to concentrate on the consequences I see for teaching classes. For starters, I’m glad to see that the book compliments the things I learned from Sharon Bowman’s Training from the Back of the Room, as well as from Chip and Dan Heath’s book Made to Stick.
Describing Agile Product Discovery
Agile product discovery works in tandem with delivery. The best effect comes when it includes the whole team, is done deliberately and continuously. The video includes the common roles, artifacts and ceremonies involved in discovery. While this is the first of many iterations to come, I hope you enjoy! What questions do you have, or feedback you would like to provide?
How to start discovery on your Scrum team
How do you get started with discovery on your Scrum team? Participants learn how to improve practices like user research and interviews, persona sketching, design studio, prototyping and story mapping by actively using them in a class. At the end of the class, participants see a different way of working. Then the discussion turns to something like- While this is undoubtedly is a better way to work, it’s so different than what we do today. How can we do this stuff where we work? How do you get started?
Consequences of Thinking, Fast and Slow – Blog Series
Have you read the book Thinking, Fast and Slow? Getting asked that occasionally I did little more that watch a video of it from AsapSCIENCE), so that I could nod vaguely as the person who asked me talked about it. Picking it up more than a couple of years after its release I made my way through it all, pausing frequently. Pausing because it’s information dense and I needed to process what I was reading. And as I processed, it made me think about what it means for how I teach and coach people.
dual track Scrum in brief
Coining the term “dual track” Desireé Sy‘s Adapting Usability Investigations for Agile User-centered Design(pdf) (2007) might be one of the first examples drawing out and labeling a process knows as dual track Scrum and stating, Although the dual tracks depicted (…) seem separate, in reality, interaction designers need to communicate every day with developers. This is not only to ensure that designs are being implemented correctly, but also so that we have a thorough understanding of technical constraints that affect design decisions