Month: October 2011

A journey to agile basics (part 2)

/ Arborosa / 2 Comments

In part 1 of my journey to agile basics I travelled back to the Agile Manifesto and its twelve principles. In this second part I will make a small tour to each of the seventeen attendees of the original meeting.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
 James Grenning
Jim Highsmith
Andrew Hunt
Ron
Jeffries
Jon Kern
Brian Marick
 Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff
Sutherland
Dave Thomas

How and why they met is briefly explained at the Manifesto itself, so I will not go into that further at this point. A few of the authors have written a recap of events at the manifesto meeting and where ever I have encountered them I have added them here too.

Some of the authors I had heard about at conferences, read work written by them or have seen them mentioned by others. But for quiet a few of them it started of as a journey into the unknown. As I travelled further I found that for some of them their work obviously spoke louder to me then their name. I might not have heard of recalled their name, their products or ideas I did recognize, appreciate and use nonetheless.

My approach to the overview of authors is that I present them in alphabetical order. I tell something about what the are doing  and for what they could / should be known. If possible I will provide links to those particular items providing possibilities for you to dig in deeper yourself.

Although the trip proofed to be taking a bit longer than anticipated I really enjoyed myself and I can only encourage you to have a go at the material yourself and treat this blog as a starting point for your own journey.

The authors

Kent Beck

Kent Beck is a software engineer. He is the founder and director of Three Rivers Institute. He is the creator of Extreme Programming (XP, 1996) and has rediscovered Test Driven Development (TDD).

Kent Beck typically is not known to be a tester. Most of his work is oriented on organizing development processes and teams. His ideas on this have had a visible impact on how agile teams are seen today. He has emphasized embracing change, stressing customer satisfaction, customer participation and the use of feedback. Testing is as such is recognized but limited to what I would call development testing (or checking). In short he sees testing as:

  • All code must have Unit tests
  • All code must pass all Unit tests before it can be released.
  • When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
  • Acceptance tests are run often and the results are published

Mike Beedle

Mike Beedle is Founder and CEO at New Governance and e-Archtitect. He also is, together with Ken Schwaber, the co-author of the first Scrum book, Agile Software Development with Scrum. Scrum has probably become the most popular agile method. Over the years Scrum has gotten many supporting organizations, training facilities and lately even certification has come available.

Arie van Bennekum

Arie van Bennekum joint the conference as a member of the DSDM consortium. Arie van Bennekum started with working on RAD, followed by DSDM and is currently more involved in Atern. He provides a nice introduction to Atern on his website (in Dutch).

Alistair Cockburn

One of the authors I had not heard or read about outside of the manifesto, kind of rang a bell and turned out to be quiet interesting. Alistair Cockburn was an advocate of the use of use cases. Later on Alistair Cockburn joint an initiative similar to the manifesto: “The declaration of interdependence for modern management”. Which declares the following:

“We …

  • increase return on investment by — making continuous flow of value our focus.
  • deliver reliable results by — engaging customers in frequent interactions and shared ownership.
  • expect uncertainty and manage for it through — iterations, anticipation and adaptation.
  • unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  • boost performance through — group accountability for results and shared responsibility for team effectiveness.
  • improve effectiveness and reliability through — situationally specific strategies, processes and practices.”

Finally Alistair Cockburn has described a group of lightweight methodologies in the Crystal family.

Ward Cunningham

Ward Cunningham is known for contributing to OO, Paterns and Extreme Programming (together with Kent Beck and Ron Jeffries). Ward Cunningham is however best known for his invention of WikiWikiWeb, better known and used as Wiki. Testing wise Ward Cunningham is known for his invention of the Framework for Integrated Test, a.k.a. Fit, an automated, open-source, tool for user tests. Fit is often used with a third-party front-end Fitnesse.

Martin Fowler

Martin Fowler focusses on understanding how to design software systems ( Patterns, Refactoring, Domain Specific Languages) and on promoting agile approaches. On his website he has a fairly nice recollection of the meeting in Snowbird in which the Agile Manifesto came to life.

James Grenning

James Grenning is a name I actually did not recall from before writing this post. But he was the first on which the initial (alphabetical) search results turned something about software testing: “Test is not about finding bugs“. James Grenning applies agile development to the embedded world. He is an XP coach, but his biggest contribution to agile is the invention of Planning Poker. Personally I find his blog, after reading several posts very entertaining.

Jim Highsmith

Jim Highsmith is the creator of Adaptive Software Development embodying the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. On contrast to the other authors (so far) Jim Highsmith is more about project management and team work than strictly programming. Together with Martin Fowlers he works at Thoughtworks Inc. and was co-author of the earlier mentioned Declaration of Interdependence.

