Online presence of Craig Smith — Agile Coach & IT Professional in Australia

Archive for September, 2011

AgileTODAY

AgileTODAYAgileTODAY is a publication associated with the Agile Australia conference that is run by SlatteryIT. It is published quarterly and I have been lucky enough to have articles in the first two editions.

You can subscribe to the print copy or access the past issues online.

Volume 1 – May 2011

In this edition I featured in a profile entitled “60 seconds with Craig Smith”.

From Miscellaneous

With 15 years of software development and eight years of Agile practice under his belt, Craig Smith is an experienced and vocal advocate of the Agile methodology. He has regularly spoken at both the global and Australian Agile conferences, and currently spends his days as an Agile Coach at Suncorp’s Agile Academy.

Craig is a Certified Scrum Master, a member of the Scrum Alliance and Agile Alliance, an advisor to Agile Australia, and will be speaking at Agile Australia 2011.

Everybody starts their Agile journey somewhere. What was your ‘a-ha!’ moment?

My a-ha moment was in the days before many folks were even calling it Agile in 2001 – 2002. I worked on a project to write a lending application written in Java where we overtook a small meeting room, started writing tasks and designs on a whiteboard, split designing screens down via CRUD and core functionality and we paired and worked as a team to get things done. I could never go back after that. What has been your greatest challenge when introducing Agile to an organisation?

How did you overcome it?

In the early days it was trying to get people to take you seriously, as not delivering reams of documentation at the start of a project was seen like being a cowboy yet we were delivering faster than the teams around us. It felt much like working in a bubble because when we went outside our team environment we had to fall back to the waterfall processes used by the rest of the organisation. When Jeff Smith joined Suncorp, it was refreshing that someone in higher management had similar views, and since that point it has been a challenge to fi nd approaches to make our IT teams (and now the entire organisation) to work more effectively.

What is your favourite Agile-related quote?

I am always having to remind people that “our job is not to do quality Agile, it is to deliver quality software or solutions”. We just use Agile values, principles and practices to help us do that. I am quite concerned how much the term Agile is overloaded or used as an excuse by many people now, so have started a movement to come up with a new label, and joked we should call it “raccoon”. (in hindsight I should have come up with a better name!)

What is the strangest situation you’ve applied an Agile principle to?

It’s amazing how many situations the core practices of stand-ups, retrospectives and Big Visual Charts are applicable to. I fi nd it more amazing that when getting together to plan work with other Agile coaches or working on different Agile conferences, how often I have to remind people to visualise their fl ow or do a refl ection on progress.

If you could have a total career change, what would you be?

I never set out to work directly in IT, as I did a dual IT – librarianship degree at university. Part of me still wants to tick that box at some stage. But if I could fi nd a job that I had the skills for that related to my love of motorsport, that would be awesome.

What is your favourite thing on your desk right now?

I don’t have a desk, so I live out of a backpack (one of my colleagues calls me “the turtle” because I carry my desk around). So when I do fi nd a real desk, a power pack is usually pretty good. As for the cool stuff, I have a Spongebob Squarepants and a bunch of Simpsons characters on my desk at home!


Volume 2- September 2011

In this edition I wrote an article entitled “The Wow Starts Now”

From Miscellaneous
From Miscellaneous

This year marks the tenth anniversary of the ‘Agile Manifesto’. This historic document was the culmination of the ideas of 17 passionate guys who got together on a mountain outside of Salt Lake City with the aim of focussing on delivering quality software rather than following mundane process.

This document was not the invention of Agile, as approaches like XP and Scrum were already around at this point, but it was the document that gave us the label ‘Agile’.

In the years since, we have seen the rise and rise of the adoption of Agile methods. However, while its core values and principles have remained the same, many new and improved practices have evolved.

We saw this in June this year when we held the third annual Agile Australia conference in Sydney. It was full of buzz and enthusiasm from the 700-plus attendees and it brought home to me what I appreciate most about being part of the Agile community. The fact that everybody – both your friends and competitors – are willing to share their experiences, good or bad, is something that I am sure would not have happened ten years ago.

On the flipside, one of the criticisms I have heard of late, is that there is no “WOW” in the Agile community anymore.

This got me questioning. Where has all the “WOW” gone?

I think in part, Agile is now seen as having well and truly crossed the chasm into mainstream. However, have we gone so far that have we have actually jumped the shark?

Judging by what I have seen at this and other recent Agile conferences, there is in fact “WOW” happening everywhere. You just have to notice and appreciate it.

These range from small examples like the different ways that people tackle retrospectives or organise their iteration planning, right through to innovative approaches to testing and deployment. We need to bring these innovations out of the shadows and shine a light on them, and not be too quick to dismiss them.

My thoughts are that we need to make sure that people who are still on their Agile journey have some basic practices and approaches to build their Agile foundation – which is a huge “WOW” on its own. For the rest of us who have made the leap, we need to remember the twelfth Agile Manifesto principle: “

At regular intervals, the team refl ects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

In other words, we need to continually adjust and share our findings, and every now and then we might just come up with a “WOW” moment. That’s how practices like user stories and test driven development were invented.

My challenge to you, reader, is what is your ‘WOW’? Sharing our experiences, good and bad, is what makes the Agile community great. We need you to share your war stories and your improvements on existing processes and practices (and if you do, we welcome you to share it at the Agile Australia 2012 conference!)

To paraphrase Martin Fowler in his closing keynote at Agile Australia 2011: If you say Agile is no longer relevant, then essentially you are saying you are happy to go back to the ways of the past. If you have truly used Agile in your organisation or team, then you would agree there is no going back – and that is the greatest WOW of all.

Craig Smith is an Agile Coach at Suncorp and an advisor to the Agile Australia Conference.


			

Agile 2011: Agile 2.0 – Rebooting a Raccoon in an Imperfect World

My presentation from Agile 2011 that I delivered with Greg Smith called “Agile 2.0: Rebooting a Raccoon in an Imperfect World” is available on Slideshare.

