Gil Broza and I are thrilled to announce the updated version of our flagship workshop, the Influential Agile Leader. If you have these kinds of challenges: Your business can’t “stop” to recreate itself as an agile organization. You need to continue and to nurture the cultural changes necessary for a successful agile transformation. You don’t […]
I’m (finally!) circling back around to Joe Berkowitz’s statement: There is no template for how to be a good man in the #MeToo era. I said that respect provided that template. (And, we can say “good people” instead of only men because abuse of power is not limited to men. See Power, Management, and Harassment: It’s
I started this series positing that respect is the cornerstone for how we might treat each other, to manage our interactions with success, especially in light of the #MeToo conversation. The series so far is: Organizations Are Not Families, Part 1. Why the metaphor of family-as-org demeans the people working there. Build Respect in Organizations,
I wrote about treating each other with respect in Organizations Are Not Families, Part 1. In these respect posts, I’ll address possible ways we can treat each other with respect. These are not the only ways. You might have better ideas than I do. Please do comment if you’ve seen alternatives that work better. I
I started this series positing that respect is the cornerstone for how we might treat each other, to manage our interactions with success, especially in light of the #MeToo conversation. The series so far is: Organizations Are Not Families, Part 1. Why the metaphor of family-as-org demeans the people working there. Build Respect in Organizations,
I read Joe Berkowitz’s story in Fast Company, John Oliver Was Right: It’s Time To Confront The Dustin Hoffmans In Your Life. There’s a link to a video excerpt in which Hoffman discusses the idea that the people felt like a family. Mr. Berkowitz says this: There is no template for how to be a good
What should managers expect from their agile teams? Should they expect perfect code, or on-time delivery, or cheaper projects? Too many people sell agile as a way to get better, faster, cheaper. The problem is that you can get better code, faster projects, and cheaper results as an outcome of agile across the organization. We
Back in Manage It!, I suggested that for requirements, the questions should be, “How little can we do?” and still have a great product. My argument was this: the longer the project (regardless of approach), the more risk there is. Can you reduce risk by reducing the requirements? That would allow you to release earlier
I have a new book in beta, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. (The in beta part means that it is in copyediting, and then onto layout and print. It’s a process.) I’m so excited about this book. My three most recent Pragmatic Manager newsletters were about jelled teams: The Case For
The Case Against Stable Teams, Part 2 In The Case for Stable Teams, Part 1 , I wrote about stable teams as a way to create jelled teams. My guideline was that the longer it took for people to be useful in the team, the more you needed a stable team. Otherwise, the cost of