On the bookshelves this year in the Agile Project Management category is Adaptive Project Framework: Managing Complexity in the Face of Uncertainty by Robert K. Wysocki Ph.D.
So, the executive summary: I like some of the ideas presented in the book. I do however feel that in the context that I am working in every day (a small web development company), that there does seem to be a little too much in terms of process for what we need. With a team of only a few programmers, and some jobs only lasting a couple of days work, we would be spending too much time following the process than actually doing the work. (But I'll address that at the end.)
So, let's start with some of the goodness.
The book has a much more academic feel than some of the others that I have read recently. What this means for you and me, is a much drier read. But it also means a lot more consideration, and thinking time has gone into the work - a book for chefs, not cooks and it covers a lot more of the why, rather than the what of the process.
One of the ideas I quite like was separating work flow into two types of work: probative and integrative swim lanes. Probative swim lanes are essentially a set of tasks that should be considered as research tasks. They are the process of investigating a particular direction of research. Thinking about the projects that I have been involved in over the years, it's a good way to get an idea of identifying how much work a particular feature might take to build. Developers are often guilty of over engineering and under-estimating their solutions, and the probative swim lane helps by spending some time looking at a feature to get a better idea of how long it will take to build. It's not about building the feature for production, but maybe trialling one aspect to see if the original estimate was correct or not, or to see if the choice of technology was a good idea. (It makes me think of the point made in Mythical Man Month where, if the development is 25% behind before the first milestone, then the next milestone will be 50% behind, and so on. Probative swim lanes help to identify this kind of issue very early on by doing some deeper research before making the estimate.)
Integrative swim lanes are where the real work is done for producing the completed product. That is, tasks which will take the project closer to it's goal and will be part of the solution. When a project starts, most of the swim lanes will be probative. Adaptive Project Framework (APF) follows the general Agile Management Methodology in that there are checkpoints along the way to assess work done so far.
Once enough research has been done, and the best solutions (at the time) have been identified in the probative swim lanes, they are then moved into integrative swim lanes at each checkpoint where they can be completed and contribute to the final solution.
Other aspects of APF that I think are worthwhile are the two resources (well, one is a document, and it's a little iffy about what the other is): the Conditions of Satisfaction (COS) and the Project Overview Statement (POS). (I'll have to admit, I kept forgetting what all the TLAs meant while reading the book. An index of terms at the end would have been nice.)
The COS is a conversation to help give an idea of what is required. In the book it states it should ideally be a verbal conversation. (This related to one of the books pitfalls, which I'll cover later.) In general terms this could be thought of as a project brief, something to get the ball rolling.
The POS is a document which helps keep the project on track, and helps identify when the project should stop - either by satisfying the goal(s) or by being killed off. The POS includes the problem or opportunity to be solved, the goal(s), the objectives, success criteria and risks and assumptions.
The author has a long history of project management, and has written a previous book that is used extensively as a textbook in educational institutions. One aspect of this book I find useful is that it puts APF in the context of other project management methodologies. If you're familiar with other Agile Project Management Methodologies such as Scrum, then you'll start mapping the terminology of Scrum onto APF, or the other way around. It is also quite clear that APF is not just for software development but any development process in the arena of the service or knowledge economy. That is, APF can be used for business re-engineering, course development or any other intellectual property based project.
The author is quite aware that this is a new framework, and expects change to occur. One of the reasons behind naming it Adaptive is to state that he expects it to change. Calling it a Framework also shows that it works at a meta level, and can be used to assess its own management processes.
So where are the pitfalls in the book? The first is a general one that I see. The author doesn't really discuss the use of distributed project teams or processes. He thinks (and I feel most Agile Methodologies have this problem) that the team should be co-located. Putting up the project information in the tea room is a nice idea, if everyone is together (and drinks tea.) But in today's distributed knowledge economy, that just can't be a given. It's a small point, but one that needs to be addressed more.
The second, and again I feel that most Agile Methodologies have this problem, is that it deals with large projects. I haven't seen any methodologies yet (that doesn't mean they don't exist, just that I haven't seen them) that deal with small projects, or projects run in parallel. The idea where the team can be devoted to the project 100% of the time just won't work in a service based, small project environment. We quite often have 3 or 4 projects (or more) running at the same time all at different stages, sometimes we have to wait a week for the client to get back to us. I can't see following a pure APF process really working.
That said, for the larger projects that we undertake then the ideas presented in the book would definitely work. (And for us, are working.)
Read more…