Andrew Hunt

Andrew Hunt co-authored the The Pragmatic Programmer and together with Dave Thomas founded the Pragmatic Bookshelf providing a series of books on software development amongst were books about the Ruby programming language. In one of his blogs I found the following rules, derived from Improv:

Rule one, agree.  Don’t reject current agile practices, but don’t accept them as written in stone either. What constitutes your current set of agile practices isn’t “done”: it’s not finished, it’s not established as canon, and it never will be. 
Rule two, add your piece.  It’s up to you and the rest of your team to evolve your agile practice, to keep it alive and keep it moving.

Ron Jeffries

Ron Jeffries is together with Kent Beck and Ward Cunningham one of the founders of Extreme Programming. His website is very informative on XP and its core practices. (Do not be fooled by the shortness of this item and visit the XP website!!)

John Kern

There is not a lot of typical information on John Kern. I suppose a good introduction is supplied by his recollection of the Snowbird meeting. In addition his blog provides a nice introduction to Ruby.

Brian Marick

Over time Brian Marick has gradually shifted from software testing to a more on general development oriented approach and is currently focussing on Ruby. He was at the time of the Agile Manifesto one of the (few) software testers present.

Brian Marick has an old and a new blog that are both worth visiting. The old blog did have slightly more focus on testing whereas the new blog is more about agile development with a focus on how testing fits in. The old blog also has a good introduction on agile testing with a series of links to interesting blog posts. Most noteworthy, to me, is the test matrix that Brian Marick developed that later on also was successfully used by Lisa Crispin and Janet Gregory in their book Agile Testing.

Robert C. Martin

Robert C. Martin also known as Uncle Bob Martin is a software consultant and author. Robert C. Martin is well-known for his books on agile software development, e.g. Clean Coder, and as a leading member of the software craftmanship approach that produced the following manifesto as an extension to the Agile Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional
software development by practicing it and helping others learn the
craft.  Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

A nice anecdote the at a keynote for the Agile 2008 conference Robert C. Martin added a fifth value to the Agile Manifesto; “Craftsmanship over Crap” which he later changed to “Craftsmanship over Execution”.

Steve Mellor

Stephen J. Mellor is known for his books on Essential Modeling Techniques and Executable and Translatable UML that was derived from Schlaer-Mellor method.

Ken Schwaber

Together with Jeff Sutherland Ken Schwaber formulated the initial versions of the Scrum development process and are authors of the definitive Scrum Guide, of which recently an update version became available. He is a founder of the Agile Alliance, and he is responsible for founding the Scrum Alliance and creating the Certified Scrum Master programs and its derivatives. Follow Ken on his blog to see what his opinions on the development of Scrum are.

Jeff Sutherland

As mentioned previously Jeff Sutherland works closely with Ken Schwaber. Ken and Jeff formalised the Scrum development process at OOPSLA’95 in the Scrum Paper of which an updated, 224 pages, version is available. Additionally this article is available on his blog and explains where the idea came from. Jeff is very active in providing training and you have ample change to meet him in this capacity.

Dave Thomas

As mentioned before Dave Thomas co-founded the pragmatic bookshelf and wrote the “The Pragmatic Programmer” together with Andrew Hunt. They also went on to write about the Ruby programming language in the book Programming Ruby and Agile Web Development with Rails, a book on Ruby on Rails which also touches on Ajax and the Ruby programming language. Dave has also coined the phrase ‘Code Kata‘.

This concludes my visit to the authors of the Agile Manifesto. In part three of the blog I will visit some of the other authors / persons that I have found noteworthy since I have gotten interested in agile.

A return to agile basics (part 1)

/ Arborosa / 1 Comment

This post is, as the title suggests, about agile. More specifically it’s about a journey I made to rediscover what agile actually means to me. My need for rediscovery started while I was co-presenting a four-hour tutorial on Agile Testing at the TestNet autumn event recently. As one of my co-presenters was opening with an explanation of agile I felt the following smoldering unease creeping up inside of me.

“We’re talking about agile sure enough, but why is it I mostly hear Scrum, Lean and Kanban content passing by. How agile is that? And if it is not how bad is that?”

This post will therefore take you along the route I took to rediscover agile. It will contain some information on agile, and is a sort of personal recap. It is not intended as a complete and detailed overview of the agile approach and all of its derived methods and practices. Where ever I mention them however I will try to add a link to guide you to more information or interesting blogs. So feel free to use it, if nothing else, as your (re) introduction to agile if you like.

