Download the full version of the ebook at ebookfinal.

com

Software Development Design and Coding With

Patterns Debugging Unit Testing and Refactoring
3rd Edition John F. Dooley

https://ebookfinal.com/download/software-development-design-
and-coding-with-patterns-debugging-unit-testing-and-
refactoring-3rd-edition-john-f-dooley/

OR CLICK BUTTON

DOWNLOAD EBOOK

Download more ebook instantly today at https://ebookfinal.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Software Design and Development 2nd Edition Samuel Davis

https://ebookfinal.com/download/software-design-and-development-2nd-
edition-samuel-davis/

ebookfinal.com

Testing IT An Off the Shelf Software Testing Process 2nd

Edition John Watkins

https://ebookfinal.com/download/testing-it-an-off-the-shelf-software-
testing-process-2nd-edition-john-watkins/

ebookfinal.com

Model Based Software Testing and Analysis with C 1st

Edition Jonathan Jacky

https://ebookfinal.com/download/model-based-software-testing-and-
analysis-with-c-1st-edition-jonathan-jacky/

ebookfinal.com

Automated Software Testing with Cypress 1st Edition

Narayanan Palani

https://ebookfinal.com/download/automated-software-testing-with-
cypress-1st-edition-narayanan-palani/

ebookfinal.com
Object oriented software engineering using UML Patterns
and Java 3rd, intern. Edition Bruegge

https://ebookfinal.com/download/object-oriented-software-engineering-
using-uml-patterns-and-java-3rd-intern-edition-bruegge/

ebookfinal.com

Head First Design Patterns Building Extensible and

Maintainable Object Oriented Software 2nd Edition Eric
Freeman
https://ebookfinal.com/download/head-first-design-patterns-building-
extensible-and-maintainable-object-oriented-software-2nd-edition-eric-
freeman/
ebookfinal.com

The Art of Unit Testing with examples in C 2nd Edition Roy

Osherove

https://ebookfinal.com/download/the-art-of-unit-testing-with-examples-
in-c-2nd-edition-roy-osherove/

ebookfinal.com

Pragmatic Unit Testing in C with NUnit Pragmatic

Programmers 1st Edition Andy Hunt

https://ebookfinal.com/download/pragmatic-unit-testing-in-c-with-
nunit-pragmatic-programmers-1st-edition-andy-hunt/

ebookfinal.com

Server Component Patterns Component Infrastructures

Illustrated with EJB Wiley Software Patterns Series 1st
Edition Markus Volter
https://ebookfinal.com/download/server-component-patterns-component-
infrastructures-illustrated-with-ejb-wiley-software-patterns-
series-1st-edition-markus-volter/
ebookfinal.com
CHAPTER 1

Introduction to Software
Development
“Not only are there no silver bullets now in view, the very nature of software
makes it unlikely that there will be any—no inventions that will do for soft-
ware productivity, reliability, and simplicity what electronics, transistors,
and large-scale integration did for computer hardware. We cannot expect
ever to see twofold gains every two years.”
—Frederick J. Brooks, Jr.1

So, you might be asking yourself, why is this book called Software Development, Design,
and Coding? Why isn’t it called All About Programming or Software Engineering? After
all, isn’t that what software development is? Well, no. Programming is a part of software
development, but it’s certainly not all of it. Likewise, software development is a part of
software engineering, but it’s not all of it.
Here’s the definition of software development that we’ll use in this book: software
development is the process of taking a set of requirements from a user (a problem
statement), analyzing them, designing a solution to the problem, and then implementing
that solution on a computer.
But isn’t that programming? Well, no. Programming is really just the implementation
part, or possibly the design and implementation part, of software development.
Programming is central to software development, but it’s not the whole thing.
Well, then, isn’t it software engineering? Again, no. Software engineering also
involves a process and includes software development, but it also includes the entire
management side of creating a computer program that people will use. Software

1
Brooks, F. 1987. “No Silver Bullet.” IEEE Computer 20 (4): 10–19. www.inst.eecs.berkeley.
edu/~maratb/readings/NoSilverBullet.html.
1
© John F. Dooley and Vera A. Kazakova 2024
J. F. Dooley and V. A. Kazakova, Software Development, Design, and Coding,
https://doi.org/10.1007/979-8-8688-0285-0_1
Chapter 1 Introduction to Software Development

engineering includes project management, configuration management, scheduling

and estimation, baseline building and scheduling, managing people, and several other
things. Software development is the fun part of software engineering.
So software development is a narrowing of the focus of software engineering to just
that part concerned with the creation of the actual software. And it’s a broadening of the
focus of programming to include analysis, design, and release issues.

What We’re Doing

It turns out that, after 80 or so years of using computers, we’ve discovered that developing
software is hard. Learning how to develop software effectively, efficiently, and sustainably
is also hard. You’re not born knowing how to do it and many people, even those who take
programming courses and work in the industry for years, don’t do it particularly well.
It’s a skill you need to pick up and practice—a lot. You don’t learn programming and
development by reading books—not even this one. You learn it by developing software. That,
of course, is the attraction: to work on interesting and difficult problems. The challenge is to
work on something you’ve never done before, something you might not even know if you
can solve. That’s what has you coming back to create new programs again and again.
There are probably several ways to learn software development. But we think that all
of them involve reading excellent designs, reading a lot of code, writing a lot of code, and
thinking deeply about how to approach a problem and design a solution for it. Reading a
lot of code, especially really beautiful and efficient code, gives you lots of good examples
about how to think about problems and approach their solution in a particular style.
Writing a lot of code lets you experiment with the styles and examples you’ve seen in
your reading. Thinking deeply about problem solving lets you examine how you work
and how you do design, and lets you extract from your labors those patterns that work for
you; it makes your programming more intentional.

So, How to Develop Software?

Well, the first thing you should do is read this book. It certainly won’t tell you everything,
but it will give you a good introduction into what software development is all about and
what you need to do to write great code. It has its own perspective, but it’s a perspective
based on our combined 40 years or so of writing code professionally and another 24
years trying to figure out how to teach others to do it.
2
 Chapter 1 Introduction to Software Development

Despite the fact that software development is only part of software engineering,
software development is the heart of every software project. After all, at the end of the
day what you deliver to the user is working code. A team of developers working in concert
usually creates that code. So to start, maybe we should look at a software project from the
outside and ask, what does that team need to do to make that project a success?
In order to succeed at software development, you need the following:

To realize that you don’t know everything you need to know at the
beginning of the project. Software development projects just don’t
work this way. You’ll always uncover new requirements; other
requirements will be discovered to be not nearly as important
as the customer thought; still others that were targeted for the
next release are all of a sudden requirement number one. This is
known as churn. Managing requirements churn during a project
is one of the single most important skills a software developer
can have. If you are using new development tools (say a new
web development framework), you’ll uncover limitations you
weren’t aware of and side effects that cause you to have to learn,
for example, three other tools to understand them (e.g., that
web development tool you want to use is Ruby-based, requires a
specific relational database system to run, and needs a particular
configuration of Apache to work correctly.)

A small, well integrated team. Small teams have fewer lines

of communication than larger ones. It’s easier to get to know
your teammates’ strengths and weaknesses, understand their
personalities and preferences, and establish who is the go-to
person for particular problems or tools. Well-integrated teams
have usually worked on several projects together. Keeping a
team together across several projects is a major job of the team’s
manager and of the individual teammates themselves. Well-
integrated teams are more productive, better at holding to a
schedule, and more likely to produce code with fewer defects
at release. The key to keeping a team together is to give them
interesting work, give them the freedom to decide how to do the
work, and facilitate the process by removing barriers and helping
with conflict resolution.

3
Chapter 1 Introduction to Software Development

Good communication among team members. Continuous direct

communication among team members is critical to day-to-day
progress and successful project completion. Teams that are co-
located are generally better at communicating and communicate
more than teams that are distributed geographically (even if
they’re just on different floors or wings of a building) or that are
working virtually.2 This is a major issue with larger companies that
have software development sites scattered across the globe.

Good communication between the team and the customer.

Communication with the customer is essential to controlling
requirements and requirements churn during a project. On-
site or close-by customers allow for constant interaction
with the development team. Customers can give immediate
feedback on new releases and can be involved in creating
system and acceptance tests for the product. Agile development
methodologies strongly encourage customers to be part of the
development team and, even better, to be on site daily. See
Chapter 2 for a quick introduction to some agile methodologies.

A process that everyone buys into. Every project, no matter how

big or small, follows a process. Larger projects require more
coordination and tighter controls on communication and
configuration management. As a result, larger teams tend to
be more plan-driven and follow processes with more rules and
documentation required. Smaller projects and smaller teams will,
these days, tend to follow more agile development processes, with
more flexibility and less documentation required. This certainly
doesn’t mean there is no process in an agile project; it just means
you do what makes sense for the current stage of your project, so
that you can correctly uncover and satisfy all the requirements,
meet the schedule, and produce a quality product. See Chapter 2
for more details on process and software life cycles.

2
Note that teams that are distributed geographically can also be closer to clients and thus have
better communication with them. Also, the advent of easy and fast conferencing software can
mitigate the disadvantages of remote work.

4
 Chapter 1 Introduction to Software Development

The ability to be flexible about that process. No project ever

proceeds as you think it will on the first day. Requirements
change, people come and go, tools don’t work out or get updated,
and so on. This point is all about handling risk in your project.
If you identify risks, plan to mitigate them, and then have a
contingency plan to address the event where the risk actually
occurs, you’ll be in much better shape. Chapter 4 talks about
requirements and risk.

A plan that everyone buys into. You wouldn’t write a sorting

program without an algorithm to start with, so you shouldn’t
launch a software development project without a plan. The
project plan encapsulates what you’re going to do to implement
your project. It talks about process, risks, resources, tools,
requirements management, estimates, schedules, configuration
management, and delivery. It doesn’t have to be long, it doesn’t
need to contain all the minute details of the everyday life of the
project, and it doesn’t even need to be written down, but everyone
on the team needs to have input into it, they need to understand
it, and they need to agree with it. Unless everyone buys into the
plan, you’re doomed. See Chapter 3 for more details on project
planning.

