Work From Home? Three Ideas for Better Project Agility Samantha, an agile manager, had a big problem. Back before everyone had to work from home, they had pretty good results with their standard agile approach. However, now that this eight-person team worked from home, they had these problems: The team didn’t share the same work […]
Many people talk about “going back to normal.” We aren’t going to return to normal. That old normal is gone, at least for a year, if not longer. (I suspect we will cycle between remote work and office work for the foreseeable future.) What we can do is discover a new normal. Discovery requires different
Are you a manager accustomed to Management by Walking Around and Listening (MBWAL)? You can use MBWAL with collocated teams. MBWAL doesn’t work for distributed or dispersed teams. Remember, working remote is Not Business as Usual. (And won’t be for a while.) And, you might still have this question: “If no one’s in the office,
Three Collaboration Secrets to Create Your Agile Culture I’ve been working with managers and technical leaders on a big problem: How to create an agile culture. The managers and leaders want to create a successful agile culture. The people on the teams—they often want to be “left alone” to do their work. That’s not horrible.
Many of my clients feel stuck with their component teams. They feel they must implement across the architecture, not through it. That’s because the people are organized in component teams. As the organization grows, so does the number of component teams. The more component teams they have, the more complexity they create in the teams, in
A potential client called me. “What’s a good tool to see the state of my projects? I need a tool.” I asked, “What problems do you see?” “Everything is late. No one’s synchronized. I can’t tell where the projects are.” “How many projects do you have in progress?” “At least 100.” (I was pretty sure
What Happened to the Beautiful Plans? (They Became Experiments) Tim, a senior manager, loved seeing plans for work and roadmaps. Then, the organization decided to Embrace, Not Manage Change. Tim wasn’t sure how to track the work. This image helps me frame the need for an agile approach. (See the blog series: Where I Think “Agile” is
Shaun’s comment on Measure Cycle Time, Not Velocity suggested a team might be better off measuring both cycle time and velocity. Why? For two reasons: “Beating” the last sprint goal Assisting the PO in a forecast of when things might be done. Let’s examine these ideas. Clarify Story Points Why even bother with story points?
I’m not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes. (See Velocity is Not Acceleration.) Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish
Sprints, by definition, are a timebox. You’re supposed to say, “Pencils down!” at the end of the sprint, show your work and reflect. One of the big problems with new-to-agile teams is their inability to finish work inside a sprint. Each team is unique. However, I’ve seen these causes most often: Team members multitask, so