Episode 171 – Beyond Legacy Code with David Bernstein

The Agile Revolution Podcast

Craig is at Agile 2017 in Orlando, Florida and speaks with David Bernstein, author of “Beyond Legacy Code“, and they chat about agile technical practices:

  • Agile does have something to with software development
  • Agile 2017 talk “Create Software Quality
  • The real value of Agile is in the technical practices so we can build iteratively, but still very few people practice them
  • The future is already here, but it is not very well evenly distributed – the same applies to Agile
  • Companies are being consumed by their technical debt and they don’t even recognise it
  • What is always cheaper in the virtual domain is building quality
  • Continuous Integration makes the most painful thing in software development (integration) our greatest asset – this in turn gives us feedback
  • We don’t necessarily know there is a better way to do things – but there is a better way to…

View original post 211 more words

Episode 101: The Lean Mindset with Mary and Tom Poppendieck

The Agile Revolution Podcast

craig-poppendieckCraig catches up with two luminaries in the Agile and Lean space, Mary and Tom Poppendieck at YOW! Conference to talk about agile, lean, rapid feedback, culture and leadership. The discussion points include:

  • Making the link between lean and software development and discovering that waterfall makes no sense
  • The origins of the first book: Lean Software Development: An Agile Toolkit
  • Agile is not lean in software development, Agile is lean in a delivery organisation
  • How long does it take you to put a single line of code into Production?
  • The manifestation of lean really kicked off in 2010 with both the rise of DevOps and the Lean Startup
  • Delivery organisations versus engineering organisations and the journey of Agile
  • Agile has not well addressed delivering the right stuff, solving the right problem and the architecture of rapid deployment
  • Only two goals at ING: Deliver every two weeks and don’t crash production, resulted…

View original post 128 more words

Impact Feedback and Finding the Right Word

updownWhen attending the Coaching Agile Teams class with Lyssa Adkins and Michael Spayd earlier in the year, one of the new concepts (at least I don’t remember it from the previous class I did back in 2013) was the idea of “impact feedback”. Simply put, impact feedback is a mechanism to give feedback to someone with a focussing on how that action impacted you. It is also a great mechanism to ensure that your are not leading the person to the solution, rather helping them see the outcome from a different perspective.

The template for impact feedback is:

When you did / said ……… the impact on me was ………

However, one of the difficulties with this technique is often knowing the right word to say. One of my colleagues from my Agile Coaching Competence Cohort program, Jessica Katz, shared this great little tool for knowing the right word to say to describe your impact emotion.

Emotional-Copywriting-Words1

It is called the Wheel of Words, it’s exact origin is not clear, although I found it in an article about emotional copywriting as well as an article about vocabularly expansion of English.

Obviously there are other uses for this tool in coaching conversations as well as discussions, presentations, training and general writing,

Agile 2012 Day 1 Review

Agile 2012With a bit of last responsible moment planning, I made the trek to Dallas (well actually Grapevine) in Texas, USA for the Agile 2012 conference. This year I was once again a reviewer on the Testing and Quality Assurance stage. This was the first year in four years that I did not have a submission accepted, however with my role as an Agile editor for InfoQ, part of my journey was to interview interesting Agile folks on camera (how cool is that!)

