tagged by: agile
The Manifesto for Agile Software Development
A group of seventeen people got together in Snowbird, UT in February 2001 to talk about new styles of lightweight methods. One result of this is coining the word agile to represent a new breed of agile processes for software development. We also put together a Manifesto for Agile Software Development which describes the values and principles of these agile methods. Jim Highsmith and I wrote this article for Software Development magazine to further explain the manifesto.
February 2001
Is Design Dead?
For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design. Not just is much design activity ridiculed as "Big Up Front Design", but such design techniques as the UML, flexible frameworks, and even patterns are de-emphasized or downright ignored. In fact XP involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style.
May 2004
article
Evolutionary Database Design
by Pramod Sadalage and Martin Fowler
Over the last few years we've developed a number of techniques that allow a database design to evolve as an application develops. This is a very important capability for agile methodologies. The techniques rely on applying continuous integration and automated refactoring to database development, together with a close collaboration between DBAs and application developers. The techniques work in both pre-production and released systems.
January 2003
article
Agile Brazil Interview
Paulo Caroli and Martin Fowler
Interview with Paulo Caroli and me at Agile Brazil
June 2010
video
It's Not Just Standing Up: Patterns for Daily Standup Meetings
by Jason Yip
Daily stand-up meetings have become a common ritual of many teams, especially in Agile software development. However, there are many subtle details that distinguish effective stand-ups and a waste of time.
29 August 2011
article
The Yawning Crevasse of Doom
Dan North and Martin Fowler
A keynote for QCon 2007 that I did with my colleague Dan North. We both see the gap between developers and their customers/users as the biggest problem in software development. (We'd call it a chasm, but that word is so overused.) Here we talk about this gap, why it's important, and what we need to do to cross it. In particular we argue that the traditional role of an intermediary Business Analyst acts as a ferry, while what we really need is a bridge that enables directly contact between developers and their customers (and analysts can build and maintain that bridge). This is one of my favorite joint keynotes, both because I think the topic is so important, and because Dan is such stimulating co-speaker.
March 2007
video
Using an Agile Software Process with Offshore Development
For the last four years ThoughtWorks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we've discovered that we can make it work, although the benefits are still open to debate. (Although this article was last updated in 2006, I our visited our offshore work in 2011 and found the lessons to still be relevant and thus the article did not need a further significant revision.)
18 July 2006
article
Agile2010
Last week I attended the Agile 2010 conference in Orlando. Agile 20xx is the major US agile-oriented conference whose roots go back to XP Universe and the Agile Development Conference. I've not been a regular attender of the main agile conferences, but I did go last year as well. Rather than make an attempt at a consolidated description, here are a few scattered impressions.
16 August 2010
bliki
AgileCertification
Should there be a certification program for agile methods?
30 April 2004
bliki
AgileImposition
According to the current board of the Agile Alliance, agile methods have "crossed the chasm" , which I think means they are becoming more widespread. While this has its advantages, it also brings problems. As a methodology or design approach becomes fashionable, then we see a lot people using it, or teaching it, who are focusing on the fashion rather than the real details. This can lead to reports of things done in agile's name which are a polar opposite to the principles of movement's founders.
2 October 2006
bliki
AgileVersusLean
I'm thinking of using agile software development - but should I use Lean software development instead?
26 June 2008
bliki
CodeAsDocumentation
One of the common elements of agile methods is that they raise programming to a central role in software development - one much greater than the software engineering community usually does. Part of this is classifying the code as a major, if not the primary documentation of a software system.
22 March 2005
bliki
CraftmanshipAndTheCrevasse
Dan North's recent blog post on software craftsmanship has unleashed a lot of blog discussions (which I summarize below, if you're interested). There's a lot in there, but one of his themes particularly resonated with me, hence this post.
19 January 2011
bliki
EarlyPain
A few years ago I was talking with a client who told me something he didn't like about the agile approach we were using: "it's doesn't feel right to have these difficulties this early in the project". Contrary to his reaction, in my mind this early pain is one of the great benefits of an agile or indeed any iterative development process.
4 November 2008
bliki
FixedPrice
Many people belive that you can't do a fixed price contract in an agile project. Since the whole point of an agile process is that you cannot predict the future, this isn't an unreasonable supposition. However this doesn't mean you can't come up with a fixed price agile contract, what it really means is that you can't come up with a fixed scope contract.
29 July 2003
bliki
FlaccidScrum
There's a mess I've heard about with quite a few projects recently. It works out like this:
- They want to use an agile process, and pick Scrum
- They adopt the Scrum practices, and maybe even the principles
- After a while progress is slow because the code base is a mess
29 January 2009
bliki
IsAgileForAll
Can average developers use agile methods?
4 April 2004
bliki
PairProgrammingMisconceptions
A bunch of common misconceptions about pair-programming.
31 October 2006
bliki
PleasingTheCustomer
All agile methods stress the importance of direct interaction between the developers of a system and customers who are its eventual beneficiaries. The agile manifesto said "Business people and developers must work together daily throughout the project", which is there to stress the high frequency of interaction. Extreme Programming stresses this through its practice of OnsiteCustomer.
15 August 2003
bliki
SchoolsOfSoftwareDevelopment
For nth, and I'm sure not last time, I'm sliding into a conversation about defining practices, labeling some of them as "best", and probably the C-word (certification). It's a familiar discussion, and although we've barely started it, I can predict much of where it will go. It's driven by a perfectly reasonable desire to identify who are the better software developers, and how existing developers can improve their abilities.
12 April 2008
bliki
TeamRoom
A common thing you find in agile projects is that the development team sits in a single open team room. It was advocated early on in Extreme Programming and called out as one of primary practices in the second edition. Agilists favor a open team room as it promotes lots of informal and deep communication between people on the team.
14 June 2010
bliki
The New Methodology
In the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landscape. In this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation.
13 December 2005
article
Pourquoi, pas comment
Neal Ford and Martin Fowler
Neal Ford and I gave a talk at USI in Paris (2010) on some aspects of why agile works (as opposed to how). This probes at some of the core forces that makes agile effective, rather than looking at techniques. In particular we look at role of communication and feedback and how they interplay in agile environments.
June 2010
video
Keeping Software Soft
Why we need methods that assume software should be soft and open to change.
December 1998
Continuous Integration
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
1 May 2006
article
Agile at 10
SD Times interview on 10 years since the agile manifesto
3 May 2011
Writing The Agile Manifesto
In February 2001 a group of seventeen software pundits got together in Snowbird UT to discuss the growing field of what used to be called lightweight methods. We decide to use the term agile to describe this new breed of agile methods. We also wrote the Manifesto for Agile Software Development , setting out the values and principles of these agile processes. I was one of these self-elected visionaries and have since come across many questions about this group's origins and the subsequent founding of the agile alliance. This is my recollection of those events.
9 July 2006
article
Interviewed by Jim Highsmith
When I went to Snowbird in 2001 for the meeting that led to the Manifesto, Jim interviewed me for a book he was working on. It provides a snapshot on my thinking on extreme programming and this thing that a few days later we called agile software development.
February 2001
AgileAustralia2010
Scattered impressions from my recent trip to Australia for the Agile Australia conference.
27 September 2010
bliki
AgileHandover
One of the most common questions I see about agile projects is how they deal with handover to another team. If you have a development team that leaves and hands over support to a support team, how do they cope when agile projects tend to produce much less documentation than plan-driven processes?
28 May 2004
bliki
AgileManifestoMeeting
The meeting at Snowbird Utah in 2001 that decided to use the word 'Agile' and began the 'Manifesto for Agile Software Development'.
bliki
C3
C3 was the short name of the Chrysler Comprehensive Compensation project, a payroll project at Chrysler which has since become famous as the 'birth project' of Extreme Programming.
bliki
ConversationalStories
Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.
4 February 2010
bliki
CustomerAffinity
When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I'll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.
28 July 2006
bliki
FeatureDevotion
A common, perhaps dominant, practice of agile methods is to develop a list of features (often called stories) for the software that's being built. These features are tracked with index cards, work queues, burndown charts, backlogs, or whatever your tool of choice is.
2 November 2006
bliki
FixedScopeMirage
Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don't get satisfactory software, then it won't cost them.
30 September 2004
bliki
FrequencyReducesDifficulty
One of my favorite soundbites is: if it hurts, do it more often. It has the happy property of seeming nonsensical on the surface, but yielding some valuable meaning when you dig deeper
28 July 2011
bliki
LargeAgileProjects
A common question is whether large projects can be done with agile techniques. After all many agile approaches are designed for smaller projects and the heavyweight ideas that they resist are more needed on bigger projects.
10 May 2003
bliki
PeopleOriented
One of the most difficult things for many people to understand about agile methods is the people orientation of agile. Those who are interested in agile processes all agree that process is a second-order effect on project success. The first value of the agile manifesto is that Individuals and Interactions are more valuable than Process and Tools.
12 January 2004
bliki
RigorousAgile
I often run into a complaint that agile methods don't have a rigorous definition. The complainer may talk about how this means that you can't tell if a particular team is using an agile method or not. They may also say that this makes it hard to teach people how to do agile methods - what's the curriculum?
29 May 2005
bliki
SpreadingIncrementalism
From time to time people question whether a particular specialty can be used incremental way: "You can't do (security | user interface design | databases | internationalization | * ) with an agile project because this aspect has to be done up front."
5 January 2005
bliki