Agile Management Blog

David J. Anderson's Agile Management Blog - The agile manager's recipe for success: focus on quality; reduce work-in-progress; balance demand against throughput; prioritize!

RSS FEED IDEMS: Agile Management Blog

  • Announcing Modus Cooperandi

    26 years ago I started my first business working with 3 school friends developing and selling computer games for the Sinclair ZX81 computer. It's amazing to think that it is almost 20 years since I ran my own business and could call myself an entrepreneur. Well I'm finally getting back to my roots. And again it is with 3 friends whom I've known and worked with for several years, Jim Benson, Corey Ladas and Daniel Vacanti. Together we have just started Modus Cooperandi, a consulting firm dedicated to improving leadership and management in knowledge worker industries. A firm that will pride itself in helping clients deliver superior results and become more competitive.

    We've occupied the offices of Jim's old business Gray Hill Solutions on Seattle's Lake Union and we've opened up shop offering consulting on agile and lean enterprise transitions and training classes in Agile Management and Kanban. We intend to be leading the move to a more collaborative, higher trust, more open, more networked, more socially connected way of working in the 21st Century.

    If you've been reading this blog for a while and wished, "if only we could hire David to come and help us..." or "I wish David taught classes in this stuff..." then your wishes have been granted. If you'd like to talk to me about helping you and your business be more successful, click the Hire David link on LHS navigation bar or drop me an email.


    Saturday, March 01, 2008

  • Kanban and Real Options in Dallas

    Feb 22nd is the next chance to see me present the kanban approach to software engineering, at the APLN Leadership Summit in Dallas. Chris Matts is presenting Real Options on the same morning and this is great opportunity to see us both on the same day and understand how kanban and real options combine as a very powerful solution for scheduling and prioritization for optimal value delivery.

    Please support the APLN by signing up for the conference and coming along to see Chris and I present in Dallas.


    Thursday, January 31, 2008

  • Purging the Kanban Backlog

    One of the PM's in our office calls it a "clean out." From time to time you should purge your kanban backlog to keep it fresh and relevant. The backlog is either a set of requirements for a project or program or a set of change requests for a sustaining engineering effort. There will always be new backlog incoming as the business changes and people have new ideas. Depending on this incoming rate compared to throughput of software delivery, the backlog may be growing, or at least not falling. A significant backlog is a problem. It affects your agility because things spend time queuing and that queue time is waste. Meanwhile, the request or requirement my be atrophying in relevance or ability to generate revenue as a differentiator.

    Purging the backlog is similar to a bug triage effort. You simply need some criteria to decide whether something stays in the backlog or is dropped. It could be very simple. For example, "anything over 6 months old is dropped." This simple rule fits with the real option theory nature of kanban pull prioritization. If something isn't important enough to get selected over a 6 month period, it probably isn't important enough - period!

    Naturally, a more complex set of criteria is possible. You might want to assess the alignment with strategic, operational and tactical objectives of the business. You might want to assess alignment with particular customer segments or even specific customer orders. As we do, you might want to consider whether a change request is obviated with a forthcoming major release, or is requested on a system due to be decommissioned at some known point in the future.

    Regardless, of your criteria, I'd recommend that you purge your backlog regularly, at least quarterly and perhaps monthly. Keeping the backlog healthy and relevant serves the business by simplifying prioritization discussions for kanban slots and by reducing queuing time and improving overall business agility from ideation to delivery of working software.

    Related Posts: Kanban in Action, Recipe for Success Technorati tag: Agile, Lean, Kanban, Software+Engineering, Project+Management


    Sunday, December 02, 2007

  • Enterprise Scale Continuous Integration

    Back in January when I spoke at the OOP conference in Munich, I described how I didn't believe that continuous integration scaled to enterprise level. Indeed, we hadn't managed to make it work. What we were doing was taking a more Lean approach to integration - little and often - and moving to fewer codelines. We were achieving this by implementing latent code patterns that enabled several projects to live in the same environment and avoid the problem of new code accidentally escaping in to the wild when another project was due for release.

    This was all very well and given enough time and enough focus on Lean principles we might yet have evolved to a continuous integration approach for the enterprise but it would have taken years.

    For the past six months I've been lucky enough to have Troy Magennis on my staff as our Enterprise Architect. Troy brought a wealth of experience in .Net and C# and large scale Microsoft technology projects to our team. Given that we suffer numerous impacts to our productivity with the constant challenge of code line management, integration, build and environment build out and reset, Troy refused to accept that continuous integration wasn't possible, and indeed in his view it was essential to eliminating waste and maintaining a regular flow of valuable software in to our production environments.

    So together with one of our architecture team and a toolsmith from our configuration management group, they spent some considerable time and effort tackling the problem of how to build our entire enterprise code base in a continuous fashion. A few weeks ago, they finally achieved it and we now have cruise control reports on the state of our enterprise code base at any given time.

    This doesn't mean that our enterprise DEV environment can be pushed to production whenever we choose. At least not without successful implementation of latent code and full regression testing to show that the new code is truly latent, but the result is that we have reduced our code line maintenance to a single line for all major projects in our portfolio plus a branch for sustaining engineering (released on a 2 week cycle).

    At my prompting Troy has gathered his thoughts on Does Continuous Integration Scale to Enterprise Projects? what it takes to achieve enterprise scale continuous integration and how to implement it, in a white paper available over on his blog. You can get it in PDF here. The main takeaway from this article isn't a revelation about configuration management or build tools. The key to enterprise scale continuous integration is solid enterprise architecture and enforcement of good software engineering principles of loose coupling and high cohesion across all projects in the portfolio.

    Yes, all you agilistas out there! Architecture does matter, if you are to scale agile techniques to the enterprise! Technorati tag: Agile, Software+Engineering, Enterprise+Architecture


    Tuesday, November 27, 2007

  • Bugs and Kanban

    Corey Ladas takes a look at two ways to treat bugs in a kanban system. The second option is the more challenging. It requires patient courageous management. My feeling is that option 2 will produce the net higher velocity (and throughput) in the long term because it teaches the team to really focus down on prevention of bugs while option 1 treats bugs as part and parcel of the business of software development. While option 1 will suffer a throughput reduction as bugs increase, there is far less incentive to focus on eliminating them altogether.

    Ideally, I'd like to run a side-by-side comparison over a 6 to 9 month period to compare these two options. How are you dealing with bugs in your kanban system? Like option 1 or option 2 or do you have you own alternative approach? Technorati tag: Agile, Lean, Kanban, Software+Engineering


    Tuesday, November 27, 2007

  • How big can an effective standup be?

    This is a picture of a standup meeting on a large project at Corbis. Today I counted 41 attendees. The attendance has averaged 39 or 40 every day for 6 weeks. Daniel Vacanti can be seen far-left leading the meeting. The kanban board is behind him out of shot. [Not everyone is standing as some are sitting at their actual desks in the communal work area. This meeting happens every day at 9.30am. It's generally over within ten minutes.

    Corey Ladas has blogged about how the Lean Kanban process scales differently and how a standup can be effective with very large numbers of people. The key is that we don't enumerate through the people asking them what they have done and will do and whether they are blocked. We enumerate through the kanban cards on the board and discuss whether work if flowing and what if anything is blocking it.

    This project has 6 dev leads and 6 dev teams working concurrently. If this were a scrum project we'd have 6 independent scrums followed by a scrum-of-scrums with only the leads (assuming the lead is playing the scrummaster role.)

    I see pros and cons to the big meeting. It is efficient. It gets the whole team together, not just the sub-teams. But it clearly isn't as personal. And the claimed peer-pressure aspect of a scrum standup meeting is missing.

    What we are finding is that some of the dev teams hold a brief huddle afterwards for just their own team. This is entirely optional, doesn't happen every day and doesn't (generally) happen in front of the kanban board - more a design coordination meeting than a project tracking meeting.

    Is anyone else running standup meeting with larger than the recommended scrum size of 6 to 12? What are your results? What's the largest effective standup meeting you've been a part of?

    Photography: courtesy Laurence Cohen
    Related Post: Lean Scales Differently than Agile, Corey Ladas Lean Scales Differently than Agile Technorati tag: Agile, Lean, Kanban, Software+Engineering, Scrum, David+Anderson, Corey+Ladas


    Wednesday, November 14, 2007

  • Kanban Workshop Dec 3rd
    Have you been wondering about how a Kanban board really works for software development?  Come to the next Seattle APLN meeting in three weeks and find out.

    Who:      Darren Davis, Manager at Corbis
    What:     Kanban workshop
    When:    Monday December 3, 5:30pm - 7:30pm
    Where:   Avanade Inc. ( 2211 Elliott Avenue, Seattle, WA)
    Why:      Learn the advantages of a true single-piece flow pull system and how to implement it in your organization

    From Darren:

    The software engineering team at Corbis has spent the last year creating and running a development process based on the principals of Lean Manufacturing.  Using this process, we have released over 190 change requests and bug fixes at regular two week intervals with very high quality and minimal management overhead.  Critical to the success of this process has been the use of a Kanban board.  Using such high-tech implements as post-it notes and Sharpies, we have created an information-rich way of controlling the amount of work in progress, minimizing inefficient multitasking, identifying and addressing blocking issues and exposing untracked work.

    This presentation, in workshop format, will define a software development workflow and create a Kanban board to track work through it.  We will demonstrate the use of post-it notes and other visual clues to provide transparency into the development process in a way that technical and non-technical people can easily understand.  We'll finish up by running a standup, at the board, to illustrate how the board is used day-to-day to organize and manage development work.

    My earlier blog post Kanban in Action discusses this process and shows Darren at the Kanban board.

    Please RSVP to Dragos Dumitriu (dragosd at avanade dot com).  If the door is locked call Dragos (425.260.9283) or David Socha (206.418.8201).

    To receive all Seattle APLN emails, subscribe to our Yahoo! Group.

    More information is at the Seattle APLN wiki.


    Wednesday, November 14, 2007

  • APLN Leadership Summit in Seattle?
    The APLN Seattle Chapter would like to organize a Leadership Summit next spring. We're looking for project managers in the Seattle area to help with the event planning. If you'd like to help organize a fun conference for project managers and are interested in getting involved in the APLN locally, please leave a comment or drop me an email to david dot anderson at corbis dot com. We've already secured a venue and we have volunteers for business development to drive the sponsorship program. We need someone to help coordinate the agenda, the invitations, the speakers and organize a fun social event in a nearby hotel. If you're up for it and perhaps have some previous event planning experience, we'd love to hear from you. Technorati tag: APLN, Project+Management
    Monday, November 05, 2007

  • Kanban Warranty Claims Processing

    Tom Hopper has implemented a kanban board for processing warranty claims following his attendance at the Lean New Product Development Summit in Chicago earlier this year.

    Related posts: Lean NPD Summit Report


    Thursday, November 01, 2007

  • Javapolis Sessions

    Here are the full abstracts for my two official Javapolis conference sessions...

    UNI: (Monday 10 December) The Zen of Agile Management

    What is the essence of agile management? How do you create a culture of continuous improvement? With light touch, empowerment, delegation, high levels of trust, and focus on the correct leverage point to drive maximum advantage. Learn the Zen of agile management! A set of techniques developed by David J. Anderson over the last 8 years through his experience managing teams at Fortune 100 companies such as Motorola and Sprint using Feature Driven Development, Microsoft Solutions Framework (and Team Foundation Server) and his latest work at Corbis using Lean ideas such as kanban. This half-day workshop dives into the heart of how to manage with queues using kanban boards, cumulative flow diagrams and application of wider ideas in management science, to software development process. Through David’s experience as senior director of the software engineering function at Bill Gates’ private company, Corbis, you will learn how to scale Agile and Lean techniques enterprise-wide.

    CONF: (Friday 14 December) A Kanban System for Software Engineering

    Ideas from Lean Thinking have been growing in popularity with the Agile software development community. Over the past year, the use of kanban (literally signal cards) popular in manufacturing has been seen as the significant innovation in managing agile work and is growing in adoption at firms such as Yahoo! David Anderson introduced the first electronic kanban system at Microsoft in 2004 and has since extended the technique through his work at Corbis. Kanban acts to limit work-in-progress and focus the team on achieving a continuous flow of value to the customer. Kanban innovates on accepted agile management practice by providing an iteration-less process with a regular release cadence. It helps achieve a balance of demand against capacity on the team and eliminate multi-tasking. David will present a brief history of the technique through case study reports from teams at Microsoft and Corbis. The kanban system enables David to deliver on his Recipe for Success: focus on quality; reduce work-in-progress; balance demand against throughput; and prioritize. Technorati tag: Agile, David+Anderson, Agile+Management, Javapolis, Kanban, Software+Engineering


    Tuesday, October 30, 2007

Submit your RSS Feed

Subscribe to this RSS Feed

Copyright © 2006-2007 Listopica, Inc. RSS Feed Directory