The nice folks at Planisware organized a webinar with me, called Scaling Agile. They recorded that, and you can hear the video here: Scaling Agile with Johanna Rothman. We spoke a lot about Agile and Lean Program Management. I referred to my multiple part series about Defining “Scaling” Agile. If you are thinking about “scaling” […]
I’ve been coaching several teams with a problem: they like to work in iterations. And, they have milestones that are not on a milestone boundary. What should they do? (I suggested flow and you should have heard their response. Well, maybe not.) Here’s why people want these milestones: The team can’t deliver (for whatever reason) as continuous
I had a blast with Tammy and Tim on the podcast (#88). We spoke about many topics: Consulting and marketing Women and computer science Writing and my workshops and books We spoke about writing earlier in the show, but at about minute 50, we spoke a lot more about writing. We laughed a lot!
There’s a twitter conversation about how to manage team compensation. How can we pay people what they are worth and compensate a team for their value? I know there are teams where I was quite valuable—not because I was “the” leader, but because I helped the team achieve our goals. And, there are teams where I
We might start to think about agile approaches as a project change. However, if you want to “scale” agile, the entire culture changes. Here is a list of the series and how everything changes the organization’s culture: Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams. Without feature teams, I don’t see how you can
One of the challenges I see in organizations is how managers can use agile approaches. One of the biggest problems is that the entire organization is organized for resource efficiency (think silos of functional experts). Agile approaches use flow efficiency. Thinking in flow efficiency changes everything. Many people in organizations believe that dividing up the
Bob Sutton (@work_matters) tweeted this the other day: Perhaps companies ought to stop using “IC” or “Individual Contributor.” It seems to absolve such employees from helping others I retweeted it and we had some back-and-forth about what to call people i organizations. Let’s eliminate these words for people who are not managers: Individual Contributor: There
Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance. In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream:
Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches: Part 1: Creating Cross-Functional Feature Teams (Teams that can produce features on a regular basis) Part 2: Programs of Cross-Functional Feature Teams (Programs (multiple teams working together) that deliver features on a regular basis) Part 3: Agile Product
As I finish the agile project management book (Create Your Successful Agile Project), I am working on what stays in this book and what I use in the agile management book (next up after the PO book). That leads me to this question: What do you call a transition to agile approaches? Is there a