On this 10th anniversary of agile, our community is struggling to address the issue of how to take experienced agile practitioners to the next level, while still providing training and tools to support those who are beginning their journey. With the “agile” word getting so overloaded, the challenge is to continually innovate without assigning labels. In this talk we will discuss how to use the best of traditional, lean and agile methods to suit any team and showcase numerous patterns that demonstrate the best process to use is often a mixture of traditional practices and new innovations.

Some of the comments on Twitter included:

@teradee: watching @smithcdau speak on “rebooting the racoon. Craig has this stuff nailed. A bright spot in our community #agile2011

@teradee: Listening to @smithcdau talk a on the Oath of Non-Allegiance via @TotherAlistair Thinking this needs more shine #agile2011

@theagilepirate: Look up the manifesto manifesto – we have enough manifestos Kumquat, raccoon is a community #agile2011

@codingbynumbers: @smithcdau gives birth to #racoon at #Agile2011 (but we know it was conceived on @codingbynumbers)! http://t.co/CyvgOer

Agile 2011: The Speed To Cool – Agile Testing & Building Quality In

My presentation from Agile 2011 that I delivered with Adrian Smith called “The Speed To Cool: Agile Testing and Building Quality In” is available on Slideshare.

Ensuring that the approach to testing and quality is understood and appropriately valued in an agile world can be a struggle for many organisations, especially when resources are limited and our customers are expecting business value in a timely manner. In this session we will define what quality means and share a number of tools for measuring it, discuss approaches to improving the skills, empowerment and role of testing in the organisation and share why testing is the coolest role on the team and why it is everyones responsibility.

Some of the comments on Twitter included:

@BrianGress: We tend to test only what we can see. #agile2011 @adrianlsmith

@tonyrockyhorror: @smithcdau Speed to Cool was best talk I’ve seen all week. It will take a mighty effort to top it. #agile2011

Adrian also posted about the talk on the Ennova blog.

Agile 2011 Day 5 Review

Agile 2011The final day of Agile 2011 in Salt Lake City was keynote day but not before a couple of announcements. Next years conference will be organised by Mitch Lacey and held in Grapevine, Texas and a number of presentations were videoed (including one of my talks) and will be available over time on the Agile Alliance website.

Finally it was officially announced that my good friend and colleague Shane Hastie had been elected to the board of the Agile Alliance (a first for our little area of the world!). Here are my notes from the keynotes:

Keynote: Code 

Kevlin Henney (author of 97 Things Every Programmer Should Know along with a couple of other books) delivered this keynote. His slides are available here.

From Agile 2011
  • functionality is an asset, code is a liability
  • IOC (International Obsifuctaed C Code Contest) – shows that bad code can look beautiful
  • how noisy is your code – throw away comments and string literals and throw it into a tag cloud generator and see what it shows you
  • code embodies principles and values – the penal code, even the Agile Manifesto
  • typing is not the bottleneck
  • it’s not about business value – it’s not very exciting, it does not get you out of bed in the morning – it’s about passion
  • we are not very good at learning from failure – we can… but we are not wired too
  • patterns manifesto – “we are uncovering better ways of developing software by seeing how others have done it”

Keynote: The Power of an Agile Mindset

Linda Rising delivered this keynote. Some resources Linda mentioned that back up her talk were the work of Carol Dweck (MindSet and Self-Theories), The Talent Myth by Malcolm Gladwell and How to Help Them Succeed from Time magazine. Here slides are available here.

From Agile 2011
  • there are two mindsets – fixed and agile – determines everything we do – determines goals, reactions to failure, belief about effort and strategy, attitudes towards others successes
  • we can continue to grow, you can’t measure someones potential with an IQ test
  • belief about yourself affects belief about others – we are hardwired to judge and stereotype others, fixed mindsets do it on very little evidence, agile mindset still does it but are less positive/negative
  • bright little girls are typically praised constantly
  • bright little boys are typically criticized or reprimanded
  • organisations have a mindset as well
  • Enron had a fixed mindset to hire the best talent – “rank and yank” – only keep the best
  • Southwest are about people not planes – don’t hire for IQ, but for attitude and learning
  • managers have a mindset – how they view their employees affects their performance (Pygmalion in Management in Harvard Business Review and Hard Facts by Pfeffer and Sutton)
  • build teams around the agile mindset
  • the mindset is a belief, it can be changed – we can encourage others to change their mindset
  • perfect vs per-fect
  • emphasis on the effort and process

And with that, the Agile 2011 conference was over!

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 5 of the conference.

Agile 2011 Day 4 Review

Agile 2011Day 4 at Agile 2011 brought a full day sessions full day of sessions followed by the conference dinner. For the first session I used the law of two feet and landed in three different sessions.

Stages of Practice: the Agile Tech Tree

Arlo Belshee and James Shore led this hands on session to build a technical tree of agile practices. I didn’t stay for long, but I was interested in the output, which I found hanging on the walls later in the day.

From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011

Creating Customer Delight

Steve Denning (author of a large number of leadership books) delivered this presentation based around a blog post of a similar name that I sat in for about 30 minutes. His presentation is available here.

From Agile 2011
  • move from output to outcome
  • customer must be surprised and delighted
  • move from implicit goal to explicit goal
  • custom delight is the new dimension of done
  • product owner adds contingent valu
  • bottom line is whole organization, not just the team
  • customer delight is measured eg. net promoter score
  • delight is happiness, joy, customer success – everybody has a story or understands this concept
  • identify your project that you wish to delight – who is your customer?
  • what do customers say they want? – warning! they don’t always know eg. New Coke
  • what is it that core customers might not like about your product? eg .why they made the Nespresso machine because people did not like cleaning up, need to get inside their head to understand what you need to change

Agile From the Top Down: Executives Practicing Agile

Jon Stahl delivered this session, and I wish I had been there for this one all the way through as his presentations are always entertaining and informative. His slides are available here.

From Agile 2011
    • visualise your work  in progress (WIP) by putting every project in progress up on the wall, also visualise your demand
From Agile 2011
From Agile 2011
From Agile 2011
    • model your application assets – you will be surprised what you will find – link them, then order them by business value
From Agile 2011
    • create a radiator wall for each one of your assets – understand technical debt, print out each of your defects, be ambarrased!
From Agile 2011
From Agile 2011
    • visualise your org chart – particularly where your skills are, then rank them by apprentice, journeyman, master – then you can score your aptitude
From Agile 2011
  • get HR to create their own room to map the organisation and look for patterns – finding the truth isn’t simple but putting stuff on walls creates conversation
  • create a tool wall – who cares what tool you use, as long as you are adding value
  • get the practice vocabulary up on the wall – matched with a booklet with more detail
  • when tracking practices move away from traffic lights and use smiley faces to track how people are feeling – don’t care about if they are doing stand ups but how are they working for them – good way to figure out where to send coaches, where the frowns are
From Agile 2011
    • transparent leadership – post and show your people what roadblocks you are working on
    • everybody wakes up everyday thinking they are doing the best thing they can – as a business the executives need to check each other to make sure they are working on the most important thing and allow each other to question
From Agile 2011
  • make roadblocks visible – you will get more respect from you people – put one up for every person who has the title manager in your organization
  • leadership team to do retrospectives every two weeks – take people out of their element, makes them more likely to talk
  • continuous improvement – force it by shutting down email, block out meeting rooms
  • you would save money on coaches if you got people to read books, free ice cream by reading a chapter in a room and talking about it in an hour
  • pair management – pair on everything to get better, pair in public which will show developers pairing is ok
  • change name of PMO to MSO (manifesto support office), make them in charge of ensuring the visual radiators are up to date
  • dashboards are costly and evil – they are not the truth, data is mostly inaccurate
  • speak in story cards – create a wall to get answers to things you want to know

Acceptance testing in the land of the startup

Joseph Wilk presented this session, his slides are available here.

From Agile 2011
  • Relish – the only way the customer will read Cucumber tests
  • two way mirrors – ensure the users are integrated into development and they can use the software, outside the building
  • good coders find stuff hard – easy to Cucumber test the full stack but the build time blows, unit tests are hard but are fast, so limit the amount of cucumber tests and isolate them
  • features rot if the Customer does not read them or not exposed via tools like Relish
  • manual testers duplicate automated tests – expose features, pair, give Cucumber ownership to QA
  • how to test lots of permutations – pairwise testing is OK, or just automate the happy path and one scenario and manual test the rest
  • Crazy Egg – monitor what users are actually using
  • use WIP to keep testing under control
  • metrics – JUnit Max to predict probability of failure
  • Limited Red – calculates the probability of Cucumber failure to improve the way we work – found features that never fail – just keep them in nightly build – means a long build usually fails very quickly
  • use JMeter to check everything is up like a tracer bullet – eg. a row has appeared in a table
  • got 8 hour build down to 20 minutes by distributing over 24 EC2 nodes – but think we were solving the wrong problem
  • slice up the architecture and have thin tests to test them
  • Spork – helps to speed up the start up time of an application – hard to know whether to reload and it adds a lot of overload at the protocol layer, so almost as efficient to run the tests
  • people have core responsibilities but we all meld in our roles to be one team and deliver

I enjoyed this session, particularly as I read about Joseph’s company in Specification By Example. I am excited about the prospect of a tool such as Limited Red as well.

Telling Better Stories with User Story Mapping

Jeff Patton led this session to a packed room that included a live appearance from his children! His slides are available here.

From Agile 2011
  • user stories are the simplest idea in the world, but like any simple idea they all get screwed up
  • it’s easy to lose the plot when you have a lot of stories
  • story mapping – tells the whole story of your product and still gets down to the iteration level
  • you already know this stuff!
  • “sharpie markers smell like ideas!”
So…
    • dump ideas onto stickies, on your own – they should almost always start with verbs – we need verbs to do things
    • verbs are a user task – they are a small task
From Agile 2011
  • now we want a flow of what we do from left to right – stack the duplicates and group the similarities – create a user workflow
From Agile 2011
  • mark where the natural breaks are – this is called a user activity – a grouping of things that a user does
  • next, identify where the pain points are
  • because it is a map you can find stuff in it
From Agile 2011
  • how to change the world – start with an idea which is product > feature > specification > requirement
  • learnt that requirement means “shutup just build it”
  • outcomes result in impact – agile is to maximize outcome and impact we get
  • stories are a conversation about the future
  • stories are 5c’s – card –> conversation –> confirmation –> construction –> consequences (when we realise our ability to predict the future sucked!)
  • Kent Beck called them stories because they were meant to be heard
  • need to figure out the who, what, why – this is the richness behind the story
  • add a short title, add a description (story template), add notes, specifications and sketches and write acceptance criteria before writing software
  • stories shrink in size and grow in detail as they travel through a pipeline
  • start with capabilities or features (understand value) –> break to release size stories– > upcoming iteration stories (priority, UI design, business rules) –> break to iteration size stories (details user acceptance tests, small enough to fit in iteration) –> completed bits of software
  • user story mapping – based on story mapping in films
  • ultimately we have big things that break down to little things

Build story maps by:

  1. talking to real users
  2. brainstorm user tasks to help them organize
  3. research and build from a narrative
  • discussions with users in front of a map drive out conversations
  • plan incremental releases as a team event – developers will actually read the plan
  • start talking about adding stickies and notes, finally get a fist of five for confidence
  • don’t prioritise user stories by ROI – target a user segment
  • like ripping a $5 note, the small stories are not valuable (Jeff actually ripped a $5 note to illustrate the point)
  • map at MVP (minimal valuable product) and MMF
From Agile 2011
From Agile 2011

Finally, Jeff has a User Story Mapping book in the pipeline which looks really interesting. I have had the pleasure of meeting Jeff a few times and always enjoy his presentation and learnings, and I am keen to give these learnings a go in my next storycard workshop.

Flirting With Your Customers

Jenni Jepsen delivered this presentation, the slides are available here.

From Agile 2011

We started with an exercise – 3 things that make a great project – trust, hard work, common goals, transparency, clear direction, grown ups, togetherness, support, communication, budget, right skills, creativity, quality, teamwork, fun, support

We then discussed 3 things that make a great romantic relationship – trust, communication, clear expectations, respect, common goals, honesty, integrity, similar values, enjoy spending time together, depth, support, compromise, patience, back rubs, teamwork, equality, chemistry, humour, passion, sacrifice

  • there is a lot of commonality between projects and a relationship
  • flirting is about making people feel valued
  • need human touch to thrive, keeps immune systems strong
  • people who are happy and feel valued at work results in increased profit
  • introverts need to take care of themselves, take energy from within – they can flirt but it takes energy
  • extroverts thrive in social situations – if your customer is an introvert they may not share your energy

The 8 steps are:

  1. radar – makes you aware of the people around you, takes confidence
  2. target – figuring out who you want to connect with in an organization, who has the real power
  3. move in – show interest, practice your opening line – make eye contact, making the person feel like they have knowledge, makes them feel valuable, interactions become richer because of this
  4. back off a little – the other person may not be ready for the interaction, give the other person space
  5. open up – being honest and laying it out, you have now created a comfort zone, you are also making yourself vulnerable, there might be some back and forward bargaining here
  6. dance – have a little fun, create conversation – lunch, cook together, virtual coffee over Skype, celebration to mark a milestone, dinner club
  7. get real – go through a crisis together, if you have flirted and built a relationship
  8. enjoy – enjoy the relationship
  • have a list of questions to get over the anxiety
  • all good steps for people you manage
  • body language is 93% of communication

Conference Party

The conference party was entertaining as always. Here is me hanging out with Alan Bustamante (who I worked with on the reviews) and the gang from Seapine Software

From Agile 2011

The acrobatic team doing their trampoling indoors was certainly a highlight:

From Agile 2011

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 4 of the conference.

Agile 2011 Day 3 Review

Agile 2011Day 3 at Agile 2011, here are my notes:

Scaling Software Agility: Advanced Practices for Large Enterprise

Dean Leffingwell is the author of Scaling Software Agility (which was written in 2006 and, in his own words, the world has changed since then) as well as Agile Software Requirements (which is really about portfolio management). Dean presented this session, a copy of his presentation is available here.

From Agile 2011
  • scrum is designed for small teams and makes no claims for scale
  • scale might not work, you can make it work
  • economics and technology have changed to make agile work

Not everything is a user story:

  • user stories came from XP, builds the user right into the requirement
  • lots of teams have their own stories in their own sprints
  • if something is in the backlog we might do it, if it is not in the backlog we won’t do it, anything that needs to be done goes in the backlog
  • best code comes from XP shops – it’s a form of hygiene, like brushing your teeth
  • the user story model lacks context – the things around it
  • at enterprise scale you have a large, large amount of stories but how do you reason about that and get the context
  • we need an additional level of planning – features which get decomposed into stories
  • features need to fit into potentially shippable increments as well, because they need to ship
  • stories need to get tested, as do features and non-functional requirements
  • use epics to describe features that are too fine grained at the enterprise level – may be implemented over long periods, even years
  • investment themes represent the budget allocations that drive the authority – at a program level figure out your epics that make up 17% of the budget, for instance

Think agile programs, not just agile teams – manifesto does not mention teams at all

  • there are lots of teams in the enterprise
  • need to train everybody, but that is slow and expensive
  • regular release train, build it this way even if if the customer / factory is not ready for fit
  • change value system from plan driven to value/vision driven – move from Clarity driven estimates which we then fix to fixing a date which we strive to meet
  • in software industry we always miss dates, build credibility by meeting dates
  • most teams are overly optimistic
  • quality needs to be built in, but features need to be variable
  • everyone needs to be on the train – waterscrumming does not work
  • hindsight brings us perspective
  • cadence alone is not enough – worst nightmare is not the facts but the false sense of security that you are going to deliver
  • slowest component drags the train – if you have a VP of system integration you are already screwed
  • make sprints the same length – two weeks is a good cadence, three weeks is too long, you can’t figure out when you should start testing
  • have regular system wide integration – use PSI (potentially shippable increment) to ensure you have a product, use hardening sprints for the things you can’t do in a normal sprint and let the team catch up
  • release train process – when you have an asset that adds customer value, ship it or ensure you have a asset that you could ship – it could save you with large maintenance renewals
  • pacemaker is release planning – need a full day or two for release planning – if you can’t spare that then plan badly – also gives us full alignment, a good point to get the architects involved because at this point you can make a change – plan using stories because that is the teams currency
  • scrum gave us a framework for sprints – plan and commit on day 1, execute for 8 days, demo and retro on day 10
  • at enterprise level raise this to the PSI level – plan and commit at the program level and demo and retro together at the end, sprints at team level in between (a program is usually 5-10 teams)
  • do a one week all in training for the team and then fire straight into release planning – then coaching is in context – don’t have good experiences with teams that go ahead without coaching support
  • take into account that your first sprint will be a little rough

Enterprise systems require intentional architecture – it matters!

  • refactoring is part of agile, list on the wall and get the product owner to stand by them, but it doesn’t scale very well
  • architecture can emerge, you can’t always plan for it
  • principles of system architecture are important
  • the architect needs to be part of the team to succeed
  • the team owns the design of the system, gives them accountability – design spike is our currency for architecture and it needs to be demoed
  • sometimes we need architectural epics – architectural epic kanban system

Portfolio management must be agile too – the mothership of all impediments!

  • PMO is governing us to a model we have abandoned, yet we created it in the first place
  • need to move from a portfolio of projects to a backlog of content management
  • need to move from cost estimation to velocity estimation and planning – so estimate your releases and epics in points too, not in dollars or hours
  • the team manages a project, not a traditional PMBOK manager
  • move from Gantt charts to a release train
  • move from milestones to fact based governance – we don’t cheat and lie on agile, the facts are friendly
  • use the term PSI rather than milestones
  • the worse your program is, the less you see it (that is, if you miss a design milestone there is nothing to see)
  • get the agile PMO to re-purpose and drive release planning, reviews and retrospectives – they need to drive the behaviours to be successful

Your enterprise can be no leaner than your executives thinking – need to turn them into leaders

  • executives are actually pigs – pigs are cool, chickens are uncool
  • I need management to resolve impediments, string vision, managing performance, etc…
  • managers must lead! – need to train them first
  • need to have respect for people
  • management needs to be trained in lean thinking, when they get lean they get agile (The Principles of Product Development Flow)

Overall, there was nothing really new in this session for me, although it was great to hear from Dean directly, especially on the topic of PMO’s and leadership. His latest book is still on my list to read.

Removing Impediments with Drawings

Carlton Nettleton led this interactive session, the instructions and agenda of the session is available here.

From Agile 2011

This session was based around Dan Roam’s Back Of The Napkin framework. There are six types of business problems:

  1. Who and what? – people, things and roles
  2. How much? – counting and measuring
  3. When? – scheduling and timing
  4. Where? – direction and how things fit together
  5. How? – how things influence each other
  6. Why? – what is the big picture

These help you focus on the types of problem you are trying to solve.

The steps to visual thinking are:

  1. Look – look around the room, get oriented
  2. See – start to recognize familiar patterns
  3. Imagine – see with our minds eye, manipulate the patterns and make the invisible visible
  4. Show – show the idea to people
From Agile 2011

A drawing is more memorable, particularly when related to a story, helps your audience visualize your message, pictures drawn by a human are better than those drawn by a computer because they look too perfect

SQVID is a metaphor of how to draw pictures. Are you drawing:

  • simple or elaborate pictures
  • quality vs quantity
  • vision vs execution
  • individual vs compare
  • change vs status quo

Imagine:

  • discuss why you are imagining
  • draw simple
  • don’t overwhelm by drawing too much
  • iteration and refinement
  • think outside the box

Show:

  • focus on the audience
  • feedback
  • evolution – start, middle, end
  • outside perspective
  • drawing is only for support

This was a very hands on session, and the charts that we used in the exercises were very good templates that I will recall and use in future. The takeaway for me was to draw pictures in real time more to illustrate and get engagement for my message. I will also take another closer look at  Dan Roam’s book.

Agile 2.0 – Rebooting A Raccoon In An Imperfect World

I presented this session with Greg Smith to a good size audience. The slides are available in a separate post.

Tightening the Feedback Loop

Patrick Kua presented this session, the slides are available here.

From Agile 2011
  • effective feedback should strengthen confidence or improve effectiveness
  • The retrospective prime directive (at retrospectives.com) also applies to feedback
  • in lean 99% of behaviors are driven by the system – people were driven by the situation at hand
  • focus on behaviors not values or judgements

Formula:

  • be specific on timeframes eg yesterday
  • your observed behavior
  • perceived impact
  • recommendation or suggested solution
  • make it a conversation – set aside time such as feedback frenzy Friday
  • give feedback earlier, not just at annual review time
  • create safety – “is now a good time”, not a public theme but in private
  • seek clarifications – apply the five why’s to feedback
  • say thanks for feedback at the end – appreciate being helped to grow
  • take action on the feedback

Overall I have always found Patrick’s writing on retrospectives helpful, however there was little new in the presentation for me.

After Dark

Wednesday night was the Sponsor Reception, where the prime aim was to get to every booth and get a sponsor stamp (the real rule was to get one stamp per page, but it was far more fun ensuring I visited every booth!) One of the amusing things in Salt Lake City was that they do not take themselves too seriously, as evidenced by this beer.

From Agile 2011

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 3 of the conference.

Agile 2011 Day 2 Review

Agile 2011Day 2 at Agile 2011 in Salt Lake City kicked off with Todd Little advising that the conference this year had 1604 attendees from 43 countries and from 968 submissions we ended up with 268 sessions. Here are my notes.

Keynote – Why Care About Positive Emotions

Barbara Frederickson led with a keynote, but unfortunately I didn’t get to stick around for much of it as I needed to prepare for my session following. Two brief notes I picked up were:

  • positive psychology is about resilience, the closest concept in psychology to agile
  • positive emotions open us – we are more creative and can see more in the periphery, we have more resilience to bounce back, better performance on exams
From Agile 2011

The Speed To Cool: Agile Testing And Building Quality In

The session that I presented with Adrian Smith from Ennova was close to a full audience and was also one of a handful of sessions that was chosen to be recorded. We received lots of great feedback. The slides are available in a separate post. The following pictures were Adrian and I outside the room prior to the session:

From Agile 2011
From Agile 2011

Agile Coaching Self-Assessment – Where Do You Stand on the Competencies?

This session was limited to 32 participants, so it was with good luck and planning that I was able to sit in workshop facilitated by Lyssa Adkins and Michael Spayd.

Coaches are energy shifters and are tuned into the atmosphere of the room. We were invited to walk around the circle and reflect on the following areas:

  • agile-lean practitioner – people who know the tools and practices
  • business mastery – know what the business needs
  • coaching -professional coaching
  • mentoring – help people access what they already know
  • technical mastery – help people create great software
  • transformation mastery – help people change
  • teaching – teach people what we know
  • facilitating – neutral assistance to a group
From Agile 2011

We were then invited to walk around the circle and land at:

  • the area of strength where I am drawn to
  • area of nervousness
  • area that would make the most difference in your role

and we discussed and shared out thoughts with others standing in the same quadrant as well as the rest of the group.

We then reflected on where we stand right now and where we want to stand, before pairing up with another participant for a short one on one session.

Finally we reflected that the coaching stance and catalyst leader are the heart of the wheel.

This was an awesome session and something I look forward to running with some of my colleagues as well as reflecting on my strengths myself.

Refactor Your Wetware

Andy Hunt (of Pragmatic Programmer fame as well as Agile Manifesto signatory) delivered this session based on his latest book Pragmatic Thinking and Learning: Refactor Your Wetware. Here are my notes from the session:

From Agile 2011

Software is written in our heads, that is where the problem starts!

Context patterns neuroplasticity:

  • context – need to not look at a whole object but how it fits into the whole system
  • patterns – in pair programming, the navigator can see patterns because they are not concerned with the symbols and syntax, pattern matching is the key to expertise
  • neuroplasticity – humans can grow new neurons, but not sitting in a cage or a cubicle, work with enlightened people or in a sensory rich environment you will grow new neurons, but if you don’t use parts of your brain it will get rewired

