Friday, October 05, 2007

Reinventing Project Management

Diamond = Triangle++;

If you wanted to reinvent a subject that has much of its literature underpinned by a(n iron) triangle, how would you get beyond that? Add a fourth dimension and call it a diamond?

My initial reaction to Reinventing Project Management by Shenhar and Dvir was mixed. I was initially super-thrilled to see a publisher as prestigious as Harvard Business School Press publishing a book that openly talked about the need for a new model of project management. I was also impressed that the authors were from a solid academic background - respectively, the Management School at Stevens Institute of Technology and Management Department at Ben Gurion University School of Management. It was also important to see that the publisher was confident enough to get this book shelved in the “management” and “business” space in the bookstores and not in the “technical” space with the other project management books. However, the concept of getting one beyond the triangle with a diamond turned me off. It left me thinking - “ho hum, just another couple of guys with some consulting buzz words.”

Thankfully a quick skim through the book - I haven’t read it cover to cover - proved that my fears were ill-founded.

The authors actually espouse much of what we captured in the PM Declaration of Interdependence that formed the basic principles and foundation for the Agile Project Leadership Network (APLN). Particularly the concept that project management solutions need to be situationally specific. The diamond from the subtitle actually refers to a four axis spider-chart that helps to identify different types of project and different management approaches that are appropriate for them. Those four axis are: Technology; Novelty; Complexity; and Pace. The technique reminded me of work by Jim Highsmith or Alistair Cockburn, but with a different slant. I really got the impression that Shenhar and Dvir would be at home (intellectually) with the founders of the APLN, while their solid academic and management science credentials might open up the APLN thinking to a much wider audience.

While this isn’t a full review of the book, I do want to bring it to our collective attention and ask you to consider it as your next project management book purchase. To help you decide, I’ll summarize the main lessons from the book (paraphrased from pages 206-208).

• Project management is not about being on-time, on-budget, within requirements but rather about serving customer needs and creating business results
• Project management is not a linear, predictable process
• Project planning should involve early identification of needs
• Project management is not a universal activity with one set of rules and processes for all projects
• The right management style for each project needs to be selected to help identify risks and benefits appropriately
• Novelty represents uncertainty of the goal and uncertainty in the market
• Technology represents task uncertainty
• Complexity is based on the complexity of the product and the project being undertaken
• Pace represents the urgency of the project
• Project portfolios should be selected based on business goals
• Innovation should be managed according to its type
• Applying an adaptive approach to a project need not be difficult
• Projects with high uncertainty may require pilot projects to help reduce uncertainty
• Projects should be planned at three levels: milestones (in quarters or years); mid level goals (in months); and detailed plans (updated for the next month)
• Rolling wave planning (use of option theory and delayed commitment) is the correct approach for the more detailed levels of planning

Much of this will sound familiar to those of you aware of the work of the APLN and its founders. So it is hugely validating to see a different set of folks frmo different backgrounds come to similar conclusions based on solid academic study. [Note to self: Must invite the authors to get involved in the APLN.] Technorati tag: APLN, Project+Management

Thursday, October 04, 2007

Amit Rathore - new Lean Dev Blog

I really like this blog by Amit Rathore that I just discovered via Aaron Sanders, Epistemologic. Amit is talking about many of the same things I’ve been working on these past 3 years - applying Lean ideas to software engineering problems. Amongst other things he has independently realized that we should stop estimating because it is waste and replace it with something more value-added, that reporting actual velocity is the measure of success that matters, we should move to an iteration less process (like my kanban system), and use charts to plot WIP and identify bottlenecks.

Go add Amit to your RSS feeds now! It’s another Lean development blog not to be missed!

Related Posts: Stop Estimating, Agile Estimating, Kanban in Action, Managing with Cumulative Flow (BorCon 2004), FDD - towards a Lean Solution for Software Engineering (TOCICO 2004) Technorati tag: Agile, Software+Engineering, David+Anderson, Lean, Kanban, Amit+Rathore, Aaron+Sanders

