|
See also the XP,
XP Skills, and
Lean Thinking pages.

|
|
Agile Modeling,
Scott Ambler. Wiley, 2002.
Agile Modeling focuses on a particular problem: how to model well but
quickly. (It's not attempting to be a complete methodology, but rather a
part that plugs into another methodology.) (Reviewed Nov., '02)
|

|
|
Agile Management for Software Engineering,
David J. Anderson. Prentice Hall, 2004.
This book applies throughput accounting to software development.
(This approach originated in Theory of Constraints and fits with lean
manufacturing) Throughput accounting focuses on the rate of sales as the
key metric; inventory is regarded as an overhead. By contrast, traditional cost
accounting values inventory and high
utilization. Anderson's experience is with FDD, and that's where the book
makes its case most cleanly. (When it talks about Scrum and XP, it seems
to bend their spirit a little to fit into the framework.)
There's some repetition, as he repeats the analysis for various processes.
This makes sections a little dry on a straight read-through, but I suspect
this will be a strength if you go in for reference with respect to a
single process.
Overall, the topic is somewhat specialized, and this is not something developers would typically read.
(It does say "Management".) But I find it cheering as a part of a
trend of books on agile software management, that tie into the experience
in the lean manufacturing world.
(Reviewed May, '04)
|

|
|
Managing Agile Projects, Sanjiv Augustine. Addison-Wesley, 2005.
Sanjiv answers the question, "What do managers do on an agile
team?" to say that they have many functions: team building, alignment,
adaptation, and more. I particularly appreciated the chapter on using a
"light touch." Throughout, the author suggests a number of activities that
a team can try to build up its capabilities. (Reviewed Sept., '05)
[Disclaimer: I was an advance reviewer, and have had a modest business
relationship with the author.]
|
 |
|
Balancing Agility and Discipline: A Guide for the Perplexed. Barry
Boehm and Richard Turner. Addison-Wesley, 2004.
Overall, this is a balanced treatment "agile" and "plan-driven"
methods. (My biggest complaint is the title; if it had been "Balancing
Agility and Planning" I think it would have been fairer. As Alistair
Cockburn points out in one of the forewords, you can have low- or
high-discipline agile methods.) The authors present the
characteristics of both approaches, and then create a risk-based
"scorecard" that tries to balance the risks and benefits of each.
Their conclusion is that the different methods have different home
grounds, and new methods need to balance both. Especially if you've
been looking at only classical methods or only agile methods, this
book is recommended. (Reviewed Sept., '05)
|

|
|
Crystal Clear, Alistair Cockburn. Addison-Wesley, 2004. Crystal Clear
is a software method that uses frequent delivery, reflective improvement,
and osmotic communication as guard rails to guide a team in development.
This book presents a number of perspectives on the methods; my favorite is
the catalog of acceptable work products. (Reviewed Jan., '05)
|

|
|
Agile Software Development, Alistair Cockburn. Addison-Wesley, 2001.
An excellent overview of agile development. "Software as a cooperative
game of invention and communication." Individuals and teams. Charts as
"information radiators." Describing methodology (it's harder than it
looks). Methodological success: it delivered, the leadership stayed
intact, and people would work the same way again. Agility as
self-adaptation. "Barely sufficient" methods. The importance of
reflection. Description of the Crystal family: Crystal Clear
(incremental delivery, without quite as much required discipline as XP),
Crystal Orange (for teams of up to 40 people), and Crystal Orange Web
(modified to support a particular web team). Analysis of the agile
manifesto. Finally, includes selections from "Programming as Theory
Building" (Naur), "On Participation and Skill" (Ehn), and "The Book of
Five Rings" (Musashi). (Reviewed Nov., '02)
|
 |
|
Agile Estimating and Planning, Mike Cohn. Pearson Education, 2006.
My back-cover review was "Mike Cohn explains his approach to Agile
planning, and shows how 'critical chain' thinking can be used to
effectively buffer both schedule and features. As with User Stories
Applied, this book is easy to read and grounded in real-world
experience." Let me add that he also discusses estimation, prioritization,
some financial analysis, and monitoring. (Reviewed Jan., 2006)
|

|
|
Wicked Problems, Righteous Solutions: A Catalogue of Modern Software
Engineering Paradigms,
Peter DeGrace and Leslie Hulet Stahl, Prentice-Hall, 1990.
This book is a critique of the waterfall model, and a description of a
number of alternative models. It has an early description of Sashimi and
Scrum applied to software. (Sashimi draws overlapping phases like slices
of fish; Scrum gives a team a goal around which it can self-organize.)
This book is mostly of historical and background interest. (Reviewed Nov., '03)
|
 |
|
The
Deadline: A Novel about Project Management, Tom DeMarco, Dorset House,
1997. A thought experiment in novel form: what would happen if we could
run the same project multiple ways in a project management laboratory? The
main character keeps a journal of all the project management ideas he
gets, including things like thinking of a jelled team as a project
deliverable, what an analysis or design needs to include, consequences of
pathological management, and the benefits of small teams (at least at the
beginning). (Reviewed Feb., '03)
|
 |
|
Software by Numbers, Mark Denne and Jane Cleland-Huang. Prentice-Hall, 2004.
An MMF - "minimal marketable feature" - represents a unit of
functionality that has value. This book shows how incremental delivery and
incremental funding of MMFs can work together to improve the value created
from software projects.
(Reviewed May, '05)
|
 |
|
DSDM: Business Focused Development, 2/e, by the DSDM Consortium,
edited by Jennifer Stapleton. Addison-Wesley, 2003.
DSDM is an agile software method. It grew out of experience with RAD
(Rapid Application Development) in the mid-1990s. Its focus is most heavy
on the front end, without a lot to say about how the software is
implemented per se. The first principle they have is "Active user
involvement is imperative"; they use timeboxing and dictate iterative and
incremental development, and require that decisions be reversible. I liked
the first half of the book (explaining the philosophy and practices) a lot
better than the second half (case studies). That might just be me though.
(Reviewed Feb., '04)
|
 |
|
Domain-Driven Design, by Eric Evans. Addison Wesley, 2004. Evans has developed a pattern language that focuses on how
thinking about our domain needs to be of primary importance in developing
software. This understanding should show up consistently in how customers and
programmers talk about the domain, as well as in the code. His language includes
discussion of key architectural concerns such as an effective persistence
mechanism and layering.
People have struggled with "what's
a metaphor" in XP. His pattern language provides the concrete notions of
"ubiquitous language" and domain modeling to make that area more concrete. He
has a wonderful example of how a shift to talking about "share pie" and "share
arithmetic" solved a lot of persistent rounding problems in financial software.
(I would call this a metaphor; I'm not sure he would.)
Like Design Patterns, this is a book that deserves to be studied and
expanded on. This will still be a significant book years from now
(Reviewed December, 2003.)
|
 |
|
Requirements by Collaboration, Ellen Gottesdiener. ISBN
0-201-78606-0. Addison-Wesley, 2002.
Workshops are an effective place to capture requirements - getting the
right people in the room, working together well, they can reach
important agreements about what is needed. This book focuses mostly on
workshops: how to organize and run them. While there's a little bit
about particular documents or approaches for requirements, this book
is focused less on those techniques and more on the workshop itself.
(Reviewed Sept., '05)
|

|
|
Adaptive Software Development: A Collaborative Approach to Managing
Complex Systems, Jim Highsmith. Dorset House, 2000. (Reviewed
Nov., '02)
|

|
|
Agile Software Development Ecosystems, Jim Highsmith. Addison-Wesley,
2002. Descriptions of several agile methods, and Interviews with their
creators. (Reviewed Nov., '02)
|

|
|
Software Craftsmanship,
Pete McBreen. Addison-Wesley, 2001.
Makes the case that software is neither art nor science, but craft, and
that we should organize our education and work life to reflect that.
(Reviewed Nov., '02)
|

|
|
The
Knowledge-Creating Company, by Ikujiro Nonaka and Hirotaka
Takeuchi. Oxford University Press,
This book describes how organizations can use the dynamics of knowledge
creation; I've created an extended description and discussion as an
XPlorations article.
(Reviewed Feb., '04)
|
 |
|
Agile Project Management with Scrum,
Ken Schwaber. Microsoft Press, 2004.
This book presents stories from several
software teams adopting Scrum. It takes stories from several perspectives
such as "The Product Owner" or "Scaling Projects using Scrum." What I like
best is that he describes the situation, and then tells you how the team
addressed it, so you can practice your own thinking about how you'd
improve projects. (Reviewed Nov., 2004)
|

|
|
Agile Software Development with SCRUM,
Ken Schwaber and Mike Beedle. Prentice Hall, 2001. Scrum explicitly
relies on the emergence of a true team. By focusing on 30-day sprints,
daily standup meetings, and management's ability to remove obstacles, a
team has an environment in which to flourish. There's also the idea of a
"Scrum of scrums," which I think has the best potential for large-scale
agile teams. (Reviewed Nov., '02)
|
 |
|
Paper Prototyping, by Carolyn Snyder.
Morgan Kaufmann, 2003.
The "Scandinavian design" tradition in human-computer interaction says
that people should be involved in creating the systems they will have to
use. Electronic tools for rapid screen design may provide a high-fidelity
view of how a system will look, but they do so by creating a privileged
group (the software people who know the tool). Paper prototypes overcome
this by putting everybody on an equal footing. Furthermore, they do so
cheaply.
Snyder describes how to create and use paper prototypes of user
interfaces. While she describes some systematic ways to use them, this is
a lighter approach (and less broad) than something like Constantine and
Lockwood's Usage-Centered Design. That doesn't diminish the book's charm.
I particularly liked the chapters that showed how to construct pages for
panes, scroll-bars, etc. It left me feeling like, "I could have worked my
way here, but somebody's done the work for me." (Reviewed Dec., '03)
|
 |
|
Radical Project Management, by Rob Thomsett.
Prentice Hall, 2002.
I don't know why the title says "Radical", as throughout the book it's "eXtreme
Project Management." Thomsett develops a project management approach that
considers value throughout the project's whole life cycle. He works
through a lot of issues around stakeholders, risks, and estimation. He has
a nice "slider" tool that lets stakeholders say what's important to them.
I don't think this is the most agile project management approach
imaginable, but I could see it helping teams work interface with large
projects and more traditional project management. (Reviewed Feb., '04)
|
 |
|
Quality Software Management, Volume
1: Systems Thinking, Gerald M.
Weinberg, Dorset House, 1992. Starts with "What is quality?" Looks at
management patterns for software development, and highlights the
importance of feedback. Uses system models (that show interconnections
with reinforcing and damping feedback) to examine the impact of management
and the need to steer. Considers the challenges of steering, and of
customer feedback.
Weinberg applies these tools to look at quality and errors. Errors
are hard to find, and resolving one problem can create others. Finally,
he looks at how stress and pressure can cause breakdowns in teams.
(Reviewed Nov., '02)
|
 |
|
Quality Software Management, Volume
2: First-Order Measurement, Gerald M.
Weinberg, Dorset House, 1997. First-order measurement is the use of
back-of-the-envelope calculations sufficient for building something.
Weinberg relates Satir's interaction model (intake, meaning, significance,
and response) to software management.
The author suggests some good metrics, and there are some effective
graphs to go with them, but the key value of this book is more in learning
to think about projects and people. I particularly liked the chapters on
"precision listening" and "observations from the empathic position."
(Reviewed Jan., '03)
|
 |
|
Quality Software Management, Volume 3: Congruent Action, Gerald M.
Weinberg, Dorset House, 1994. Considers software management from the
perspective of family therapist Virginia Satir. People can take different
incongruent stances: placating, blaming, super-reasonable, or irrelevant.
But a congruent stance is more effective, balancing self, other, and
context, to provide helpful feedback.
Weinberg also looks at a number of challenges around team formation.
It's important to give teams the right level of challenge and support, and
to intervene effectively when they need it. (Reviewed Nov., '02)
|
 |
|
Quality Software Management, Volume 4: Anticipating Change, Gerald M.
Weinberg, Dorset House,
1997.
This book contains advice for people who are trying to be change artists,
those who change their world. One technique they use is to provide a
number of challenges you can try yourself. Other sections consider how to
start, run, and stop projects, and describe things to listen for to help
understand your situation. If you could only read one of these volumes,
this would be the one to read; it's a culmination of the first three
volumes, and has a summary of key ideas from them. (Reviewed
July, '03)
|
I link to Amazon.com as
part of their associate program, but don't forget to check
half.com and others, especially if you don't
mind a used book.
|