If you study in an artificial environment you will get artificial results.

Skills – the Dreyfus model – rules –> intuition, consider everything –> relevant focus –> detached observer –> part of system

  • novice – no experience, accomplish a goal, want to get it done, don’t know how respond to mistakes, only way to be effective is to have contact-free rules (ie working in a call centre, following a script), need recipes to follow, can’t get much productivity from this level
  • advanced beginner – start trying tasks on your own, don’t want the big picture
  • competent – build conceptual models, troubleshoot on your own
  • proficient – want to understand the big picture, want to understand why, frustrated by oversimplified information, self correct previous poor task performance (retrospectives are a good example of why they need an experienced coach), learn from previous experience, can understand and apply maxims
  • expert – primary source in their field, continually look for better methods, work from intuition, world does not really work on rules it works on experience
  • second order of incompetence – know what you don’t know and admit to it
  • nursing practice shares a lot of similarity to software development – you need to solve problems then and there – need to become outcomes-based, importance of the individual, keep experts in practice, pay based on value added to the company
  • South American monkey trap is like the tool trap – confuse model with reality, de-value traits that cannot be formalised, legislating behaviour that kills autonomy, alienated experienced practitioners, demand for conformity of tools, insensitivity to contextual nuances
  • brain is not a computer – made up of L mode and R mode and we switch between them – spinning girl exercise – creativity and intuition works better in R mode
  • image streaming – pose a problem to yourself, close your eyes for 10 minutes and then for each image that crosses your mind describe it out loud, image it with all five senses and describe it in the present tense
  • free form journalling – first thing in the morning, write three pages long hand, uncensored, don’t skip a day – way to get it out
  • Thomas Edison used to take a nap with a cup of ball bearings and when it dropped he would wake up and write down what he was thinking about
  • whack on the head – look at problems from a different point of view or the opposite – a good tool is the Creative Whack Pack iPhone app
  • ten mental locks – the right answer, that’s not logical, follow the rules, be practical, avoid ambiguity, ……
  • you need to keep track of your ideas, otherwise you will stop having them – everyone has great ideas, fewer keep track of them, even fewer act on them and very few can pull them off
  • carry something with you all the time to record notes – tools like The Pocket Mod or Evernote
  • mind maps
  • we miss things that change slowly – this happens on projects on all the time
  • 90 cognitive biases that people suffer – memory stinks – every read is a write that can create false memories, anchoring, fundamental attribution error, need for closure (agile estimation) – we will take any information even crap information for closure – in agile we want to keep things open ended, exposure effect, Hawthorne effect, relativity
  • ask yourself how you know what you know
  • your age group changes the way we view and understand things
  • some people need auditory, visual, kinetic
  • how to read – SQ3R – survey, question, read, recall, review
  • how to take notes – make a mind map, the sensory of pen and paper is better
  • use a wiki – has a category
  • use affinity mapping with post it notes – Behind Closed Doors describes this in more detail
  • get your ideas out there and blog it, tweet it, present it
Warnings:
  • multitasking – when you get interrupted your memory is blown, constantly checking email is an IQ drop of 10 points, three times as much as smoking a joint!
  • send less email and you will receive less email – pick up phone, walk down the hall
  • choose your tempo for an email conversation
  • don’t context switch – scan queue once, put things into piles, no mental lists (GTD)
  • set cues for task resumption when you get interrupted, leave a quick mote in code or on a notebook – gets back to resuming task much faster
  • set team interruption protocols – most teams say this is the happiest times they have coding
  • second monitor is a 20-30% productivity gains – ALT-TAB in windows is context switchin
Change is hard:
  • start with a plan
  • avoid inaction not errors
  • new habits take time (3-4 weeks)
  • belief is physical
  • take small next steps

This was a great session with so many techniques to look (and re-look at). As a result I think I will also add this book to my reading list (especially given that The Pragmatic Programmer in one of may favourite books). Finally, Andy reminded everybody that the Pragmatic Programmers also have a free magazine that is worth checking out.

After Dark

Tuesday night is typically the night that most of the vendor parties happen. I managed two invites – one to the Atlassian Drink-Up (which unfortunately due to talk preparation I ended up missing) and one to the Celebrate with Rally party which I was able to make for a couple of hours at the end.

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 2 of the conference.

Agile 2011 Day 1 Review

Agile 2011It was great enthusiasm that I set off to Salt Lake City last month for Agile 2011. In the lead up I was a reviewer on two stages (Testing & Quality Assurance and Working with Customers), plus I was lucky enough (and apparently the only submitter) to have all three of my original submissions accepted (although conference rules, for good reason, restrict speakers to two sessions). Whilst its a been a month since the conference (I took some time afterwards to spend time on both the east and west coast of the USA), I wanted to ensure that I posted my notes.

Here are the notes from the sessions that I attended on day one.

The Product Partnership: Using Structured Conversations to Deliver Value

Mary Gorman and Ellen Gottesdiener led this tutorial. They started by taking about requirements by collaboration and leading a discussion on things that hinder and help.

From Agile2011

Things that hinder: access to the right people, thinking about the solution rather than what needs to be done, multitasking, people not listening, customer not clear of needs, backlog too big, stories too big, missing product owner

From Agile2011

Things that help: centralised repository, short backlog, story maps, clear business goals, UI mockups part of the story, clear priorities, crisp acceptance criteria

From Agile2011

To set the stage we need:

  • a sponsor, product owner / champion, customer, technology
  • a shared understanding of vision, much like an infinity loop we: discover –> prepare –> deliver
From Agile2011
From Agile2011

They then went on to speak about value:

  • conflicting voices for value – not just from the customer but technology value, we need to listen to all the voices
  • evaluate requirements – value, risk (such as technology risk, team risk, outsourcing risk) and dependencies (dependent on other teams or external vendors and requirements and dependencies where value violates the way we would like to build the system)
  • benefit – IRACIS (increase revenue, avoid cost, improve service) needs to be balanced with cost, time and delivery
  • table stakes – the things we must deliver to stay in business
  • differentiators – point of difference in the marketplace
  • up sell revenue potential
  • foundation for long term savings
  • provides revenue for future
  • frequency of use
  • automate labour intensive tasks
  • no viable manual workaround
  • reduces pain for end-users