When somebody says that things are always bigger in Texas they are not kidding! The Gaylord Texan Hotel and Conference Center is huge, in ways that cannot be explained without seeing it. Everything is accessible without really needing to leave the enclosure (which is great because you don’t need to experience the 110 degree heat outside.

From Agile 2012
From Agile 2012

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

From Agile 2012

Bad-Assed Double-Loop Learning: From Judgmental to Good Judgement

This was a workshop led by Derek W. Wade and Susan Eller. Susan comes from a medical background while Derek has experience in health care and aviation. Their presentation is available here.

From Agile 2012
  • 70% of health care errors happen due to lack of communication, similar numbers for aviation
  • transparency is starting to be accepted as a given, but still opaque in communication (people apply filters)
  • the “core protocols” help transparency
  • people in health care often perform non-health care scenarios (for a scenario that is unfamiliar to them)

We were then given a clinical scenario to watch in which a doctor is giving a medical update to a parent.

  • we observed that: the doctor gave out a broad range of data, the senior doctor fled the scene, the doctor was not looking to the parent at eye level, there was lots of technical jargon
  • our coaching advise to the doctor would be: sit down, don’t be alarming, wait for a response from the parent and address any  concerns, focus on the more likely data at the moment, know the patient, get the senior doctor to introduce the new doctor and stick around for the discussion, ask the parent if he has any needs

We then launched into talking about feedback:

  •  judgemental feedback – “I wouldn’t have done that”
  • non-judgemental feedback – sounds like you are being nice, but are actually statements that make people defensive, “the wolf in sheep’s clothing”, “do you think you could have done better?”
  • frames (mental models) – context is king, match our context to the other person and determine what frame they are in
  • ladder of inference – we can observe data and experiences as well as the actions, but everything else is within, are you basing conclusions on something observed or something inferred (The Fifth Discipline Fieldbook)

Ladder of Inference

  • you need to check in with yourself – are you using observable or inferred data
  • like the donkey’s balls vide, you need to have a WTF moment – what is your cue? Ask “where’s that from” when you have a mismatch rather than rage with WTF!!!
  • single loop interaction – inferred frame, “why we think they did it” (do something and get an outcome, repeat) as opposed to double frame interaction asking “why they did it” (do something, get an outcome, learn from the interaction on why)
  • not all about how you did it, but the way you deliver the message, need to bring to the attention of other person what you saw (your frame), need to understand why they did it
  • uncover your own thinking, use lots of “I” statements to remove defensive stance, “here is what I noticed”, “here is what I do”
  • data -> advocacy -> inquiry
  • balance with inquiry
  • as a coach if you understand the appropriateness rather than just telling them, you are doing double loop learning
  • you have a level of knowledge, so you need to understand but still use good judgement
  • “I noticed…”, “why did you do that?”, “I observed you were polling for status at the scrum… Why did you do that?” In this case, the answer was respecting the time box. Responded, “I understand that…”, “but it is my view that…”, “what do you think about that?”
  • can also do this with your spouse, teenagers (gets through the pain quicker), can also do via email, it’s not the medium it’s yourself (are you genuinely curious)?

The debrief stages are:

  • reaction – not “how did that go”, but “how did that feel”, chance to vent about any feelings
  • description – ensure we are all asking about the same problem, can you give a summary of what happened
  • analysis – use advocacy / inquiry and ask how that related and expose frames
  • generalisation – look for outstanding examples, how can we apply this learning to reinforce

Finally, when you hear yourself thinking “WTF!”, balance that with “What’s that from”

Agile Inception Deck – 10 Questions You’d Be Crazy Not To Ask Before Starting Your Project

This workshop was led by Jonathan Rasmusson, author of the Agile Samurai. Much of this workshop was common sense and very close to the Concept process I have been using and teaching for the last few years. His presentation is available here.

From Agile 2012
  • we start projects thinking we are aligned, but often we are not
  • ten questions – good for 1-6 months of planning, should take a couple of days to a week to complete
  • the last thing executives want is the team asking for more money – they prefer a larger number up front
  • at the front of a project is the time to ask the hard tough questions
  1. ask why we are here – why are we spending shareholder money and capital on this, most projects skip this, if you can go and spend time at the client site
  2. create an elevator pitch – in 30 seconds you have to be concise, in Crossing the Chasm by Geoffrey Moore there is a template for an elevator pitchfor (number one customer constituent)
    who (the problem)the (name of the project)
    is a (type of project)
    that (the intent)
    unlike (competitors)
    our (differentiation)
  3. product box – what would it look like, what are the features and the related benefits – a list the benefits; b) create a slogan; c) draw your creation
  4. create a not list – focus on what we are not going to resolve – in, unresolved and out of scope
  5. meet your neighbours – your project community is always bigger than you think ,core team -> people to start building relationships with -> then everyone else, stakeholder map
  6. show the solution – pick your architecture when you pick your team, be aware that people bring baggage, knock together a high level architectural diagram, show the challenges to the sponsors (eg. no test instances), also show the out of scope and unresolved architecture, understand gaps of licensing, etc…
  7. what keeps you up at night – risks worth taking and those that aren’t
  8. size it up – we don’t know how big – estimate in month-ers, go through the master story list, it’s a guess, not a commitment, think small, no project should take longer than 6 months
  9. be clear on what’s going to give – the secret of agile is that it does the same thing you do when you have too much to do and not enough time, dropping agile is just dropping cost (“or just sending the problem downstream to another manager” as per someone from the audience), the furious four, agile likes to bend on scope, use trade-off sliders, if they don’t want to make a decision you need to remind them that at some stage someone will make a decision, do other important stuff on a separate slider
  10. what’s it going to take – be clear on your team (who do you need, what skills, make sure you have your stakeholders on there as well to be clear on commitments), clarify who is calling the shots (especially when you have multiple stakeholders) and who will make the final decisions from a customer stakeholder point of view (who is the person with the goal), come up with a rough back of the napkin budget
  • should be 10 slides in PowerPoint or keynote – clarity, creative, drives conversation, easy to participate

