How to Manage by “Walking Around” When You’re Remote If you’re like me, you learned a lot by walking around and listening when you were in the office. I saw and heard the state of the various teams. I could see in-progress work. I could see and hear how the team members treated each other. […]
Three Tips to Move from Agile in Name Only to Real Agility Several of you have written to me, asking about the problems you see. Your managers focus on certifications, practices, and vanity metrics—not real agility. The managers don’t understand how agility can help them. You see cargo cult agile. You worry that agility is
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?