To know where you are at all times. It’s that communication thing
again. Most projects have regular status meetings so that the
developers can “sync up” on their current status, get a feel for the
status of the entire project, and to create a sense of camaraderie
within the team. This works very well for smaller teams (say, up
to about 20 developers, many of which will have daily “stand-
up” meetings to sync up at the beginning of each day. Different
process models handle this “stand-up” meeting differently. For
instance, plan-driven models don’t require these meetings,
depending on the team managers to communicate with each
other. Agile processes often require all-hands daily meetings
to facilitate constant team communication in a highly dynamic
project environment.

5
Chapter 1 Introduction to Software Development

To be brave enough to say, “hey, we’re behind!” Nearly all software

projects have schedules that are too optimistic at the start. It’s
what clients want to hear, what companies want to offer, and
what managers and developers want to supply. “Sure, I can get
that done in a week!” “I’ll have it to you by the end of the day.”
“Tomorrow? Not a problem.” No, no, no, no, no. Just face it. At
some point you’ll be behind. And the best thing to do about it is
to tell your manager right away. Sure, they might be angry. But
they’ll be angrier when you end up a month behind and they
didn’t know it. Fred Brooks’ famous answer to the question of how
software projects get so far behind is “one day at a time.” The good
news, though, is that the earlier you figure out you’re behind, the
more options you have. These include lengthening the schedule
(unlikely, but it does happen), moving some requirements to a
future release, getting additional help, and so on. The important
part is to keep your manager informed.

The right tools and the right practices for this project. One of the
best things about software development is that every project is
different. Even if you’re doing version 8.0 of an existing product,
things change. One implication of this is that, for every project,
you need to examine and pick the right set of development tools.
Picking tools that are inappropriate is like trying to hammer nails
with a screwdriver; you might be able to do it eventually, but is
sure isn’t easy or pretty or fun, and you can drive a lot more nails
in a shorter period of time with a hammer than with a screwdriver.
Even if you have to first obtain a hammer and then learn how
to use it for the very first time, you are leveling up your toolkit
and your skills in the process, investing in your ability to work
more efficiently going forward. The three most important factors
in choosing tools are the application type you are writing, the
target platform, and the development platform. You usually can’t
do anything about any of these three things, so once you know
what they are, you can pick tools that improve your productivity.
A fourth and nearly as important factor in tool choice is the
composition and experience of the development team. If your

6
 Chapter 1 Introduction to Software Development

team are all experienced developers with facility on multiple

platforms, tool choice is much easier. If, on the other hand, you
have a bunch of fresh-outs and your target platform is new to all of
you, you’ll need to be careful about tool choice and fold in time for
training and practice with the new tools.

Conclusion
Software development is the heart of every software project, and it is the heart of
software engineering. Its objective is to deliver excellent, defect-free code to users on
time and within budget—all in the face of constantly changing requirements. This makes
development a particularly hard job to do. But finding a solution to a difficult problem
and getting your code to work correctly is just about the coolest feeling in the world.

“[Programming is] the only job I can think of where I get to be both an engi-
neer and an artist. There’s an incredible, rigorous, technical element to it,
which I like because you have to do very precise thinking. On the other
hand, it has a wildly creative side where the boundaries of imagination are
the only real limitation. The marriage of those two elements is what makes
programming unique. You get to be both an artist and a scientist. I like that.
I love creating the magic trick at the center that is the real foundation for
writing the program. Seeing that magic trick, that essence of your program,
working correctly for the first time, is the most thrilling part of writing a
program.”
—Andy Hertzfeld (designer of the first Mac OS)3

References
Brooks, F. 1987. “No Silver Bullet.” IEEE Computer 20 (4): 10–19. www.inst.eecs.
berkeley.edu/~maratb/readings/NoSilverBullet.html.
Lammers, Susan. 1986. Programmers At Work. Redmond, WA: Microsoft Press.

3
Lammers, Susan. 1986. Programmers At Work. Redmond, WA: Microsoft Press.

7
CHAPTER 2

Software Process Models

If you don’t know where you’re going, any road will do.
If you don’t know where you are, a map won’t help.
—Watts Humphrey

The process of developing software is commonly described as the Software

Development Lifecycle (SDLC). Every program, no matter how small, has a life cycle,
broadly composed of the following steps:

1. Conception

2. Requirements gathering/exploration/modeling

3. Design

4. Coding and debugging

5. Testing

6. Release
7. Maintenance/software evolution

8. Retirement

Your development process may combine multiple steps or iterate over a subset of steps
repeatedly between releases, but, in one form or another, all development should encompass
all of the above life cycle steps in order to create high-quality software. The two most
common variations are plan-based models1 and the newer agile development models.2

1
Paulk, Mark C. 1995. The Capability Maturity Model: Guidelines for Improving the Software
Process. The SEI Series in Software Engineering. Reading, Mass.: Addison-Wesley Pub. Co.
2
Martin, Robert C. 2003. Agile Software Development, Principles, Patterns, and Practices. Upper
Saddle River, NJ: Prentice Hall.
11
© John F. Dooley and Vera A. Kazakova 2024
J. F. Dooley and V. A. Kazakova, Software Development, Design, and Coding,
https://doi.org/10.1007/979-8-8688-0285-0_2
Chapter 2 Software Process Models

With plan-based development, the project team will generally do a complete life
cycle (at least steps 2 through 7) before going back in the SDLC to start working on the
next version of the product. In plan-driven models, the methodology tends to be stricter
in terms of process steps and when releases happen. Plan-driven models have more
clearly defined phases and more requirements for sign-off on completion of a phase
before moving on to the next phase. Plan-driven models require more documentation at
each phase and verification of completion of each work product. They tend to work well
for large contracts for new software with well-defined deliverables.
In agile development, which is more prevalent now, the project team will usually
iterate over a partial life cycle (usually steps 3 through 5) several times before proceeding
to the release step. The agile models are inherently incremental and operate under the
assumption that small, frequent releases produce a more robust product than larger, less
frequent ones. Phases in agile models tend to blur together more than in plan-driven
models, and there tends to be less documentation of work products required, the basic
idea being that code is what is being produced and so developer efforts should focus
there. See the Agile Manifesto web page at https://agilemanifesto.org to get a good
feel for the agile development model and goals.
There is no one best process for developing software. Each project must decide on
the model that works best for its particular application and base that decision on the
project domain, the scope of the project, the experience of the team, and the timeline
of the project. In this chapter, we begin by reviewing the shared variables of software
development projects, followed by a discussion of the different broadly defined
approaches, and finally we take a look at several prominent specific software model
implementations as well as how they can be hybridized together.

The 3(+3) Variables of Software Development

According to the Project Management Institute,3 the three main variables of software
development are cost, time, and scope.

• Cost (a.k.a. resources) is usually the most constrained; as a developer,

you have very limited control over cost and you cannot spend your
way to quality or to being on schedule. Cost can influence the size

3
Project Management Institute. 2021. A Guide to the Project Management Institute Body of
Knowledge. 7th ed. Project Management Institute, Inc. www.pmi.org.

12
 Chapter 2 Software Process Models

of the team or the types of tools available during development. For

small companies and startups, cost also influences the environment
where the developers will work.

• Time is your delivery schedule and is typically imposed on you

from the outside. For example, most consumer products (be they
hardware or software) will have a delivery date somewhere between
August and October in order to hit the holiday buying season. You
can’t move Christmas. If you are late, the only way to fix your problem
is to drop features or lessen quality, neither of which is pretty. Time is
also where Brooks’ Law gets invoked (adding programmers to a late
project just makes it later).

• Scope (a.k.a. features) is what the product actually does. This is what
developers should always focus on. It’s the most important of the
variables from the customer’s perspective and it is also the one you
as a developer have the most control over. Controlling scope allows
you to provide managers and customers control over quality, time,
and cost. If the developers don’t have control over the feature set for
each release, then they are likely to blow the schedule. This is why
developers should do the estimates for software work products.

Together, cost, time, and scope form the Iron Triangle of software development, in
which specifying two of the variables defines the third. In the real world, a customer will
often specify timeframe and budget for the task, which will then be your constraints to
estimate a realistic scope within the broader task.
Occasionally, a fourth variable is added (usually as the center of the triangle).

• Quality is the number/severity of defects, simplifications, or

functionality reductions you are willing to release with. Thus, quality
may be used to describe non-binary characteristics of features in
your scope (e.g. the time to respond to a user query should be no
more than n milliseconds, but the lower the better). This is not,
strictly speaking, an input variable like cost, time, and scope, but
rather a metric for the quality of your output. You can make short-
term gains in delivery schedules by sacrificing quality, but the cost

13
Chapter 2 Software Process Models

is enormous. It will take more time to fix the next release and your
credibility will be pretty well shot. More commonly, there is an
expected minimum expected quality for the product, fixing this
“variable”.

In some definitions, the scope of the task/product is considered to be fixed or,

otherwise, intertwined with quality, leading instead to an Iron Triangle consisting of
cost, time, and quality.4
More recently, two more variables have been defined as part of the new six-variable
set of constraints:5

• Benefit is the value delivered to the product provider and to the

client. With new information about the market, client needs, or target
audience, benefit may change, requiring changes to scope or to other
variables.

• Risk is the likelihood of not meeting expected values for the

other criteria (such as failing to implement features, increasing
development time, or exceeding the expected budget). Managing
one type of risk may increase another type of risk (e.g., increasing
time makes scope less risky, but is likely to increase cost). To
minimize risk, developers need to control as many of the variables as
possible, always keeping in mind that the only constant of software
development is change. If you pay attention and effectively cope
with change as it occurs, you can keep the risk and cost of change
manageable.

As shown in Figure 2-1, all constraints need to be balanced. Altering one will require
adjusting others to compensate.

4
https://ronjeffries.com/xprog/articles/practices/pracfourvariables/
5
Siegelaub, J. M. 2007. “Six (Yes Six!) Constraints: An Enhanced Model for Project Control.” In
Proceedings of the PMI Global Congress 2007. Atlanta, GA: Project Management Institute, Inc.
www.pmi.org/learning/library/six-constraints-enhanced-model-project-control-7294.
See also https://prince2.wiki/.

14
 Chapter 2 Software Process Models

Figure 2-1. The six variables of software development

A number of other expansions to the variables that define a software development

project have been suggested over the years. For example, The Square Route combines
the Iron Triangle with additional considerations of project evaluation at the delivery
stage and post-delivery stage.6 Additional constrains external to the organization and
the client may also play an important role in the creation of software products, including
social, economic, legislative, environmental, and other factors.7

Software Development Approaches

When it comes to developing software, there are several general approaches, which
can be employed separately or together within an organization or even within a single

6
Atkinson, Roger. 1999. “Project Management: Cost, Time, and Quality, Two Best Guesses and
a Phenomenon, It’s Time to Accept Other Success Criteria.” International Journal of Project
Management 17 (6): 337–42.
7
www.smartsheet.com/content/project-constraints

15
Chapter 2 Software Process Models

project. Below we discuss planning, reducing waste with lean methodologies, and
adapting by remaining agile.

Plan-Based Software Development

The main characteristic of plan-based software development is to make a plan and
then follow through with it. It seems simple enough...except that to make a reliable
plan you need to have all of the information AND that information must not change.
As we are neither omniscient nor clairvoyant, this poses a bit of a problem. We are at
the mercy of imprecise language describing poorly understood requirements that are
devised to solve problems for changing real-world scenarios by teams of predictably
unpredictable humans.
Still, plans are comforting. It allows the illusion that we know what is going to
happen. If we follow a plan and get a result, we hope that following the same plan in the
future will yield the same result. Of course, controlling for all variables (both internal and
external to the project) is impossible. Plans also allow for subplans and estimations for
the entire hierarchy of plans. Granted, the further away the step, the less accurate our
estimation. Plans also allow us to assess dependencies and schedule tasks accordingly.
Of course, any change can tumble the carefully scheduled house of cards which we
painstakingly designed, estimated, sorted, scheduled, and partially developed.
Let’s say we do have a plan: we have devised steps and we will complete them one
by one, in order. For a small project with a single developer, who is also the client, this
may very well work out. In a more realistic scenario, the client is not us, the project is
complex, and we have to coordinate with other stakeholders. Let’s say our basic plan
has a design phase, an implementation phase, a testing phase, and delivery. We take
several months to come up with a beautiful design and show our client, but the client
wants changes. We take a few weeks to make changes to the design; the client approves.
We make a development plan and attempt to implement our design over the next several
months. In that time, some of the libraries we were relying on have been deprecated,
some developers leave, new ones join the team, the market changes, causing the client to
request changes to the design, and ultimately our development plan and our design are
both obsolete. Do-over time... To make matters worse, so far we have delivered no value
to the client and they are starting to lose confidence that we ever will. To recap, making
reliable short plans for small projects is doable; anything else is wishful thinking.

16
 Chapter 2 Software Process Models

Agile Software Development

Starting in the mid-1990s, a group of process mavens began advocating a new model for
software development. Targeting medium-sized software projects and smaller teams of
developers, the new approach was intended to allow teams to quickly adjust to changing
requirements and customer demands, while also releasing functional software much more
quickly and frequently than under plan-driven models. The new model was, in a word, agile.8
In most agile process models, we start with the “known” requirements (a snapshot of
the requirements at some time early in the process) and prioritize them, typically based
on the customer’s ranking of what features are most important to deliver first. Keep in
mind that what we think we know or understand about these requirements is commonly
only somewhat accurate: natural language is imprecise; the understood meanings differ
based on communicator background, positionality, and other context; and clients often
do not necessarily understand what they want or need to solve their problem. Thus, one
of our most important challenges in software development is to iteratively approach an
accurate shared understanding of the problem and the prospective solution. According to
Tom DeMarco, iterative software development follows one basic rule:
Your project, the whole project, has a binary deliverable. On the scheduled
completion day, the project has either delivered a system that is accepted by
the user, or it hasn’t. Everyone knows the result on that day.
The object of building a project model is to divide the project into compo-
nent pieces, each of which has this same characteristic: each activity must
be defined by a deliverable with objective completion criteria. The deliver-
ables are demonstrably done or not done.9

Rather loosely, we can devise a series of iterations, where each iteration is a complete
Minimum Viable Product (MVP), working and robust, albeit with fewer features than
the final goal product. For each iteration, we will select a set of the next highest priority
requirements (including some you or the customer may have discovered during the
previous iteration), develop, test, and demo the MVP, and gather feedback. This feedback
may drastically alter our initial plan, which is why our initial plan is only a loose sketch of
future development iterations.

8
Cockburn, A. 2002. Agile Software Development. Boston, MA: Addison-Wesley.
9
DeMarco, Tom. 1983. Controlling Software Projects: Management, Measurement and Estimation.
Yourdon Press.

17
Chapter 2 Software Process Models

So what happens if you estimate wrong? What if you decide to include too many new
features in an iteration? What if there are unexpected delays? Well, if it looks as if you
won’t make your iteration deadline there are only two realistic alternatives: move the
deadline or remove features. We’ll come back to this problem later when we talk about
estimation and scheduling. The key to iterative development is “live a balanced life—
learn some and think some and draw and paint and sing and dance and play and work
every day some,”10 or in the software development world, analyze some and design some
and code some and test some every day. We’ll revisit this idea when we talk about the
agile development models later in this chapter.
Overall, agile is composed of ongoing short-term experiments, iteratively reviewed
to evaluate product and practices, and to find processes that work for the team and the
client. In other words, some good old-fashioned trial and error. While some failure is
inevitable, it is more informative and less costly to fail on small increments, to fail early,
and to learn from it quickly. Thus, we reduce the pressure of needing our intermediates
to be right, requiring only that these decision are useful in helping us learn more about
what was actually needed.
Agile development works from the proposition that the goal of any software
development project is working code. Consequently, the development team should spend
most of their time writing code, not documentation. As opposed to the heavyweight plan-
driven models mentioned above and espoused by groups like the Software Engineering
Institute (SEI) at Carnegie Mellon University,11 this new process model was lightweight,
requiring less documentation and fewer process controls. Lightweight methodologies
tend to emphasize writing tests before code, frequent product releases, significant
customer involvement in development, common code ownership, and refactoring
(rewriting code to make it simpler and easier to maintain). Lightweight methodologies do,
unfortunately, suffer from several myths, the two most pernicious being that lightweight
processes are only good for very small projects and that lightweight projects lack process
discipline. Both of these are incorrect. The truth is that lightweight methodologies have
been successfully used in many small and medium-sized projects (say up to about 500K
lines of code), as well as in very large projects. Larger projects can nearly always be
organized as a set of smaller projects, which together provide services to the single larger

10
Fulghum, Robert. 1986. All I Really Need to Know I Learned in Kindergarten. New York, NY:
Ivy Books.
11
(Paulk 1995)

18
 Chapter 2 Software Process Models

product. Lightweight methodologies also require process discipline, especially in the

beginning of a project, when initial requirements and an iteration cycle are created, and
in the test-driven-development used as the heart of the coding process.
In the remainder of the chapter, we will review the agile values, principles, and
activities that have been defined over the years. Note, however, that agility necessarily
extends to how these concepts and practices are ultimately incorporated into development
(i.e., to iteratively determine what works and what does not for each particular product/
organization/team/etc.).

Agile Values, Principles, and Activities

In early 2001, a group of experienced and innovative developers met in Snowbird, Utah,
to talk about the state of the software development process. All of them were dissatisfied
with traditional plan-driven models and had been experimenting with new lightweight
development techniques. Out of this meeting came the Agile Manifesto.12 The original
description proposed by the group included two parts: values (the manifesto itself ) and
principles.
The four Agile Values showcase that while the authors recognize the value of the
items on the right, they view the items on the left as the most crucial to successful
software development:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
The following 12 Agile Principles were defined by the authors to focus and guide
development:
• Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.

12
https://agilemanifesto.org/
19
Chapter 2 Software Process Models

• Business people and developers must work together daily throughout

the project.

• Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to

and within a development team is face-to-face conversation.

• Working software is the primary way to measure progress.

• Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace
indefinitely.

• Continuous attention to technical excellence and good design

enhances agility.

• Simplicity—the art of maximizing the amount of work not done—is

essential.

• The best architectures, requirements, and designs emerge from self-

organizing teams.

• At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly.

The following four main Agile Activities (although originally defined as part of the
Agile variant called eXtreme Programming) are applicable for all Agile methodologies:
Design while you code. In real world domains, all the requirements aren’t
typically known or correctly understood in advance. Mistakes and oversights will
be made in architectural design, detailed design, and coding. Additionally, during
product development, requirements and constraints may change, as no project
exists in a vacuum, away from real world events such as turnover in the development
team, updates to customer needs due to market changes, the development of new
technologies, and so on. Agile software development models build products a piece
at a time, with each product increment allowing for several crucial events to happen
earlier and more frequently: delivery of value to the customer, feedback gathering,
and adaptation to changes. Designing while coding allows more developer freedom to
choose how to deliver on the tasks, promoting developer agency while increasing their
responsibility to self-manage.

20
 Chapter 2 Software Process Models

Direct communication is best, although what “direct” means has shifted greatly in
recent years. We see “direct communication” as happening in real time, with direct
exposure to both verbal and non-verbal cues, which would encompass in-person
discussions, video conferencing, and even advanced virtual environments. In any given
software development project, there are two types of knowledge: 1) the customer has
domain knowledge and what understanding of what the system is supposed to do and
2) the developers have technical knowledge about the target platform, programming
language(s), and possible implementation issues. The customer doesn’t know the
technical side and the developers don’t have the domain knowledge, so effective
communication—on both sides—is a key activity in developing the product. Frequent
communication means everyone is learning from everyone’s process, creating a more
well-rounded shared understanding faster.
Code is the main deliverable. The fundamental difference between plan-driven
models and agile models is this emphasis on the code, as code is where system
knowledge resides. In a plan-driven model, the emphasis is on producing a set of work
products that together represent the entire work of the project with code being just one
of the work products. In agile methodologies, the emphasis is placed squarely with code
as the deliverable; in addition, by structuring the code properly and keeping comments
up to date, the code itself becomes documentation for the project.
Test-driven development. Test cases for the required features are written before
development takes place and should all initially fail. Once all tests for a feature pass,
the feature implementation is completed. Test-driven development is instrumental for
managing change, as continuous testing tells you when a new feature is completed and
integrated into the system without breaking any of the pre-existing functionality.

Lean Software Development

Lean software development comes from the just-in-time manufacturing processes (also
known as the Toyota Production System, among other names), which were introduced
in Japan in the 1970s and then made their way around the world in the 1980s and 1990s,
encouraged by the publication in 1990 of The Machine That Changed The World13

Womack, James P., Daniel T. Jones, and Daniel Roos. 1990. The Machine That Changed the
13

World: The Story of Lean Production -- Toyota’s Secret Weapon in the Global Car Wars That Is Now
Revolutionizing World Industry. New York, NY: Simon and Schuster.

21
Chapter 2 Software Process Models

