Network book cover is up

A total surprise for me. Cambridge still hasn't updated the book title on the page, but the proper book title is on the cover. I'm just delighted to see it coming out, and incidentally I like that the typeface and bars make it look a little similar to my other book's cover.

Here they are together, my two books, just hanging out.

Microsoft to buy Powerset, or Yahoo Search, or something

People are all excited about the rumor that Microsoft will buy Powerset to beef up MS Live Search. Of course, this succeeds the rumor that MS is back in talks with Yahoo to buy it or its search business. My sense is that the Powerset deal is a possibility, but MS is floating it now to keep Yahoo's stock from rising on speculation.

I remember this pulp cover for 1984

Cory Doctorow just reposted an excited blog post about a pulp fiction-style cover for George Orwell's 1984.(Click through to see the lurid cover.) The blog's author enthuses: "Significant is the artwork and over-the-top copy on the back, which is quite different from almost every other edition of this novel that I've seen."

The funny thing is that this is the version of 1984 we had when I was growing up. I think I read this thing when I was ten, and I remember feeling a little let down that the material was less exciting than the cover.

Big glossy love letter to Android in Wired

Google\'s Open Source Android Phone Will Free the Wireless Web

Reading :: Agile Project Management

Agile Project Management: How to Succeed in the Face of Changing Project Requirements
By Gary Chin

I've reviewed several project management books lately, and so far this is the best-of-breed in terms of defining agile project management, describing its need, and setting out a list of concepts for understanding it. The book isn't a set of heuristics and principles, nor is it a methodology, but it provides a solid basis for those other sorts of books.

Starting in the Preface, Chin argues that highly innovative businesses, especially those that push the limits of current technology, face challenges in discovery and planning that have not been encountered before. Such projects have inherent uncertainty, and face multiple paths, decision points, and iterations. Classic project management, he argues, is simply not set up for that sort of problem (p.vii). He ties this issue to the advent of the knowledge-based economy and acknowledges that although project management could be a key advantage for smaller businesses in this economy, classic PM is not well suited for helping them (p.ix).

It's not that classic PM is broken, he argues in Chapter 1, but it's been overextended. Agile project management is seen not as yet another extension, but a new foundational element (pp.2-3). The focus of agile PM moves from planning to execution -- a necessary move because

Agile PM Environment = [Uncertainty + Unique Expertise] + Speed (p.3)

or, in other words, the agile PM environment involves specialized problem solving that has not been done before, at the edge of experience, with rapid development. It's for startups in particular. Think in terms of software development, but also other lightweight tech-heavy development such as search engine optimization, social networking, and social media marketing. Organizations functioning in this space have "gurus" rather than interchangeable resources, working on problems that change from day to day, opportunistically incorporating new technologies to accommodate a rapidly shifting environment with both internal and external uncertainties. In contrast, classic project management assumes familiar problems, interchangeable expertise, unchanging objectives, and minimized internal and external uncertainty -- all signs of more mature industries such as construction.

I've discussed emergent organizational structures such as networks, federations and coworking on this blog. Chin doesn't quite get there -- he is still envisioning single organizations, multiple organizations, and single companies within multiple organizations (pp.17-20). Yet he edges closer to a federation understanding in Chapter 3, when he argues that in smaller companies, projects are the business (p.22) -- that is, a single project might be the central activity of the startup. In such an environment, classic PM, with its emphasis on project boxes that cut across silos, is not wholly applicable (p.25). Naturally, a project-driven organization is better suited to agile project environments (p.33).

In agile spaces, Chin argues, teams need to be boundary-crossers in order to solve new, multidimensional problems (p.43). Agile decision-making must be decentralized as well, pushed down to the level of the local team when possible (p.46); it is rarely handled through formal authority, most frequently through personal credibility established during the project (p.69). "The agile project operates in an atmosphere of high interactivity, boundary crossing, and multiple simultaneous pathways," he adds (p.79), which is to say (in my terms) that agile PM is a result of splicing dissimilar activities. It's not surprising (to me) that he points to telecommuters as good candidates for agile projects (p.94).

Chin goes on to offer some heuristics and practical approaches to implementing agile PM. But the real value in this book is Chin's sharp eye for the connections between classic and agile PM, grounded in the differences among organizations, industries, uncertainty, speed, and expertise. It's a great book for getting an overview of agile PM rationale.

Reading :: Managing Agile Projects

Managing Agile Projects
By Sanjiv Augustine

In my ongoing quest to read about project management and its permutations, I picked up Augustine's Managing Agile Projects. This book is focused on software development projects, as much of the agile literature is, but provides principles that could be more broadly abstracted. Like other books along these lines, this one takes pains to separate its brand of project management from more traditional, PMBOK-based project management.

The author draws heavily from agile programming and its variants (eXtreme Programming, Scrum, FD). But he also draws from a broad set of other concepts and frameworks, and the result is sometimes a grab bag of theories and concepts: complexity theory, memes (as cultural DNA), game theory, mental models, and communities of practice all make a showing without much to tie them together. But this book really isn't a theory book -- it's more about a set of organizing principles put forth as a compact or a constitution for governing team interactions. Augustine introduces this notion from the beginning with a clarifying "fable" based on an actual shift from traditional to agile project management (Ch.1).

Essentially, agile project management as it is described here consists of the following principles:

• foster alignment and cooperation
• encourage emergence and self-organization
• institute learning and adaptation (p.25).

Complementing these are the following practices:

• organic teams (small, flexible, composed of generalizing specialists)
• guiding vision (keeping the team aligned with the same "mental model" or "commander's intent")
• simple rules (generative process rules that can result in emergent organized behavior)
• open information (vs. information kept in silos)
• light touch (fostering emergent control rather than heavy-handed rules)
• adaptive leadership (continuously monitoring, learning, and adapting) (pp.26-29)

The author lists certain core values for agile project managers:

• trust
• collaboration
• learning
• courage (pp.38-39)

The rest of the book elaborates these principles, practices, and values and supplies heuristics for implementing them. Overall, these are well done, with clear guidelines and relationships. But, I hasten to add, the approach really does assume strong management backing to push through this compact, even though the end result is to get everyone else on board. Also, the approach is meant for larger organizations working on large software projects, and may not be appropriate for other industries -- too variable for longer-term manufacturing projects, too heavy-handed for smaller, lighter organizations with short engagements.

Plurk has third-party updating available via HelloTxt

... along with several other services. Have not tried it yet, but this was one big obstacle to using Plurk. Perhaps I will set up an account and double-update for a bit.

HelloTxt - Help SMS Gateway