1.Kent Beck 2.  Mike Beedle 3.  Arie van Bennekum 4.  Alistair Cockburn 5.  Ward Cunningham 6.  Mar(n Fowler 7.  James Grenning 8.  Jim Highsmith 9.  Andrew Hunt 10.  Ron Jeffries 11.  Jon Kern 12.  Brian Marick 13.  Robert C. Mar(n 14.  Steve Mellor 15.  Ken Schwaber 16.  Jeff Sutherland 17.  Dave Thomas

1. Presenta(on Topic
Agile signatory: Alistair Cockburn
(pronounced Co-burn)
Presenter: Abdul Rahim Khurram

2. Presenta(on Outline
• Agile and Agile Overview
• About Alistair Cockburn
• Alistair Cockburn‘s Career
• List of Books wriGen by Alistair Cockburn
• Selected publica(ons
• Achievements
• Why he is in Agile Manifesto Signatories
• What is the “Crystal methodology”?
• How I saved Agile and the Rest of the World

5. The full list of authors and signatories, in alphabe(cal
order by last name, is this:
1. Kent Beck
2. Mike Beedle
3. Arie van Bennekum
4. Alistair Cockburn
5. Ward Cunningham
6. Mar(n Fowler
7. James Grenning
8. Jim Highsmith
9. Andrew Hunt
10. Ron Jeffries
11. Jon Kern
12. Brian Marick
13. Robert C. Mar(n
14. Steve Mellor
15. Ken Schwaber
16. Jeff Sutherland
17. Dave Thomas

7. Alistair Cockburn
(pronounced Co-burn, the Sco8sh way)

9. Alistair Cockburn
Name : Alistair Cockburn (pronounced Co-burn, the Scobsh way)
Born: 19 November 1953
Educa(ons: Cockburn obtained his degree in computer science at the Case Western Reserve
University. In 2003 he received his PhD degree from the University of Oslo.
Contribu(on in Agile :
• Crystal family
• helping write the Agile Development Manifesto
Others
• describing Soeware development as a Coopera(ve Game
• crea(ng the oath of non-allegiance
• defining Use Cases
• for developing the ini(al response technique relaxa(on / massage form.

10. • Alistair Cockburn (pronounced Co-burn, the Scobsh way) is an American computer
scien(st, known as one of the ini(ators of the agile movement in soeware
development.
• Dr. Cockburn (pronounced Co-burn, the Scobsh way) is an interna(onally
renowned project witchdoctor and IT strategist.
• Alistair Cockburn, founder of Humans and Technology, is known for his extensive
interviews of project teams. These interviews, together with his ac(ve
par(cipa(on on live projects, form the basis for his methodology designs: light but
sufficient, and self-evolving.
• Alistair's work in the 1990s grew into the Crystal family of agile methodologies.
• Alistair and Jim Highsmith are now working together to evolve Crystal and the
Adap(ve ideas into recommenda(ons for crea(ng agile soeware development
ecosystems, the mee(ng of generic methodology with a project team's specific
situa(on.
• Alistair and Jim are co-sponsoring the Agile Soeware Development book series to
publish techniques for personal growth and examples of agile methodologies that
have been used successfully.

11. Career
• Cockburn started his career in the field of
communica(on technology and OO -Soeware
development at IBM operates from 1984 to
1991.
• He then moved into an advisory role at IBM, in
par(cular the methods of OO soeware
development. From 1994, "Humans and
Technology" in Salt Lake City.

12. other than agile
he likes to travel, dance, dive, or sit underwater.

13. Books wriGen by Alistair Cockburn
1. Wri(ng Effec(ve Use Cases 1st Edi(on
2. Agile Soeware Development: The Coopera(ve
Game (2nd Edi(on) 2nd Edi(on
3. Agile Soeware Development
4. Surviving Object-Oriented Projects 1st Edi(on
5. Crystal Clear: A Human-Powered Methodology
for Small Teams: A Human-Powered
Methodology for Small Teams 1st Edi(on

14. Selected publica=ons
1. Surviving Object-Oriented Projects, Alistair Cockburn, 1st edi(on, December,
1997, Addison-Wesley Professional, ISBN 0-201-49834-0.
2. Wri(ng Effec(ve Use Cases, Alistair Cockburn, 1st edi(on, January, 2000,
Addison-Wesley Professional, ISBN 0-201-70225-8.
3. Agile Soeware Development, Alistair Cockburn, 1st edi(on, December 2001,
Addison-Wesley Professional, ISBN 0-201-69969-9.
4. PaGerns for Effec(ve Use Cases, Steve Adolph, Paul Bramble, with Alistair
Cockburn, Andy Pols contributors, August 2002, Addison-Wesley Professional,
ISBN 0-201-72184-8.
5. People and Methodologies in Soeware Development, Alistair Cockburn,
February 2003, D.Ph. disserta(on, University of Oslo Press[1]
6. Crystal Clear : A Human-Powered Methodology for Small Teams, Alistair
Cockburn, October 2004, Addison-Wesley Professional, ISBN 0-201-69947-8.
7. Agile Soeware Development: The Coopera(ve Game, Alistair Cockburn, 2nd
edi(on, October 2006, Addison-Wesley Professional, ISBN 0-321-48275-1, ISBN
978-0-321-48275-4 .

15. Achievements
• Dr. Alistair Cockburn (pronounced Cō-burn)
was voted one of the “All-Time Top 150 i-
Technology Heroes” for his work in crea(ng
and steering Agile soeware development.
• Three of his books have won Jolt awards and
been listed in “The Top 100 Best Soeware
Books of All Time”. He consistently receives
high ra(ngs for his presenta(ons and courses.

16. What is Jolt Awards???
• Dr. Dobb's recognizes the best books of the last 12 months via the Jolt Awards —
our cycle of product awards given out every two months in each of six categories.
No category gets more entrants than books, and this year was no excep(on with
more than 30 nominees submiGed by publishers, vendors, readers, and the Jolt
judges themselves. The award covers all books published during the twelve
months ending June 30th of this year.
• The Jolt judges did an ini(al triage that reduced the field to a readable number of
entrants. Then, there followed a second pass in which the top books were selected
and ranked — aeer long delibera(on and considerable discussion. As always, the
best book of the year receives the Jolt Award; the two runners up each receive a
Jolt Produc(vity award; and the remaining three books are awarded Jolt Finalist
status. Reviews of these six volumes are included in this ar(cle.
• The judges for this category were Andrew Binstock, Jonathan Harley, Gastón Hillar,
David Mulcihy, Larry O'Brien, Gary Pollice, Roland Racko, Mike Riley, and Gigi
Sayfan. Given the many nominees and the large number of judges, you can have
high confidence that the award winners represent the very best of the books
published in the 12-month award period.

17. Why he is in Agile Manifesto
Signatories
• Cockburn helped write the Manifesto for Agile Soeware Development in 2001, the
agile PM Declara(on of Interdependence in 2005, and co-founded the
Interna(onal Consor(um for Agile in 2009 (with Ahmed Sidky and Ash Rofail). He is
a principal expositor of the use case for documen(ng business processes and
behavioral requirements for soeware, and inventor of the Cockburn Scale for
categorizing soeware projects.
• He co-authored the Manifesto for Agile Soeware Development and the
“Declara(on of Interdependence,” created the first Agile Soeware Development
Conference, co-founded the Agile Project Leadership Network, served on the
board of the Agile Alliance, designed the Crystal family of agile methodologies, and
co-founded the Interna(onal Consor(um for Agile.
• The methodologies in the Crystal family (e.g., Crystal Clear), described by Alistair
Cockburn, are considered examples of lightweight methodology. The Crystal family
is colour-coded to signify the "weight" of methodology needed. Thus, a large
project which has consequences that involve risk to human life would use the
Crystal Sapphire or Crystal Diamond methods. A small project might use Crystal
Clear, Crystal Yellow or Crystal Orange.

18. What is the “Crystal methodology”?
• Introduced by Alistair Cockburn, Crystal Methods, which is a
collec(on of Agile soeware development approaches, focuses
primarily on people and the interac(on among them while they
work on a soeware development project. There is also a focus on
business-cri(cality and business-priority of the system under
development. Unlike tradi(onal development methods, Crystal
doesn’t fix the tools and techniques of development, but keeps
people and processes at the core of the development process.
However, it is not only the people or the processes that are
important, rather the interac(on between the two that is most
important.
• In Cockburn’s words, “Crystal is a family of human-powered,
adap(ve, ultra light, ‘stretch-to-fit’ soeware development
methodologies.”

19. what does “human-powered, adap(ve, ultra light,
‘stretch-to-fit’” mean?
• Crystal is “human-powered”—This means that people are the most important aspect of
Crystal, and all the processes and tools are rela(ve to them. Crystal believes that soeware
development is essen(ally a human ac(vity, so people involved in this ac(vity are vital while
the processes should be modelled to meet the requirements of the team, not the other way
around. Crystal emphasizes that development teams are self-sufficient and self-organizing,
so they are capable of streamlining the processes as the development process progresses
and become more organized and competent.
• Crystal is “adap(ve”—First of all, it should be remembered that Crystal is not a set of
prescribed tools and techniques for soeware development; rather, it is an approach. So, the
processes and tools are not fixed, but have to be adjusted to the requirements and
characteris(cs of the project. In other words, Crystal is a “stretch-to-fit” methodology,
because each project is unique and require methods that suit the business requirements and
that sa(sfy the technical requirements of the project.
• Crystal is “ultra light”—Crystal is known as a “lightweight methodology.” This is because
Crystal doesn’t advocate too much documenta(on, overhead management and repor(ng.
Instead, it believes in keeping things light and focusing on developing business-valued and
func(onal soeware. For this, teams following the Crystal approach work toward enhancing
free and open communica(on among team members as well as establishing transparent
flow of informa(on between developers and stakeholders.

20. How does Crystal operate?
• As stated above, Crystal is not a set of prescribed development tools and methods,
but a family of various development approaches. At the beginning of the project,
the processes and tools are not fixed but are decided by considering the business
requirements and technical needs of the project. When deciding whether Crystal is
the right methodology for a project, consider comfort, discre(onary money,
essen(al money and life along with the size of the team working on a par(cular
project. Various methodologies in the Crystal family are known as the various
“weights” of the Crystal approach and are represented by different colors of the
spectrum.
• Therefore, the Crystal family of methodologies consists of the following variants:
Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red,
Crystal Maroon, Crystal Diamond and Crystal Sapphire
• To clarify, Crystal Clear is more appropriate for compara(vely short-term projects
being managed by a team of six developers working out of a single workspace,
whereas Crystal Orange is suited for projects that require a team of 10 to 40
members and have a lifespan of 1-2 years. On the other hand, Crystal Sapphire or
Crystal Diamond methods are used in large projects that involve poten(al risk to
human life. Therefore, the weight of the Crystal methodology is determined by the
project environment and the team size.

21. What are the main prac(ces
recommended by Crystal?
• Crystal is precise about certain prac(ces because these are crucial for the
successful implementa(on of the Crystal approach onto any project. These
prac(ces include:
• An itera(ve and incremental development approach—The project is developed in
itera(ons that are generally (me boxed. The feature delivered at the end of an
itera(on is integrated into the overall system. User feedback taken at the end of
an itera(on is used to plan the next itera(on; and, new and addi(onal features are
added in every subsequent itera(on. All this results in refinement and comple(on
of the overall soeware.
• Ac(ve user involvement—This is a must because Crystal is a people-centric
approach and emphasizes transparency. So, users are not only ac(vely involved
but also regularly informed about the progress of the project.
• Delivering on commitments—The team endeavors to ensure frequent delivery of
client-valued, poten(ally-shippable func(onali(es. It is to this end that Crystal
follows an itera(ve and an incremental development approach.

22. What are the roles prescribed by
Crystal?
• The Crystal approach defines a number of roles:
Project Sponsor, Senior Designer/Programmer,
Designer/Programmers (Business Class Designers,
Programmers, Soeware Documenters and Unit
Testers) and Users. Also, there are a number of
other roles such as Architect, Coordinator,
Requirements Gatherer, Business Expert,
Business Analyst/Designer, Project Manager,
Design Mentor, Usage Expert, Lead Design
Programmer, UI designer, Technical Facilitator
and Technical Writer.

23. • Crystal is non-jealous, meaning that a Crystal methodology permits
subs(tu(on of similar elements from other methodologies.
• Methodologies are big things, and Crystal is a family of them.
Although there is a growing book collec(on about the Crystal
methodology family, not everything of value can be collected into
that book collec(on (some people had the audacity of publishing
good books before Crystal was conceived!) Further, Crystal is non-
jealous, meaning that you might wish to subs(tute something in
that wasn’t given a prime spot in the family.
• Crystal is evolving in tandem with our understanding of the
principles of lightweight soeware development processes and
people-centric project management. It aligns with the manifesto
for soeware development.

24. How I saved Agile and the Rest of the
World
• This is not about me saving anything. It is to remind you that
the Agile Manifesto was wriJen by 17 people, all very experienced
and with very different backgrounds. Before you claim to
understand the heritage of the agile soeware development, you
need to interview all 17 of those people who wrote it. Hopefully
someone will do that before we start dying off.
• In par(cular, pay aGen(on to the authors of Pragma>c
Programming, Dave Thomas and Andy Hunt. They are
underrepresented in the history of agile, because they just kept
doing their agile thing, crea(ng Pragma(c Bookshelf, which brought
agile working style and con(nuous integra(on to publishing. They
are on record as being preGy sad with what the industry did with
the agile manifesto, so they went silent. But that doesn’t have
anything to do with how much they contributed to the mee(ng

25. • Ask Brian Marick where he was taking his thoughts from at the
(me. A deep thinker, he has contributed many original thoughts on
the subject. He is on record as preferring the term "Ar(sanal retro-
futurism ⊗ team-scale anarcho-syndicalism", partly because it is
more accurate, as he explains, but also so that not everyone will go
around saying they are that.
• The European DSDM community, largely out of England and
Holland and represented by Arie van Bennekum, were perhaps the
best organized of all of us, alongside XP. They had already wriGen,
in 1995, nine principles that we could have taken whole cloth as the
en(re agile manifesto. If you haven’t seen those principles, you
should study them. However, Arie represented his own background
and thinking, not just the DSDM doctrine of the (me.
• Jon Kern came on behalf of the FDD community, originally coming
out of Australia, represen(ng his own experiences and personal
views as well.

26. Alistair Cockburn ‘s Contribu(on
in Agile
• Jim Highsmith had goGen to his “Adap(ve Soeware Development” by studying
teams at Nike around 1994. His was his own original line of inves(ga(on, which
someone should capture. Jim won the pres(gious Wayne Stevens award in 2005
for his work on agile methodologies, and his book “Agile Soeware Development
Ecosystems” contains insigh{ul interviews and characteriza(ons of some of the
manifesto authors, well worth reading now, just as it was when it came out.
• Side note: Jim Highsmith and I represented the view that there is
no one methodology, every project needs its own personal methodology. We
were represen=ng the plurality of methodologies. What we wanted was that
EVERY methodology produced had these characteris=cs.
• And as an odd twist of history, Wayne Stevens was my technical boss at IBM
1991-93 and it was he, along with Dick Antalek, who taught me what I know
about methodologies and successful soNware development. He died late in 1993,
and had a methodology award created in his memory. My Crystal methodologies
are actually a con=nua=on of the program he was pushing at the IBM Consul=ng
Group at the =me. I oNen wonder what he’d think of what I’ve produced.

27. • Kent Beck’s Extreme Programming was the dominant agile methodology in the
world at the (me. A number of people at the mee(ng were then using XP as their
current way of working. But don’t overlook their past. Ward Cunningham, Ron
Jeffries and Bob Mar=n each had a deep past outside of and inside of XP. Mar=n
Fowler is an avowed “I don’t belong to any group that will accept me” person, who
had been studying XP and other ways of working for a long (me. James
Grenning was and is a real-(me-systems expert.
• Scrum was represented by three people, Ken Schwaber, Jeff Sutherland and Mike
Beedle. Odd though it seems now, Scrum was preGy much unknown at the (me. it
was only with the advent of Ken Schwaber’s 2-day Cer(fied Scrummaster
Cer(ficate several years later that Scrum rose in ascendancy, un(l now there are
hundreds of thousands of people passing along the Scrum view of the world. The
fact that Scrum is dominant in the industry 15 years aeer the wri(ng of the
manifesto is unrelated to its prac((oners’ contribu(on in the mee(ng, just as XP’s
popularity at the (me had liGle to do with the name chosen and the words we
wrote then.

28. • Steve Mellor originally was there just to see what was going on (“I’m a
spy”, he famously said as he introduced himself). But his deep background
and insight had a big effect on our discussions, and he ended up co-
construc(ng and agreeing with the words we produced just as much
anyone.
• My own work was mo(vated by my boss at the IBM Consul(ng Group
1991, Kathy Ulisse. I was a newbie methodologist. She said I should
debrief some teams to learn what does and doesn’t work. That sent me
down the path of grounded research and my eventual doctorate in 2003.
From those interviews I created in 1992 the first IBM methodology for
Smalltalk and C++ projects (which contained, for those interested, only
incremental development, use cases, CRC cards, and version control as its
elements). We got to use that on a large fixed-price project in 1994, which
became the seed for Crystal Orange. As many know from my wri(ngs, I
interviewed dozens of teams over several years, and worked to construct
a theory to cover those findings. That produced the Crystal approach.

29. • Side note about selec>ng the name ‘aglie’: I facilitated the name-finding session, so I have a fairly detailed recall of
how that went: “Agile”, for example, was not a sure winner for a name at any >me, “Adap>ve” >ed it at the final
round. We filled pages with brainstormed names. We selected a handful and said why we did not like them, odd
though that procedure sounds. The dominant meme in that discussion was “I don’t want to have to wear pink
>ghts and a tutu when I say it”! We voted down to five, then voted for a winner but found a >e between agile and
adap>ve, then selected “agile”.
• Bob Mar(n floated the idea for manifesto wri(ng and provided the ini(al invitee list (many of whom couldn’t
make it). I was local organizer. Jim Highsmith got the CuGer Consor(um to sponsor part of the costs of the
mee(ng. Once those three items were taken care of, it was a free-for-all, that is to say, there was no given
purpose or agenda. Self-organiza(on at it’s finest, held together by deep respect and generous listening on all
sides. What emerged was what these exact 17 people could produce together at that par(cular moment in
history. We agreed at the end never to update the manifesto for that exact reason. (So don’t ask us to)
• What I hope you see is that the Agile Manifesto was the product of 17 people from different schools and
backgrounds. No one person is responsible for the words we came up with – it is clear that it was the product of all
17 people. The addi(on or removal of any 1 person would have changed the outcome, something we recognized
and discussed at the end of that mee(ng.
• Whether you think “agile” saved the world or poisoned it, be sure always to recognize that it grew from a rich
compost (joke inten(onal) of backgrounds. The next (me you read a would-be history of the agile movement, look
for all those names. If you don’t see them, it is not a history, it is one person’s personal recoun(ng of their own
journey, years aeer the event (as indeed, this one is). As you go forward discussing the origin and heritage of the
agile movement, please be sure to credit the diverse thinkers who put so much into that wri(ng.

30. • Name : Alistair Cockburn (pronounced Co-
burn, the Scobsh way)
• TwiGer & Facebook: @TotherAlistair
• Website : hGp://alistair.cockburn.us/

31. Thank you