(Womack et. al.). Just-in-time manufacturing evolved first into lean manufacturing and
then into lean product management systems throughout the 1990s. The publication of
Poppendieck & Poppendieck’s Lean Software Development: An Agile Toolkit14 in 2003
marked the movement of lean into the agile development community.
Lean software development is a set of principles designed to eliminate waste in
order to improve productivity, quality, and customer satisfaction. Waste is anything that
does not add value to the product. Thus, lean emphasizes that the team should only be
focusing on activities that add immediate value to the product.
The Poppendiecks14 transformed the lean principles that started at Toyota into seven
key principles for software development:

• Eliminate waste

• Build quality in

• Create knowledge

• Defer commitment

• Deliver fast

• Respect people

• Optimize the whole

We will go through each of these principles briefly to illustrate how they apply to
software development.

Lean Principle 1: Eliminate Waste

The main goal of lean software development is to eliminate waste, defined as anything
that does not add value to the product or increases its cost or time. In software
development, the main sources of waste are the following:

• Partially done work, as it adds no immediate value and may become

obsolete before it is finished

Poppendieck, Mary, and Tom Poppendieck. 2003. Lean Software Development: An Agile Toolkit.
14

Upper Saddle River, NJ: Addison-Wesley Professional.

22
 Chapter 2 Software Process Models

• Extra processing, such as excessive documentation/paperwork or

unnecessary meetings

• Extra features that are rarely, if ever, used, while taking up resources
and cluttering code

• Task/context switching, which reduces efficiency by introducing

delays and increasing cognitive load for the developers

• Waiting for approvals and dependencies causes wasteful bottlenecks

• Motion of artifacts and of information can be wasteful without

the necessary regulation to ensure artifact/data organization and
labeling is usably clear and consistent

• Defects, which become increasingly expensive to fix as detection time

moves further from the defect’s inception

A general approach to reducing all forms of waste in a project is to continually

reconsider how the team’s development process is working and what can be improved
(i.e., “What was wasteful and how can we change it to be less wasteful next time?”).
Small iterative adjustments to the workflow will lead to an overall reduction of
development wastes.

Lean Principle 2: Build Quality In

Quality issues lead to a variety of software development waste. Finding and logging
defects, fixing defects, and re-testing all result in waste we’d like to eliminate. “Building
quality in” refers to focusing on and incorporating quality directly into the software
development processes.
There are many techniques to increase the quality of your development processes.
Two popular techniques that improve code quality at the source are pair programming
(two programmers coding together, following a set of predefined practices) and Test-
Driven Development (TDD) (writing software with the goal of passing all previously
defined test-cases). Both allow developers to write, test, and fix code quickly and before
the code is integrated into the product code base where defects become harder to
find and fix. Integrating new features as soon as they are done gives the testing team
a new version of the product to test as quickly as possible and shortens the amount
of time between code creation and testing. Another relatively painless, but somewhat

23
Chapter 2 Software Process Models

controversial way to improve quality of your code: instead of logging discovered defects
in a defect tracking system, fix it NOW. As soon as you find it. That builds quality in and
eliminates waste simultaneously.15 Another technique to improve software quality is
constant feedback. One way to facilitate this feedback is to make the customer part of
the development team, allowing for direct repeated evaluation of new iterations of the
product and providing developers with crucial timely feedback on what is suitable and
what needs to be changed.

Lean Principle 3: Create Knowledge

While working through requirements, creating the design, and implementing the
code, the team is necessarily learning new things. You learn by working to understand
requirements. You learn by beginning with an initial design and realizing how the design
must change as the requirements become better understood. You learn more about
the domain, the customer, the tools, the dependencies, and so on. Thus, you are jointly
creating knowledge that is embodied in the code you produce and ship.
To ensure all this knowledge is truly “created” (meaning that it survives longer-
term and allows the team to really “learn” by keeping this knowledge), some shorter-
term practices are necessary. For example, if one teammate learns something crucial
about the project’s requirements or dependencies, they must ensure this information
is made available to the rest of the team. This can be achieved through consistent
code documentation, well organized wiki pages, dependency management tools,
targeted trainings, etc. Overall, these practices can reduce the motion of artifacts and
information, extra processing, and even defects. The focal point is to ensure that any new
information doesn’t just solve short-term problems for whoever encountered them, but
truly turns into knowledge that helps the whole team level up their understanding, their
skills, and their products.

Lean Principle 4: Defer Commitment

This lean principle really dates back to the early 1970s and the advent of top-down
structured design. Deferring commitment means putting off decisions (particularly
irreversible or highly consequential ones) for as long as possible and only making them
when absolutely necessary.

15
(Poppendieck & Poppendieck 2003, 25-26)

24
 Chapter 2 Software Process Models

One way to defer commitment is to follow a flexible, hierarchical, and modular

design. In top-down design, you can begin with a general formulation of the problem
solution, increasing future flexibility, and pushing implementation decisions further
down to whenever the design and the code need to become more detailed. Creating
libraries and APIs can allow us to implement flexible functionality without committing
to how it must be invoked, leaving those decisions to the individual developers of each
feature. In this way, by the time you reach the level where these details are required,
more information is typically available, allowing the code to be developed more
naturally and with greater ease.

Lean Principle 5: Deliver Fast

The faster we can deliver value to the customers, the sooner we can obtain crucial
customer feedback to guide future development. Additionally, minimizing the
time between when requirements are generated and when product meeting those
requirements is delivered, there is less time for the requirements—and the market—
to change.
So how do you deliver fast? Lean into the principles (pun intended). Keep
requirements clear and simple. Don’t add too many features and don’t spend time pre-­
planning future features. Don’t over-engineer the solution. Find a reasonable approach,
a reasonable set of data structures, and reasonable algorithms to implement your
solution. Remember that the perfect is the enemy of the good—and the fast. Satisfice
instead of optimizing: if it’s a suitable solution for the immediate need, move on. Finally,
a crucial path to deliver fast is to have an experienced, well-integrated, cooperative, self-­
organizing, respectful-of-each-other team with the right skill set for your product. The
team quite literally makes or breaks the product.

Lean Principle 6: Respect People

Respecting people is the key to building cohesive, productive teams. The focal idea is
that the people doing the work should make the decisions. Process and product creation
decisions should not be imposed from above, but rather generated from the trenches.
From the manager’s perspective, respecting your team means empowering the team
to make their own decisions, including about task time estimates and decomposition,

25
Chapter 2 Software Process Models

processes, tools, and design. This empowerment means that the manager must learn
to listen to their team and take their ideas and concerns into consideration. It also
means that the manager must act as a facilitator and a shield for their team, allowing
them to get the job done. Together, everyone must endeavor to create an environment
where everyone is able to speak their mind and disagreements are resolved with respect
for each other. This creates a team with open communication and decision-making
transparency. More on this in the next chapter.

Lean Principle 7: Optimize the Whole

“A lean organization optimizes the whole value stream, from the time it
receives an order to address a customer need until software is deployed and
the need is addressed. If an organization focuses on optimizing something
less than the entire value stream, we can just about guarantee that the over-
all value stream will suffer.”16

The main idea behind optimizing the whole is to keep the entire product picture in sight
as you develop. One way to prevent myopic views is to have diverse, multi-­disciplinary,
well-communicating teams, which contain all the skills and product creation functions
needed to deliver a product that truly meets the customer’s needs.

Implementations of Software Development Models

“When I read them, I want to shout, Draw me a map! Show me the way! But
all the authors do is describe their footprints and talk about their shoes,
which are always the best, the only true shoes.”17

When it comes to implementing any software development model, there are endless
accounts of general approaches, countless possible tweaks, and a cornucopia of books
and other resources that aim to guide you through the process. Consequently, we do not
aim to provide exhaustive nor prescriptive step-by-step implementation details. Instead,
in this section, we review the most prominent implementations of the ideas presented
earlier in this chapter. Our goal is to delineate the unique focal points of each approach,

(Poppendieck & Poppendieck 2003, 39)

16

Bancroft, Josiah. 2013. Senlin Ascends (The Books of Babel). CreateSpace Independent
17

Publishing Platform. www.amazon.com/Senlin-Ascends-Books-Babel-1/dp/1482590956.

26
 Chapter 2 Software Process Models

which we hope will not only help you distinguish them, but also hybridize them in order
to better suit your team, project, organization, and client needs.

The Waterfall Model: An Assembly-Line Approach

The first and most traditional of the plan-driven process models is the waterfall model.
Shown in Figure 2-2, it was created in 1970 by Winston Royce18 and addresses all the
standard life cycle phases. It progresses nicely through requirements gathering and
analysis, to architectural design, detailed design, coding, debugging, integration and
system testing, release, and maintenance. It requires detailed documentation at each
stage, along with reviews, archiving of the documents, sign-offs at each process phase,
configuration management, and close management of the entire project.

Figure 2-2. The Waterfall process model

18
Royce, W. W. 1970. “Managing the Development of Large Software Systems.” In Proceedings of
IEEE Wescon, 1–9. Piscataway, NJ: IEEE Press.

27
Chapter 2 Software Process Models

It also doesn’t work (at least not for anything beyond tiny projects). There are two
fundamental and related problems with the Waterfall model that hamper its acceptance
and make it very difficult to implement.
Problem 1: Waterfall requires that you finish phase N before you move on to
phase N+1.
Problem 2: Waterfall has no provision for backing up to earlier stages for
adjustments.
Waterfall is fundamentally modelled like an assembly-line for developing software.
The initially comforting straightforward progression through the waterfall stages
requires that all steps be completed in order and, since there is no way to go back and
rework earlier development phases, each phase must be completed perfectly. In the
simplest example, this means that you must precisely nail down all your requirements
before you start your architectural design, finish your coding and debugging before you
start unit testing, and so on. Additionally, each phase must be thoroughly documented
along the way. In theory, this would be great. In practice, however, this never happens.
No doubt having the complete set of perfectly understood requirements would be ideal
before diving into designing the system. Alas, we have never seen a project where all
requirements were known from the start, or where these requirements were correctly
understood by all stakeholders, or where big things didn’t change at some point during
development of real-world projects with dynamic real-world needs and constraints.
Consequently, finishing one phase before the next begins is problematic, not to
mention ensuring that nothing was missed or otherwise requires updating in any of the
preceding phases. You never know everything you need to know at exactly the time you
need to know it. This is why software is a wicked problem.
Nevertheless, the Waterfall is a terrific theoretical model. It isolates the different
phases of the life cycle and forces you to think about what you really do need to know
before you move on. It’s also a way to start thinking about very large projects, breaking
them down into smaller phases, and giving managers a warm fuzzy mirage of a plan.
It’s also a reasonable model for inexperienced teams working on a well-defined small
project, because it leads them through the life cycle and clearly labels what’s happening
at each stage. Most organizations that implement the waterfall model modify it to have
the ability to back up one or more phases so that missed requirements or unsuitable
design decisions can be fixed. This helps and generally makes the waterfall model
usable, but the requirement to update all the involved documentation when you do back
up makes even this version problematic.

28
 Chapter 2 Software Process Models

The Code and Fix “Model”: A Proto-Agile Approach

Coding and fixing as you go is not a formal model, but it is what most of us do when
we’re working on small projects by ourselves or maybe with a single partner. This
code and fix “model”, depicted in Figure 2-3, is often used in lieu of actual project
management. In this approach there are no formal requirements, no required
documentation, no quality assurance or formal testing, and release is haphazard at best.
Don’t even think about effort estimates or schedules when using this model. And yet it is
attractive enough and useful enough when we don’t need to coordinate with others.

Figure 2-3. The code and fix process model

“Code and fix” requires a minimal amount of time to understand the problem
(usually because we made up the problem/requirements ourselves) and jump straight
into coding. Compile your code and try it out. If it doesn’t work, fix the first problem you
see and try it again. Continue this cycle of type-compile-run-fix until the program does
what you want with no fatal errors and then ship it. We’ve all used it way more than once.
Software created using this model will be small, short on user interface niceties,
and idiosyncratic. With no real mention of configuration management, little in the
way of testing, no architectural planning, and probably little more than a desk check of
the program for a code review, this approach can be very dangerous for most software
development. It is, however, good for one thing: quick, disposable, maintenance-free
projects developed by tiny 1-2 person teams. In other words, for quick and dirty proofs-­
of-­concept, such as to validate architectural decisions, show a quick version of a
user interface design, or to understand some larger problem you’re working on.

29
Chapter 2 Software Process Models

If this reminds you of a mini version of agile, you are not wrong. This approach is wildly
flexible and allows us to iteratively gain insights from our progress toward the goal. For
this reason, we consider code and fix to be the proto-agile model.

Agile Development Implementations

The best practice is to iterate and deliver incrementally, treating each itera-
tion as a closed-end “mini-project,” including complete requirements,
design, coding, integration, testing, and internal delivery. On the iteration
deadline, deliver the (fully-tested, fully-integrated) system thus far to inter-
nal stakeholders. Solicit their feedback on that work, and fold that feedback
into the plan for the next iteration.
(From “How Agile Projects Succeed”19)

Agile development is all about adaptability, which can take on many different forms
depending on the project scope and timeline, the development team, and so on.
Applying agile development prescriptively will break the very agility of agile. Thus,
although a number of specific agile approaches have been devised over the years, it
is important to remain flexible in their understanding and implementation. Below,
we discuss a number of these implementations, highlighting their core values and the
accompanying nomenclature intended to help developers lean into these values.
Agile processes all aim to provide agility during software development, but how
that agility is achieved can differ widely. As you read about each agile implementation,
keep the following key differences in mind and consider the remaining specifications
to be descriptive but non-prescriptive guidelines for how one might approach
operationalizing each approach:

• eXtreme Programming delivers agility by prioritizing specific

software engineering practices (in particular, pair programming and
constant integration).

• Crystal delivers agility by prioritizing people and their interactions,

allowing each team to self-organize as they see fit.

19
www.adaptionsoft.com/on_time.html

30
 Chapter 2 Software Process Models

• Scrum delivers agility through explicit short iterations (“sprints”) that

deliver product increments, although what is “short” depends on the
scope of the project.

• Kanban delivers agility through a continuous flow of tasks from

being needed to done, where the remaining tasks can be altered and
reprioritized at any time.

Agile Methodology - eXtreme Programming (XP)

Kent Beck and Ward Cunningham created eXtreme Programming (XP) around 1995,
describing it as a “lightweight, efficient, low-risk, flexible, predictable, scientific, and fun
way to develop software.”20 XP focuses on productive technical development, particularly
pair programming and constant integration.
XP relies on the following fundamental ideas:

• Heavy customer involvement: XP requires that a customer

representative be on site at all times to define the content of each
iteration of the product, as well as to create all the acceptance tests
for each interim release.

• Short iteration cycles and frequent releases: XP typically uses release

cycles in the range of a few weeks or months and each release is
composed of several iterations of 3-5 weeks each.

• Pair programming: XP requires that all code be jointly written by

pairs of developers, alternating as the driver and the navigator
periodically (approximately every 30 minutes). The driver codes while
the navigator watches, making suggestions, thinking about design
and testing, and so on. While less code can be written in this way, the
resulting code contains fewer defects, improving productivity.

• Continuous unit testing (also known as Test-Driven Development or TDD):

XP calls for developers to first write the unit tests for any new features and
then develop these features in a way that passes the predefined tests.

20
This is a very short description of how XP works; for a much more eloquent and detailed
explanation see the bible of XP: Beck, K. 2000. Extreme Programming Explained: Embrace
Change. Boston, MA: Addison-Wesley.

31
Chapter 2 Software Process Models

