First, there was the volcano in April and some speakers couldn’t make it to Atlanta so we had OpenVolcano 2010. This was just an appetiser. Today was another tasty bite, a conference at Bletchley Park organised by Karl and Rachel (to coincide with Agile Coaches Gathering), with a bunch of great presentations initially destined for Atlanta.
The day was nicely concluded by Eric’s talk adapted on the fly and a quick fishbowl session.
Some of the recurrent themes I picked upon, were:
visualising the work
understanding how the work works
understanding the product
importance of creating good relationships with all people involved, identifying all stakeholders
integrating IT as part of the organisation (not them v/s us)
small, small and small – defying the complexity
getting quick and frequent feedback, closing the feedback loop
code is inventory not until it goes live but until it goes live and delivers value
flow – making sure the work flows cleanly and there are clear exit criteria
continuous learning by running deliberate experiments and collecting feedback
the PDCA Shewhart (Deming) cycle
Kanban is becoming increasingly popular, useful and adaptable as a tool that help visualising the system and thus facilitating learning and creating a shared understanding.
The main challenge still remains with over-engineered organisations that are bafflingly refusing to embrace the lean goodness defending the status-quo.
Thanks to the organisers, the sponsors, presenters and all the great folk from the community. It was a day well spent.
Presentations and podcasts should be available on Skills Matter website.
08:30-09:00 – Registration and Coffee
09:00-09:45 -KarlScotland- A Kanban Multiverse
09:45-10:30 – Eric Willeke – Value Stream Languages
10:30-11:00 – Coffee
11:00-11:45 – Simon Baker & Gus Power – Product Development in the Land of the Free
11:45-12:30 – Damon Morgan – Learn to Lean: Becoming a Lean Startup
12:30-13:30 – Buffet Lunch
13:30-14:15 – Benjamin Mitchell – Using Kanban to Get Knowledge and Continuously Improve
14:15-15:00 – Liz Keogh – Behaviour Driven Development: Learning as a constraint
15:00-15:30 – Coffee
15:30-16:15 – Mattias Skarin – Converting A Scrum Team to Kanban
I saw a tweet this morning. I thought it was funny and witty, another sign of good things to come from Glitch.
You pinched a Crab. The crab is hurt. It’s not so much the pain of the pinching as the encroachment on the crab’s job description. (-2 mood)less than a minute ago via webGlitch, the game
playglitch
It prompted me to write this post because it is very true and quite applicable to agile environments.
Success of any agile team, especially a newly forming one, depends heavily on their ability to work together collaboratively and to communicate effectively. Anything that stands in their way (like not sitting together, multitasking between projects, lack of information radiators, etc.) separates the team from potential success. One of the considerable barriers for new Agile teams is existence of explicit, specific, detailed and deeply ingrained job descriptions and job titles. It is often underestimated and overlooked as a potential problem but despite good will from fresh agile team members it can come to pinch you.
Specific job description is something people can hide behind: “I’m not going to clarify those requirements, it’s not my job”. It also provides a (somewhat false) sense of security: “I’m the only person in the team who can sing-off testing”. People can feel uneasy, after all: “Only us developers can write good code”. It can undermine equality and take focus away from the ultimate goal – delivering quality software that provides business value. It creates boundaries, promotes silos, isolation, exclusion – or at least it can in some (sadly not uncommon) situations. It appears to stand in conflict with the idea of cross-functional team.
If abandoning job descriptions (and specific titles with it) sounds risky and dangerous – perhaps it is. It certainly requires commitment, transparency and responsibility. It breaks the traditional mould, it is brave. Yet it has successfully been done before and not only in IT (where it slowly becomes less and less controversial) but also in other industries and disciplines. My favourite example is that of Ricardo Semler’s Semco:
Performing multiple roles during the crisis gave workers greater knowledge of the operations and more suggestions on how to improve the business. Reforms implemented during that time led to 65% reduction in inventories, a marked reduction in product delivery times and a product defects rate that fell to less than 1%. As the business climate improved, Semco’s revenues and profitability improved dramatically.
As of 2003, Semco had annual revenue of $212 million, from $4 million in 1982 and $35 million in 1994, with an annual growth rate of up to 40 per cent a year. It employs 3,000 workers in 2003, as opposed to 90 in 1982.
–Wikipedia
In practice you rarely get to influence the company so profoundly and win the battle with HR. It is nevertheless worth remembering as a potential problem, and can be addressed early on by creating a clear vision for the team and uniting around a common goal of delivering excellent software which will hopefully prove more important than any potential encroachments.
I like when that happens. I grabbed a “random” book in the office, flicked through and it turned out to be a real gem. “The Trusted Advisor” by Tom Peters, David Maister, Charles Green and Robert Galford is unsurprisingly all about trusts. It talks about the role and importance of creating and sustaining trust for professional consultancy services. You can use it as a guide for building and evolving trust. It describes what it looks like when you experience a trust relationship and gives good reasons why trust is more important that technical excellence.
I really liked this book primarily because I attribute similar importance to trust. I also think it is still greatly underrated in both management and in IT industry but it is changing. Agile manifesto as well as XP both emphasize that software development is primarily about interaction between people (at all different levels) and about technical practices second. One of the principles behind Agile Manifesto explicitly refers to it: “Give them the environment and support they need, and trust them to get the job done.“
Refer to my mindmap as a guide through the book or a reminded of some of the key themes. Good, useful and relevant read. Recommended.
Give them the environment and support they need,
and trust them to get the job done.
Today I’ve spent one of the most enjoyable days recently, at least as far as my professional life goes. It all started a couple of days ago when Roy (@RoyOsherove) and Paul (@PDarrall) decided to take advantage of the #ashcloud still lurking over Europe and gather together people who would otherwise have been flying around the globe (with Lean Conference in Atlanta being one of the prime destinations). Thus #openvolcano10 an open space conference was born.
In the truly agile spirit the conference has been put together in a matter of days. Notwithstanding the (mis)fortunate circumstances of many great folks not being overseas it was quite an achievement. Setting out this morning I was thinking I will blog about some of the talks and share what I’ve learnt. It very quickly became apparent that I will fail. Not because I haven’t learnt much or the speakers where not interesting but on the contrary – I wasn’t prepared for the speed, intensity and diversity of my learning experience – it was fantastic. So I could mention the first session I put together on Agile Analysis joined by Chris (@PapaChrisMatts), or the Rightshifting talk by Bob (@flowchainsensei) or the heated debate on Scrum Master Certification led by Gojko (@gojkoadzic) or his other session on the future of acceptance testing or Robert (@unclebobmartin) getting us to think and discuss functional programming and clojure or Kevlin’s (@KevlinHenney) lightning talk on why we don’t learn from mistakes, or… you can see where this is going. So instead I’ll just thank everyone who made today’s experience possible – Paul and Rob for stepping-in to organise, all the sponsors for making it a free event: iMeta, Emergent Behaviour, JetBrains, Riverglide and XTC; and to Skills Matter for providing the venue at short notice; Rachel for facilitating the day. Today wouldn’t be the same without all great personalities from the community – those who I’ve met before (Kevlin, Liz, Ian, Anthony, Gojko) those who I had a first change of meeting (Robert, Bob, Jeff, Tom, Rachel, Chris, …) and everyone whose names I didn’t remember yet.
Today we have discovered and experienced a new format for agile technical conferences where everyone had an equal opportunity to participate, speak, contribute, exchange idea, ask questions and get answers. It was a learning experience for everyone.
Having been running around with a camera I have captured a few images that you can now find in the #openvolcano10 flickr set.
During the Lean transformation in my current company we get to learn lots of new things and unlearn a lot of old ones as we familiarise ourselves with new concepts and tools.
One of the fundamental agile tools in the space of requirements capture is using user stories rather than previously used use cases or functional specifications. User stories should be sort, concise, specific, usually written on a small card and usually following the ubiquitous pattern (As a … I want to … so that …). On the back of the card, there would usually be some acceptance criteria so that we know how to test it and see when the particular story is done.
In a discussion with one of the analysts today, reflecting on a previous sprint I’ve heard: “I’m certainly getting better at those user stories – for the last few I’ve written I had no questions at all from developers or testers“. Well, that’s great I though and… panicked! How deeply rooted we still are in the old days and the old ideas – documentation is everything.
User stories are not a different format of the spec that fully express any given (perhaps more fine-grained) requirement. They should be place-holders for conversation. Statements of requirements indeed but ones that need to be explored and enhanced in collaboration of the development team and the business side.
We still have a lot to learn – or rather unlearn. (And perhaps shrinking the cards will help?)
First, there was the volcano in April and some speakers couldn’t make it to Atlanta so we had OpenVolcano 2010. This was just an appetiser. Today was another tasty bite, a conference at Bletchley Park organised by Karl and Rachel (to coincide with Agile Coaches Gathering), with a bunch of great presentations initially destined for Atlanta.
I like when that happens. I grabbed a “random” book in the office, flicked through and it turned out to be a real gem. “
