Author: J.D. Meier

J.D. Meier has lead distributed teams around the world on time, on budget, high impact for more than 10 years. He is the author of Getting Results the Agile Way, which is a book on how to be "Agile for Life." J.D. shares proven practices for personal effectiveness at SourcesOfInsight.com. He is currently on the Enterprise Strategy team at Microsoft where he is in the business of business transformation with technology, and focusing on business value creation and business value acceleration. Check out 30 Days of Getting Results, a hard-core free training on mastering productivity and time management.

The Art of the Agile Retrospective

I’ve been asked to do a lot of Agile retrospectives around Microsoft over the years.  I don’t know how it started, but it started several years ago when somebody recommended that I lead a retrospective for their team, and then it caught fire from there. In this article, I’ll share a simple recipe you can use as a baseline to help shape your Agile retrospectives for building high-performance teams. Agile retrospectives are a powerful way to help teams go from good to great, and to help less than good teams, get better fast.   The value of a retrospective is the learning and insight that you can carry forward.  A retrospective is a look back with an open mind on the collective learning around what to start doing, stop doing, and continue doing. With that in mind, the true value is in the actual change in the people, process, or technology that supports your ability to flow value. To drive a great Agile retrospective, it helps to know what gets in the way or what goes wrong: Lack of clarity on outcomes Lack of focus during the retrospective Too much debate and not enough dialogue. Below is a recipe that you can use that should help you get started or improve your retrospectives.  Nothing is set in stone, but it helps to see some things that have worked time and again (the timeless truths.)  Be sure to adapt as you see fit, but at the end of the day, remember that establishing is important, and that your best outcome is a short list of what to start doing, stop doing, and continue doing – that you actually implement. Keys Set and agenda with a timebox (and allow plenty of time to really dive into the issues) Ask what went well Ask what could be improved Outcomes List of highlights and wins Inefficiencies and improvement opportunities Contextualized best practices Flow Agenda Celebrate accomplishments Brainstorm what went well Identify what needs improvement Talk about the details Identify 3 actionable things to carry forward, with dates and owners (accountability) Scrum Master sends out summary Switching Perspectives I’ve found two Edward de Bono techniques help deal with conflict during hot topics are: The Project Management Institute (PMI)® (Plus Points, Minus Points, and Interesting Points) – What’s the upside? what’s the downside? and what’s interesting about this? Six Thinking Hats – A way to switch hats to switch perspective to see multiple angles on the same topic. I find these techniques help keep an open and curious mind.  Especially if you use them in a question-driven way and keep it simple.  Rather than have people arguing different sides at the same time, have them argue the same side at the same time, and then switch perspectives (or “hats.”)   Category Items The Hats · White Hat – the facts and figures· Red Hat – the emotional view· Black Hat – the “devil’s advocate”· Yellow Hat – the positive side· Green Hat – the creative side· Blue Hat – the organizing view Questions · What are the facts and figures?· What’s your gut reaction?  How do you feel about this?· Why can’t we do this?  What prevents us?  What’s the downside?· How can we do this?· What are additional opportunities?· How should we think about this? (what are the metaphors or mental models) Dialogue, Debate, and Discuss Sometimes, the best way to help people stay open and Dialogue – listening with an open spirit. Debate – listening to win an argument — a verbal “fight.” Discuss – listening to break apart an issue and pushing a winning idea. How to Shift to Dialogue: How might that be true? What is it you see that I don’t? How do you see this differently and why? Highlights / Wins Highlight 1 … Highlight 2 … Highlight 3 … Affinity Exercise You can skip doing an affinity diagram exercise, if folks are comfortable with each other and there’s no recent new members.  Otherwise, it’s overhead, but it helps for the following: Get people to open up Get more people contributing Give people time to think since new members bring up more issues There are other tricks of the trade, but if you focus on a clear agenda, compelling outcomes, and manage the conflict while driving an open dialogue, you’ll be in good shape. May the power of Agile retrospectives serve you well.

Kanban: The Secret of High-Performing Teams at Microsoft