While all Agile approaches favor direct communication, XP extends this notion to
direct coding communication (both with a coding partner and with the rest of the code)
and to direct client communication. Frequent releases require constant integration and
building of the product. Whenever a programming pair finishes a feature or task and it
passes all their unit tests, they immediately integrate and build the entire product. They
then use all the unit tests as a regression test suite to make sure the new feature hasn’t
broken anything already checked in. If it does break something, they fix it immediately.
So in an XP project, integrations and builds can happen several times a day. This process
gives the team a good feel for where they are in the release cycle every day and gives the
customer a completed build on which to run the acceptance tests. Having an on-site
customer representative allows the XP team to get immediate feedback on new features
and to uncover design and requirements issues early.
Implementing XP may vary depending on the team and the project, but should
involve some form of the following practices:

• The planning game: Develop the scope of the next release by

combining business priorities and technical estimates. The customer
and the development team need to decide on the stories/features
that will be included in the next release, the priority of each story,
and timing of the release. The developers are responsible for
breaking these stories into tasks and estimating the duration of each
task. The sum of the durations will determine which tasks can get
done by delivery date. If necessary, some stories are moved out of a
release if the numbers don’t add up.

• Small releases: Put a simple system into production quickly, and

then release new versions on a very short cycle (1-2 months, with
duration and size depending on what makes sense from a business
perspective). The larger the release scope and duration, the harder it
is to estimate.

• Metaphor: “A simple shared story of how the whole system works,”

which replaces your architecture. The metaphor must be a coherent
explanation of the system, decomposable into smaller bits called
stories. Stories should always be expressed in the vocabulary of the
metaphor, and the language of the metaphor should be common to
both the customer and the developers.

32
 Chapter 2 Software Process Models

• Simple design: Keep the design as simple as you can each day.
Redesign often to keep it simple. According to Beck, a simple design
(1) runs all the unit tests, (2) has no duplicated code, (3) expresses
what each story means in the code, and (4) has the fewest number
of classes and methods that make sense to implement the stories
so far.21

• Testing: Programmers constantly write unit tests. Tests must all

pass before integration. Beck takes the hard line that “Any program
feature without an automated test simply doesn’t exist.”21 Although
this works for most acceptance tests and should certainly work for
all unit tests, this analogy breaks down in some instances, notably
in testing the user interface in a GUI. Even this can be made to work
automatically if your test framework can handle the events generated
by a GUI interaction. Beyond this, having a good set of written
instructions will normally fill the bill.

• Pair programming: Two programmers at one machine must write all

production code in an XP project. Any code written alone is thrown
away. This has the effect of reinforcing collective ownership by
spreading the knowledge of the entire system around the entire team.
It avoids the “beer truck problem,” where the person who knows
everything gets hit by a beer truck and thus sets the project schedule
back months.

• Collective ownership: The team owns the entire project and all of its
code, sharing the reasonability for designing, writing, altering, and
testing all features. This supports “ego-less programming,” promoting
effective teamwork.

• Continuous integration: Integrate and build every time a task

is finished, possibly several times a day (as long as the tests all
pass). This helps to quickly detect and isolate bugs and defects by
narrowing issues to the latest code and its interactions with the
existing code base.

21
(Beck 2000)

33
Chapter 2 Software Process Models

• Refactoring: Make small improvements of non-functional aspects

of the code without changing its external behavior in order to make
the code cleaner, less redundant, more readable, more efficient, and
more maintainable. The principle of simple design imposes on you
the responsibility to make refactoring changes when you see they are
needed, while collective ownership allows you to refactor code written
by others.

• 40-hour week: Work a regular 40-hour week. Never work a second

week in a row with overtime. The XP philosophy has a lot in common
with many of Tom DeMarco’s Peopleware arguments. People are
less productive working overtime, having to handle personal affairs
during the workday, being tired and making more mistakes, being
stressed and irritable with their teammates, and so on. Having time
to relax and recharge allows developers to focus on their work during
the work day, making the team more productive.

• On-site customer: A customer is part of the team, is on-site, writes

and executes functional tests, and helps clarify requirements. The
customer’s ability to give immediate feedback to changes in the
system also increases team confidence that they are building the
right system every day.

• Coding standards: Because of collective code ownership and

ongoing refactoring, the team must follow sensible coding standards
to improve communication in and out of the code base. These
standards should make your code easier to read and maintain but
should not constrict creativity.

 gile Framework - Crystal: Flexible Customization to Team/

A
Project Needs
Crystal is an agile method originally devised by Alistair Cockburn22 while he was working
at IBM in the early 1990s. He noticed that projects vary too much for any one set of
project steps to suit them all. Instead, Crystal is thus organized around the people rather

22
Cockburn, Alistair. Crystal Clear. Upper Saddle River: Addison-Wesley, 2004.

34
 Chapter 2 Software Process Models

than around processes or tools. This means human interactions, as well as individual
skills, talents, and needs, all of which are variable across teams, as well as within teams
over time.
As we are not focusing on specific processes, Crystal has no formal structure.
Instead, Crystal development believes the following:

• All projects are unique. Tools and processes need to be determined

for each project, as well as adapted if/when changes occur.

• Teams can self-optimize. Tools and processes need to work for the
project but also for the team, thus teams themselves should jointly
determine the workflow that will work best for them, as well as adjust
it as needed during development.

To support these characteristics, Crystal development is organized around the

following 7 principles:

• Frequent delivery: Frequent (a relative term depending on project

overall scope) testing and new releases.

• Reflective improvement: The team will periodically reflect on and

make improvements to practices and tools.

• Osmotic communication: Osmotic for small teams, closed loop for

larger teams.

• Personal safety: Create an environment where members feel safe to

express their opinions, suggestions, and needs.

• Focus: Team members need a shared understanding of the big

picture and of the individual tasks.

• Easy access to expert users: On-demand access to experts to resolve

questions, concerns, or gaps in understanding.

• Technical environment with automated tests, configuration

management, and frequent integration: When organizing around
people, there is a lot of development flexibility, so frequently
integrating everyone’s work, automatically testing to ensure
everything works individually and together smoothly, and using
version control for backup and partial releases is paramount.

35
Chapter 2 Software Process Models

You can see that Crystal is very flexible and thus can be adapted to the needs of each
team and project. For shorter projects, Crystal’s reduced organizational scaffolding and
required processes can be beneficial, as it allows focus on how the specific team can
accomplish the required work. The main caveat here is that if the team is newer, larger,
or remote, self-organization can get tricky.

 gile Framework - Scrum: Iterative Sprints Toward the Next

A
Short-Term Goal
Scrum derives its name from rugby, where a scrum is a means of restarting play after
a rule infraction: the 8 forwards on a rugby team (out of 15 players in the rugby union
form of the game) attempt to (re)gain control of the ball and move it forward towards
the opposing goal line. The idea in the agile Scrum methodology is that a small team
is unified around a single goal and gets together for sprints of development that move
them towards that goal.
The original process management idea for Scrum comes from Takeuchi and
Nonaka’s 1986 paper, “The New New Product Development Game”23, while the first use
of the term “Scrum” is attributed to DeGrace and Stahl’s 1990 book Wicked Problems,
Righteous Solutions.24
Like other agile methodologies, Scrum emphasizes the efficacy of small teams,
direct communication, iterative development, learning from frequent feedback, and
collective ownership. What distinguishes Scrum is its focus on team management and its
structure of explicit time-boxed periods of development called sprints. Each sprint has a
predetermined duration (commonly 1-4 weeks), with a fixed delivery date that does not
move out. The scope of work to be delivered needs to be chosen so as to accommodate
this delivery date, while still delivering the next Minimum Viable Product (MVP) to the
client each sprint. The goal of each sprint is to provide a prototype that showcases your
most current understanding of the client needs and your plan for delivering a solution.
Showing this prototype (no matter how rudimentary) allows you to begin a conversation

23
Takeuchi, Hirotaka, and Ikujiro Nonaka. “The New New Product Development Game.” Harvard
Business Review 64, no. 1 (1986): 137-146.
24
DeGrace, Peter, and Leslie Hulet Stahl. 1990. Wicked Problems, Righteous Solutions: A Catalogue
of Modern Software Engineering Paradigms. Yourdon Press Computing Series. Englewood Cliffs,
N.J.: Yourdon Press.

36
 Chapter 2 Software Process Models

about what was understood correctly and what needs adjustment. Ensuring this happens
early limits the work that needs to be redone to make the necessary adjustments before
developing further. Thus, sprints are “about creating conditions that enable better
decision making, sooner.”25

Scrum Roles
Scrum explicitly defines three roles in a development project:
The product owner is the person who generates and prioritizes the requirements
for the product. These requirements commonly take the form of user stories, which are
features that can be summarized into sentences like “As a <type of user>, we want to <do
something>, so that <some value is created>.” The product owner adds the user stories
to the product backlog and prioritizes them. The product owner is also charged with
making sure that the team understands the requirements behind the user stories.
The Scrum master is an expert in Scrum who facilitates development by coaching the
team through Scrum values and practices (such as the daily Scrum meetings), helping
the team self-organize (e.g., by increasing transparency), helping resolve internal and
external blockers, and protecting the team from outside influences during the sprint.
The scrum master is emphatically not team lead/manager because, as Scrum teams are
teams of equals and arrive at decisions by consensus.
The development team is everyone else: designers, developers, writers, and so on.
The team reviews the user stories generated and prioritized by the product owner,
turning each highest priority story into one or more tasks that suggest how the necessary
feature will be developed in order to deliver value. Selecting a subset of stories and tasks
that can be accomplished within the given sprint duration, the team self-organizers by
jointly deciding who will work tasks and what development processes they will employ.
Regardless of task allocation, the team collectively owns all code and the project, sharing
the goal of delivering the next functional MVP at the end of every sprint.

www.linkedin.com/pulse/agile-consistently-lowering-standards-part-2-changing-­
25

andy-­reid/

37
Chapter 2 Software Process Models

Scrum Artifacts
Scrum requirements are encapsulated in two backlogs:

• The Product Backlog is the prioritized list of all the requirements for
the project. The product owner creates and prioritizes the product
backlog composed of user stories, based on a desired Product Goal.
The development team breaks the high-priority user stories into tasks
and estimates them. This list of tasks becomes the Sprint Backlog.
• The Sprint Backlog is the prioritized list of user stories for the current
sprint. Once the sprint starts, only the development team may add
tasks to the sprint backlog; these are usually bugs found during
testing. No outside entity may add items to the sprint backlog, only
to the product backlog. The focus of the sprint backlog is the Sprint
Goal: a guiding star for the team to follow; any changes during the
sprint should protect this goal.

• The Increment is a contribution to the Product Goal that means

the definition of Done, which is a formal quality measure decided
upon by the organization (or by the team, if not otherwise defined).
Multiple backlog items may reach Done state during a single Sprint.

Scrum Board
In most Scrum teams, the sprint backlog is visual, providing everyone with a clear shared
view of the progress status of the sprint work. It is represented on a board using either
Post-It notes or index cards, with one note or card per task; it may also be an online
virtual board (e.g., Trello, Jira, Notion, or Pivotal Tracker). This task board, shown in
Figure 2-4, always has at least three columns: ToDo, Doing, and Done, though more
commonly it also includes a Product Backlog, a Sprint Backlog, and a column for testing
such as Quality Assurance/Review. At the start of a sprint, the Development team selects
some of the top priority items from the Product Backlog and moves them to the Sprint
Backlog. These items are then broken down into tasks, which become the ToDo items for
the sprint. These tasks will move across the board until reaching the Done column once
fully developed, tested, and integrated into the code base.

38
 Chapter 2 Software Process Models

Figure 2-4. A generic single-sprint Scrum board. Dark arrows indicate the
movement of items during sprint planning; light arrows indicate the movement of
items during the sprint

Scrum Values
In order to facilitate the teamwork necessary for an agile self-organizing team, SCRUM
relies on individuals practicing the following:26

• Commitment to the shared goals and each other

• Focus on the Sprint Goal and Sprint Backlog

• Openness about the work and challenges (including interpersonal)

• Respect for each other as individuals and as capable contributors to

the shared goals

• Courage to tackle difficult tasks, to bring up difficult conversations,

and to generally “do the right thing”

Scrum Ceremonies
Scrum teams have several types of meetings that help the team self-organize.
Sprint planning: An initial planning phase that creates the product list of the initial
requirements, decides on an architecture for implementing the requirements, divides

26
https://scrumguides.org
39
Chapter 2 Software Process Models

the user stories into prioritized groups for the sprints, and breaks the first set of user
stories into tasks to be estimated and assigned. They stop when their estimates occupy
all the time allowed for the sprint. Tasks in a sprint should not be longer than one day
of effort and ideally can be accomplished in one sitting (to avoid task switching). If a
task is estimated to take more than one day of effort, it is successively divided into two
or more tasks until each task’s effort is the appropriate length. This rule comes from the
observation that humans are terrible at doing exact estimations of large tasks and that
estimating task efforts in weeks or months is basically just a guess. So breaking tasks
down into smaller pieces gives the team a more reliable estimate for each.
The daily stand-up is a short meeting (15–30 minutes; the shorter the better) where
the entire team discusses sprint progress. The daily scrum meeting allows the team to
share information and track sprint progress. By having daily scrum meetings, any slip
in the schedule or any problems in implementation are immediately obvious and can
then be addressed by the team at once. “The Scrum Master ensures that everyone makes
progress, records the decisions made at the meeting and tracks action items, and keeps
the scrum meetings short and focused.”27 During the daily stand-up, each team member
answers the following three questions in turn:
How have you furthered development since the last meeting?
How will you further development between now and the next meeting?
Is anything standing in your way?
Note that the wording of these questions may be tweaked slightly, but the sentiment
must remain. Discussions other than responses to these three questions are deferred
to other meetings. Daily stand-ups are crucial to help everyone track progress towards
the shared Spring Goal, facilitate collaboration, and improve accountability and
engagement.
The sprint review happens at the end of each sprint, presenting the newly developed
MVP to the product owner (commonly as a demo), who may perform acceptance testing
on it. The meeting “reviews” everything that has been “Done” this sprint as part of
fulfilling the Spring Goal, as well what was left out and why.
The sprint retrospective is held after the sprint review to “retrospect” on how the team
worked together: their processes, communication, collaboration mechanics, meeting

Rising, Linda, and Norman S. Janoff. 2000. “The Scrum Software Development Process for Small
27

Teams.” IEEE Software 17 (4): 26–32.

40
 Chapter 2 Software Process Models

expectations, etc., searching for areas in which they can improve performance for the
next sprint. Retrospectives are a crucial tool for improvement, as they are responsible
for the agile iterative improvement of the teamwork itself. The retrospective marks the
official end of the current sprint.
Backlog refinement or story time meetings are held periodically throughout the sprint
(such as once a week) in order to refine backlog items, ensuring they are ready for future
sprint planning. Product owner participates by adding and (re)prioritizing stories, and
developers participate by breaking down high priority stories into tasks.
Although sprints usually end at the end of the predefined sprint period, a sprint can
be terminated early if all work planned for the sprint has been completed. While new
work could be added, it is generally most suitable to go through all the end-of-sprint and
sprint-planning procedures in order to properly review what was done, retrospect on
how it was done, and plan next development steps.

Scrum Velocity
With most teams, estimates of tasks become better as the project progresses, primarily
because the team now has data on how they have done when estimating on previous
sprints. The measure of the amount of work completed in a single sprint is called
velocity. Over time, this allows the team decide how many tasks to include in each sprint.
With meaningful retrospectives and the resulting iterative improvements to the team’s
processes and practices, velocity should increase over time as the team becomes better
at breaking down and assigning tasks, creating accurate estimates of the work needed for
each task, as well as at collaborating with each other.