Here is the deck that the table I was working with created:

From Agile 2012

A blank deck and summary is also available. Jonathan also posted some notes and pictures of the session.

Jonathan also made some time to speak to me briefly on the podcast below.

Podcast

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

YOW! 2011 Australia Review

YOW! 2011The YOW! 2011 Australian Developer Conference was held a couple of weeks ago in both Brisbane and Melbourne and I was able to attend with thanks to Dave Thomas and the organisers of the conference on my press credentials for InfoQ. I had the ability to record some podcasts for The Agile Revolution and Coding By Numbers as well as chat with most of the Agile related speakers. Here are some of my notes from the sessions I got the opportunity to sit in.

Dave Thomas kicked off proceedings with some Lady Java:

Keynote: Top 10 JVM Erroneous Zones

Cameron Purdy from Oracle presented this session. Whilst it is good to see management levels talking about and understanding the core business, I found this keynote rather average. The presentation is available here.

From YOW 2011
  • immutability – no concept in Java, introducing would be good for thread safety but would also improve garbage collection (stop the stop -the-world clauses)
  • primitive types – binding between interface and implementation, improving would simplify and fix auto-boxing and generics, would need to make sure code compiles the same way
  • interface vs implementation – they are all the same thing, a problem that we all inherit from the same parent
  • properties – very fixed contract currently, need to loosen this up
  • obvious intrinsic types – Decimal needs to follow IEEE standard 754-2008 (754r), need to upgrade to a 128- bit world
  • real runtime model – JVM must provide predictability, need more access at code level
  • constants – no constants for intrinsics or other similar types
  • alternate class file format – limited to 64KB in methods, hierarchies make no sense like inner and anonymous classes
  • tail recursion / tail call optimization – performance benefits like Scala

Continuous Design

Getting the opportunity to see Mary Poppendieck speak is always a pleasure, for this conference she delivered her talk on Continuous Design. As the program host for the Lean and Agile track, I also had the pleasure of introducing Mary. Her presentation is available here.

