Influential Agile Leader, Boston and London, 2016

Is your agile transition proceeding well? Or, is it stuck in places—maybe the teams aren’t improving, maybe the people are multitasking, maybe you are tired and don’t know how you’ll find the energy to continue. You are the kind of person who would benefit from the Influential Agile Leader event in Boston, April 6-7, and in London, May 4-5, 2016. Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your business challenges. If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us. Super early bird registration ends January 31 for London. Our super early bird for Boston is sold out, and the early bird registration is still a steal. If you have questions, please post a comment or email me. Hope to work with you there. (See the servant leadership tag for the Pragmatic Manager  and the leadership tag on this blog to see relevant articles I’ve written...

Resource Efficiency vs. Flow Efficiency, Part 5: How Flow Changes Everything

The discussion to now: Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability When you move from resource efficiency (experts and handoffs from expert to expert) to flow efficiency (team works together to finish work), everything changes.   The system of work changes from the need for experts to shared expertise. The time that people spend multitasking should decrease or go to zero because the team works together to finish features. The team will recognize when they are done—really done—with a feature. You don’t have the “It’s all done except for…” problem. Managers don’t need to manage performance. They manage the system, the environment that makes it possible for people to perform their best. Managers help equip teams to manage their own performance. The team is accountable, not a person. That increases the likelihood that the team will estimate well and that the team delivers what they promised. If you are transitioning to agile, and you have not seen these things occur, perform a retrospective. Set aside at least two hours and understand your particular challenges. I like Agile Retrospectives: Making Good Teams Great, Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises, and The Retrospective Handbook: A Guide for Agile Teams for creating a retrospective that will work for you. You have unique challenges. Learn about them so you can address them. I hope you enjoyed this series. Let me know if you have questions or...

Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability

This is the next in a series of posts about resource efficiency vs. flow efficiency: Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability: Accountable to the project for finishing their own work Accountable to their team for participating fully by doing their work Accountable to help other people learn what they did by documenting their work Accountable for meeting their estimates Accountable for how the project spends money … There might be more accountabilities Let’s take the first two together: Accountable for finishing their own work and by doing their work I suspect that managers mean, “How do I know each person does their work? How do I know they aren’t asking other people to do their work? How do I know these people are learning to do their own work?” Those are good questions. I have yet to see a single-person feature. At the least, a developer needs someone to test their work. Yes, it’s possible to test your own work. Some of you are quite good at that, I bet. Many people are not. If you want to prevent rework, build in checking in some form or another: pairing, design review, code review, unit tests, system tests, something. So the part about “own work” seems a little micro-managing to me. The part about doing their work is a little trickier. When people get stuck, what do they...

Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance

Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System explains resource efficiency and flow efficiency. Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People explains why flow efficiency helps you get features done faster. Here, in part 3, I’ll address the performance management question. New-to-agile (and some experienced) managers ask, “How can I manage performance? How will I know people are accountable for their work?” These are good questions. Performance management and accountability are two different things in flow efficiency. Here are some ways to manage performance: Ask for the results you want. Ask the team to work together to produce features. Create communities of practice to help people learn their craftsmanship. Provide the team members with the knowledge of how to provide feedback and coaching to each other. As a manager, you provide meta-coaching and meta-feedback to team members. (The team members provide each other feedback and coaching, managing their daily performance.) (See also Four Tips for Managing Performance in Agile Teams.) If you do these things, you will discover that people are accountable to each other for their work. The point of a standup is to help people vocalize their accountabilities. If the team works as a swarm or as multiple pairs/triads/whatever, they might not need a standup. They might need a kanban board with WIP (work in progress) limits. If your organization likes iterations because it provides boundaries for decision-making or providing focus, that works. It can work with or without a kanban board. Here’s a question I like to ask managers, “Have you hired responsible adults?” The managers almost always say, “Yes.” They look at me...

Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People

If you haven’t read Resource Efficiency vs. Flow Efficiency, Part 1: Seeing the System,  I explain there about optimizing for a given person’s work vs. optimizing for features. Some people (including managers) new to agile have questions about working in flow vs. optimizing for a person. The managers ask: How do I know the work won’t take longer if we move to flow efficiency? How do I do performance management if a single person isn’t responsible for his/her work? (What’s the accountability, etc.?) This post is about the length of the work and how people feel when they can’t finish work. When you have experts, as in resource efficiency, the work queues up behind the expert. Let’s say you have three senior people with these separate expertise areas: Cindy has deep knowledge of the internals of the database and how to make things fast. (I think of this as the platform.) Brian has deep knowledge of the transaction layer and how to move data from one place to another in the product. (I think of this as the middleware.) Abe has deep knowledge of how to present data to the customers and how to create a great customer experience. (I think of this as the UI layer.) You want Features 1 and 2, which have significant UI impact. Abe is a master at iterating with all the necessary people to get the UI just right. In the meantime, Cindy and Brian go on to Features 3, 4, and 5 because they aren’t needed (yet) on Features 1 and 2. If you measured cumulative flow, you would see that all...