Scrum End of Project

After the last scheduled development sprint, a final sprint may be done to bring closure
to the project. This sprint implements no new functionality, but prepares the final
deliverable for product release. It fixes any remaining bugs, finishes documentation,
and generally productizes the code. Any requirements left in the product backlog are
transferred to the next release. A Scrum retrospective is held before the next sprint
begins to ponder the previous sprint and see if there are any process improvements that
can be made.

41
Chapter 2 Software Process Models

 gile Framework - Kanban: Continuous Flow

A
with Limited Current
The Kanban Method is a practice derived from Lean manufacturing (the Toyota
Production System) and other change management systems; it draws most of its original
ideas from the just-in-time manufacturing processes. Kanban is more methodology than
process; it is an objective and a set of principles and practices to meet that objective.

The Kanban Board

To help organize development, Kanban employs the following notions:

• Work in progress (WIP) is the total number of tasks the team is

currently working on, including all the states in which a task may find
itself (in-progress, done, testing, review, etc.).

• Flow is the passage of tasks from one state to another on the way to
completion.

• Lead time: The amount of time (in hours or days) it takes for the team
to get a task from the initial ToDo state to the Done state. Over time, as
the team finishes more and more tasks, the average lead time can be
computed for the team, allowing for an estimation of how long it will
take any one task to get Done, which serves as a measure of productivity.

What distinguishes Kanban is the continuous flow of the work. There are no
timeboxed sprints and, consequently, no smaller sprint backlogs containing a subset of
tasks for the team to focus on next. All remaining ToDos are in a single backlog and to
help the team get organized, Kanban uses swimlanes: horizontal dividers to segment the
tasks. Swimlanes can represent any useful separation, including task priority, task type,
different projects/products, and even different teams.
With all remaining tasks sitting in the backlog, limited work-in-progress is how
you allow the team to stay focused on the flow. Work-in-progress and flow can be
asynchronously tracked by developers using the Kanban board, a variant on the Scrum
task board. Figure 2-5 shows a generic task/Kanban board. These boards can be physical
white boards that occupy one wall of a common space for the team or shared digital
boards. On this board the team will add physical or digital post-it notes to identify tasks,
which can then be moved from column to column (i.e., state-to-state) on the board.

42
 Chapter 2 Software Process Models

Figure 2-5. A generic task/Kanban board, with WIP maxima and swimlanes,
with arrows depicting flow

With this type of board, users have the option of changing the number and headings
of the columns in order to make the board fit their process. Kanban works by using a
pull system: instead of pushing items out to other stages, Kanban tells developers to pull
items from a previous stage as they have the capacity to handle them. At the end of every
task completion, the team will have working software with a new feature added.
The team can then specify the maximum number of tasks that are allowed to be
worked on simultaneously (i.e., “Doing” and “Quality Assurance/Review”) referred to as
the work-in-progress or WIP, used to control the flow of work through the team. There
is not hard rule for the WIP, but it should account for: 1) the number of people on the
team and 2) how many tasks should each person be juggling concurrently. The general
recommendation is somewhere between 1 to 2 tasks per person. For example, let’s say
that every state on the Kanban board is maxed-out (there are N tasks in development,
M in review/testing) and a developer finishes developing a new task. This task cannot
move to the Review state until one of the tasks currently under review is finished. We’ve
just exposed a bottleneck in the flow of work. In Kanban, the developer would jump in
to help review one of the tasks in that state. No new tasks can be pulled into the Develop
state until there is room for the finished task downstream.

43
Chapter 2 Software Process Models

In Kanban, the objective is to maximize WIP within the constraint of the maximum
number of tasks allowable at any time. There is no time-boxing as in Scrum; the goal is to
move tasks through as quickly as possible (have the shortest lead time) while maximizing
productivity by working up to the maximum number of tasks allowable.
You can note that when we say maximizing WIP, we don’t mean giving the team more
work. In fact, the goal in keeping the maximum number of tasks in each state low is
to reduce the team’s workload and allow them to focus on a smaller number of tasks
(we want to avoid multitasking). The idea is that this will reduce stress and expensive
task-witching, while increasing work quality and throughput. You’ll notice that there
are some things missing here, notably, how things get on the ToDo list, and what Done
means. That’s because Kanban isn’t really a project management technique. In order to
use Kanban, you need to have some process in place already and you need to manage it.

 ybrid Software Development Approaches

H
for Multi-Level Focus and Scope
Multiple software development philosophies and even multiple implementations
can coexist effectively within the same organization, team, or project. You may need
to choose several approaches to help you get organized at different times and focus
levels. Consider that the overall company needs to get organized, a project needs to get
organized, and development needs to get organized.
“While all of the Agile processes have commonality, their sweet spots are
attuned to specific organizational levels: different “views” for different
audiences. Lean shines when applied to those with a strategic, organiza-
tion and shareholder value focus: the Executive. Scrum shines when applied
to those with a team organization, management, and project delivery focus:
the Project Management. Extreme Programming shines when applied to
those with a development delivery and tactical focus: the Development.”28

28
Bourne, Geoffrey. 2010. “The Marriage of Lean, Scrum, and Extreme Programming (XP): How
to Align Agile Across and Organization.” AgileConnection. www.agileconnection.com/article/
marriage-lean-scrum-and-extreme-programming-xp.

44
 Chapter 2 Software Process Models

Most notably, it is not lean versus agile, but rather crucially lean AND agile, where
lean focuses on improving the process by reducing wastes, while agile focuses on
improving the product by effectively adapting to new information throughout the
project. Both are crucial to developing software. Additionally, agile does not mean no
planning, as not thinking far enough ahead can lead to incorrect early decisions; a better
perspective is to borrow lean’s deferring of commitment to ensure that early decisions
to do not eliminate potentially useful future options. Here are a few ways that the
implementations of these ideas can play off of each other:

• Lean can be naturally combined with Scrum, as agile allows early

feedback, reducing how much needs to be reworked, and clear
shared understanding among teammates can reduce motion, defects,
non-utilizing talent, overproduction, and waiting.

• Since XP is mainly focused on programming, development can easily

benefit from team management defined in Scrum.

• While coding individual features, developers naturally employ mini

Waterfalls, creating a plan and following it to develop and test each
new feature.

• While developing prior to an initial release to the public may be most

fruitful with Scrum, providing continuous services and fast changing
projects may be better represented through Kanban, allowing for a
continuous approach.

• Scrum is well suited to projects where discrete increments are

meaningful and for working toward an initial release, while Kanban
lends itself naturally to ongoing operation such as providing a
continuous service; Scrumban29 is a fused approach that allows
for the development of new features while also providing ongoing
services.

As can be seen from the methodologies described in this chapter, iteration and
collaboration are the key. The most effective way to build complex software is to
incrementally gather insights, leaning what to make and how to make it better at each

29
See www.agilealliance.org/scrumban/

45
Chapter 2 Software Process Models

following step. You must recognize that you never have all the knowledge at the start,
and that designing, writing, testing, and delivering incrementally better code is the most
reliable and effective path toward creating great software.

References
Anderson, David J. 2010. Kanban: Successful Evolutionary Change for Your Technology
Business. Sequin, WA: Blue Hole Press.
Atkinson, Roger. 1999. “Project Management: Cost, Time, and Quality, Two Best
Guesses and a Phenomenon, It’s Time to Accept Other Success Criteria.” International
Journal of Project Management 17 (6): 337–42.
Bancroft, Josiah. 2013. Senlin Ascends (The Books of Babel). CreateSpace
Independent Publishing Platform. www.amazon.com/Senlin-Ascends-Books-Babel-1/
dp/1482590956.
Beck, K. 2000. Extreme Programming Explained: Embrace Change. Boston, MA:
Addison-Wesley.
Bourne, Geoffrey. 2010. “The Marriage of Lean, Scrum, and Extreme Programming
(XP): How to Align Agile Across and Organization.” Article. AgileConnection. www.
agileconnection.com/article/marriage-lean-scrum-and-extreme-programming-xp.
Cockburn, A. 2002. Agile Software Development. Boston, MA: Addison-Wesley.
DeGrace, Peter, and Leslie Hulet Stahl. 1990. Wicked Problems, Righteous Solutions:
A Catalogue of Modern Software Engineering Paradigms. Yourdon Press Computing
Series. Englewood Cliffs, N.J.: Yourdon Press.
DeMarco, Tom. 1983. Controlling Software Projects: Management, Measurement
and Estimation. Yourdon Press.
Fulghum, Robert. 1986. All I Really Need to Know I Learned in Kindergarten.
New York, NY: Ivy Books.
Jeffries, Ron. 2015. The Nature of Software Development: Keep It Simple, Make It
Valuable, Build It Piece by Piece. Programming. Dallas, TX: The Pragmatic Programmers,
LLC. pragprog.com.
Martin, Robert C. 2003. Agile Software Development, Principles, Patterns, and
Practices. Upper Saddle River, NJ: Prentice Hall.
McConnell, Steve. 1996. Rapid Development: Taming Wild Software Schedules.
Redmond, WA: Microsoft Press.

46
 Chapter 2 Software Process Models

Paulk, Mark C. 1995. The Capability Maturity Model: Guidelines for Improving the
Software Process. The SEI Series in Software Engineering. Reading, Mass.: Addison-­
Wesley Pub. Co.
Poppendieck, Mary, and Tom Poppendieck. 2003. Lean Software Development: An
Agile Toolkit. Upper Saddle River, NJ: Addison-Wesley Professional.
Project Management Institute. 2021. A Guide to the Project Management Institute
Body of Knowledge. 7th ed. Project Management Institute, Inc.
Rising, Linda, and Norman S. Janoff. 2000. “The Scrum Software Development
Process for Small Teams.” IEEE Software 17 (4): 26–32.
Royce, W. W. 1970. “Managing the Development of Large Software Systems.” In
Proceedings of IEEE Wescon, 1–9. Piscataway, NJ: IEEE Press.
Siegelaub, J. M. 2007. “Six (Yes Six!) Constraints: An Enhanced Model for Project
Control.” In Proceedings of the PMI Global Congress 2007. Atlanta, GA: Project
Management Institute, Inc. www.pmi.org/learning/library/six-constraints-
enhanced-model-project-control-7294.
Takeuchi, H., and I. Nonaka. 1986. “The New New Product Development Game.”
Harvard Business Review 64 (1): 137–46.
Womack, James P., Daniel T. Jones, and Daniel Roos. 1990. The Machine That
Changed the World: The Story of Lean Production -- Toyota’s Secret Weapon in the
Global Car Wars That Is Now Revolutionizing World Industry. New York, NY: Simon and
Schuster.

47
CHAPTER 3

Project Management
Essentials
“The first step of any project is to grossly underestimate its complexity and
difficulty.”
—Nicoll Hunt

Once your project begins, it needs to be managed. You need to manage the schedule,
the people, the process, and above all, yourself (wherever you fit on the team). There
is no one correct way to manage development, but there are some ways to do this well
and even more ways to do it poorly. We have certainly uncovered some of both over the
years, so let us try to make your journey less perilous. It’s dangerous out there; take this
chapter!
Working on anything other than personal development projects means working on a
team; and working on a team means being managed, either from above or from within.
Thus, learning about project management from both sides is an essential part of learning
software development. Project management can be seen as managing the work and
managing the people, so we divided this chapter into two major sections:

1. Project planning: Much of how daily tasks are managed depends

on the chosen software development model, which you saw in
the previous chapter. What’s left are the parts of the project that
need to be established before the project begins (i.e., project
planning tasks):

a. Organization

b. Risk analysis

49
© John F. Dooley and Vera A. Kazakova 2024
J. F. Dooley and V. A. Kazakova, Software Development, Design, and Coding,
https://doi.org/10.1007/979-8-8688-0285-0_3
Chapter 3 Project Management Essentials

c. Resource requirements

d. Task estimation and schedule

e. Defect management

2. Soft-Aware development: The most important and complex aspect

that must be managed in any project are the people. Developers
and managers are not just a valuable resource, but rather the
very biosphere of development. Maintaining and supporting this
biosphere with all of its complex dynamics will not only impact
the success of the current project but also all the projects to
follow. In the second half of this chapter, we review how and why
we must strive to be Soft-Aware (“soft-skill” aware) throughout
development, by discussing

a. The dark side of teamwork

b. Supporting individuals

c. Supporting the culture

d. Conflict as opportunity

e. Teamwork artifacts

Project Planning
Project plans are a great tool for setting down what you think you’re doing, an outline of
how it will be done, and how you plan on executing the outline. The problem with a project
plan is that, once it’s written and signed off on, upper management thinks the project will
run exactly as stated in the plan. But the reality of the project often thwarts the plan.
Project planning is forever; it continues throughout the entire duration of the project.
“The Plan” is never really set in stone because typical software projects are usually in
constant flux. In those projects that are using a plan-driven process model, a project plan
is an actual document that is written by the project manager and that is approved and
signed off on by the development team and by upper management.
It is, in effect, a contract, albeit a rolling one, of what the team is going to do and how
they are going to do it. It says how the project will be managed, and in the most extreme
plan-driven projects, even states how and when the document itself will be modified.
50
 Chapter 3 Project Management Essentials

Project Planning: Organization

Before work can begin, you need to decide how you are going to organize development.
If you’re working with an experienced team, you can reuse your previous organizational
documentation, but you should never skip this. The two main but often intertwined
sides of project organization are the development and the people:

• How are you going to organize the product? (Waterfall or iterative

development? Version control tools? Project scope and schedule?)

• How are you going to organize the people making this product? (What
is the team organization/hierarchy? How and when will everyone
communicate and coordinate?)

It is crucial to have explicit agreement and precise shared understanding of

scheduling and expectations across all stakeholders. Choosing a development process
model (see previous chapter) will provide many of the answers about how to organize
your project. For instance, any agile project will be focused around features and
require a schedule of iterations, each beginning with planning and culminating in a
minimum viable product. Agile teams are hierarchically flat and self-organizing, with
the team owning the agile project plan (not the project manager) and requiring frequent
communication on a variety of open channels. Agile teams also co-own all code, thus
requiring everyone to follow shared code-management practices, such as git-flow
branching for source control. Narrowing down the process model from agile to a specific
implementation (such as XP, Scrum, Crystal, feature-driven, etc.) will further specify
details of organizing both the product and the people.

Project Planning: Risk Analysis

Next we need to think about risk analysis. What can possibly go wrong with a project and
what will we do when it does? Let’s look at some possible risks1:

• Schedule slips: That task that you estimated would take three days
has just taken three weeks. In a plan-driven project, this can be an
issue if you don’t have regular status meetings. Waiting three weeks
to tell your boss that you’re late is always worse than telling her that

1
McConnell, Steve. 1996. Rapid Development - Taming Wild Software Schedules. Microsoft Press.

51
Chapter 3 Project Management Essentials

you’ll be late as soon as you know it. Don’t put off delivering bad
news. In an agile project, this is unlikely because most agile projects
have a daily status meeting (or stand-up). This way schedule slips
are noticed almost immediately, and corrective action can take place
quickly.

• Excessive defect rate: Your testing is finding lots of bugs. What do

you do: continue to add new features or stop to fix the bugs? Again,
this can be a real issue in a project where integration builds happen
according to a fixed schedule, say once a week. In a project where
integrations happen every day, or every time a new feature is added,
you can keep up with defects more easily. In either case, if you are
experiencing a high defect rate, the best thing to do is to stop, take
a look around, and find the root cause of the defects before adding
more functionality. This can be very hard to do from a project
management standpoint, but you’ll thank yourself in the end.

• Misunderstood requirements: What you’re doing isn’t what the

customer wanted. This classic problem is the result of the fact that
customers and developers live in two different worlds. The customer
lives in the application domain where they understand from a
user’s perspective what they want the product to do. The developer
understands from a technical perspective how the product will work.
Occasionally, these worlds intersect and that’s good, but often they
don’t and that is where you get a misunderstanding of requirements.
The best approach is to have the customer on site as often as possible
and to produce deliverable products as often as possible.

• Requirements churn: New features, altered features, deleted

features… Never-ending requirements churn is probably the largest
single reason for missed delivery dates, high defect rates, and
project failure. Churn happens when the customer (or your own
marketing folks, or the development team itself ) continues to change
requirements while development is underway. It leads to massive
amounts of rework in the code, retesting of baselines, and delay after
delay. Managing requirements is the single most important job of the
project manager. In a plan-driven process, a change control board

52
 Chapter 3 Project Management Essentials

(CCB) examines each new requirement and decides whether to add

it to the list of features to be implemented. There may be a member
of the development team on the CCB, but that’s not required, so the
danger here is that the CCB adds new features without understanding
all the scheduling and effort ramifications. In agile processes, the
development team keeps control of the prioritized requirements list
(called the product backlog in Scrum), and only adjusts the list at
set points in the project—after iterations in XP and after each sprint
in Scrum.

• Turnover: Your most experienced developer decides to join a start-up

three weeks before product delivery. The best way to reduce turnover
is to (1) give your developers interesting work, (2) have them work
in a pleasant environment, and (3) give them control over their own
schedules. Oddly enough, money is not one of the top motivators for
software developers. This doesn’t mean they don’t want to get paid
well, but it does mean that throwing more money at them in order to
get them to work harder or to keep them from leaving doesn’t generally
work. Still, despite your best efforts, some developers will leave. The best
way to mitigate the effect of turnover is to spread the knowledge of the
project around all the members of the development team. Principles
like common code ownership and techniques like pair programming
work to invest all the team members in the project and spread the
knowledge of the code across the entire team. We will talk more about
how to support developers and maintain a healthy workplace culture in
the “Soft-Aware Development” section of this chapter.

Once you’ve got a list of the risks to your project, you need to address each one and
talk about two things: avoidance and mitigation. For each risk, think about how you can
avoid it. Build slack into your schedule, do constant code reviews, freeze requirements
early, do frequent releases, require pair programming so you spread around the
knowledge of the code, and the like. Then you need to think about what you’ll do if the
worst-case scenario does happen; this is mitigation. Remove features from a release, stop
work on new features and do a bug hunt, negotiate new features into a future release,
and so on. If a risk becomes a reality, you’ll have to do something about it; it’s better to
have planned what you’ll do beforehand.

53
Exploring the Variety of Random
Documents with Different Content
 his equestrian statue in Parliament Close, 477.
Charms for healing sores, &c., i. 324.
Specimen of, ii. 153.
Chattan or Macintosh, Clan, Earl of Moray’s expedition against, i.
542, 543.
Cheviot, order against hunting in, i. 453.
Chiesley of Dalry shoots Sir George Lockhart, ii. 495.
Chiesley, William, writer in Edinburgh, punished for a cheat, ii. 445.
Child-murder, hanging of women for, &c., ii. 414.
Chisholms prosecute M‘Leans for witchcraft, ii. 293, 294.
Christie’s Well, pilgrimages to, i. 323.
Christmas-day, James VI. orders keeping of, i. 426;
general disregard of, 506.
Its observance in Edinburgh, ii. 297.
Church-discipline, severity of, i. 336; ii. 196-199.
Church-lands, convention for revocation of, ii. 6.
Church matters, meeting for deliberation on, ii. 12.
Citadels, order for destroying those raised during the
Commonwealth, ii. 279.
Clairvoyance, quasi case of, ii. 394.
Clark, Alexander, provost of Edinburgh, his reception of Charles I.,
ii. 63-65.
Clark and Ramsay, hanged for poisoning their master, ii. 373.
Clergy, their zeal and self-denying poverty, i. 132;
collisions with Edinburgh merchants, 241, 242;
their intolerance, 244;
their admonitions of James VI., and general denunciations
against common corruption of all estates of the realm,
 267.
Perfect accord with the Estates, ii. 179-181.
Clothing and cloth-works in Scotland, anecdotes connected with,
ii. 416-422.
Cloth-manufacture, seven Flemings engaged to set agoing; result,
i. 362;
encouraged by James VI., 425.
At Newmills, near Haddington, ii. 418.
Coaches, early examples of, i. 19;
first hint at public coaches and wagons in Scotland, 431.
Street coaches, ii. 358;
stage-coaches, 218, 247, 391, 476.
Coal, early digging of, i. 24;
Countess of Sutherland first works coal of Brora, 302;
coal-works at Culross, 485;
price of coal fixed, 519;
Johnston’s licence to export, 520.
Cochrane of Ochiltree, saved by his heroic daughter Grizzel, ii. 479.
Cockburn, the executioner, hanged, ii. 433.
Cockie, Isobel, burned for witchcraft, i. 280.
Cockpool, inundation of house of Old, anecdote of, ii. 17.
Coffee-houses, first known in Edinburgh and Glasgow, ii. 359-361.
Coin, attempt to raise the value of, i. 122.
Coke, William, burned for sorcery;
bill of expenses, ii. 70, 71.
Collace, Mr William, first regent in St Leonard’s College, i. 73.
College of Physicians, proposed in Edinburgh, i. 521.
Colquhouns and Macgregors, battle between, i. 377, 378.
Colville, Lady, imprisoned for educating her son in disloyal
principles, ii. 467.
Colville, Lord, mission to France concerning the Scots Guard, i.
535.
Combat, a remarkable, i. 285;
among the last attempts to settle a dispute by, 414.
Comets, early ideas about, i. 112, 113;
appearance of a remarkable, in 1618, 505.
Appearance of one during the day, ii. 185;
in 1664 and 1665, 300-302;
in 1676, 376;
in 1680, curious notions regarding, 410-412;
Halley’s, in 1682, 444.
Communion Tuesday meetings; their object, i. 508.
Communion administered in Edinburgh after an interval of six
years, ii. 235.
Con of Achry, a papist, excommunicated by presbytery of
Aberdeen, ii. 59.
Confession of Faith, commonly called the King’s Confession, i. 142.
Conventicles, various persons fined for attending, ii. 334.
Copper-mine in parish of Currie, ii. 453.
Corn, great dearth of in 1567, i. 52.
Cornwall, Archibald, hanged for poinding the king and queen’s
portraits, i. 349.
Corstorphine, frightful tragedy at village of, ii. 401-403.
Costume, court order of, i. 426.
Court of Session, suspension of, ii. 128.
Couts, Janet, accuses eleven women of witchcraft, ii. 194, 195.
Covenant, National, signed, ii. 105, 116;
 forced on people at Aberdeen, 120, 123.
Covenant, Solemn League and, made, ii. 109;
character and consequences of, 111;
forced on Lady Frendraught, 159;
opinion of royalists regarding rule of, 160, 161;
taken by Charles II., 175;
forced on Marquis and Marchioness of Douglas, 191, 193;
burned at Linlithgow, 291.
Covenanters, proceedings of the, ii. 106-113, 119-121, 123-126.
Covenanter’s Ribbon, ii. 124.
Cowdothe, an epidemic so called, i. 117.
Cowper, William, bishop of Galloway, a libel against, i. 372;
his sudden death, 507, 508.
Craig, Marjory, hanged as a witch, ii. 377-379.
Crawford and Glammis, feud between, i. 117, 118.
Crawford, Earl of, confined in the Tower, ii. 218;
appointed Lord Treasurer, 255.
Crawford, Master of, young Edzell’s attack on, i. 405, 406.
Crawford gold-field, i. 17, 51, 253, 290, 474.
Creditors, supposed power of, over interment of the dead, ii. 328,
329.
Crichton of Frendraught and Gordon of Rothiemay, dispute
between ii. 45-50, 76-79, 84.
Crichton, Sir Robert, of Cluny, a caption used against him in
church, i. 474.
Crombie, Thomas, summoned for slaughter of William Blair, ii. 4.
Cromwell, Oliver, his first visit to Edinburgh, ii. 170, 171;
crosses the Tweed with an English army, 201-207;
anecdotes of, 203, 204;
 his law-commissioners for Scotland, 219;
breaks up the General Assembly, 221;
proclaimed protector, 242-244.
Crossford visions, Walker’s account of the, ii. 485-487.
Cultmalindy and Monyvaird, feud between, i. 490.
Cumming, Isobel, a teacher of young ladies, her petition, ii. 482.
Cunningham and Crawford, Captains, harry Bothwell Moor, i. 71.
Cunningham of Robertland, murders Earl of Eglintoun, i. 161.
Poinding of his goods, ii. 340.
Cunyie-house, master of, visits England, i. 386.
Cupar (Fife), great fire at, in 1668, ii. 321.
Custom-officers and Edinburgh merchants, dispute between, ii.
299.
Customs, i. 339-342;
Spalding bewails suppression of old Christian, ii. 142.

Daes, Alexander, introduces paper-making, ii. 398;

favours the shewing of an elephant, 410;
complaint from, 432.
Dalkeith, James VI. residing at, i. 146.
Dalry paper-mills, Daes’s petition for, ii. 398.
Dalrymple, Janet, the unfortunate Bride of Baldoon, ii. 326-328.
Dalrymple, William, murdered by Mures of Auchindrain, i. 435-437.
Dancing, laws against, i. 338.
Danish nobles and gentlemen entertained by Edinburgh
magistrates, i. 199.
Darnley, Lord, i. 35-37;
his murder, 40.
Davidson, William, an Edinburgh flesher, a monster-pig farrowed in
his house, i. 76.
Day of Law in the reign of James VI., i. 247.
Dearths in Scotland, i. 59, 94, 99, 116, 117, 179, 180, 265, 271,
303, 304, 318, 444, 476, 530, 531, 538, 539; ii. 74, 75, 85,
134, 144, 149, 156, 185, 207, 235.
Deer slain with guns near the Border, i. 103.
Deer-hunting, the Water-poet’s description of Highland, i. 497.
Deil stick the Minister, anecdote of, ii. 453.
Denmark, King of, 2000 men raised in Scotland for, i. 53.
Devil of Glenluce, a house-infesting spirit, ii. 228-232.
Devoe, Andrew, a dancing-master in Edinburgh, Bayne’s petition
against, ii. 384;
his complaint against the Fountains, 401.
De Vois, Cornelius, a gold-seeking adventurer, i. 50.
Dick, Alison, burnt for witchcraft; curious bill of expenses, ii. 70,
71.
Dick, Sir William, wealth of, ii. 183;
his history and death, 236-240.
Dick’s house of Priestfield burnt, ii. 413.
Dickison, Provost, murdered in Peebles, i. 81.
Allusion to, ii. 480.
Dickson, David, minister of Irvine, Stewarton Sickness takes its rise
under, ii. 43;
moderator of the General Assembly, 221.
Dickson, John, an Englishman, hanged for slanderous speeches
against James VI., i. 273.
Dickson, John, of Belchester, broken on the rack for murder of his
father, i. 224.
Dissection, malefactors given for, ii. 96.
Dissent, progress of Presbyterian, i. 543-545.
Divines, Assembly of, at Westminster, ii. 111.
Diving-bell, Maule of Melgum’s invention of the, ii. 387.
Dog dispute, tragical issue of a, ii. 478.
Dogs, acts against bringing to church, i. 342.
Donaldson, Robert, murdered, ii. 329.
Douglas, Andrew, minister of Dunkeld, tortured and hanged for
rebuking Morton, i. 80.
Douglas, Colonel, diligent training of his regiment, ii. 462.
Douglas, Hon. George, his quarrel with John Corsehill, ii. 478.
Douglas, Janet, a deaf and dumb girl, her deceptions as a witch-
finder, ii. 376-381.
Douglas, Marquis of, his difficulties with the presbytery of Lanark,
ii. 190-194.
Douglas, second Marquis of, his separation from Lady Barbara
Erskine, ii. 340.
Douglas, Mr Archibald, his mock-trial for concern in murder of
Darnley, i. 163.
Douglas of Lochleven, his hatred of the Hamiltons, i. 100.
Douglas, Sir James, of Parkhead, slays James Stewart of Newton, i.
274.
Douglas, William, beheaded for concern in duel with Home of
Eccles, ii. 318.
Douglas, William, stabs Thomas Lindsay, ii. 439-442.
Downie, John, the pest breaks out in his ship, i. 139.
Dowries or Tochers, examples of, ii. 35.
Dragon-hole, near Perth, yearly procession to, i. 327.
Dream regarding Dunnottar Castle, i. 210.
Dress of clergymen and their wives, General Assembly’s
regulations regarding, i. 102.
Dresses of the sexes, prank of interchanging, i. 327.
Drinking, Aberdeen town-council’s order against compulsory, ii. 4.
Drinking-debauch, unfortunate issue of a, ii. 345, 346.
Dromedary, exhibition of a travelling, ii. 249.
Drumlanrig and Cashogle, private war between, i. 520, 521.
Drummond, Lady Jean, her portion of 5000 merks, ii. 34, 35.
Drummond of Hawthornden, Ben Jonson’s visit to, i. 500-503.
Drummond, Robert, his exposure in the ‘stocks’ for adultery, i. 92.
Drummond, Sir George, becomes bankrupt, ii. 479.
Drummonds and Oliver Young, dispute between servants of the, i.
293.
Drury, Sir William, threatens to destroy the town of Linlithgow, i.
63.
Dryfe’s Sands, clan-battle of, i. 252.
Duddingston Loch, legal case about swans on, ii. 492.
Duff, David, outrages committed by, in a dispute about land, i.
348.
Dumbarton, Castle of, taken by surprise by the king’s party, i. 73.
Its ruinous state for national defence, ii. 18.
Dumbarton, encroachments of the sea on, i. 400.
Dumblane, four priests of, condemned to death for saying mass, i.
59.
Dumfries, complaint against minister and reader of, i. 95;
 James VI. executes justice at, 294;
anecdote of a mission to Wigtown to purchase cattle, 304.
A papist priest taken at, ii. 11;
papist marriage at, 72;
case of poisoning at, 92;
insecurity of its jail, 442.
Dunbar, Earl of, hangs above 140 Border thieves, i. 400;
his ecclesiastical mission to Scotland from James VI., 413;
further proceedings against Border thieves, 422, 423.
Dunbar, 300 fishermen perish at, i. 125.
Battle of, ii. 176;
the witch of, 493.
Dundee, its quarrel with Perth, i. 48;
coining at, 157;
anecdote connected with the pest, 399;
suffers under pest, 414.
Sack of, by General Monk, ii. 207;
witch case at, 330;
a jail delivery by Graham of Claverhouse, 461.
Dunfermline, great fire at, i. 542.
Dunglass Castle, dismal accident at, ii. 136.
Dunlop, Bessie, her trial for witchcraft, i. 107-110.
Dunlop, Thomas, a poor Quaker, persecution of, ii. 443.
Dunnottar Castle, dream regarding, i. 210.
Siege of; anecdote of regalia of Scotland, ii. 213;
Whigs confined in, 480.
Dunse, possessed woman at, ii. 43.
Dunse Law, magazine of pebbles at, ii. 126.
Duntreath, deaf and dumb Laird of, his divinations, ii. 384, 385.
Durie, Gibson of, story of his kidnapping, i. 355, 356.
Durie, John, a minister of Edinburgh; his return from banishment,
i. 148.
Dutch invasion; fleet appears at mouth of Firth of Forth, ii. 318.