From YOW 2011
  • continuous delivery misses design and feedback – how do we know what to develop if we are thinking about continuous delivery, has created a need
  • continuous delivery uptake is increasing, takes about a year to get going
  • need to assemble a diverse team – frame, ideaton, experimentation then iterate
  • 3M – make a little, sell a little, learn a little (repeat) – the fastest through this loop is the winner – fastest can be four times faster
  • need good people (pay attention to hiring) and a whole team (need all the functions which can break the agile 7 +/- 2 model), measure success in customer satisfaction
  • start with customers – Amazon (working backwards – write a press release, write FAQ, describe customer experience, write user manual)
  • disruptive design – companies like GE are starting to design products for different markets like China and India rather than USA and Europe – resulted in different design , thinking, price point
  • need to decide when it is time for people to see it – it’s hard to refactor books, hardware and first impressions but you need to take a chance and find out that you are wrong – a balance trade-off
  • minimum viable product – biggest waste is building the wrong thing followed by complexity – build it and measure the response (learn)
  • implement a show me more button and forward to to an under construction page and measure the clicks
  • Eric Ries – The Lean Startup 
  • avoid vanity metrics, need actionable metrics, use innovation accounting – start with a hypothesis, build MVP, target initiatives at improving a growth metric in your hypothesis, measure done as adding value
  • use A/B tests to change your conversion rate
  • test early – don’t waste your time arguing
  • cohort metrics – operate on data, as people run into my product how do they behave
  • feature toggles – switch features on/off on demand, wrap entrance to feature with toggle code, control via configuration file – customers love it
  • canary releasing – take a small amount of users and give them a new version, need to be able to tell a good change from a bad change very fast – monitor key thresholds and roll back fast if required – make sure when something goes wrong it never goes wrong again
  • Apple – ” it’s not about money” – understand customer problem and the revenue will turn up
  • Google – “it’s best to do one thing really, really well” – stay focussed
  • Amazon – “think long term” – you don’t want make a lot of money off your best customers, some things don’t always make financial sense
  • 3M – “hire good people and leave them get on with it”

I also had a great half hour chat with Mary on the second day of the conference where we talked in-depth about continuous design as well as size of the product team. She believes the key is to enable the complete development cycle and discover good engineering products. We should stop using software words, including Agile, and start using system level engineering. As for the team size debate, we should use system engineering and break our teams into appropriate sub-components.

60 Years of Innovative and Agile Work Practices

Nigel Dalton led this entertaining and informative trip down memory lane, and as the program host for the Lean and Agile track I also had the pleasure of introducing him. The presentation is available here.

  • people who pay your wages don’t know your stuff, this is a heavy duty approach that has been used for the last 100 years
  • 1930’s Cabinet War Room – as close to an agile room design as you can get, war is a fairly big project!, agile does scale (WWII), lucky it did or this presentation would have been in German!, military and politicians were in the same room, no battle plan survives contact with the enemy
  • 1940’s Lockheed Martin – trademarked skunk works – built a team and in 143 days built the XP-80, built skunk works rules
  • 1950’s U2 and SR71 – if you do good engineering, you will be amazed how long it lasts
  • 1960’s moon race – iteratively learning through doing, working rockets are the primary measure of focus
  • 1970’s Luna Tractor – Russians were striving for a different question, what is on the moon?, different question and cost a lot less money, Apollo 13 is the greatest example of an agile project, ask the right question…
  • 1980’s cold war fears – madness of strategic parity, Russians learnt a space shuttle program cost a lot of money after duplicating it, took the USA 30 years to learn it

I also had the opportunity to talk more in-depth with Nigel Dalton after his presentation for The Agile Revolution podcast with Renee Troughton.

Product Engineering

Mike Lee presented this session, in a sombrero, and his slides are available here.

From YOW 2011
  • underwear gnome algorithm, product engineering is step 2
  • product engineering is overarching, top down and empathetic
  • think about what you are going to do before you do it…
  • million dollar idea – ideas don’t matter and are usually terrible, originality does not matter, it is quality
  • ideas – it’s like a blank but with blank…
  • consider your customers – start at the end by making a commercial (30 – 90 seconds on the problem you are going to solve and how you are going to solve it)
  • your best product tester is your arch nemesis
  • in user interface – it is much more important to be consistent than correct
  • real artists ship – plan, design, ship on time!
  • don’t ship the rough draft
  • fear social debt much or more than technical debt – you can fix technical debt (you can but you won’t!)
  • shipping a product is like giving birth to a kid – there is a heck of a lot more work to come
  • endeavor to kill your own, you are never done, when people are raving about the first one, you are already finishing the second, you want an army of evangelists
  • Appsterdam – the most important thing we have is the community
  • the hook is the difference to a defining product, but need to keep being innovative

