One of the challenges as an organization becomes agile is what to do with HR and Finance. How can HR and Finance become more agile? In this series, I’ll address HR (Human Resources). (I’d actually started drafting this series a few months ago, but Diana Larsen pinged me with her note of Human Resources Is Dead. […]
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”
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
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
Have you ever worked on a project where the management and/or sponsors felt it necessary to provide you warnings: “This release better do this or have that. Otherwise, you’re toast.” I have, once. That’s when I started to use release criteria and check with the sponsors/management to make sure they agreed. I happen to like
I’ve said before that agile is a cultural change, not merely a project management framework or approach. One of the big changes is around transparency and safety. We need safety to experiment. We need safety to be transparent. Creating that safe environment can be difficult for everyone involved. John LeDrew has started a new podcast,
Culture is a combination of three things: how people treat each other, what people can discuss, and what the organization rewards. Team 1 has a project manager who believes in collaboration. She encourages people to move work across the board, regardless of how many people it takes to finish a story. The team members joke
In our projects, we solve problems all the time. We might solve customer problems—how to make this feature work the right way. We might solve project problems—how to get to continuous integration or how to build enough and the right kind of test automation to make it easier to release. We even solve so-called people
One of my colleagues wants to standardize all his agile teams on one process. He happens to like iterations, so he wants everyone to use two-week iterations. He wants them to use Scrum rituals and ceremonies. I understand what he wants to accomplish: gaining the ability to look across the projects and see the same
A project manager proudly told me he was agile. “We do standups every day. We work in iterations.” I asked, “How does the product owner like what you deliver every day or so?” “Oh, we only deliver once we have a hardening sprint, after our three development sprints.” He continued to describe what they do: