All the time I hear people talking about software projects as journeys, and I think
they are implying that software projects are not just journeys, but they are journeys
into the unknown. We start with funding from a sponsor, muster together a
stout-hearted crew, head out in what we guess might be a useful direction, and the
rest is The Odyssey. We live the tales of the brave Odysseus: tales of Lotus Eaters,
the Cyclops, Circe, the Sirens, Scylla, and Calypso. We succeed or fail only with
the help or rage of the gods. How wonderfully romantic, and how perfectly silly.
I think that the more appropriate analogy along this line is the project as an
expedition. We have a goal or a short list of goals. We have some well-proven maps;
we have some vaguer ones, too. We have the advice and journals from those who
have been out there and made it back to tell their stories.
We don’t walk out the door and face the unknown; but on the other hand,
there are some big question marks, and these bring us into a high-risk position. We
accept these risks, because if the expedition can succeed there are surely significant
rewards. We have skills, but there are uncertainties.
How do we deal with this? I recommend that we look back, oh, about 300
years, to the York Factory on Hudson Bay in Canada. At that time this was the
headquarters of the Hudson Bay Company. The Hudson Bay Company’s main
line of business was to be the supplier of all necessary provisions for fur traders
going out on, you guessed it, expeditions, from Hudson Bay. The fur traders developed
a great way to start an expedition, and it was called “The Hudson Bay Start.”
Having done their one-stop shopping at The Company, the fur traders would go
out of Hudson Bay only a mile or two and set up camp. Why? Certainly not to set
up traps; they wanted to discover what they forgot to bring while they were less
than an hour’s hike back into town! Being the excellent project person that you
are, you know that for the vast majority of time the leather-faced expert fur trader
would reappear for another shopping trip.
What the heck does all this have to do with the book in your hands right
now? With Succeeding with Agile, Mike Cohn has delivered The Hudson Bay Start
for agile development. This is it. This is a weather-beaten experienced fur trapper
giving you the checklist to work through before you begin your expedition. By
reading this book, you will find that Mike brings up issues that you never thought
of, offers advice on how you might handle situations, and helps you define
Product development is becoming increasingly complex. The pace of technological
change grows daily, leaving little time to accumulate expertise before development
of a new product begins. Acquiring enough experience to be able to predict the
risk and develop the courses of action during the development is difficult and often
happens during the course of the true developmental phases of the new product
development. This situation creates a need for tapping into the skills and abilities
of all the participants in the development effort and relying less on heroic efforts
to save the day and carry the project and product to a successful conclusion. Even
when we have product development heroes and they carry the day, the loss of these
individuals to the organization will be detrimental to the organization and represents
a human resources risk. The recovery period can be prolonged for organizations with
poor team practices and those that favor heroic actions.
We are presenting a modified version of the agile software development tool
scrum as an alternative to traditional program management and as a tool for standard
line management. Both of us have experience in deploying and implementing the
tool. We understand the pitfalls of this method, which we will elucidate during the
course of our discussion.
We are not saying that we believe the waterfall approach should be condemned
to obscurity or that we are calling for the death of this development model. In fact,
we know of few organizations that take the waterfall method as it is often portrayed
in books; that is, taking it to be a rigid and one-way pass through the development
process. In fact, there are some similarities between the methods, although scrum
approach throughput is quicker and keeps people focused on what is deemed important
by the project managers. Basically scrum is to the waterfall approach what
lean manufacturing (especially one-piece flow) is to batch-mode manufacturing.
Additionally, the team aspects of the method—moving toward self-directed work
teams—means the actions of the team must be successful and are largely in the hands
of the team itself. The concept of a self-directed work team also suggests we must
have a motivated and skilled team capable of achieving project goals. It is unwise to
condemn conventional tactics across the board, when frequently the conventional
tactics are not executed well. Poor execution does not improve the probability of
From a leader in the agile process movement, learn best practices for moving agile development with Scrum from the skunk works (small team) to the shop floor (the enterprise). Managers get case studies and practical guidance for managing the change processes for applying Scrum in the enterprise.
The product owner is a new role for most companies and needs this
book’s compelling and easily understandable presentation. When
the first product owner was selected, I was a vice president at Object
Technology, responsible for delivering the first product created by
Scrum. The new product would make or break the company, and I
had six months to deliver a development tool that would alter the
market. In addition to creating the product with a small, carefully
selected team, I had to organize the whole company around new
product delivery. With only a few months until product shipment,
it was clear that the right minimal feature set would determine success
or failure. I found that I did not have enough time to spend
talking with customers and watching competitors closely so that I
could precisely determine the right prioritized feature set up front
and break those features down into small product backlog items for
the team.
I had already delegated my engineering responsibilities to
Agility is the word of the new millennium. As the world around us grows more complex, we
strive to build more complex products. These products often consist of many components that
must interact precisely through sophisticated interfaces. At the same time, these products are
being used in more sophisticated, critical applications, including life-critical products such as
pacemakers and nano-robots, and society-critical applications such as an intelligent energy grid.
In parallel with the growth of complexity, there has been a need for increased safety, predictability,
risk management, and control—both of the development process itself and the resultant products.
At the same time, our need to be nimble, flexible, and adaptable has increased. Enter the era
of agility.
Agility first formally entered the product development arena with the publishing of the
Agile Manifesto in 2001. As of 2008, more organizations are employing agile techniques and
processes to develop and sustain complex products than those that continue to employ more traditional
techniques. Of those using agile techniques, 84% of them employ an agile framework
process, Scrum.
A complexity faced by almost all large organizations is
Andrew Pham’s book is an answer to the prayers of newbies to Agile/Scrum. Right
from assessment techniques for your project/enterprise for agility, to guidance on
implementing it—he has included, not only theoretical aspect, but also human
and practical aspects. Simply put, for all the impediments he and his team faced
over years he has put together a learning guide and answered for us most of the
questions which we might face to start with Agile transformation. A great tool for
any team trying to explore the Agile path!
Programers have a lot on their minds . Programming languages,
programming techniques, development environments, coding style, tools,
development process, deadlines, meetings, software architecture, design patterns,
team dynamics, code, requirements, bugs, code quality. And more. A lot.
There is an art, craft, and science to programming that extends far beyond
the program. The act of programming marries the discrete world of computers
with the fluid world of human affairs. Programmers mediate between the
negotiated and uncertain truths of business and the crisp, uncompromising
domain of bits and bytes and higher constructed types.
With so much to know, so much to do, and so many ways of doing so, no
single person or single source can lay claim to “the one true way.” Instead, 97
Things Every Programmer Should Know draws on the wisdom of crowds and
the voices of experience to offer not so much a coordinated big picture as a
crowdsourced mosaic of what every programmer should know. This ranges
from code-focused advice to culture, from algorithm usage to agile thinking,
from implementation know-how to professionalism, from style to substance.
The contributions do not dovetail like modular parts, and there is no intent
that they should—if anything, the opposite is true. The value of each contribution
comes from its distinctiveness. The value of the collection lies in how the
contributions complement, confirm, and even contradict one another. There
is no overarching narrative: it is for you to respond to, reflect on, and connect
together what you read, weighing it against your own context, knowledge, and
experience.