Better Testing With Less Work: QuickCheck Testing in Practice

John Hughes delivered this interesting session around Quick Test. The slides are available here.

From YOW 2011

Keynote: Escape From the Ivory Tower: The Haskell Journey From 1990 to 2011

The keynote kicked off with a tribute to some of our founders who we lost in the last year, including Dennis Ritchie:

Simon Peyton-Jones, the inventor of Haskell, delivered this entertaining keynote, his slides are available here.

From YOW 2011

Keynote: Temporally Quaquaversal Virtual Nanomachine Programming In Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces…Made Easy!

With an award for the best title for a keynote ever, Damian Conway kicked off day 2 with this entertaining session.

From YOW 2011
  •  change your velocity, rotate your space-time deep
  • rod logic

Problem-Solving and Decision-Making in Software Development

Linda Rising pronounced this as the “weird talk”, her slides are available here.

From YOW 2011
  • meetings – no thinking
  • no scientific experiments that show agile is any better
  • we need sleep – but average time is dropping, naps are good too…
  • we are hardwired to look at the horizon, so lift your eyes and look around and blink
  • lying down improves your cognitive performance
  • research from University of Queensland – the longer you sit the sooner you will die
  • the startling ideas come at a time when you are doing nothing
  • eat before you’re hungry, drink before you’re thirsty – when the brain is lacking energy, the default is to say no
  • we are hardwired to be close to nature – we do better with natural light and real plants around us, take 5 minutes outside in a natural environment
  • explain the problem to your dog or a stuffed toy
  • in meetings, when at an impasse, get each person to explain each others version of the problem
  • fearless change experiments – test the waters, reflect, small success, step by step

I also had the opportunity to sit in on a very interesting interview with Linda Rising on the Coding By Numbers podcast with Craig Aspinall and Steve Dalton.

Domain-Driven Design for RESTful Systems

Jim Webber delivered this entertaining session, perhaps the most entertaining part was when he tried to explain a cassette tape to a young audience member (I remember loading Commodore 64 games off tape…). His slides are available here.

From YOW 2011
  • embrace HTTP as an application protocol
  • hypermedia helps us to explain to humans what to do next, can also use for computer to computer

Feedback Makes Everything Better: Understanding the Software Engineering Process

Bjorn Freeman-Benson presented this session, his slides are available here.

From YOW 2011
  • problem with Agile is we release and it vanishes with customers – The Progress Principle, The Lean Startup and Continuous Delivery are good books that solve this problem
  • continuous deployment – eliminate the fear around doing deployment
  • tests – a version of feedback, need confidence
  • automated deployment strategy – need to be repeatable using tools, need to be able to do quickly
  • need architecture that can handle inconsistencies in the system at any one time – different versions of API’s, etc. in the system at the one time
  • feature toggles – need on the technical and business side, toggles for beta users, power users, need to be able to work on one code stream all the time for it to work
  • traffic – need traffic for this to be successful, especially to get useful metrics
  • monitoring and feedback – what characteristics are being used, monitoring and qa are the same thing (see Steven Yegge’s rant on big SOA)
  • Apollo program was basically Agile and continuous deployment in the 1960’s – 61 launches until they landed on the moon – only way they made progress was because they were monitoring everything
  • record all the values all the time
  • pay attention to long term metrics, not just instantaneous
  • should use the word anomoly more (not bug) – use feedback to understand and fix our anomalies

Other Stuff

Joshua Kerievsky gave two talks at the conference that I unfortunately did not get to see live (Lean Startup and The Limited Red Society), but I did get the opportunity to speak to him in-depth with Renee Troughton for the Agile Revolution podcast.

Renee and I also did a wrap-up podcast.

I have also published a news article for InfoQ where I asked all of the Agile speakers at the conference what the Agile community needs to embrace in 2012.

Channel 9 were at the conference and recorded a number of video interviews with speakers that are well worth viewing. Peter Sellars has also written a comprehensive wrap-up of the day 1 talks.

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.