Craig 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
When 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.
With 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.
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.
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)
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.
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
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
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)
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
create a not list – focus on what we are not going to resolve – in, unresolved and out of scope
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
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…
what keeps you up at night – risks worth taking and those that aren’t
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
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
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:
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.
The 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.
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
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.
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
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
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
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
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.
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.
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.
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
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.
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
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.
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:
Craig Smith 
You must be logged in to post a comment.