From a very early age, we are taught to break apart problems. When we try to ‘see the big picture’, we try to reassemble the pieces in our minds, but this like trying to reassemble the fragments of a broken mirror to see a true reflection. After a while we give up trying to see the whole altogether.
Friday, 29 December 2006
Wednesday, 27 December 2006
Friday, 22 December 2006
First incremental release of badjit
Posted by Simon Baker
For the last 8 weeks one of our teams has been developing an experimental application called badjit . And we've now put the first incremental release to production. The concept is simple - badjit is a social network that connects people via their shared passions. Visit badjit now and have your say. Say what you really think and explore what other people love and hate. Obviously, after only 8 weeks the functionality is basic but we've got a product backlog full of goodies coming in the New Year. The project was the brainchild of one of our product owner s. An objective of the project was to demonstrate that an idea could be taken from conception to production in a few weeks and without a requirements specification by using a co-located product owner and agile team .
Comments: 1
Sunday, 17 December 2006
Saturday, 9 December 2006
ABC2006: Scaling agile
Posted by Simon Baker
Colin Bird said when you scale it's even more important to understand the principles (of the Agile Manifesto ). Damn right! So often they're compromised and you end up with something that just isn't that agile anymore. The practices also need to be consistent across the organisation. Here's what I took from the session: Start off with a beach-head team to build a head of steam. Create a cross-functional team from early evangelists and opinion leaders. Keep the team together long enough to succeed. Start small and make the team progressively larger over time, until it eventually becomes too big. Then split out people to seed new teams. Create enough cause for people in different teams to talk to one another. If you cannot avoid distributed teams, maximise communication with instant messengers and VOIP solutions; use an integrated development environment with a common continuous integration environment; cycle people through all teams. Avoid communities of common disciplines, e.g. DBAs or architects. Stagger daily stand-ups so that people from other teams can attend. Synchronise iterations to allow joint planning and delivery. More reading on Colin Bird 's blog: - Scaling agile - part 1 - Scaling agile - part 2
On average
Posted by Simon Baker
Here's the content of a presentation I recently put together based on some averages derived from how we've been working.
Read more...
XPDAY2006: Joshua Kerievsky's keynote speech
Posted by Simon Baker
Joshua Kerievsky of Industrial Logic gave the first keynote speech at XPDay . He talked about selling agile methods. Here's what I took from the session:
Read more...
Thursday, 7 December 2006
Sunday, 3 December 2006
Ken Schwaber talks about agile quality
Posted by Simon Baker
Ken Schwaber talks about Agile Quality: A Canary in a Coal Mine . If you get told to deliver specific functionality by a specific date that is impossible to attain without sacrificing quality, just say no . Remind the person who is effectively telling you to cut quality, that the software you're developing is a corporate asset . Do the right thing - don't build crap corporate assets.