Anatomy of an Operations Review

I get asked what we present at operations review every month. As you can see, we have a full agenda. One key element is that I’m not a presenter. I do open the meeting and close the meeting with just a couple of minutes of very quick remarks to set the scene, remind everyone about the month in review and why we do operations review, and I close by thanking those who contributed and organize the event each month. For the remaining 145 minutes, its the management team that each present their own material.

The agenda is as follows:-

• We lead with action items from last time - kaizen suggestions and follow up
• Then we have company level financial performance and sales performance by market sector etc.
• Next up we present departmental budgets year-to-date plan versus actual and year on year. And we list headcount, open reqs etc.
• Then we typically have a guest speaker from some other business unit who presents on what they do and how they rely on IT for support. Perhaps they focus on a recent initiative that we have supported. This helps connect our people to specific business units and work we undertake for them.
• Next up our business intelligence group reports on some recent release and typically gives a 3 month review of metrics on performance - might be revenue generated, or costs saved, or customer click-through etc etc.

Then we move in to the software engineering section of the agenda…

First we present sustaining engineering stats - throughput, lead time, due date performance on SLA, quality etc

• We then repeat this process for major projects and have our Config Management and SQA department managers present stats for work in the build lab, pre-prod support and quality assurance departments e.g. throughput of test cases written, lead time on builds, build breaks, time to recover a build break, server up time, server outages and so forth.

Then we have our downstream value chain partners present…

Change Control reports successful changes, sources of change failure and so forth

• Help Desk reports tickets and root causes

It’s fairly comprehensive. There are typically over 70 slides of data. We round out with a summary of issues and suggestions raised and we allocate owners for each suggestion/issue.

Related Posts: Operations Review Technorati tag: Agile, David+Andeerson, Lean, Kaizen, Organizational+Maturity, Agile+Management

Wednesday, October 03, 2007

Some other kanban activity

Scott Miller has been blogging about using kanban board in software development and how he went about designing his board.

Meanwhile, Business Lean blog has some advice on the trade off between an electronic kanban system versus a manual system. As many of you know I addressed these issues myself with the Sticky Buddy scheme and the Digital White Board. Technorati tag: Agile, Software+Engineering, David+Anderson, Lean, Kanban

Team Frustration Server

I thought I’d continue my short series on first year job frustrations, with my thoughts on Team Foundation Server and MSF. [At the severe risk of upsetting a bunch of my buddies across the lake in Redmond. ]

TFS has been an agent of change for me. But implementing it was painful. It comes with so much inertia that the team struggled for 5 months prior to my arrival and got nowhere. When I arrived I put some management weight behind it and supported the rollout with resources and political capital. In addition, I focused the efforts of my own direct line management team, by announcing that our first operations review would be held in December and therefore, we needed TFS in place by November 1st in order to have data to present. That gave us three months to complete the rollout. Using a date as a forcing factor really focused folks attention and the work got done. But, think about it - 3 months to roll out version control, work item tracking and reporting! That’s a long time and major management investment. For me it was one of my major “First 90 Days” initiatives.

Since then TFS has become an essential part of how we do our day-to-day work. We also use the TeamLook plug-in for Outlook and the former TeamPlain web client access now available from Microsoft directly. We have well over 100 users on the system. In fact so many non-technology folks now have access that I’d don’t actually know precise numbers. We have vendors using the system and storing their work items and test cases on our servers. We’ve developed a replacement user interface that simulates our kanban white boards. And that user interface has become the client of choice for many of the technology folks working on projects. I hear people refer to “Digital White Board” far more often than I hear “TFS” when I attend stand-up meetings. TFS has become part of the fabric of how we engineer software. [And now… here it is… drum roll please…] But…