Eagles, remarkable anecdotes of, ii. n. 268.

‘Earth-dogs,’ or terriers, James VI. writes to Earl of Mar for, i. 547.
Earthquakes, i. 140, 292, 420, 454, 522; ii. 241.
Easter Sunday, communion on, disinclination of the people to
kneeling, i. 509.
Ecclesiastical discipline, i. 336-338.
Its bearing on the habits of the people, ii. 156-161.
Echt, Barmkyn of, strange sounds heard at, ii. 115.
Eclipses of the sun, i. 296; ii. 215.
Economy, traits of the public, i. 345-347.
Eddy-pool of Water of Brechin, drying up of, ii. 75.
Edinburgh, effects of the civil war on, i. 79-81, 87, 88;
spirited resistance to Earl of Bothwell, 189;
filthiness of, in 1617, 486.
Charles I.’s visit to; his reception, ii. 63-69;
taxes, poverty, vanity, and debt of, 235, 236, 247;
three fires at, on one Sunday, 487.
See whole work passim.
Edston-haugh, near Peebles, duel at, i. 265.
Edzell, Laird of, his attack on Master of Crawford, i. 405, 406.
Eels, thousands of dead, cast on banks of North Loch, ii. 234.
Eggs, act against exporting, i. 467.
Eglintoun and Glencairn, Earls of, feud between, i. 394, 395.
Eglintoun, Earl of, murdered by Cunningham of Robertland, i. 161-
163.
Egyptians, Privy Council’s order against, ii. 54.
Elder, James, a baker, tried for usury, ii. 298.
Elephant, the first seen in Scotland, ii. 410.
Elgin Cathedral, choir of, destroyed by a high wind, ii. 114;
casting down of timber-screen of, 138.
Elizabeth, Queen, sends a hostile army against Queen Mary’s
friends in Scotland, i. 61;
another, 85;
intelligence of her death brought to King James, 381.
Elphinstone, George, a Glasgow bailie, violent attacks against, i. 90.
Elphinstone, Sir George, his dispute with Sir M. Stewart at Glasgow,
i. 396-398.
English judicature at Leith, impartiality of, ii. 215.
English soldiers, their description of the Highlands, ii. 218;
their contempt for stool of repentance, ibid.
English, their jealousy of the Scotch in reign of James VI., i. 432-
434.
Entry-money at taking service, Privy Council’s proclamation
against, i. 489.
Episcopacy introduced by James VI., i. 379, 394, 415, 426, 428,
480, 523; ii. 1, 2;
abrogated, 106;
re-established, 256;
finally abolished, 474.
Equinoctial gale of 1606, devastating effects of, i. 392.
Ericht, subscription for building a bridge over river, ii. 54.
Errol, Earl of, makes his peace with Kirk of Aberdeen, i. 288;
trait of his domestic circumstances, 466.
His death, ii. 55.
Erskine, Robert, with his three sisters, condemned to death for
poisoning his two nephews, i. 452.
Eskdale Muir denuded of sheep, ii. 367.
Estates and Clergy, perfect accord between, ii. 179-181.
Evelick, singular boy-murder near, ii. 439.
Ewe and Lamb, a kidnapping ship so called, ii. 359.
Excommunicated persons, Privy Council’s measures against, ii. 18,
20-28, 36-41.
Excommunication, i. 336;
pronounced against Marquis of Huntly, 417.
Dealt out liberally, ii. 173;
of a gardener revoked by James VII., 482.

Faas, gipsies, a number of, executed, i. 476.

Falkirk and Stirling, sixteen farms between, buried in moss, ii. 35.
Falkland and Holyrood, improvement on the palaces of, for king’s
visit, i. 476.
Famine in 1563, i. 25;
severity of, in 1623, 538, 539.
See Dearths.
Farquhar, Robert, a rich Aberdeen merchant, his loans to the state,
ii. 181;
story of, 182.
Farquharson of Inverey, his fine of £4000 [Scots?], ii. 184.
Fast-day in Old Aberdeen, in 1644, a reality, ii. 154.
Faw, Moses, a gipsy, his petition granted, i. 426.
Faws and the Shaws, battle between, ii. 388.
Female Remonstrants in Parliament Close, strange scene with, ii.
369.
Fenelon, Sieur de la Motte, a French ambassador, i. 151.
Fiacre, origin of application of the term to hackney-coaches, i.
324.
Fian, John, schoolmaster at Prestonpans, burnt as a wizard, i. 211,
212.
Fielding, Beau, and two Scotch gentlemen, drink three horrid
toasts, ii. 381.
Fiery-cross, the Macleans raise 300 men by the, ii. n. 371.
Fife and Kinross, enormous sacrifices made by counties of, to
resist Cromwell’s invasion, ii. 206.
Fines, Scottish Estates impose severe, ii. 183, 184;
for attending conventicles, 334.
Finnie, Agnes, burnt for witchcraft, ii. 149-153.
Fire-engine for Glasgow, first, ii. 244.
Fires on Midsummer and St Peter’s Eves, i. 326.
Fish, white, destroyed by dog-fish; Spalding’s idea of, ii. 144.
Fishermen, Earl of Errol’s petition against, ii. 458.
Fishing Society, formation of a, ii. 330, 331.
Fleck, George, reveals where the Earl of Morton’s treasure lay, i.
142.
Fleming, Lord, his marriage celebrated, i. 29;
sufferings in the civil war, 1570, 62.
Flesh, use of, forbidden by Privy Council, i. 50.
Fletcher, Christian, saves the regalia of Scotland, ii. 214.
Flood in the Tay, remarkable, i. 525-527.
Florida, one of the Spanish Armada vessels, blown up, ii. 386-388.
Foot-race, curious, of twelve brewsterwives, and sixteen fishwives,
ii. 273.
Foot-soldiers, five companies raised by Charles II., ii. 296.
Forbes, Dr, bishop of Edinburgh, i. 544.
——, of Corse, banishment of, ii. 146;
his corpse refused burial in his own ground, 451.
Forbes, Master of, and George Leslie, fight between, ii. 134.
Forbes of Leslie, his prosecution of Farquharson of Inverey, ii. 184.
Forbes of Tolquhoun and Ogilvie of Forglen, dispute between, ii.
477.
Forester, a bailie of Stirling, rare form of his funeral, i. 260.
Forrester, Lord, murdered by his mistress, ii. 401.
Forth, Firth of, alarm of invasion from vessels appearing in, ii. 15.
Foulis, Lady, extraordinary trial of, for witchcraft, i. 202-205.
Foulis, Thomas, an Edinburgh goldsmith;
his gold, silver, and lead mines, i. 252-254, 290;
a creditor of James VI., 295, 296.
Fountains, two brothers, their patent as Masters of the Revels, ii.
400, 459.
France, differences between Great Britain and, ii. 12.
Fraser, Helen, burnt for witchcraft, i. 280.
——, Janet, strange phenomenon on her Bible, ii. 488.
Fraser, Lord, and Laird of Philorth, dispute between, ii. 99, 100.
Fraser of Kirkhill, extracts from his diary, ii. 241.
Fraser’s view of the customs of the Highlanders, ii. 383.
French, Adam, of Thornydykes, his abduction, i. 469.
French language, town-council of Edinburgh patronise the
teaching of, i. 94.
French Protestants, contributions for, i. 102;
 warmly entertained in England and Scotland, 163.
Frendraught and Rothiemay, dispute between, ii. 45-50, 76-79, 84,
98.
Frendraught, Lady, falls under discipline of presbytery of
Strathbogie, ii. 158-160;
persecution of, 335.
Frolics and masqueradings, i. 327-329.
Frosts, great, in 1570-1-2-3, i. 72, 84, 457;
freezing of several rivers in Scotland; a fair held upon the ice
on the Thames, 409.
Frost of 1683, ii. 454.

Gallow-lee, five phanatiques hanged at the, ii. 428.

Geddes, Jenny, supposed heroine who cast the first stool at the
bishop, ii. 103.
Geddie, John, his novel bee-house, ii. 323.
General Assembly, fasts for steerage from papists, i. 196;
held in 1608, 416.
Covenanting assembly at Glasgow, ii. 106;
suppression of, by order of Cromwell, 221, 222.
Ger, John Dhu, an outlaw, outrages of, ii. 121, 128, 135, 263.
German legions, unscrupulous recruiting of, in Scotland, ii. 13.
Gibb, Muckle John, chief of the Sweet Singers of Borrowstounness,
ii. 415.
Gibson, Alexander, kidnapped, i. 355.
——, Anna, abduction of, ii. 319.
Gilderoy, with nine caterans, executed, ii. 96-98.
Gillon, James, condemned for a riot, i. 9.
Gipsies, their first appearance in Scotland; act against, i. 84;
 severities against, six hanged, 476;
their harbourage at Roslin, 539.
Edict against, ii. 54;
some in Haddington jail, ordered to be hanged and drowned,
99.
Girdle for baking invented in Culross, ii. 493.
Girvanmains, Laird of, kills M‘Alexander of Drumachryne, i. 310, 311.
Gladstanes, Archbishop, his cook killed, i. 431.
Gladstanes, Marion, nearly poisons Nicolas Johnston, ii. 92.
Glammis and Crawford, feud between, i. 117, 118.
Glammis, Lords, and Lindsays of Forfarshire, feud between, i. 312,
313.
Glanvil’s Saducismus Triumphatus, ii. 476.
Glasgow, an earthquake in, i. 64;
Smith’s excerpts from burgh records, 88-92;
attempt to demolish its cathedral, 122, 123;
tumult in 1606, 395-399.
Great fire at, ii. 216;
interesting incidents connected with, 244, 245, 247;
another fire at, 389;
a cloth manufactory set up in, 445;
subscription for a fire at Kelso, 458.
Glass-manufacture, patent granted for, i. 432.
——work in Wemyss, Fife, the first known in Scotland, i. 510, 511.
Glen, James, fined for publishing the Root of Romish Ceremonies,
ii. 490.
Glencairn and Eglintoun, Earls of, feud between, i. 394, 395.
Glengoner, gold-digging in, i. 18, 152, 253.
Glenluce, Devil of, incidents in history of the, ii. 228-232.
Gloucester frigate, shipwreck of the, ii. 405, 439.
God and the King, a book so called, i. 474.
God’s Blessing, a shaft of Hilderstone silver-mine so called, i. 412.
Gogar, Miller, and Sangster, hanged, ii. 422.
Gold and silver, licence to search for, i. 50.
——, exportation of, forbidden, i. 107.
—— mines in Lanarkshire, i. 17, 50, 152, 253.
Golden Assembly, why so called, i. 428.
Goldsmiths, the Edinburgh, historic importance of, i. 253.
Goodman’s Croft, the, act against, i. 324, 325.
Gordon, Adam, sets fire to Alex. Forbes’s house, and burns his
lady, children, and servants—twenty-seven in all, i. 75.
Gordon, Adam, and Francis Hay, combat between, i. 468.
Gordon and Mackay, strife between, and Earl of Caithness, i. 440-
443.
Gordon, Jean, divorcée of Bothwell; her coal and salt works at
Brora, i. 302.
Pleasing character of, ii. 30.
Gordon, Lord, commander of French Scots Guards, i. 535, 536.
His commission against excommunicated papists, ii. 36-41.
Gordon, Mr James, a Jesuit, James VI. reasons with, i. 182.
Gordon of Craig, banished for papistry, i. 545, 546.
His petition to the Council, ii. 38;
petitions Charles I., 59.
Gordon of Dunkintie and his eldest son slain, ii. 69.
Gordon of Enbo, his quarrel with Sutherland of Duffus, ii. 5, 6.
Gordon of Gight, revenges his brother’s death, i. 468.
Gordons of Gight, persecuted for papistry,
i. 352, 353, 403, 404;
outrage by, at Turriff, 354;
strange act at Aberdeen, 468.
Gordon of Rothiemay and Crichton of Frendraught, dispute
between, ii. 45-50, 76-79, 84.
Gordon, Sir Robert, sent against Earl of Caithness, i. 536-538.
Gordon, William, his contempt of presbytery, ii. 160.
Go-summer and go-har’st, definition of, ii. n. 79.
Gould, Mr William, his representations to Council against papists,
ii. 59, 60.
Gourlay, Agnes, punished for charming the milk of kine, ii. 188.
Gourlay, John, customer, i. 195.
——, Robert, punished for exporting grain, i. 93;
Regent Morton confined in his house, 143;
king lives in same house, 255;
illustration, 554.
Gowdie, Isobel, the witch, her confession, ii. 286-291.
Gowrie, Earl of, arrives with his brother in Edinburgh from Padua, i.
313;
their attempt on life of James VI., 319.
Gowrie treason, anniversary of, a holiday, i. 408.
Grace, Act of, its effects, ii. 225.
Graham, Bessie, executed for witchcraft, ii. 187, 188.
Graham, Helen, an heiress, abduction of, i. 470.
Graham, Mr John, of Hallyards, and Sir James Sandilands, litigation
between, i. 245.
Graham of Claverhouse, imports cloth for his soldiers, ii. 419;
entreats mild punishment for ordinary crimes, 461;
 his conduct at the Revolution, 473.
Graham of Duchrae, his encounter with Earl of Airth, ii. 309.
Graham of Inchbrakie, postmaster-general for Scotland, ii. 316,
317.
Graham, Patrick, Captain of Town Guard of Edinburgh, ii. 420, 438.
Graham, Richard, a wizard, worried and burnt at Cross of
Edinburgh, i. 235.
Grain and fruit, abundance of, ii. 293.
Grainger, Mrs, saves the Scottish regalia, ii. 214.
Grant, memoir of the family of; traditionary anecdote, i. n. 234.
Grant of Carron and Grant of Ballindalloch, feud between, ii. 50-
54.
Grant, younger of Ballindalloch, presents M‘Grimmen’s head to the
Council, ii. 85.
Gray, James, his forcible abduction of the daughter of John
Carnegie, i. 222.
Gray, James, a lieutenant in the Midlothian Militia, beheaded, ii.
395.
Greg, John, singular persecution of, ii. 99.
Gregor, Clan, proclamation against, i. 524.
Greybeard, a Dutchman, works valleys of Wanlock-head for gold, i.
51.
Greyfriars, influence of, i. 3.
Grieve, a maltman, murdered by his son, ii. 293.
Grieve, Thomas, accused of curing disease by witchcraft, i. 540,
541.
Gueldres, Mary de, re-interment of her supposed remains, i. n.
222.
Guild, William, convicted of stealing, i. 14.
Guinea, a gold coin so called, ii. 114.
Gunpowder, manufacture of, ii. 11.
—— Plot, general joy in Scotland at detection of, i. 391.
Gustavus Adolphus, 6000 Scots go to assistance of, ii. 55-57.
Guthrie, Bishop, preaches before Charles I., ii. 67.
Guthrie, James,beheaded; anecdotes of, ii. 275-277.
Guthrie, John, minister of Perth, marries a couple of thirteen, i.
505.
Guthry, Helen, admonishes James VI. of his duty, i. 236, 237.

Hackney-coach licensed between Leith and Edinburgh, ii. 264.