My original journey to agile started in 2007 and I will start once more at what was then my starting point. One of my colleagues came back from EuroSTAR 2007 and was enthusiastically talking about this new thing: Agile! I had heard about it before but had never really dug into it before. So like then I will go to where agile had taken off: the declaration of the Agile Manifesto in 2001. Seventeen people came together in a ski lodge and drew up a manifesto with the four following lines and guideline:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This probably still is the best known part of agile there is. No self-respecting course will bypass these lines and not show them and declare them the essence of agile. Personally I think the manifesto, once read, makes sense to almost everybody who has been in IT for more than a couple of years. Their strength lies in stating something people sense but not always come to formulate themselves.

A lot of courses on agile do not go beyond this and do not also show the additional: “Principles behind the Agile Manifesto”. They jump straight to one of the methods and often enough without mentioning the principles at all. In my opinion this does not do justice to the manifesto as a whole. Therefore let’s have a look at these twelve principles. The seventeen authors of the manifest, who are also hardly ever mentioned, are part of the second part of this small series of post on agile. The third part will be on other prominent authors, like Lisa Crispin, and popular methodologies.

The Principles

    • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The three elements of this principle, customer satisfaction, early continuous delivery and valuable software seem key to agile. But other software development approaches are known to strive for these elements also. So the difference will have to be in the way agile goes about achieving these elements. Lets travel further.
    • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

As many of us have probably experienced, changes in requirements during development and even late in development is not new to software development. To accept and embrace these changes is certainly less common. This is one of the items that differentiates agile from other approaches. Other (more traditional) approaches either deny the existence of such possibilities, are unable to cope with them or try their utmost to abolish them.

  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

All software projects aim to deliver working software. The difference here is that agile projects aim to deliver more than once and to do so within a (far) shorter time span.

  • Business people and developers must work together daily throughout the project.

Two elements in this principle provide direction into how business people and developers should work together. Those are to do it daily and to do it throughout the project. This combination I believe is typical to good software development in any approach. A lot of the other approaches have formalized so much however that to do so amounts in a breach of process, plan or protocol.

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

In management theories this concept has been around for decades. For some reason however the application of these theories seems not so common place in the software development world. In this respect this principle sets the right mindset in creating self steering, responsible and trusted teams.

  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is a radical break to what is, or I rather would hope, was considered standard in software development. Still a lot of developers, testers and even more so managers and stakeholders consider it impossible to do without upfront and approved documentation. “How else would you know what to do.” Reality is that documentation hardly ever completely describes what the customer wants. Let alone that it completely describes how to build it. I can personally not think of a faster way to retrieve or confirm information then by asking the informant directly. And if anything needs to be recorded you can do that while talking together, in the code or on paper later.

  • Working software is the primary measure of progress.

There is beauty in this principles simplicity. As a tester however I think it’s a bit to simple. What does that mean “working software”? Does the code run, does it pass all checks or is it tested also and do the customers find the value in product that they were looking for. The intent of this principle is good, but it needs enhancement on the concept of what working means in your context and to whom.

  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I can only adhere to and promote this. I do realize however that it often is not on the mind of project managers. PM’s regularly still steer their projects on cost, time and scope using unfounded estimates that still have to be kept even when pushes personnel to their limits and over.

  • Continuous attention to technical excellence and good design enhances agility.

I suppose this applies as an enhancement to all software development and therefore also to agile. If it actually enhances agility I am not so sure. The need for short sprints, iterations, cycles, or what you call them seems to work counterproductive here. (At least for the developers and architects I know.)

  • Simplicity–the art of maximizing the amount of work not done–is essential.

In order to deliver the right content swiftly you should refrain from adding self thought up features or so-called enhancements. Unless the stakeholders or users are informed before and see them as adding additional value. Otherwise these items are likely to go in unnoticed, undocumented and untested. With all the risks that come with that. As to minimizing the work on agreed upon requirements I applaud the intent, but I think most developers start of to do their best and refactor when they see possibilities. In that sense it is wisely mentioned but if it really brings benefits in practice I have doubts about. (But I will get to this when I go into Lean later.)

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

I totally agree with the idea behind this principle. Self-organizing teams are a good breeding ground for this. It should however not limit them to seek and accept expert input if this brings even better results.

  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The best way to handle your faults, or any experience, is to reflect and learn. This applies to teams as much as to individuals.

This concludes the first part in which I have travelled along the Manifesto and its twelve principles. I will continue (next week) with some info about the authors. Which is actually new to me as well, so that will be a journey into largely undiscovered country.