Maintaining and supporting TFS has proven hugely expensive for us. We’ve had to invest heavily. While we value the investment - the team lives and breaths on the utility it provides - for an IT shop of our size the investment is non-trivial. We’ve had to invest in supporting work item type definition and process template customization, and in configuration management and Team Build expertise, but most of all we’ve had to invest in report authoring. Currently we have probably 3 headcount dedicated to TFS - one on reports, one on process templates and one on build and config management. Each of those folks but especially the process template and report guys have a long backlog of work.

TFS just isn’t a very agile tool and it doesn’t support so well, the kind of agile/Lean environment and culture, that I’ve built at Corbis. We find that our highly empowered teams are making process changes weekly. Kaizen events that change a process happen too often for a middle-manager like me to keep up with them all. Each time a process change is implemented, there is a work order generated for TFS changes - any change to a work item type definition creates a knock-on change to reports. It can be 4 to 6 weeks later before the electronic system catches up with the manually maintained system. This can lead to incorrect reporting and other funky side-effects in reporting.

We are also not using the out-of-the-box MSF process templates - though we do tend to customize from the MSF CMMI template by default. We like the CMMI template because it comes with an Issue work item type and a “proposed” state in many of the WIT definitions that easily enables our triage process. We almost always customize the work item type definitions and consequently break all the out-of-the-box reports. This causes inertia getting new projects spun up and tracked electronically.

We’ve also found that we have to abandon the MDX authored reports as we are unable to maintain them. We can’t afford to train a developer on MDX. This is a pity because some of the more valuable out-of-the-box reports (read some of the more powerful and complex) are authored in MDX.

We’ve also found TFS to be a lousy tool for continuous integration and we’ve had to abandon it and go with Cruise Control.

We’ve also abandoned the use of the MSF process guidance templates and we use our own custom developed Sharepoint wiki for process guidance. While some tooling has appeared from Microsoft as unsupported Power Toy releases allowing editing of process guidance after a Team Project is deployed, it came too late for us. We’d already committed to Sharepoint. The editing and support experience is nicer too. We’ve been able to open our process guidance up as a wiki where everyone on the team can provide edits. This means we can keep guidance up-to-date with process changes as kaizen events happen. If we were stuck with the XML of MSF then we’d probably have dedicated technical writing resources who’d have a 6 to 8 week backlog of process guidance changes to update.

While TFS continues to be a drain on our resources, and a ball that we drag on a chain slowing our progress, we really couldn’t live without it. It’s power and flexibility is unchallenged in the .Net space and possibly in the entire market. We’ve been able to develop innovative agile/Lean process solutions and put in place innovative reporting methods to provide feedback and management reporting. Powerful but niche products such as Rally, VersionOne, or FDD Tracker might be easier to use, require less resources, provide better and more powerful out-of-the-box reports but they don’t offer the flexibility and programmability and integration with version control, build and test that TFS can offer. TFS truly has been the enabler of our Lean solution, our Kaizen culture and our Kanban process for development scheduling and prioritization.

So we will continue to invest in TFS and it will continue to be mission critical for us. We have some advantages that we have very close links with Microsoft and we can use that influence to provide feedback and target the future direction of the product. However, as many of you will be aware the release cycle remains painfully slow. The interim Orcas release is delayed until next year and it remains to be seen when we get Rosario. Unfortunately the fix for many of the flexibility issues we have with WITDs, reports, process guidance and process definition probably won’t appear until the one after that, if at all. So I know I need to continue to budget for three people to maintain TFS for at least the next 4 years. This cost is justified as long as we continue to get the productivity gains we’ve seen. But my conclusion is that a full-blown TFS implementation like ours is not for the faint of heart. Go there at your peril!

Related posts: First Year Frustrations, One Year Anniversary, My Approach at Corbis, Digital White Board Technorati tag: TFS, VSTS, MSF, Team+Foundation+Server, Visual+Studio, Microsoft, Lean, TeamLook, Personify+Design, Software+Engineering