Haitly of Mellerstanes, slain by his father-in-law, i. 372.
Halkit Stirk, a Highland robber so called, apprehended by Laird of
Grant, ii. 263;
committed to the Tolbooth, 343.
Halley’s Comet in 1682, ii. 414.
Hallucinations, curious religious, ii. 313-315.
Hamilton, a soldier, resolves to challenge Captain Bruce, i. 549.
Hamilton, Alexander, a warlock, worried and burnt, ii. 32, 33.
Hamilton, Archibald, a spy for Cromwell, hanged in chains, ii. 205.
Hamilton, David, younger of Bothwell-haugh, complaint against, i.
347.
Hamilton, James,of Bothwell-haugh, shoots the Regent Moray, i.
60.
Hamilton, John, archbishop, keeps up the rites of the Catholic
church, i. 23;
hanged at Stirling, 73.
Hamilton, Lords John and Claud; their conduct to old Carmichael
and Laird of Westerhall, i. 99.
Hamilton, Lord John, his narrow escape from town-guards’ volley of
honour, i. 238.
Hamilton, Marquis (subsequently Duke) of, raises 6000 Scots for
Gustavus Adolphus, ii. 55-57;
his expedition in 1648, 113, 170.
Hamilton, Mr Robert, minister of St Andrews, writes down Knox’s
prediction about Kirkaldy of Grange, i. 85.
Hamilton, Patrick, his attack on Abacuck Bisset, i. 180.
Hamiltons of Livingstone, lawless acts of, i. 258.
Hammerman, an Edinburgh, 1555, illustration, i. 10.
Hand-fasting, a custom so called, i. 335.
Hardheads, base coin so called in Scotland, act against, i. 101.
Hares, singular visit of, to city of Edinburgh, ii. 228.
Hart and Norton, booksellers, petition for liberty to import German
books duty-free, i. 194.
Hart, Andro, printer of Napier’s Logarithms, i. 455.
Hart, John, printer, his edition of the Bible, ii. 41.
Harvests, plentiful, ii. 222, 226.
Hawking, James VI.’s love of this sport, i. 391.
Hay, Francis, and Adam Gordon, combat between, i. 468.
Hay, Lord, of Yester, his conduct to Brown of Frosthill, i. 256.
Hay, Lord, of Yester, brother of the preceding, his widow founds a
church in Edinburgh, i. n. 264.
Hay, Margaret, forcible abduction of, i. 223.
Heiresses under twelve years, fines for marrying, ii. 251.
Henderson, Robert, a baxter’s boy, burnt for fire-raising, i. 155.
Henderson, Robert, his wonderful cures, i. 24.
Hepburn, George, his duel with Brown of Hartree, i. 264, 265.
Hepburn, Robert, a partisan of Queen Mary, i. 68.
Hepburn, James, of Moreham, his duel with Birnie, a skinner in
Edinburgh, i. 285.
Hepburn, Thomas, murder of, ii. 284.
Heraldry, Scottish touchiness regarding, i. 393.
Heres, Peter Groot, a German, receives a licence for paper-making,
i. 194.
Heriot, George, founder of Heriot’s Hospital, i. 253.
Heriot, William, becomes cautioner for repentance of George
Heriot, i. 59.
Heriot’s Hospital, solemn dedication of, ii. 253;
barber-chirurgeon dispute, 342.
Hermaphrodite, a, hanged at Edinburgh, ii. 220.
Hertsyde, Margaret, her prosperity and adversity, i. 412.
Hesse’s eldest son, Landgrave of, visits Edinburgh, i. 530.
Higgins, an Englishman, reprints the Mercurius Politicus at Leith, ii.
272.
High Commission Court established, i. 428.
—— School boys of Edinburgh, mutiny of, i. 261-264.
Illiberality of master of, to private teachers, ii. 426.
Highland and Border incursions, i. 310.
—— bowmen, Charles I. raises a small troop of, ii. 14.
Highland spraichs, ii. 262.
Highlanders, pure loyalty of the, ii. 178, 179.
Highlands, rude condition of, i. 164, 378; ii. 306-311.
Scarcity of schools in, 179.
Hilderstone silver-mines, i. 411, 412.
Hill, a musician, his abduction of Marion Foulis, ii. 227.
Hirsel, tragical incident at the, ii. 455.
Hogg, James, account of ‘Thirteen Drifty Days,’ ii. 366.
Holidays and popular plays, i. 326, 327.
Holland, war with, causes stagnation of trade, ii. 302.
Holstein, Duke of, visits Scotland, i. 298.
Holyrood and Falkland, improvements on the palaces of, for king’s
visit, i. 476.
Holyrood Palace, as before the Fire of 1650, illustration, ii. 205;
a popish chapel, college, and printing-office in, 483.
Home, David, of Wedderburn; his son’s portraiture of, i. 95-99.
Home, Jean, of Ayton, her abduction and marriage to George
Home, ii. 390.
Home, Lady, of Manderston, tried for witchcraft, ii. 33.
Home, Lord; slaughter of Bailie Lauder, i. 300.
Home, Sir George, of Wedderburn; sketch of his character by David
of Godscroft, i. 119-122.
Home, William, stabs Johnston of Hilton, ii. 455.
Hope, Sir Thomas, extracts from his Diary, ii. 148.
Hoppringles and Elliots in Edinburgh, day of law between, i. 71.
Horse, exhibition of a dancing, ii. 247.
Horse-racing in Scotland, early practice of, i. 103, 410, 514.
Every Saturday at Leith, ii. 273.
Horses, act preventing exportation of, i. 47.
House-painter craves permission to set up in Glasgow, ii. 247.
Hume, Sir Patrick, of Polwarth, his remarkable hiding-place and
escape, ii. 464-467.
Huntingtower Well, supposed sanative qualities of, i. 322.
Huntly, fifth Earl of, his mysterious death, i. 103-106.
Huntly, sixth Earl (subsequently first Marquis) of, marriage to Lady
Henrietta Stuart, i. 184;
slaughter of Bonny Earl of Moray, 230-236;
makes his peace with the kirk at Aberdeen, 288;
his rental sheet, 315-317;
excommunicated as an apostate papist, 417;
relieved from excommunication, 429;
Orders of Privy Council against, ii. 20-28, 36-41;
his death and character, 89-92.
Huntly, Marchioness of, her mourning procession to Charles I., ii.
69;
persecuted and exiled as a Catholic, 139.
Huntly, second Marquis of, marriages of his daughters, ii. 134;
beheaded, 178.
Huntly, fourth Marquis of, decree ordering him to be separated
from his mother, ii. 311.

Idolatry, act against, i. 147.

Illusions of sight and sound, curious, ii. 313-315.
Importation of goods, decree against, i. 458.
‘Incest,’ trials, and severe punishment of cases so called, ii. 28, 29.
Independents in civil war, ii. 111.
Indian Emperor, Dryden’s prologue to the, ii. 404.
Inglis, Esther, her beautiful handwriting, i. 550.
Innes, Alexander, slays Innes of Peithock; beheaded, i. 110-112.
Innes, tragedy, the, i. 134-137.
Insane, treatment of the, in past times, ii. 424.
Interregnum, 1649-1660, ii. 174-254.
Inundation and violent tempest, memorable, ii. 17.
Invasion, alarm of, from vessels in Firth of Forth, ii. 15;
fear of, 18;
by the Dutch fleet, 318.
Inverness-shire, sad account of, in 1666, ii. 308.
Ireland, Alexander, minister of Kincleven, his complaint against Sir
John Crichton, of Innernytie, i. 390.
Irish Ague, an epidemic so called, ii. 199.
Irish beggars, order against, ii. 34.
—— rebellion, anecdote of Charles I., ii. 141.
‘Iron yetts’ of the Border thieves, i. 401.
Irvine of Drum, his dispute with presbytery of Aberdeen, ii. 210-
212.
Irving, Francis, imprisoned in the Edinburgh Tolbooth for a papist
riot, ii. 338-340.
Islay and Kintyre, Lords of, tale of commotion between, i. 164-168.

Jack, Robert, merchant, hanged for coining, i. 48.

Jaffray, Alexander, an Aberdeen magistrate, ii. 96.
Jaffray, Grizzel, executed for witchcraft; affecting anecdote of her
son, ii. 330.
James VI., his birthplace, i. 38;
writes to lords of secret council, 122;
his formal visit to Edinburgh, 126, 129-131;
sets up the doctrine of the divine right of kings, 127;
a guise or fence played before him at St Andrews, 138;
his gay mood after Morton’s death, 146;
policy with French ambassadors, 151;
his Essayes of a Prentise in the Divine Art of Poesie, 154;
his opinion of the pest, 154;
anecdote of Bothwell-haugh, 163;
orders prayers for his mother, 170;
his grief at her death, 171;
his visit to St Andrews with Du Bartas the French poet, and
disputation with Andrew Melville, 173-175;
his attempt to reconcile his nobles, 177, 178;
writes to Denmark about grain, 179;
reasons with Mr James Gordon, a Jesuit, 182;
anecdote of Spanish Armada, 185;
in expectation of his Danish bride, writes pressing letters for
contributions, 192-200;
sets sail for Denmark to bring her home, 193;
his arrival with the queen at Leith, 196;
her reception in Edinburgh, 196-199;
supposed groundwork of his Demonology, 212,
quoted, 306;
his imbecility amidst his rude courtiers, 221;
remonstrates with two Edinburgh ministers, 224;
admonished by James Davidson, minister, for failures in king-
craft, 227;
his grudge against the ministers, 236;
admonished by Helen Guthry, 236;
Earl of Bothwell’s first, second, and third attempts to seize his
person, 229, 237, 238;
commissions Lord Ochiltree to seize the house of Row as a
manufactory of false coin, 239;
anecdote of courtship of Earl of Mar, 243;
again in bad odour with clergy, 243-245;
scene with Bothwell in his chamber at Holyrood, 250, 251;
Thomas Foulis his Bank of England, 253;
his queen delivered of a prince, 255;
his fear of Bothwell, 255;
inconstancy of his favour to Countess of Bothwell, 264;
his proclamation against forestallers, 266;
attempts to reconcile his hostile nobles, 266, 267;
admonitions from clergy, 267, 268;
his edict against, 275;
its consequences, 276, 277;
revokes commissions against witchcraft, 291;
Melville’s Dix-huitaine, 291;
hangs a number of Border thieves, 293;
his debts to Edinburgh goldsmiths, 294, 95;
nearly drowned on returning to Falkland from a General
Assembly, 314;
Gowrie conspiracy, 319;
his restriction on number of persons entering Stirling Castle,
320;
letter to laird of Dundas, 322;
made a burgess of Perth, 348;
poinding of his and the queen’s portraits, 349;
his proclamation at Dumfries, 368;
death of Queen Elizabeth, 381;
his fondness of hawking, 391, 392;
his unfortunate silver-mine adventure, 411, 412;
his episcopal innovations, 415-417;
persecution of Catholics, 421, 422;
encourages cloth-making, 425;
orders keeping of Christmas-day, 426;
acknowledged head of the Kirk, 428;
his reply about ‘beggarly Scots,’ 433;
unrelenting towards satirists, 453;
his ideas of free-trade, 459;
Lord Melville’s letter to, 473;
his visit to Scotland, 479-486;
his disputations with Edinburgh professors, 483-485;
anecdote of visit to Culross coal-mines, 485;
his declaration regarding Sunday sports, 491;
his interest in the pearl-fishery, 518;
 his Counterblast to Tobacco, 532;
his letter to his Scottish councillors about liberty of
conscience, 533;
his picture falls from hall of Linlithgow Palace, 536;
his death, 552.
James VII., his residence at Holyroodhouse, ii. 403;
gives balls, plays, and masquerades, 404;
plays golf on Leith Links, 405;
Mons Meg fired in honour of, 409;
his act for encouragement of trade and manufactures, 417;
Earl of Roscommon’s prologue to, 429;
nearly drowned, 439;
flies to France, 494.
Jameson, George, the Scottish portrait-painter, ii. 62, 63.
Jedburgh, attempt made to proclaim Queen Mary at, i. 75.
Jesuits in Scotland, i. 182;
fast held for discovery of, 465, 466.
Johnston, Agnes, executed for murder of her grand-niece, ii. 367.
Johnston, Janet, excommunicated; anecdote of her accouchement,
ii. 19.
Johnston, Laird of, and Lord John Maxwell, feud between, i. 155,
251, 301.
Johnston, Laird of, shot by Lord Maxwell, i. 410.
Johnston, Nicolas, Marion Gladstanes nearly poisons, ii. 92.
Johnston of Hilton, stabbed by William Home, ii. 455.
Johnston, Sir Archibald, his prayers, ii. 148;
executed, 256.
Jonson, Ben, his visit to Scotland, i. 499-503.
Jop, Peter, a sailor, his petition to Privy Council on behalf of his
papist wife, ii. 140.
Jougs, James Middleton threatened with the, ii. 160;
illustration, 501.
Jugglers and the steeple-trick, i. 303.

Kate the Witch assails Sir F. Walsingham, i. 152.

Keith, Robert, attempts to take forcible possession of the Abbey of
Deir, i. 209.
Kello, John, minister of Spott, executed for the murder of his wife,
i. 68.
Kelso burnt down in 1645, ii. 163;
again in 1684, 457.
Kenmure, Lord, a partisan of Charles II., ii. 222.
Kennedy, a notary in Galloway, mysterious circumstance regarding,
i. 492.
Kennedy of Bargeny and Earl of Cassillis, dispute between, i. 311,
360-363.
Kennedy, Quentin, disputation with John Knox at Maybole, i. 21.
Kennedy, Sir Thomas, of Colzean, his feud with Mure of
Auchindrain, i. 277, 360-363, 366-368, 435-437.
Ker, James, a barber, his petition, ii. 399.
—— of Kersland, leader of an Edinburgh mob for burning popish
relics, ii. 500.
Kerr, a blacksmith, hanged, i. 385.
—— of Cessford, act of penitence for murder of Scott of
Buccleuch, i. 27.
Kerr, Robert, younger of Cessford, his encounter with Earl of
Bothwell, i. 251.
Kerr, Thomas, killed by Turnbull at Jedburgh, i. 320.
Kilbirnie, Lady, and her husband, die of a pestilential fever, ii. 409.
Kilmarnock completely destroyed by fire in 1668, ii. 321.
Kilpont, Lord, his dispute with Ardvoirlich, ii. 154-156.
Kincaid, John, of Craig House, fined 2500 merks for abduction of
Isobel Hutcheon, i. 223.
Kincaid, John, a pricker of witches, ii. 278, 285.
Kincaid of Warriston, murdered at instigation of his wife, i. 317.
Kindness, a sickness so called, i. 137.
King, clergy cease praying for the, ii. 235.
Kingdom’s Intelligencer, remarkable advertisement in the, ii. 272.
King’s evil, Charles I. touches 100 persons for, ii. 67.
Kinmont Willie, Buccleuch’s gallant relief of, i. 269-271.
Kinnoul, first Earl of, his funeral-procession, ii. 88.
Kintail, Mackenzie (subsequently Lord) of, a royal commission
given to him and retracted, i. 256;
bond of friendship with Earl of Huntly, 316;
his quarrel with Macdonald of Glengarry, 369-372;
his dispute with Macleod of Raasay, 437-439;
obtains possession of island of Lewis, 424.
Kintyre and Islay, Lords, tale of commotion between, i. 164-170.
Kirk, Robert, minister of Aberfoyle, his translations and Essay on
Fairies, &c., ii. 361-363.
Kirkaldy of Grange, his defence of Edinburgh Castle, i. 82;
hanged by Regent Morton, 85-87.
Kirke, Thomas, account of Scotland by, ii. 407.
Kirkpatrick, younger, of Closeburn, Lady Amisfìeld contrives his
escape from prison, i. 427.
Kirkton, Rev. James, his praise of the morals of Scotland in 1650,
ii. 197.