If you are a project manager or a program manager, or aspiring to be, one of the best project management tools you can add to your toolbox is the Kanban. In fact, if somebody were to ask me, what’s the single best way to exponentially improve project execution, I would probably say, the answer is Kanban. (Well, I might first say, get my book, Getting Results the Agile Way, and adopt Agile Results A Kanban is a simple project management tool. It enables you to visualize your workflow, limit your work in progress, and optimize your “cycle time” (the time it takes to complete one item.) For software development projects, this is a big deal. It helps you find bottlenecks and push quality upstream. Ultimately, you shape your process to flow more value as efficiently and effectively as possible, “just in time.” Another way to think of it is, your users “pull” value through your development chain, while you streamline your process. I first got introduced to Kanban, several years ago, by one of the best and brightest in software engineering, Corey Ladas (author of Scrumban.) My introduction was a “learn by doing” exercise. Identify State Changes in Your Workflow We went to the whiteboard and Corey has me identify the main states of my project workflow. While it was iterative, and a lot of work was done in parallel, the main stages were: Analysis, Design, Development, Test, and Release. It looked something like this:   Identify Work Items Next, Corey asked me to identify the “things” or “items” that I would show on my Kanban. I had a hard time breaking things down into useful units until I used a simple test. What’s the smallest, most useful thing I could demo to users? For simplicity, let’s just say I broke things down into features and user stories. In this case, a user story was simply a persona-based scenario with a goal. In my case, I also needed some “system” stories. The bottom line was that each of these was a “chunk” of value that I would ship to users. Corey had me name some of these items and write them down on stickies. He then had me place them wherever they were currently at on my Kanban. It looked something like this:   What surprised me was that he didn’t ask me to change our team’s process. The goal was simply to reflect whatever process we were already using. The most important thing was really to identify the most meaningful state changes in our workflow, and to identify the work items that flow through it. He said the power of the Kanban is that we would tune our process over time, with real data and real results. It’s a living thing. And it’s a visual thing. Set Limits for Work in Progress The next thing Corey had me do was to set a limit for how many items should be actively in development at any given time. I struggled here at first because I was used to having a lot of work in flight. He pointed out the problem with a lot of work in flight is that there’s thrashing, and more time spent context switching than actually finishing the work. Worse, if we’re not closing things down, then we aren’t flowing value. He said, to keep it simple, as an experiment, set the limit at 3. Find out what your team can do. For example, with focus, how quickly can we close down an item? Where does the bottleneck happen? Which resources are idle? Could idle developers pair up with testers and unblock test, for example? He got me thinking.   Push Quality Upstream This is where the magic happened. Corey asked me to identify some of the most common issues found during Test. I rattled off a few common problems. He then asked me what I could check for before entering test. We then repeated this process a few times until we had a few simple checks before we leave Analysis, and before we leave Design, and before we leave Development. It sounds so simple, and it is,   But the big deal was having it all at a glance, on the whiteboard.  We could now easily get the right people at the board, having the right conversations. A Living Process The beauty is that we ended up with a unique process for our team — built by us, built for us, and optimized by us. As a team, we could now all visualize our process. We could easily see our bottlenecks. We could easily add quality checks. We could easily add more states to our Kanban if we needed more fine-grained visibility. We basically achieved a highly-flexible, highly relevant process that struck a balance between self-organization and workflow specialization. Kanban for Execution Excellence That was the start of my Kanban adventures, long ago. In the years since, I’ve experimented with Kanbans, personal kanbans, Kanban tools, and various approaches. The Kanban has proven itself time and again for me as one of my most effective project management tools. It really is “just enough process” combined with a focus on flowing value and improving quality. It’s one of the best tools I’ve used for driving execution excellence across people and teams in an empowering and self-directed way. When the question is, “How do we improve our execution?” … even if Kanban is not the answer, it’s very often as good place to start. After all, if you can show somebody your Kanban with current activity, chances are you can find the bottlenecks and optimization opportunities. At the minimum, you’ll have a shared frame of reference, the visualization of your process, which is a great way to dive deeper to troubleshoot any execution issues.