Episode 88: Scrum Australia Anticast

The Agile Revolution Podcast

weisbartsaAdam Weisbart turns the tables hosting an anti-podcast where he interviews Craig, Renee & Tony at Scrum Australia 2014 in Sydney on their highlights from the conference. The conversation included:

* Adam Weisbart’s “Agile Antipatterns” talk and his awesome Agile Antipatterns cards
* Craig Smith’s “40 Agile Methods in 40 Minutes” talk (and the methods on the cutting room floor)
* Agile movements are just as important as methods
* Tony mentions the original Winston W. Royce “Managing the Development of Large Software Systems” waterfall paper – why??
* Henrik Kniberg’s “Scaling Agile @ Spotify” keynote
* Matthew Hodgson’s “Backlogs, Story Mapping and Star Wars” talk
* Knowing one of the organisers like Star Wars helps!
* Renee Troughton’s “Darth Vaderless Daily Scrums” talk
* Important to know the expectations that everyone else should be having on each other to…

View original post 83 more words

Advertisement

Scrum Australia 2014: 40 Agile Methods in 40 Minutes

My presentation from Scrum Australia 2014 called “40 Agile Methods in 40 Minutes” is available on Slideshare.

With 73% of the world using Scrum as their predominant Agile method, this session will open up your eyes to the many other Agile and edgy Agile methods and movements in the world today. For many, Agile is a toolbox of potential methods, practices and techniques, and like any good toolbox it is often more about using the right tool for the problem that will result in meaningful results.

Take a rapid journey into the world of methods like Mikado, Nonban, Vanguard and movements like Holacracy, Drive and Stoos where we will uncover 40 methods and movements in 40 minutes to help strengthen your toolbox.

Huge recognition to Renee Troughton who created the basis for this talk as part of her Enterprise Transformation Meta Model work.

Honoured to have Henrik Kniberg, Nick Muldoon and Adam Weisbart in the audience for this talk and lots of good feedback on Twitter.

Episode 64: Interstate 40 East with Nick Muldoon

The Agile Revolution Podcast

Nick-CraigOn a road trip to Agile 2013 from Dallas to Nashville, Craig chats to Nick Muldoon while cruising in a Chevy Equinox eastbound on Interstate 40 between Memphis and Nashville. Nick is an Agile Coach at Twitter and formerly the Product manager for GreenHopper at Atlassian and whilst doing 65 miles an hour they chat about:

View original post 91 more words

Agile 2012 Day 2 Review

Agile 2012Day 2 of the Agile 2012 conference in Dallas, here are my notes.

Keynote: Scaling Up Excellence. Mindsets, Decisions and Principles

This keynote was delivered by Bob Sutton, author of a number of business books including “Good Boss, Bad Boss” and “The No Asshole Rule“. A similar presentation to the one he delivered is available here.

From Agile 2012
  • organisations have centres of excellence – how do you spread it from the few to the many without screwing it up? (examples – Hendrick Motorsports growing from 2 to 4 teams, McDonalds opening 1,460 stores in China)
  • shared mindset (what people should and should not do) is crucial to scaling up – Apple has a secrecy mindset, Amazon has an openness mindset, so there is no one right way
  • a mindset is required to be successful at Agile – going to a talk or reading a book is not enough, you need to grind out the message and do the same thing day after day and live by it (Facebook – employee on boarding is a six week bootcamp where they work on 12-13 short projects, focus is to inject people into the mindset and determine their best fit at the organisation)
  • the never ending danger is that things might go bad (Onward Memo by Howard Schultz – growth of Starbucks from 1,000 to 13,000 stores, in the rush to get a huge footprint, the mindset got watered down – got excited by growth and left the excellence behind)

Choice Point 1 – More vs Better

  • strategic tradeoff
  • voltage loss – things get lost in the translation, sometimes this is worth it because it is half as good as the best but twice as good as it is now
  • learning curve problem – takes people a while to get good when spreading knowledge from the few to the many
  • overload problem – burden of the management team in trying to maintain momentum