From Agile2011

This led to a discussion about backlog:

  • we want to build the most valuable things first
  • two states – credible (it has some kind of value) or buildable (it has been prepared and is sliced, groomed or right size as well as understood well enough to estimate, test and document)
  • incorporate UX into preparation, collaborated workshops
  • slice for value – starts with a glean in someone’s eye, then it gets bigger because we have a bunch of options, so we need to fit based on value to contract the list
From Agile2011

And finally onto requirements:

  • product provides value to users – who will receive value from the product
  • what actions need to be performed – what are set options
  • what is the data (noun) and the type and state of data
  • what are the constraints – policies or controls that need to adhered to, business rules

The example for this tutorial was getting to the Agile 2011 conference. We first ask the question: what do we value.

From Agile2011
    • customer value – convenient parking, staying in conference hotel, cheap flights, etc…
    • business value – people stay at conference hotel, one stop shopping on the website to save aggravation for Agile Alliance as well as attendees
    • user roles – travel explorer – individual attendees (speakers, sponsors, volunteers, attendees) and corporate travel agencies for group travel
From Agile2011
    • actions – hotel information, distance to the venue from home, distance from other hotels
From Agile2011
    • data – link to hotel (official hotel plus local hotels), Salt Lake City information
From Agile2011
    • control options – the business rules, such as when you need register by, etc…
From Agile2011
So we start with the requirement:
I need to: register
User role
  Type options: member*, non-member, group, academic
  State options: active*, inactive
From Agile2011

Then the actions:

Action options
  learn
  pay
  confirm
  communicate
  cancel / transfer
From Agile2011

Then the data:

Data: Fee
  Type options: regular, early bird, super early bird
  State options: available, sold out
Data: Payment
  Type options: credit cards, payment order, check
  State options: paid, pending, not paid

We may also visualize this as a data model or a state diagram

From Agile2011

We then need to look at the business rules and prioritise them.

From Agile2011

Once this is complete we can now we slice for value and write a story. This needs to be the silver bullet / tracer bullet, then you can break down from there. At this point you can write the stories and throw the sheets away. This all leads to:

As a... I need... so I (value)

Requirements leads to examples which leads to tests. We can now link this to given when then:

 Given: pre-condition (state), fixed data
 When: action, business rules, input data
 Then: output data, post condition (state)

It is recommend that you come to these workshops with some pre-planning but be under the agreement that they are draft and often wrong. These could be release or iteration planning workshops.

Now the forgotten heroes, the non-functional requirements:

    • design and implementation constraints – the givens, the parts of your technical infrastructure that are dictated or restricted – worth pausing and discussing if there are any options
From Agile2011
    • interfaces – human, other systems and device interfaces such as messages (you could use a context diagram to illustrate this) – with the diagram you can start discussing the options / choices / possibilities
From Agile2011
    • quality attributes – things like speed, stability, uptime, security, scalability, usability, extensibility, etc…, need to be testable and SMART (specific, measurable, attainable, realistic, time-based) – eg. recover from user error in x clicks, x time
From Agile2011

You can do this at the big view (business process, features, MMF, scenarios), pre-view (user stories, user story maps where you lay out stories left to right, scenarios) or the now view (buildable, scenarios). The granularity will change.

From Agile2011

Plans in an array matrix – the anchor is the action dimension

From Agile2011

Need to have a structured conversation to communicate effectively. Face to face is the most effective and get a shared understanding of the highest value.

Overall, this was an enjoyable session. I really liked the templates for mapping out the requirements (despite the fact that these were essentially just aids for the workshop) as they helped focus the conversation and gave our group something to focus on. Mary and Ellen are currently writing a book based around this content, so I look forward to seeing that in the future.

Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership

Christopher Avery (creator of the Leadership Gift and author of The Early Admissions Game: Joining the Elite, which apparently is 10 years old and still in print) led this extremely packed session, the essence is contained in this publication available here (as well as here).

From Agile2011

We started the workshop by competing in a spaghetti challenge (based on the Marshmallow Challenge) which consisted of the materials of just 10 pieces of spaghetti and a  line of tape. The team I was working with constructed a tower of 35 inches, which ended up being the second tallest in the room.

From Agile2011

There is a pattern in our mind that kicks in every time something goes wrong – creates angst and anxiety – responsibility process – a descriptive model:

  • QUIT – the pressure of responsibility and obligation can lead us to quit, an avoidance move, a lack of completion, active disengagement
  • RESPONSIBILITY – call yourself on obligation so you start looking for solutions – start saying “I get to go to this stupid meeting”, means you have a choice – we were taught that doing stuff we have to do makes us responsible
  • OBLIGATION – I have to go to his stupid meeting have to but don’t want to – leads to resentment
  • SHAME – how could I do this, how could I be so stupid – laying blame on self – premise is the problem, you can’t learn
  • JUSTIFY – it was raining, I dropped my keys – story makes it just – “that’s just the way it is around here…”
  • LAY BLAME – who took my keys? – not a solving position of mind
  • DENIAL

3 keys – descriptive model

  • INTENTION – wanting to get something done, get to RESPONSIBILITY around every problem in your life
  • AWARENESS – be aware of which level you are in
  • CONFRONT – ability to face, taking yourself to the edge of your comfort zone, comfort zone = current capability, confront = expanding capability – every person you know was once a stranger

Example coping mechanisms are: learn to live with it, it worked on my machine, they just don’t get it, it’s the vendors fault, it’s too hard, you’ve been here long enough to know that’s not going to happen, murphys law, we did exactly what they asked for, …

We then did a “Be With” exercise, which was essentially sitting knee to knee with the person next to you, in complete silence,  for 30 seconds, to feel the others anxiety. Ultimately, it’s not the other person that makes you feel bad, it is yourself.

