Eventyr

Go Go Ninja Dinosaurs

Because today the monkeys have broken out the zoo.

Thanks Judith.  I've now bought my own copy of Colours are Brighter.

("Colours are Brighter is a thirteen track compilation of children's songs recorded by the likes of Belle and Sebastian, Snow Patrol, Franz Ferdinand, Four Tet, Kathryn Williams and The Divine Comedy. It will be released on Rough Trade Records on 16th October 2006 and all the proceeds go to Save The Children.")

Dangers when adopting agile

1. Unfamiliarity
2. Top-down thinking
3. Culture change
4. Incomplete implementation
5. Silver bullet syndrome

5 dangers when adopting agile processes - and what to do about them

Going Agile - APM

Taking an Agile approach to software development for the first time is no small task:  there are a number of different practices to onboard and process change is disruptive, frustrating and potentially demoralizing. How do you onboard Agile practices and still meet delivery requirements? To what extent can these be introduced, especially the first time around, so that they stick?

There are two things to balance when introducing new practices: adopt at a pace that doesn't push too far too fast and simultaneously establish a "critical mass" of core practices to reap symbiotic benefits. While there are no hard-and-fast rules on how or where to begin, the right sequence can increase probability of success and set the stage for greater process adoption.

So You've Decided To "Go Agile" - A Pragmatic Approach To Onboarding Agile Project Management

Potentially the main document I need to think about, and digest, this week I think.

Myths about Game Design

Historical Roots: Software development as an engineering discipline
Myth: “Upfront design reduces risk”
Myth “The cost of change increases exponentially as time goes on”
Myth: “A specialized workforce organized into functional silos is the key to productivity”
Myth: “There is one game designer who holds the vision for the project”

Danc at Lostgarden presents Persistent Myths about Game Design, and discusses problems and alternatives.

Scrum - Oh Yes

A very tongue-in-cheek video (10mb wmv) from High Moon Studios about how they use Scrum in their company.

I laughed.

Mongo Bad.

What is Agile?

Agile is an iterative and incremental (evolutionary) approach to software development
which is performed in a highly collaborative manner
with "just enough" ceremony
that produces high quality software
which meets the changing needs of its stakeholders.
Scott W. Ambler

“a set of techniques and procedures with minimal overhead that allow us to make sound, just-in-time decisions.”
Noel Llopis (with a set of very interesting visualisations)

and, of course:

agile vs. Agile

Software Testers

• The love for bugs
• Detectives of the IT world
• We break things because we can
• Testers maintain focus
• Always learning

Characteristics of software testers by Rosie Sherry

Implemented Practice

We implemented the following practices:

1. Smaller, fully functional teams.
   
2. Agile planning and scope management.
   
3. Individual commitment to results.
   
4. Each day is a project.
5. Granular planning and estimates on the level of hours.
   
6. Refactoring.
   
7. Pair programming.
8. Open communication.

Introducing XP Turns Waterfall Project Around

Just noting the practices above.  Nothing to see here, please move on.

Process Facilitator

The term "Process Facilitator" refers to the people in your organization whose primary responsibility lies in improving the effectiveness of the work that the teams are doing. This responsibility is mainly around the process the teams are using, but also encompasses less tangible aspects of work such as team development, organizational culture change, administrative and technical tools, and working with other Process Facilitators both inside and outside of your organization.

In an agile environment, the Process Facilitator has several aspects of expertise and skill to develop, and not all of these can be developed simultaneously:

• Basic Agile Work administrative skills.
• Obstacle removal.
• Team dynamics and development.
• Coaching individuals.
• Organizational development.
• Training groups and teams.
• Promoting agile methods.
• Strategic application of agile methods.

Reward your Process Facilitators as they take on and master each of these areas of skill and knowledge. A Process Facilitator is successful when he or she is able to help a team to become self-sufficient. The team has learned and perfected the basic Agile Work process. The team has gone through the stages of team development (forming, storming, norming and performing) and is now capable of self-directed self-improvement. The organization is no longer resisting the team's efforts to self-organize, to continue learning and to eliminate waste, but rather is fully supportive of these efforts. Once all this happens, the Process Facilitator is no longer necessary as a separate role. The person who has filled this role may then go on to become the Process Facilitator for another team or another part of your organization, or even be loaned out into your supply or customer chain in order to help make those relationships with your organization more effective.

Managing Process Facilitators

Ok, so...  Facilitator.  Not administrator or coordinator. Good to know for future reference. 

Actually, it's really good to know that this exists, and is not a self-created figment.  For now I shall stick with my role as Process Administrator.

More Links:
The Above Article as a PDF
Process Facilitator Cheat Sheet
International Association of Facilitators

Ripping up Cards

The physical manifestation of agile stories are a description of the requirement (in the form “as a [user], I want to [goal], so that [reason]”) written on an index cards with the acceptance critiera written on the reverse. The developer can pick up the card and work with it. Once the acceptance critiera are met it can be put in the pile of completed cards. If at any stage of the process we are not happy with the card, given that it is only a “promise for a conversation,” it can easily be torn up and rewritten. Tearing up cards is a powerful statement. We don’t like what we’ve written? That doesn’t matter, rip it up and start again. That works well in the opening stages of a project, but sooner or later the cards will be copied into a spreadsheet and this is where the problems start. We become attached to the story; good project management discipline demands we keep an audit trail of what we do. Suddenly it is not so easy to rip up the card. Maybe the initial story did not truly represent the requirement. More often than not the story title, and detail will remain the same, but a notes column will be spawned in the spreadsheet and the change to the story will be entered as narative in this column.

And then in the comments:

One advantage of copying the cards to a wiki if you need to access them remotely, rather than using a spreadsheet is that you can delete and rewrite them to your heart’s content, and the page’s history is your audit trail. We all know that no-one will ever look, but at least you can reassure people that the history isn’t lost, and because it happens automatically there’s no overhead. We tend to keep the bare minimum (title, estimate and a few notes) on the index cards, and put the expanded information, including acceptance criteria, on the release plan wiki page. Apart from anything else, the less you write on the cards, the less reluctant you are to tear them up if they need changing.

Getting Attached to Stories by DancingMango

I shall be interested to see how the issues around impermanence resolve themselves in our case.  There is such a tension between official audit trails and the physical impermanence of story cards.