Choice Point 2 – Alone vs With Others

  • collaborate with competitors (Glad Press ‘N’ Seal), open source is one extreme, do it alone is the other (everybody at Pixar is an employee, nothing is outsourced

Choice Point 3 – Catholicism vs Buddhism (Replication vs Localisation)

  • roll out to the masses or a central set of beliefs
  • cranking out clones – works in manufacturing like Intel plants, Sees Candy and In-N-Out Burger either work in a market or not (pull out if not)
  • replication trap problem – Home Depot is a DIY model and when they rolled it out in China it did not work in their culture
  • localised solution – Buddhist approach to tweak just as much as needed to make it work

Scaling Principles

  • link hot causes to cool solutions – fire up contagious emotions first, humans are irrational, to motivate people get them emotionally cranked up (but the danger is that they get angry) so need to have a solution to cool their energy (watermelon offensive at Stanford for bike safety involved smashed watermelons and subsidized helmets or the first all-hands meeting at Apple after Steve Job’s return where the share price was not good so Jobs declared war on Dell and charged up people to make Apple great or get out)
  • live a mindset, just don’t talk about it – do actions that are consistent with the direction you want them to go, what we tell them doesn’t matter it is what they do that counts
  • when in doubt, cut it out – reduce cognitive load but deal with necessary complexity (A.G. Lafley keep it “Sesame Street simple”, Baba Shiv experiments on cognitive load for 2 vs 7 digit numbers), go simpler when trying to sell a message
    • when systems get larger and more complex, you need to deal with the complexity – Ben Horowitz “give ground grudgingly”, add people and processes only when things start to break down
    • Hackman’s rule for teams – over 6 people problems arise, more than 10 you are really in trouble, optimum is 4-6 people, Navy Seals and fire teams have 4-5 people, any more is more complicated
    • Dunbar’s number is 150 (100 to 230) – the cognitive number of relationships we can manage, pirate ships only have about 100 pirates per ship before dividing, Twitter average is about 100-200 followers
    • as the team gets bigger you spend more time on the dynamics and less time doing the job
  • little things pack a big wallop – subtle cues mobilise mindsets – design things that people barely notice but have a huge impact on their behaviour (background music, language, smells and sounds affect people’s behaviours)
    • Kathleen Vohs money research – people are less likely to ask for help or give help, will work alone when money is the object – leads to selfishness and self sufficiency
    • think about the little cues you are sending
  • connect people and cascade excellence – get one group to mentor the next to spread the excellence, grow your own replacement to get a promotion (Zynga), make your initial group diverse because more variation will give you a bigger impact
  • the mindset is the steering wheel and incentives are the juice – money is an incentive but so are pride and shame, how can I embarrass them or how can I make them proud (using mimes to mimic jaywalkers, Ben Horowitz fines people $10 a minute they are late for a meeting – it is not the money that motivates them it is the embarrassment, gets them to pay him on the spot!)
  • don’t put up with destructive beliefs and behaviours – bad is stronger than good, bad behaviours are ingrained more deeply, to spread excellence you need to stop the behaviours, bad behaviours are 5x worse than the good, destructive team members that can’t be reformed can bring down performance by 30% to 40% because you spend more time dealing with them rather than the work (Barry Feld of Cost Plus World Market would look for two things when visiting a store – greeting me and the customers and are the bathrooms clean)

Traps

  • don’t mistake swarming for scaling – raising awareness is not enough
  • too fast, too far – when people say they want to scale quick and fast, they are looking for the easy way (you are fighting a ground war not an air war)

When scaling you need to be master of addition and subtraction. – everytime you add something good, you need to remove unnecessary and bad things to make way for the good.

I also wrote an article on this session for InfoQ.

Why Agile Needs More Cowboys

Mike Griffiths presented this talk, his slides are available here.

From Agile 2012
  • do you ever see cowboys looking after cows?
  • real cowboys protect the herd, select the lead, direct into natural flows
  • agile is humanistic rather than mechanistic, so is leadership – manage property and lead people
  • “Leadership is the capacity to translate vision into reality” (Warren Bennis)
  • levels of maturity (Stephen Covey) – dependent -> independent -> interdependent
  • leadership is the next step beyond management – to a soft skills focus
  • productivity – undermining / resistance -> passive compliance -> active participation -> committed dedication -> passive innovation – move up the scale with good leadership
  • model desired behaviour – same attributes of a good leader are modeled over many years and in different countries – honest (will not knowingly follow someone who is dishonest), forward looking (describe the future state), competent (don’t want to be embarrassed by our leader), inspiring (The Leadership Challenge), a leader needs to shield the team, remove impediments, carry food and water and re-communicate the vision
  • communicate a vision – like driving in fog, without clear vision you need to slow down, clear direction allows focussed effort and speed, Jim Highsmith’s kick off meeting vision exercise, reinforce the vision frequently
  • create a learning and sharing environment – “if you have two hands to work with and you use one to cover your butt, you only have on hand left to work with”, set an example and admit mistakes and share information, ask questions of your team, make it OK to discuss the bad stuff
  • share information / power – agile tools allow move from micro management to navigation and communication
  • fostering functional accountability – accept that conflict is good, Patrick Lencioni on The 5 Dysfunctions of a Team
  • importance of the team – COCOMO Estimation model (Barry Boehm) shows that people factors has a multiplication factor of 33 (there is a 10x difference on good people over good process)
  • challenging the status quo – retrospective, “areas for improvement” works better in some cultures over “what didn’t work well”, retrospective action wheel, gathering lessons learned is one of the most frequently dropped agile practices
  • innovation and learning – if people are trying hard, then mistakes don’t really matter, Toyota collects lots of ideas with small incentives rather than one big idea
  • encouraging each other – treat people as volunteers, paying people just incentivises people to show up but volunteers are passionate, say thank you and why you are thanking them and what the benefit was, celebrate interim goals frequently, at the end is too little too late
  • shared leadership – aiming for teams of competent leaders (“Project Leadership” by Jeffrey Pinto)

I also interviewed Mike Griffiths for InfoQ.

Leading Conflict: A Systems Intelligence Approach to Conflict Facilitation for Leaders

This workshop presented by Michael Spayd and Lyssa Adkins was one of the highlights of the conference for me. The key takeaway for me was that “everyone is right… partially!” The slides are available here.

From Agile 2012

The workshop started with a discussion on the conflict we see on teams and then about why we came to the session and what we had hoped to get out of it.

  • systems oriented leadership – structured, holistic, organic, complex, end to end – move from the work level to a birds eye view
  • relationship systems intelligence – we are all in relationships – personal, work, departments
  • the human system is not in alignment with what agile does, leadership begins inside
  • see conflict through the right view – the right view leads to the right action, everyone is right partially, self organisation happens when all perspectives are represented, conflict is something trying to change in a system and not a problem to be managed

We then had a discussion around what is the benefit of the right view, is it difficult?

  • what is the difference between finding someone wrong as to finding someone right – go and hunt out why they are right
  • container – not necessarily physical but made up of behaviours, norms and culture of the team and environment

We then did an informal constellation exercise – 20 people in a circle, put the subject on a piece of paper in the middle, make a statement if it is true stand close, if not true stand away then ask those in the constellation what it means to you, need to talk from experience not what you think, remember people are right partially (take a soft focus). It is called a constellation because it looks like a star in the sky, speak from your experience, only people who wish to speak should

From Agile 2012
  • container – culture of the team, want to raise level of positivity and decrease level of negativity and toxicity, educate team about conflict and team agreement about digging into it
  • positivity and team performance – continue to abdicate your position is bad, needs to be balanced with inquiry – “not sure I agree with you, but tell me more”
  • all teams have an emotional bank account – positive interactions are a deposit and negative interactions are withdrawals, what is positive for your team and what is “flipping the asshole bit”
  • build the container – positivity vs productivity
                Happy camp     |    Insanely great
Productivity    ---------------+-------------------
                Prison camp    |    Sweat shop         
                           Positivity
  • emotional withdrawals – blaming, defensiveness, stonewalling, contempt, excessive advocacy – contempt is most prevalent on software projects
  • emotional deposits – appreciations (noticing people doing little things, in front of the group), acknowledgements, more inquiry and less advocacy
  • never praise people for the work they do, but for who they are, turn up acknowledgements and turn down appreciations
  • appreciative inquiry – look at the strengths of teams

We then had a discussion around our teams positive /negative ratio

  • dealing with cultural conflict – inquiry openness, use my land your land ” in my land we…, what happens in your land?”
  • teams move around the quadrants – prison camp is not sustainable, happy camp and sweat shop are intolerant
  • conflict protocols – team needs to come to consensus, leader needs to take a facilitator / coach role – what is the environment and behaviour we want when we are in conflict, everybody’s job is to call out the protocols when needed, not enforce them
  • be a facilitator – more helpful than resolving it, keep reviewing the right view beliefs (fake it till you make it), understand your triggers
  • process the conflict – reframe the conflict” “I wonder what this conflict is trying to tell us”
  • don’t want debate or vote, a prelude to a discussion to find out what’s true
  • we get triggered by people who are like us who exhibit behaviours we don’t like
  • Getting to Yes – Roger Fisher
  • to hear from silent others, ask “lets hear from those who have not not spoken” and then be silent

I was lucky enough to interview Michael and Lyssa with Shane Hastie for InfoQ.

The Product Owner Role is a Stupid Idea: Improving How We Handle Customer Requests

Jeff Patton is always entertaining, and I was not disappointed with this session. I would hope that his slides get published at some stage.

From Agile 2012

He kicked off the session with a live poll by getting the audience to answer the question “what goes wrong with product ownership” and then got everyone to move around the room based on experience, how well the product owner works (they don’t correlate!), internal versus external product development and the ability to change products

  • why is there a difference between developers and customers?
  • single product owners don’t work – whole teams own products
  • processes aren’t designed for success (including Agile ones)
  • safety isn’t success – Nordstromare a big successful company so they have lots of rigour around their process, nothing innovative gets through the net, so they built an innovation lab
    • waterfall model – step after step models have no feedback, Royce was trying to explain why it was a bad idea, experts have been trying to tell us why this is bad since the 70’s, traditional development models are safe
    • agile is the new waterfall – product owner creates stuff and gives it to someone else – someone to blame like the preceding process in waterfall
  • velocity isn’t value – being great at delivering software using agile then you should realise that it doesn’t matter, if we build more shit we just have more shit, we are not here to build software we are here to change the world, everything that happens (outcome) is after delivery, so need to maximize this, difficult to measure
  • underpants gnomes – a meme for something people are building but have no idea why
  • to get value you must form a hypothesis on how you’ll get it – this is the first shift companies need to make – how will we measure the output
  • one balanced team not client vendor – if we want to fail we can probably fail cheaper abroad
  • ideal product should be valuable, usable and feasible, product manager understands the value, UX or BA understands the usable, lead engineer understands the feasible, this is a balanced team – how should we build it, will they use it and how much will it cost
  • working as a team of comakers, we need to do a lot of mind reading, visibility is not good enough, shared understanding is what we are striving for
  • discovery complements delivery, morale suffers when we just build stuff, the thrill is seeing how well it works and debating the results and planning the next approach
  • story maps describe outcomes that we are shooting for
  • personas – don’t necessarily need to be accurate documentation but facilitate shared understanding
  • need face time with real people to understand, go watch people work to learn, then build models to map what you learnt (experience or journey map), when users explain a problem that should trigger an idea, share product story or product as part of a regular internal tradeshow
  • we need to understand the problems and find solutions to get us there, MVP (minimal viable product) should be the least we can build to solve a particular problem,
  • a newer version of MVP is lean startups (build -> measure -> learn) MVPe, smallest viable experiment so that we can learn and eventually earn
  • ready for release board – for each card, an explicit measure step and metrics, then before it leaves the board they need to learn
  • Nordstrom Innovation Lab learning loop – Replace the Mirrors – look for the number of learning loops, no idea on their velocity but we know how much they learned, just budget for learning – “life is better here, even though we fail most of the time”
  • you fail most of the time at predicting outcomes and getting value (Marty Cagan – Inspired)
  • making good product decisions is hard, focus on how fast we learn and how fast we get things out there
  • don’t focus on velocity and worry about who’s fault it is, focus on the things that matter

To succeed:

  • adjust your head – get out of the old client vendor model, be less like a waiter and more like a doctor and solve problems
  • take on the persona of a music producer – listen to bad music and help make others ideas better
  • be the film director – focus on the talent of the people you are working with, give direction and passion without stealing ownership

Industry Analyst Panel Discussion

I sat in the first 40 or so minutes of this discussion. Unfortunately, the room was so packed and the panel was not elevated so it was very hard to determine who was saying what. The panelists were Tom Grant from ForresterThomas Murphy from GartnerMelinda Ballou from IDC and Christopher Rommel from VDC.

  • should we stop focussing on agile adoption?
    • disagree – fewer people to execute, focus on importance, deliver benefits quickly, tackle issues like mobile and embedded
    • agree – not about how many people are doing this or certifications, there are plenty of problems to solve, a foregone conclusion, let’s tackle the bigger issues, adoption is superficial metric, plenty of challenges beyond pure software development
  • can you define ALM?
    • no agreed definition, lean concept of flow, includes the tools and processes
    • typically think about standard phases but the end to end lifestyle doesn’t work, now need to look at DevOps and cloud now, more complicated to deploy now
    • ALM tools are a misnomer, output of SDLC, fundamental issues with tools currently, we do not develop and done any more, need to start thinking about products and products have lifecycles
    • going forward will be more about traceability of past development and operations
    • worst thing is the name
  • what should we call ALM instead?
    • Application Lifestyle Context
    • Gartner are talking about this internally
    • nirvana…, once the new taxonomy is decided it will be antiquated, we are here to improve!
    • dynamic end to end process, software lasts decades longer than we expect it too, needs to sustain life
    • ripple effects of agile disrupts it
  • Gartner’s prediction of 80% of software development teams doing agile by 2012, where are we?
    • at least 80% of all IT organisations have some agile and 20% of large organisations, on everyone’s mind, businesses are talking about it, will probably still be another 10 years because big change takes that long
    • estimate that 40% of organisations are using agile, has blown past all the other methodologies, businesses realised recently that they’re not innovating
  • are we seeing issues with organisations part doing agile and part traditional?
    • often the only way organisations are initially successful, different processes (eg. software and embedded), needs to rolled out staggered and incremental
    • fair adoption in development teams, but now what does it mean to be a tester, lots of centres of excellence still exist, Facebook deploying every 25 mins scares the heck out of most traditional organisations, companies need to get to the right fit
    • majority of Agile teams are not purely Agile, use water-scrum-fall, slimming down requirements and deployments is not sprinting, Facebook analogy does not fly with corporate clients
    • need to begin where people are, approach what is the best for the organisation and adjust for the context
  • how do you measure effectiveness of Agile methods and compare them?
    • prefer not to speak about methods but rather patterns and practices, compare using customer satisfation, ROI long term for the organisation, organisations still like function points delivered because it is easier to count
    • one of the biggest pluses is on quality and that is subjective and hard to measure, metrics that can point like customer satisfaction, rework and defect counts, time to market also better, it is often a leap of faith
    • velocity interest is going down in industry, but many in the executive suite only think about velocity, a loaded word
    • don’t know soft value if you don’t baseline, now we just fix metrics inline and not all defects and features are equal, need to measure qualitative benefits to the business, will see more as metrics around Agile evolve
    • need to pull testing and quality in all the way through, drive better quality and user experiences
  • describe how you evaluate the tooling landscape?
    •  most observations come from end users, tools aren’t the key most important thing, want to understand where the market is going and what is the right fit
    • biggest differentiator is picking the right tool for the job and the organisation
    • there are tools that enhance Agile that were not built for Agile, and there are specialised tools for Agile, vendors do put thought into who they are targeting so you need to listen, we don’t live in a world where everybody gets their tools from a single place

After Dark

A huge thanks to my friends at Atlassian and Opower who allowed me to tag along to an awesome Tex-Mex joint in Grapevine called Uncle Julios.

From Agile 2012

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 2 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.