Confront is the angst of confronting yourself. If you want to change something you need to poke it, and observe the change.

Accountability Responsibility:

  • accountability is the number one tool of management – it’s the way we manage commitments between two parties – its outside of us because it is us and someone else
  • responsibility is about how we respond – internal to us, and different for all of us
  • what people are signed up for is greater than what they are responsible for
  • what people are responsible for is greater than what they are accountable for <– We want to be here
  • they are both equal

Where’s the bottleneck?

  • what if you had to reproduce the code, if you had the same team and resources?
  • what percentage would be more efficient the second time?
  • modal is 70%. You would be better because you have solved the problem before. Learning takes time. Essence of agility is to learn and take feedback.

There is lots of feedback in agile practices such as retrospectives, showcases, standups, etc… If you are not going to do anything about it, stop investing in the feedback loop. The fastest way to learn is to take ownership.

Fastest way to elevate responsibility in a group is demonstrate it yourself. If you are saying people around you are not displaying responsibility, then you are just laying blame.

Exercise coaching responsibility. The responsibility process only works when it is self applied! You need to teach it so others can self apply it. Counter not being good enough yet to teach this yet:

  1. Give yourself forgiveness, forgive yourself for being human
  2. Teach this with a light tone. Make yourself the brunt of all the jokes that are below the line
  3. Don’t go into agreement (“but I do have to go into that stupid meeting”) – don’t confuse the facts with the mental position – take time, breathe, count 10 seconds and answer – validates they raised a good question and allows you to respond – ask if you can push back on them a little bit, and ask them to identify where they are on the chart
  4. Make sure you support – need to forgive yourself, let go and move onto a better future

Taking responsibility is owning your power and ability to create, choose and attract.

Responsibility is the design space. What do we want from this? Be clear with what you want and be clear about the consequences. Responsibility gives you power but also potential consequences.

There is a difference between choosing something and avoiding something.

As a coach you get to intervene in situations, so you need to act from a position of responsibility and check where you are coming from (move through the model as quick as you can). Ask yourself if your message is clear and does not sound like blame.

Advice is seldom effective so stop giving advice. You are transferring responsibility from them to you. If it doesn’t work they perceive it as being your fault. Instead:

  1. Resist giving advice. Tell me what you have tried, tell me what you haven’t tried
  2. If you must give advice, give three alternatives so they have to choose, putting responsibility on them. “If I were in your shoes I might consider a…, b…, c… What do you think about those?” One coaching company advises 10 alternatives, so you really think about the responsibility.

Finally, play the “Catch Sinner” game to learn the process:

  • make a score card
  • choose a word for today
  • make 2 columns – “get off of it” and “it got out”
  • throughout the day, everytime you catch yourself in a position of “blame” mark your chart
  • 10 points for the left and 1 point for the right column
  • build tremendous awareness for each word at least for one day

There are a bunch of resources at Christopher’s website, in particular he encouraged us to get a copy of the teaching poster and empowered us to teach the process to our peers.

Overall, I really enjoyed this session, as I had heard good reports from this session when it was help in 2009, and this year it was listed as one of the most popular sessions. The responsibility process is something I would really like to work on personally.

The Agile Manifesto 10th Anniversary Reunion: The Big Park Bench

This was one of the highlights of the conference where 15 of the 17 original authors of the Agile Manifesto got together on a big park bench to discuss the writing of the manifesto.

From Agile2011

There were heaps for great stories but here are some of the snippets I took away:

  • started with XP Immersion
  • at the XP Leadership meeting, rejected idea of creating a group
  • Bob Martin and Martin Fowler sketched out an idea for the Lightweight Methods conference
  • Jim Highsmith noted that there us nothing about it that he would change and would not get back together with these people to do it!
  • Ward Cunningham would change the colour balance of the background image
  • Brian Marick noted that individuals and interactions can often be a beat up for people who appreciate tools
  • Jim Highsmith commented when asked about the next 10 years that agilists don’t predict!
  • they never expected that something written in a couple of afternoons would be this big
  • Brian Marick recalled that the stated objective of the meeting was a manifesto and it seemed miraculous that they left with a good framework . Bob Martin was just surprised that he has been to one meeting that worked!
  • Martin Fowler did not want to call it agile, he wanted a wackier name
  • Agile Manifesto nailed it as a baseline – they might have added “we really mean it” or “we are not kidding”!
  • when you gel with a team you get what can be summed up in 3 words: high quality work
  • great teams change people lives. “The manifesto changed our lives, and probably yours too”
  • many people who may have survived under waterfall may not survive much longer under agile, as it is flushing out bad practices
  • other potential names for agile were: adaptive, hummingbird, lean (used already), PPP, a bunch of acronyms, did not want a word they would have to wear pink tights and a tutu to explain!
  • Agile was a coincidence – people following lean in the 1990’s were saying agile is the future, which was good because agile has a meaning in the business world
  • the most argued item on the manifesto – iteration timeframe, executes terminology
  • the principles were harder to arrive at
  • biggest disappointment – everyone wants to be agile but too few people want to do it (when they wrote it they really meant it), the scrumbut
  • biggest success – uses outside of software (for example Pragmatic Programmer publishing), wanted teams to be able work freely in a way they wanted to work
  • need a revolution in middle management and need a similar framework for agility
  • Agile is not the “not-waterfall” – it’s about teams and delivering software
  • Agile stands as a beacon of hope, for it to disappear would mean the evil empire has won
  • in software, we still need to ask how do we do a better job?
  • an Agile process of inspect and adapt is what makes lean companies great
  • Jim Highsmith particularly called out Jeff Smith, the CEO of Suncorp Business Services as being someone who got promoted from CIO to CEO through the success of Agile
  • consider lean inside the same heritage as agile
From Agile2011
From Agile2011
From Agile2011

A reunion site has been setup in conjunction with this event.

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 1 of the conference.

Twitter Summary August 2011

A summary of my Twitter posts from August 2011: (more…)

Twitter Summary July 2011

A summary of my Twitter posts from July 2011: (more…)

Follow

Get every new post delivered to your Inbox.

Join 1,101 other followers

%d bloggers like this: