Dave Thomas on Maximum Software Productivity – Breaking The Rules!

Dave Thomas paid a visit to Brisbane to present his talk Maximum Software Productivity – Breaking The Rules! at the Microsoft office at Waterfront Place. He set the scene by suggesting the last time he gave this talk he was innundated with hate mail from agilista and objectas! Dave promised the slides would be posted, but I have not been able to locate them if they have. Here are my notes from the session:

  • tired of need to get agile and need to get objects – both good, but got nothing from it, where is the value?
  • objects good, agile good, but are we any better off?
  • most software late, bloated, poor to maintain
  • business does not define requirements well, don’t engage or talk to the customers (NEHITO visits – “Nothing Ever Happens In The Office”), insist on the industry norms because that is what everybody else is using
  • storypoints – training wheels for people who don’t know how to estimate
  • IT does not estimate well, do not build continuously or automatically test (need to be prepared to write a big cheque), also fixed in technology
  • if not ready to do TDD, just stop! Scrum will only make you feel good
  • need to change the rules to be competitive
  • living in legacy due to OO mud ball – legacy is code where there is no tests (see Brian Foote – Big Ball Of Mud)
  • objects too hard for normal people, first thing to be voted off the island should be Hibernate, objects don’t work for lots of things (queries, rules, transformations, etc…)
  • 80% of objects are CRUD – no objects except for the junk in the middle – just data, no simulations or data model – taking a solution and making it complicated and slowing it down
  • frameworks – so many to choose from, new versions, latest things, lots of dependencies
  • dependency injection is proof of how much we have screwed up objects
  • object libraries are unstable and languages are complex (attributes, generics, concurrency)
  • very few people use interfaces properly and keep them stable release to release
  • little reuse – promise not a reality
  • serialization carries all of the baggage of the objects contained within
  • objects suck up performance and memory – bulky and computationally expensive
  • objects cumbersome and slow for multi-core processors to run efficiently
  • objects are sequential and parallel
  • Java application will be 4 to 5 times slower than PHP, because objects are slower
  • can we shorten software value chain – shorter, faster, cheaper – Facebook built in PHP but the money rolls in
  • agile shows predictability and productivity but zip about quality
  • agility is good, but in Java it is very difficult to change the code quickly
  • scrum increases morale (everybody feels better), but makes no difference to quality unless doing TDD
  • lean thinking – software waste – if not prepared to spend $2 million to do continuous integration and TDD then they are not serious about their software output and quality
  • don’t go to meetings unless it is increasing the bottom line – will it help ship code?
  • how to make zero defect code? Don’t ship anything!
  • lean – simple – why am I doing this? – do we need a new framework? – NO!
  • staff a team with people who have shipped software (have a track record)
  • fix price your consultants and enforce that they make delivery with acceptance tests – pay when they pass
  • reward people on delivery, not how long they work
  • tangible requirements – story on the front, acceptance criteria on the back, start with acceptance tests, they are more valuable
  • envisioning – what the developer sees is not what the customer wants
  • agile great for prototyping – building small requirements on the fly
  • a backlog filled with lumpy requirements will burn out designers and product owners – original Scrum paper said sprint 0 should be 3 months – envisioning
  • architects – not a job, a role – should be able to code
  • some companies pay senior developers same as VP
  • extreme design – four hours to design software and hardware and cost it – after a few, you can get close and find out quickly what you don’t understand
  • serious engineering needs design
  • API first – design the architecture, should always be able to get architecture from the code (push a button)
  • need API’s versioned in the code
  • want to close gap between needs and solution
  • a picture is 1,000 words, a table 200 and a diagram 50
  • table driven programming – easily understood, easy to refactor, easy to consistency check (look for missing data), easy to version and diff (just data), data driven can be changed live in a running instance
  • integration – talk to old systems use RSS/ATOM feed (almost all old systems will give a feed for each transation) then you can talk it without custom api’s, REST/JSON your services or use ODBC as a simple interface (its not just for databases), use mashup tools to deliver an integrated application view
  • use scripts to save time & dollars – most software gets thrown way even before turned on, C# and Java too heavyweight, Ruby, Python, PHP, Groovy, Clojure, can easily leverage cloud services and existing services
  • productive languages – LINQ and Reactive LINQ (Haskell underneath), Erlang (good for swicthing and moving traffic, highly efficient), F#, Ruby, Scala (a better Java), Kleisli (bioinformatics), Clojure
  • Everybody should read “The Wizard Book”, Structure and Interpretation of Computer Programs by Abelson, Sussman, and Sussman
  • hardware is cheap, cloud is cheaper – all interesting data is in memory, databases are just journals and don’t really exist, Google does everything by brute force search (eg. translation), speed now means complicated stuff can be done easier and cheaper
  • data driven – massive storage means we can store it all very cheaply, run smart algorithms to determine best value customers because we have all of the data, recommendation engines (NetFlix), Net Promoter, complex event processing (open intelligence), real time financials (no end of month financials, know state of company all of the time)
  • query oriented programming (QOP), Greenplum, Q, Aleri (basically extended SQL dialects with functions) and other functional languages
  • array VM’s – better than object VM’s – always boxed, simpler garbage collection, support all data types (array of stuff is an array of stuff), VM can be small (just an interpreter), arrays are column stores already and trivially serialised, take less space and programs concise and compact
  • best practices for functional programming – agile , refactoring tools, FindBugs / Lint
  • challenges for functional programming – get out of math phobia, different way of thinking, need to write literate and understandable code, think in functions
  • yesterday and tomorrow is always wrong – if you get more bang for buck and competitive advantage, why use existing technologies, if you believe IT is strategic you need to do something strategic with it and dare to be different
  • lost of old things work, lots of new things work well, get out of agile and OO box

Barcamp Brisbane IV Wrapup

Barcamp BrisbaneLast weekend I got along to Barcamp Brisbane IV (held at the East Brisbane Bowls Club), and once again it was a worthwhile meetup of locals willing to share their skills with others.

From the lightning talks that I attended:

Speed Networking

One minute to introduce yourself to someone you don’t know. Worked well, although I knew more people this time around (after last BarCamp and other meetups).

Search Engine Optimisation (SEO)

Michael Smale led this discussion on SEO (unfortunately it started a little late and lost a bunch of attendees, including myself, at the end due to a Google Wave presentation following it!). My notes from the session:

  • SEO is optimising for Google (& Yahoo!)
  • 9 out of 10 people search for content, very few click the sponsored search
  • keywords – on page (to help Google index) and off page
  • stem analysis – trunk and branches (eg. golf and balls, clubs, shoes) then leaves (buy golf shoes and Brisbane) – before SEO, find out what target audience is looking for
  • tools to analyse keywords – Google Adwords Keyword Tool (slightly out of date, monthly), worldwide but narrowed down to regions
  • to know backlinks, etc – Traffic Travis, Market Samurai (free and paid version)
  • not your trunk and branches, but for your leaves you may want to buy keywords, you can optimise different landing pages (separate URL but not a duplicate of pages as Google will drop prioritisation)
  • car rental very competitive for SEO
  • Google Trends for search – can see if things are trending up and down or compare
  • on page optimisation – Firebug for Firefox – drill down and inspect code, JavaScript debugger
  • YSlow – tell you how page is loaded and report on how to optimise page loading
  • each page needs to be optimised with its own title – what’s in the title is what the link on Google says
  • meta description after link is the blurb on Google – not visible to users on site, Firebug will help you see competitors meta tags are, but will not get you up in the ranking
  • meta keywords – does not mean anything anymore
  • care about content on site using LSI (Latent Semantic Index)
  • link text important, add href no follow so Google will ignore

Google Wave

Paul O’Keeffe and Steve Dalton led a live demonstration of Google Wave.

  • collaborative tool, still in preview, crashes, interface still weak
  • proliferated from developers in Google sandpit, only give 8 invites to each user
  • a wave is a single collaboration / conversation
  • has Gmail feel, add and save searches, folders, etc…
  • have a wave inbox
  • with:public – see any waves that are public
  • search with:public gardening
  • new wave by default is not public, add public@a.gwave.com
  • to start, drag contact in, give wave a name
  • drag and drop seems to depend on Google Gears, works out of box with Chrome
  • bots and plugins eg. pirate speak or add a Google Map / Twitter in
  • open source version of Chrome – Chromium
  • Sweepy bot – remove the empty conversations
  • can mute conversation and replay, has version control so you can see how it was and then fork it off

Business Structures

Malcolm Burrows from Rostron Caryle gave this presentation. I hope the slides are made available, as this was a large topic for a 20 minute slot. These are my notes but should not be relied upon an advice or for accuracy!

  • sole trader – liable for own debts, etc, house on the line, no protection freom risks, okay if you have little risk
  • partnership – not sure why anybody would do this now, agreement and governed by those terms, in Queensland partners are liable for acts of the other, everything has to be tailored, risks
  • company structure Pty Ltd – level of risk reduction such as corporate veil, shareholders only liable for the capital put in as long as you don’t do stupid stuff like trading insolvent, as directors do not profit from position of power, need to disclose, 12/20 rule can’t make more than 20 offers in 12 month period, no more than 50 shareholders, replaceable rules (eg. regulate by ASIC or regulate yourself in your constitution)
  • company structures – Limited – Public – all of baggage of public company without the good stuff, horrible!
  • trust – discretionary and unit
  • joint ventures – used a lot in mining, in IT where people agree to do stuff, like a trust is a feature of contract, rights of joint ventures can get very long
  • income distribution structure and IP protection structures
  • options for IP – spin out trading company, spin out company owned by trusts, spin out company licences another

Smile! Say Cheese!

DJ Paine from Studio Promise dropped by, and offered attendees a free portrait, which I certainly took advantage of. Just wished I had of known, and I would have had a shave and worn a nicer shirt!

All of the shots from the day are here and if you need professional photography, support those that support BarCamp!

Symphony – Open Source Content Management

Allen Chang and Alisair Kearney led this session on Symphony:

  • originally called TypeWorks
  • 2.0.6 out now, 2.1 on the way
  • uses XML as data format, output format standards compliant
  • Drupal and Joomla! cores are huge, they wanted a small footprint and control over data structure
  • use XSLT to transform XML to any format you like (eg. HTML, CSV, JSON, etc..)
  • native intergration REST API for Twitter, RSS, etc…)
  • uses open standard templating language, as per all CMS systems
  • a number of data sources for which you can apply rules
  • around 8,000 members, 10% of these contribute
  • users include Australian Museum of Democracy, Heineken and City of Westminster (London) amongst many others
  • ensemble – fully functional website package, Symphony itself is an ensemble

Agile Overview – The Three T’s

It occurred to me in the speed networking session that a number of attendees did not know what this agile hype was about, so I decided to on short notice to propose the talk I gave at Agile Australia 2009 to try and give that overview. Not sure if I succeeded, but got some questions afterwards nonetheless.

Had to laugh at one of the tweets from @funkygorilla (Simon Griffiths): “Agile web development in a 10 min presentation. That’s agile!”

Overview of Agile 2009 / Agile Australia 2009 / AAFTT Workshop

A couple of people decided they wanted to chat about some of the learnings and trends from the conferences I had recently, so a couple of us sat around and chatted about agile testing mainly.

New Hotness

Greg Luck led this discussion as he mentioned to me he came to Barcamp to hear about the new hotness. He has written the notes, but here were the notes I was taking at the discussion:

Wrapup

Paul and Steve reminded everybody about the Queensland Legion of Tech and Greg Luck announced the inaugural Brisbane Jelly (adhoc working together at a location)

Agile Australia 2009 Day 2 Review

Agile Australia '09Day two of Agile Australia kicked off with a breakfast to discuss facilitation of the open space sessions later in the day, that I was lucky enough to be invited to participate in.

Once again I would have liked to have attended Phil Abernathy’s discussion on agile governance (video), Lachlan Heasman and Jody Podbury’s discussion on Agile Business As Usual (presentation) and unfortunately I was scheduled at the same time as Rowan Bunning’s talk on Agile Mistakes and How To Avoid Them (presentation).

Here is an overview of the sessions I attended:

Keynote – Increasing Business Value Through Simplicity

Jeff Smith, CIO of Suncorp gave this keynote, and whilst I have heard a version of this talk a number of times, it never fails to inspire!

Some of the quotes from the talk included:

  • “There is no technology constraint. The only constraint is constraint of thought”
  • “Every product can be copied, but you can’t copy culture”
  • “We don’t do any actual work as leaders, we create the environment for others to do so”
  • “Leaders must important work is to create a productive environment”
  • “When selecting a team, availability is not a skillset”
  • “Leaders should use passion instead of fear to get things done”
  • “There is no skills shortage, there is a shortage of leadership”
  • “Productive Partnerships – work with people you inspire to be like”

ZDNet also summarised this keynote: http://www.zdnet.com.au/news/software/soa/Free-interns-boost-Suncorp/0,130061733,339299090,00.htm

Lean & Agile In The Large

I have seen this talk by Dave Thomas before as well, but wanted to enjoy it again!

Some of the quotes from the talk included:

  • “Smell is a valid engineering term and will soon be a valid business term”
  • You know you’re agile when you no longer have DOORS, Mercury or MS Project
  • “You can only improve what you can measure”
  • “To be agile all the way up you need to be lean all the way down from the top”
  • You need to have someone on your team who’s seen the movie before to be successful”
  • “You must reach outside your own circle of influence to build a community”
  • “If you happen to think that UML is useful then generate it from your code”
  • Learn your tools. You can’t do TDD unless you know keyboard shortcuts”
  • Done = Acceptance Tested!”
  • A story is a wish unless it has acceptance criteria”
  • Architecture is a role not a job”
  • The ultimate expression of process is a culture where building software is more like playing jazz. People just do it!”
  • Definition of SWAG – “Software Wild Arse Guess”

Understanding Just In Time Requirements To Support Lean Software Development

Martin Kearns from Renewtek delivered this presentation. My key takeaway was to remember to scout ahead to be successful.

  • grow change – yourself -> team -> organisation, need to influence your team, change your world and the world around you
  • Toyota production system – two pillars including Just In Time (JIT), falls down without it
  • JIT is about a need – teams want to understand what they are delivering beyond the sprint
  • takt time – theoretical figure on how long it takes to make a product, compare to total cycle time to look for waste (eg, 2.5 days to build car and 4 weeks to deliver, where is the waste?)
  • continuous flow processing – re-arrange for work-piece flow, kaizen to solve bottlenecks
  • one piece flow helps identify quality, ask these questions in retrospectives
  • batching – push process
  • kanban – pull the work – get team to dictate what they need and when they need it, gets team commitment when you supply their needs
  • power of team based approach – able to direct each other and influence the organisation
  • Ron Jeffries Three C’s – card, conversation, confirmation
  • be aware of never ending stories – chasing tail, not sure what we are creating
  • need to scout ahead – to be productive in the now, need to spend time looking ahead to manage uncertainity
  • 5 levels of agile planning (Rally) – 1) visualise what we want to do 2) need a roadmap to know when things are coming so we can focus on the now, need to trust and challenge the roadmap 3) release – incremetal focussed on an outcome, reflect and recalibrate  4) sprint try to get sustainable pace 5) course correct daily
  • project bridge – how are people going to critique our work
  • people want strategic direction – put a date range around release dates
  • understand concept, then formulate a high level design (can be photo on a wiki), should not be done in sprint planning because it can bring uncertainity, implementation,  specification
  • concept – visualise accomplishments and how to communicate to the team
  • need trust and openness – barriers is not a team
  • take baby steps and work your way through dysfunctions

Lean Thinking for Lean Times

Jason Yip from ThoughtWorks and Alan Beacham from KM&T delivered this presentation. The slides are available here. It was a good overview of Kanban (it allowed me to get that a-ha moment in relation to measuring flow).

  • best source of information is Kanban vs Scrum by Henrik Kniberg
  • most agile shops already have a wall with steps, kanban trying to show full process and make explicit, visualise hand off points, set limits on the capacity (otherwise burden people and nothing actually moves)
  • Corey Ladas – Why Pull Why Kanban – JIT backlog – only do what you can do, lean has articulated what XP folk were talking about
  • event triggers – order point to trigger upstream process so not starved of work
  • size of cards now hard to relate back to customer value (software by numbers – minimal marketable features), so track both on wall (feature and then stories and tasks)
  • standardise size of work items instead of estimating (so just tracking work estimates) – at ThoughtWorks Jason determined everything is 2.25!
  • Kanban – means card or sign – referred to as signboard in a pull system
  • allows to understand consuption rate (how much work in progress)
  • manages amount of work, flow of materials and understand when people work
  • left to right thinking not the way, donlt understand the problem when you start, usually do 80% of project in last 20% of time, kanban brings to the front
  • schedule from right to left, process goes left to right, fixed date and desire, requires innovative thinking
  • kanban is growing trend, challenges fundamental concepts (eg CSM training), has to be suited to the type of work

The Inter-Sprint Break

Simon Bristow from Acnoex delivered this presentation. The presentation is available here. My key takeaway were the many techniques used throughout the sprint and in the break.

  • Aconex – have a break between sprints
  • Scrum is unstopbbale momentum
  • a holiday or time to kick back – no!
  • 3 week sprints, sprint planning at start and demo at the end
  • start sprint on Tuesday and finish on Thursday – so 2 day break
  • benefits – teams were stressed and burning out but then got extra benefits
  • track at retrospectives the mood-o-meter and stress-o-meter – mood started high, dropped low throughout sprint and raised at end of sprint again and stress low but raises at end of sprint
  • team used to have 6 month releases, now they think 3 weeks is too long
  • asked team to draw pictures on how they thought sprint went
  • were looking for consistent level of mood and stress
  • distractions and flow – always other stuff during the day not related to doing sprint work, when you take somebody away from task there is waste as they ramp back up, made rule that meetings were moved into inter-sprint breaks such as management one on ones, brown bags still run at lunchtime because it is useful
  • collaboration – classic IT/business divide but also discipline silos (test, UI, middleware) – moved to a cross functional team, used scrums of scrums
  • in intersprint break – strategic planning, technical debt for discipline, information sharing, improvements in tools (changed toolset from JUnit to TestNG in two days and got immediate improvements)
  • paying down technical debt – argue that if technical debt is important it should be in our sprint backlog, but this only allowed them to focus on parts of the system they were changing and not the system as a whole
  • war on warnings – complier warnings
  • testivus – refactor or add new tests
  • QA deathmatch – find a bug get a point, fix a bug get a point and prizes for most points, fun activity and some competition, keeping the garden free of weeds
  • innovation – need time to breed creation
  • hackathon – like Atlassian Fedex day – can do anything with any technology for any purpose, demo something that can improve product or look at new tools, gets creative juices flowing, lets IT show the business we can tackle anything
  • extended to researcharama – like hackahton but not to produce prototype but present research to increase knowledge of teams
  • looking to do howhardi gras – answer question how hard would it be? response, take some of those questions to pick it up and have a crack at solving it
  • things you get for free – product reflection, think about team actions from retrospective, admin catchup
  • things to watch – don’t make it too long or sluggish to get back to sprint, activities for all, clear outcome and purpose, have a champion
  • during the sprint keep sustainable pace and don’t use intersprint break as excuse to leave things
  • sell to business – constant sprinting understood and can cause burn out, started with hackathon to demonstrate importance
  • draw a map of sprint to find major events (PC broken, etc), then get team to draw their mood on top
  • use a thumbs up, thumbs down, OK in standups
  • sprintometer – identify how we are travelling visually, get somebody to move this at the end of the sprint
  • called Gatorade Breaks elsewhere
  • have already determined the game team will play in the break, maybe should ask team what they want to play, been based on what has been going on in the organisation
  • have a tendency when sprints go bad to use break to catch up , champion needs to ensure that they get the activity done
  • transparent and business aware of release cycle and to use break for distractions, trying to hammer distractions and bad flow
  • prioritise BAU work in backlog, must talk to Scrum Master, for silo teams have to constantly remind managers that speaking to a team member affects productivity
  • all sprints synchronised, originally thought it was good idea to stagger for room bookings, etc, but all teams together ended up working much better

After The Consultants Leave

Adam Mostyn from BT Financial delivered this presentation. The slides are available here. It was interesting to hear the successes and failures in what I thought to be an environment that would not be receptive to agile.

  • Phew, go back to what we did before
  • started in 2006, not looking for agile but for bright people to attack a skills shortage
  • showcases worked well (especially beer and pizza to get people in!)
  • storywall worked well to see progress
  • user stories, standups both stuck
  • product owner did not stick – went back to old way of handing requirements over, showcases fell by wayside, sprints fell by the wayside because not ingrained in culture
  • did not have education and understanding what agile meant – business had thirst but projects started to fail
  • have resistance from business – need to convince it is a methodology that has rules
  • need to convince that agile is a journey and not a switch
  • ensuring that they have qualified Scrum Masters on every project team, otherwise will fall into same hole
  • trying to define the role of product owner
  • fun, so engages and empowers staff

Achieving Project Success With Agile

The session I presented, I think got a reasonable turnout for the last session of the conference on a Friday afternoon. The slides are available in a separate post, but are also available here.

Agile Open Space

I facilitated a session on agile technical issues (amongst 13 simultaneous discussions). We discussed TDD, automated testing, pair programming amongst other topics.

Agile Australia 2009 Day 1 Review

Agile Australia '09I must admit, I turned up to the inaugural Agile Australia conference with no idea what to expect, but a good range of Australian speakers (including myself!), keynote speakers and a healthy number of attendees, the conference exceeded my expectations.

There were a number of sessions I would have liked to attend that clashed with those I attended, such as Shane Hastie on Agile Transitions (presentation and video) and Julian Boot and Marina Chiovetti and their talk Show Me The Money Honey.

The sessions I attended on day 1 were as follows:

Panel – The Journey Towards The Agile Enterprise

This was the kickoff panel featuring Beverley Head (BH) (Journalist), Nigel Dalton (ND) (Lonely Planet), John Sullivan (JS) (Sensis) and Katy Rowett (KR) (Suncorp). My key takeaway was the acknowledgment that you need the right people (“the bus”) and the retaliation that the journey continues.

  • BH – agile is “in your face computing”
  • journey not for the faint hearted

Why did you begin on a journey to the agile enterprise?

  • ND – major event of waterfall failure, so much so the owners sold the company, could actually sell them on “anything but waterfall”
  • KR – Suncorp started with one mans vision as part of synergy savings of merger of Suncorp and Promina, needed to do something different in IT to meet the timelines
  • JS – changes taking to long to get into the market place

Productivity?

  • KR – has not been an easy road to success, still a way to go, social change in the way people are being asked to collaborate and work, productivity initially took a dip as they learnt a new way of working
  • JS – agile breaks the barriers, but the types of people you want to do this with are not the people that you started the journey with (essentially you are starting the  journey with the  wrong people on the bus), last time on a panel he controversially said “sack their arses”  but nicely that means  “move them to a different bus”, its all about moving people from punch in and punch out to giving people a career
  • ND – thank god for big banks and Sensis who took the people who were failing at Lonely Planet!, some people are not great at working in this environment

Business embracement?

  • JS – whole company has to go for the journey, from the person who organises desks to the people who put the walls up, didn’t follow the agile books and got IT into the business (not relying on people coming to them), need to understand the business
  • KR – relationship is crucial, luckily the relationship was already there as it allowed to take first step with blind faith, worked less well where this was not there, ramming agile word down their throat, need business to steer solution and IT will bring intellect to the table, when business see something they can make sense of they are along for the journey, prioritisation and politics an issue for a large organisation
  • ND – prediction – in two years time the theme of conference will be product management in an agile way, had huge failure with seagull product managers

Skunkworks approach to agile?

  • KR – not in Suncorp, was the way before Jeff Smith came along and then he tipped the boat over, Jeff Smith is a visionary who surrounds himself with people who have passion and energy
  • is agile a generational thing for the next age gap of CIO’s?
  • JS – in two years time we will be talking about how to do data warehousing in agile, the tools support doing web-based front-end applications very well, need to support back end process and get the developers to signup to the principles and practices such as automated testing

Legacy?

  • KR – agile is whole of system approach, Suncorp has lots of legacy, extends to mainframe, web and product support and maintenance

There were then some questions for the panel.

Introverts vs extroverts, we would like to bring as many people on the bus, how do you bring the introverts along?

  • ND – as an introvert, have learnt one or two practices to move from introvert to a mile-high extrovert, introduced “the red button” to identify issues, agile is a massive opportunity to learn IT and networking skills and has flattened the team out so everybody gets their say, more respect than traditional teams
  • KR – there is always something that motivates somebody or pushes their buttons, this is contagious in agile teams, in the Melbourne office you could originally hear a pin drop but now you can’t hear yourself talk

Jim Highsmith says you get the customer happier, faster?

  • JS – under promise and over deliver, builds trust
  • KR – business wanted a Lamborghini but as the system was being built they were happy with the Commodore, then really happy when they got the extra feature!

What do you do with skilled developers who do not want to fit the mould?

  • JS – building a team, these people are disruptive to the team, you end up getting rid of them anyway, have to identify that while these people are brilliant they are counter-productive, spend way too much effort trying to harness it or find them something in the skunkworks
  • ND – have tried to put them on a spike, but in the end you still wish you could have paired so other people know what is going on, agile is doing extraordinary things with ordinary people

Finally, the wrap up!

How long does it take?

  • KR – joruney never stops, Suncorp has been doing it for 2 years, have a baseline of success and failures (which are deemed as successes), currently assessing where we are and how we can be better
  • ND – two years with BBC ownership who are big on agile, as they have matured the have realised it is a learning, how you learn is the killer outcome of agile
  • JS – three years, originally got up and running in 8 weeks after throwing a big bucket of money at it (rather than taking the journey), went from 12 people to 60 people in a 4 week window

What has it done for the business?

  • ND – for R&D, who believes that the agile cult is the barrier to high speed innovation, his response is prove it
  • KR – Suncorps new CEO Patrick Snowball said BT is our biggest asset and our goldmine
  • JS – it’s bloody expensive!

Keynote – 12 Agile Adoption Failure Modes

Jean Tabaka (from Rally Software and author of Collaboration Explained) delivered the keynote, the slides are available here.

  • roadblocks to agile success – think about growth, business wants results straight away, but we don’t pay attention on what it takes to do it, hence we get failure

Benefits you’ll derive:

  • stop denial that waterfall is actually delivering
  • put on reality goggles – this is the truth of it and agile will help us get there
  • seek out insight pools, will allow more collaboration
  • create your own reality – core value at Rally, can help individuals which then moves throughout the organisation
  • all of these together deliver customer value

Checkbook commitment failures:

  • CEO/CIO level, have a problem and agile will solve it
  • unengaged – “just do it”
  • looking for immediate results
  • have not commited to organisational change that is required
  • same metrics – everybody still reporting the same way up and down, continues the illusion that software development is deterministic

Culture that does not support change failures:

  • everybody expected to follow a plan, how well are we doing on a plan we created a year ago?
  • they enforce standard of work to ensure we get to the plan (governance = conformance), standard of work static, everybody works the same way
  • success mode to ask each team what the best practices are rather than declaring them up front
  • belief that more documentation will enforce standard of work – need to create knowledge creating companies, rather than declare standards across the organisation, tacit knowledge creates implict knowledge which in turn creates tacit knowledge
  • PMO as enforcer in failure mode, should act as broker for knowledge

Ineffective use of retrospectives failure:

  • what are we doing well, what’s not serving us as a team, what can we change to improve?
  • if you want to fail, don’t do any at all
  • retrospectives ignored, team gives lots of ideas but facilitator explains why none of them are correct
  • no action on retrospectives

Ignore needed infrastructure failure:

Lack of full planning participation failure:

  • act collaborative and want insights, but save money and get a few people to do it who are well meaning – means teams are not committed to tasks and estimates – how can we march to the plan?
  • waiting for decisions – waste – if we do not have the  right people in room we cannot make decisions in an expedient amount of time, lean is about eliminating waste
  • osmotic conversation – creates better commitments and better plans which means better insights – learn from all of the skillsets about how we can measure ourselves against the plan
  • commitment – have run planning sessions with 100 people, a 2 day event, people thanked at the end for being involved

Unavailable product owner failure:

  • not available when trying to go faster
  • too many product owners
  • agile asks a lot of product owners – usually they are too busy to do the communicating, will suggest that agile is too hard to get engaged in
  • need them engaged to agree on priorities
  • when they are engaged they are commiting with the team, want product owner at standup asking where are we with the commitment and how can I help?

Bad scrum masters failure:

  • want somebody facilitative, not dictatorial playing the scrum master, does not need to be a master of the domain but a master of the process
  • do not have role of command and control – hard for existing project managers
  • command and control lowers morale and lowers IQ – when kids ask you what you did at work today, tell them you lowered peoples IQ’s!
  • serve and facilitate rather than command and control – need to be Superman and help you raise your IQ
  • need someone who serves and facilitates and removes impediments – cleans up mess, is committed to help team meet their commitments

Not having an onsite envangelist failure:

  • if distributed, need one in each location, otherwise team do not believe anybody cares about them, this leads to remote roadkill (on your own and if you get run over by a truck that is your problem)
  • can’t reap the benefits if you leave them on their own
  • need to advise, motivate, protect and serve – bring in their insights rather than pushing insights on them, help them be successful

Team lacking authority failure:

  • don’t empower team and leave them to deal with the red tape (difference between Toyota in Japan to the USA, western culture less successful at empowering teams)
  • TED TalksBirth of the Computer, Motivations
  • motivation – understand how teams work, takes work to be a high peforming team (first form the team, invite conflict into the team, converge insights, then you hopefully get a norming team who just get things done)
  • empowered team amplify learnings – individuals to organisation and back again
  • inspect and adapt to get better at delivering – high performing can speed up and continue to deliver

Testing not pulled forward failure:

  • do not invest in infrastructure, do not believe necessary, do not have the appetite (do testing in subsequent iterations or do one iteration for planning, one for code and one for testing)
  • need to look at capacity utilisation, agile optimises the process, some people think it looks like wasted utilisation but what we do is create more defects when we are pushed to 100% capacity
  • piled up technical debt if coders coding at 100% capacity in an iteration, slows down ability to deliver
  • need to stop the line, don’t emphasise 100% capacity but emphasise quality (when you find a defect stop), Toyota showed this at a GM plant, fired everybody then hired them back by changing the measurement of success from number of cars to the defect level, first day made 2 cars! but ended up doubling the output of the plan

Managers yearly expectations failure:

  • eliminate performance appraisals – get in the way, evaluate teams working together, do not reward individual heroics
  • teams evaluate each other, called 360’s at Rally
  • how did you bring level of skillet of this team up? – reward team contribution

Reverting to form failure:

The wrap up:

  • call to action – pick one of these, hold a self retrospective in 30 days
  • when do you give up? – if teams not getting there after 6 months, Mike Cohn will just say “you can’t do agile so just give up” – after 6 months look at failure modes and run a retrospective, need to be prepared for a 2 year journey up the organisation to scale and mature
  • ensure balance of tech lead and scrum master – hired to be the brightest guy on the team, need to decide that you want to get smarter by increasing the IQ of the room, move from how smart I am vs look how smart team the is – see Good To Great (Level 5 leader takes ego and turns it to look how good team is)

7 Habits Of Highly Effective Agile Developers

Steve Hayes presented this talk, the slides are available here. My key takeaway was the idea of the emotional bank account (and the build story!).

  • management may not be natural but leadership is – need to engender trust and faith
  • talk based on Stephen Covey – 7 Habits of Highly Effective People
  • be proactive – take responsibility for own life, don’t lay blame, many organisations use reactive language (eg. I have to do this), proactive people trying to increase circle of influence
  • begin with the end in mind – need vision on what you are trying to achieve before you can achieve it, create your own mission statement (personally and organisationally), does my mission statement match my teams mission statement (am I in the right place?)
  • put first things first – urgent and important, most underused word in professional life is no (what would you like me to not do?), delegate (go’fer delegation and stewardship delegation), self management and self supervision is hard but agile demands it to work effectively
  • emotional bank account – make deposits and withdrawals, too many withdrawals and you will go into overdraft, understand the individual, meet commitments, make apologies for withdrawals, etc..
  • if you aim for win/win, you need to be prepared to walk away if you cannot win
  • seek first to understand, then to be understood – Indian talking stick (don’t give up the stick until you feel you have been understood, understood if people can repeat your position and you can answer yes), use your opposition as input to your position or as an option you have not considered
  • sharpening the saw – need time to recover production capability

Finally, Steve told the story about standing on the desk and shouting at the developers at Lonely Planet about the red build light, which was a great story and repeated throughout the conference. The only reason he could do this was because he had the build credit in the account first.

People Driven Agile Transformation

John Sullivan from Sensis delivered this talk, the slides are available here. My key takeaway was the acknowledgement of the importance of people and technology in a successful agile rollout.

  • started in May 2006, hand picked a new team and formed a company (Majitek), then rolled out across 80-150 people across Sensis
  • have developers that are really good architects that can cut code
  • agile manifesto – it’s all about people not about the methodology, the agile luminaries would have definitely prioritised the list
  • assess thresholds – organisational change – will always be thwarted, companies focussed on a threat will not have the appetite as you need people to learn new things, tried to introduce pair programming at a bank but the union thwarted it because everybody needed a corner desk, etc…, currently at Sensis have a big battle about where to put story cards (because board members walk passed and thought they looked unslightly)
  • assess thresholds – people change – too many people in IT punch in and punch out, can change people but it takes time that most companies can’t stomach, might need to move people out, want to challenge people to do better tomorrow, most people don’t want to learn something new because it makes them anxious
  • assess threholds – technology change – change the architecture to get people interested (eg. introduced Ruby On Rails to give an option to hire interesting and good people)
  • movements need committed people – need to get people on the bus, where are you today and where do you need to go and why, ask people to write down what they would like to be as an industry luminary, need to make people understand why we need to do this, once you have buy in you need to action very quickly and slam people with actions
  • technology – most agile teams favour XP practices (they are common sense), use the threshold to decide what tools to use (Ruby on Rails is all hype, get professionals to pair, throttle back on some of the cutting edge technologies that consultancies try to sell you on), simplified architecture (rule that all applications had to go onto an application server – why??)
  • lease the process before you own it – get the right team of experts in to establish experts, learn from them and get them out as soon as possible
  • build relationships – IT people like screens, go to the business, don’t make them come to you, talk to them in their language
  • can trust an agile advocate as much as you can trust a real estate salesman – need to learn from failures, build trust, IT willing to sell success but mask failure, Dr. Jeckyll and Mr Hyde (front up whether good or bad), take the how out of estimates, just write down what outcome you want to achieve and how much it will cost, agile can be overstated (does not make risks disappear but it highlights them and lets you fix them), you could do an agile and waterfall project in the same time (you will just get the features you want to Production sooner), physically more expensive to do agile but the outcome is better
  • don’t care about process, need the right people to do the right job
  • agile does not sit well with people who want to coast – Sensis is competing with Google!, it is not a job it’s a career, most organisations are setup incorrectly
  • want master craftsman, inspire people to do better every day
  • worked out ways of influencing change, could not change everything so worked out ways to work around the roadblocks
  • don’t use term agile anymore, originally was a fascinator, now it is all about self improve

Taking The Leap Of Faith

Mike Allen from Racing and Wagering Western Australia (RWWA) gave this talk, slides are available here. My key takeaway was the sotry about how their investment in agile allowed them to replace 15 year old legacy totaliser machines in 5 iterations.

  • RWWA – mainframe shop – hard to get developers, licencing costs high, time to market too long
  • educate on agile – had to dispell myths – no design (do it all the time, more than waterfall, every iteration), no planning (plan everyday)
  • establish a tempo – 3-6 month releases, have showcase at the end of release
  • plan at the right level – has a Gantt chart, can tell you that on 15 March next year that developer “James” will be doing development, which is all you need to know!
  • hire the right people – biggest secret to agile success, need open people, want to be challenged, not possessive or obsessive about code, cap the hours at 40 hours per week, have external activities, most people at RWWA contractors, agile is infectious
  • create the right environment – spent $175K and ripped the existing building infrastructure apart, smaller desks, greater density, lots of wall space (hide nothing, transparent about everything)
  • start producing software – start to see functionality grow week by week the way the customer wants
  • Mike’s Balls – variant of a burn down chart – demonstrate scope vs progression, different colours for different teams, can see where progess is being made
  • don’t fight everyone – big organisations sometimes want to use tools that cost lots of money
  • deliver high quality software – quality should be immutable, zero defects (means for the time we spend testing the system we will fix those bugs), replaced 15 year software at TAB in 10 weeks (5 iterations), RWAA have been good at giving the customer and empowering them to make decisions
  • produce good documentation – produce right at the end, a DVD player comes with technical guide and technical specifications, written at the end, long running documentation should be produced at the end, tossing the requirements out after the project is done is still a battle
  • have some fun too – a good agile project should be about fun

Some questions at the end:

  • scope, how much will it cost? – captured a card for each functional area (too high to estimate), then broke down to smaller cards and got development estimates in developer days, then add up and apply a sophisticated formula (multiple by 2 to allow for testing and BA resources!)

Better Software Faster

Michael Milewski from Realestate.com.au delivered this talk, the slides are available here. My key takeaway was the change of technology to attract quality people.

  • originally a LAMP stack with Perl
  • requirements hell – high cyclomatic complexity, tool 9 months to choose a colour picker!
  • top down approval for agile rollout plus bottom up readiness
  • pair programming – did coding dojo (tight time frame 6 minutes per pair at 1 station), learn new skills
  • Perl to Ruby and vi to IDE – Ruby has more buzz which attracts better people and energizes people
  • BDD – Business Analysts and Test Analysts own the stories in this way, CI (confident it works), BA’s understand the behaviour
  • iterative development – transparency when running a showcase
  • track progress – with pen and paper, can walk up and see what is going on
  • retrospectives – small issues are visible, clears the air
  • project delivered, happy business, strategic success to core website
  • failures – one big release (not small releases), when iterations have failed (hard to celebrate, but have to realise you have failed fast), still trying to determine how to deal with product management (still fall back to waterfall practices)

Atlassian VIP Tour

I skipped the last two sessions to take the opportunity to tour the Atlassian offices with Nick Muldoon and JC Huet. The work environment was incredibly impressive and it was great to talk to some of the developers of Jira directly and its future along with GreenHopper sounds exciting.  Oh yeah, they’re hiring as well!

ThoughtWorks Open Office

Buffet

Most of the conference headed on over to the ThoughtWorks Sydney office for drinks and conversation. Plus myself, Rene Maslen, Tammy White and James Couzens won the agile trivia competition!

Brisbane Scrum User Group: Agile Tool Hacking – Taking Your Agile Development To The Next Level

Brisbane Scrum User GroupI volunteered to give the Agile Tool Hacking talk from Agile 2009 to the Brisbane Scrum User Group. The slides are available on SlideShare. I also understand there may have been videoed but have not seen it posted anywhere at this stage.

Feedback from some of the attendees was very positive, thanks everybody for your kind comments!

  • “ A fantastic talk by Craig Smith of Suncorp, and a great bunch of guys. ”
  • “ Great session on the subject and very comprehensive ”
  • “ It was a good talk, giving people a range of different tools and understanding of what goes to make up good practice. Obviously it had to be quick and Craig managed to fit this in as best he could. Would love to have a retro on this talk at the next meet ”
  • “ The presentation was excellent. It was useful for ones with minimal knowledge on Scrum or Agile or the Scrum Masters. ”
  • “Craig offered a great deal of useful information – Excellent speaker ”

Agile 2009: Agile Tool Hacking – Taking Your Agile Development Tools To The Next Level

I'm speaking at Agile 2009

I’m speaking at Agile 2009

The presentation by myself and Paul King from Agile 2009 called “Agile Tool Hacking – Taking Your Agile Development Tools To The Next Level” is available on SlideShare.

Agile 2009 Day 4 Review

Agile 2009The last main day of talks at Agile 2009, and once again lost the morning to preparation and presenting a talk with Paul King.

Here is an overview of the sessions I got to:

Agile Tool Hacking – Taking Your Agile Development Tools To The Next Level

The session I presented with Paul King, we got close to a full house and the session feedback forms were overwhelmingly positive. The slides are available in a separate post.

P1000086
P1000089

The Kanban Game

A full house to this session run by Tsutomu Yasui gives some validation to the fact that Kanban is gaining traction with the agile community. All the details and materials for the game are available at http://www.yattom.jp/trac/public/wiki/ProjectGames/TheKanbanGameEn. I only sat in on the first half of the session so I could fit in some other last minute talks.

Agile 2009 Kanban Game

Agile User Experience Design Emergent Practices

I had an aim to get to at least one talk by Jeff Patton (especially for bragging rights for one of my work colleagues, Teale Shapcott)! I actually got to have a brief conversation with Jeff later in the evening which was awesome.

Agile 2009 Jeff Patton

  • adapting to agile difficult for UX practitioners – Jeff Patton came late to usability but early to agile usability
  • five stages to agile adoption (salesforce.com) anger, denial ,bargaining, depression, acceptance

Homonyms

  • design – agile (how to build product), designer (what to build based on user needs)
  • iteration – agile (short time box to build software), usability (builf representation of product idea for evaluation and change)
  • story – agile (short description of what user might want built), usability (agile design for goal)
  • customer – agile (someone who writes a user story), usability (a person who buys a product)
  • small bit of software – agile (developer can build in a few days), usability (something a user can complete is a single sitting)
  • test – agile (means complete and meets acceptance criteria), usability (user can use the software and it meets their needs)

Then:

  • usability practitioners view of design and development – understand business need, understand user need, personas, create and validate high level design, create and validate UI design, create and communicate design specification, develop software, usability test finished product
  • you could do all that for a sprint right? – agile changes usability practice but does not have to threaten it
  • patterns have emerged as usability practitioners have adapted – had to go postal or figure it out – great idea is not a pattern, great idea that multiple people use is a pattern (at least 3 companies)

The emerging best practices are:

  1. usability designers are part of product owner or customer team – in drivers seat, part of the planning, part of product owner team or the product owner. Product owners already take multiple roles, product owners are thinking about this release and the next release
  2. research, model, design up front (but only just enough) – learnt how to cut up work, high level design but just enough, task model (but agile people think they are stories), usability people need to be connected to backlog, own and leverage it
  3. chunk your design work – break up design work to perform incrementally throughout development, organise story into a map that helps communicate structure of the system (see The new user story backlog is a map on Jeff’s blog), organise the backlog (don’t just prioritise – communicate with user about what we are seeing)
  4. parallel track development to work ahead and follow behind (see Lynn Miller – Case Study of Customer Input for a Successful Product on agileproductdesign.com) – time machine essential for product owner and usability team, design and coded features pass back and forth between tracks (design ahead, look at stuff already built and stuff that is being built now)
  5. buy design time with complex engineering stories – product owners responsible for scheduling, sometimes highest value is to put a story that is easy to design but hard for developers to build to buy time! (Lynn Miller talks about SketchUp File – Save As as easy to design but took ages for developers to develop)
  6. cultivate pool of users for continuous user validation – (see Heather Williams – The UCD Perscpective on agileproductdesign.com), Salesforce have a person that coordinates this, keep feedback fresh by rotating every few months
  7. schedule continuous user research in a separate track from development – Kitchen Stories a silly Swedish movie has usability connotations, research is continuous, not just a phase, schedule visits with users ahead of how we know why we want to be there
  8. leverage time with users for multiple activities – do some usser interviewing, do prototyping, show and review current software (one mand band), use RITE to iterative UI (rapid iterative testing and evaluation) (see numerous RITE articles on agileproductdesign.com), use time before sprint to refine design, test something and fix it to burn down failures
  9. prototype in low fidelity – prototype in public so people can see what you are doing, look at Balsamiq as a tool
  10. treat prototype as a specification – have a discussion
  11. designer developers iterate design outside development iteration  (eg. CSS, HTML and visual design), “art is never finished, only abandoned”  (Da Vinci)
  12. become a design facilitator – designers do collaboration and facilitation, practices like design studio and sketchboard technique to get developers involved, sick of developers armchairing their design (get them to sketch it out, developers get to weigh in good ideas, developers get their design ripped apart, usability people get people to read their designs)

Finally, most usability designers won’t go back after doing agile!

Agile By The Numbers: What People Are Really Doing In Practice

I was keen to go and see Scott Amber speak, you can view the session or view the data. According to Scott, this is what people are doing in practice and this talk is exploring some myths.

Agile 2009 Scott Ambler

Majority of organisations doing agile?

Majority of teams doing agile?

  • in 76% of organisations, 44% of project teams doing agile
  • BUSTED
  • numbers claiming to be doing agile, can’t test this theory, expect number is high
  • how do you measure agile?

Pretty much all development in agile?

  • agile practices that most effective – CI (65%), daily standup (47%), TDD, (47%) iteration plan, refactoring, retrospectives, pair programming, stakeholder participation, shippable software, bundown tracking
  • practices that want to adapt – almpot all technical – acceptance and developer TDD at top of list
  • PLAUSIBLE

Agile is just for small teams?

  • 1-5 and 6-10 success, starts to taper off for teams 11 and up, but success at all sizes of teams
  • BUSTED

Does not apply to regulatory situations?

  • 33% need to apply to legislation
  • BUSTED

Agile and CMMI don’t work together?

  • yes 9%, only small amount of people doing it
  • no statistical differenece between CMMI and non-CMMI agile projects
  • BUSTED

Agile process empirical?

  • teams collect and act on metrics, 51% collect but do it manually (according to Scott Ambler, don’t trust manual metrics as they are behind and altered to tell a better story and meet bureaucracy), 26% no and 19% majority automated
  • CONFIRMED

Agile teams doing greenfield development?

Becoming a Certified Scrum Master is a good idea (2 days)?

  • 78% think certification is meaningless
  • nobody respects this, shame on certification trainers, better way to earn a living, step up, 2 days on a business card is not a good idea, preach less and act more
  • BUSTED
  • Ambler certified for a good laugh

Most agile teams are co-located?

  • 42% co-located – good thing, reduces risks, 17% same building, 13% driving distance, 29% very distant
  • a third of teams have geographic sistribution issues
  • BUSTED, majority of teams distributed in some way

Agile teams don’t provide up front estimates?

  • majority of teams do up front estimates
  • need estimate to tell senior management to get project off the ground
  • 36% reasonable guess by experienced person
  • BUSTED

Agile teams just start coding

  • on average takes almost 4 weeks to warm up – modeling, set up environment, design, …
  • BUSTED

Agile follows common development guidelines?

  • practice in XP
  • 49% project / enterprise conventions (19% enterprise level conventions)
  • 22% UI convention, 25% data conventions, expect lower than development because not as cool as code
  • PLAUSIBLE (but borderlne) – room for improvement

Rights and responsibilites are part of agile culture?

  • 58% defined for development team vs 35% for stakeholders
  • PLAUSIBLE

Agile test often and test early?

  • developer TDD 71%, 52% still doing reviews / inspections, 45% end of lifecycle testing, acceptance TDD 40%, one third of teams have independent team who look at system independently
  • CONFIRMED – doing testing throughout lifecycle

Agile don’t do up front requirements modelling?

  • 76% do this, need to come up with stack of cards now
  • 52% capture in word processor, 45% capture as tests
  • BUSTED

Agile don’t do upfront architecture?

  • 70% high level architecture modeling
  • metaphor is a total waste of time
  • organising a conference is just like organising a conference…
  • BUSTED

Agile write interim documentation?

  • 56% yes
  • CONFIRMED

Agile produce supporting documentation?

  • 70% write these, minimal amount of stuff that need to be developed
  • CONFIRMED
  • sometimes when compared, agile write more

Agile works better than traditional?

  • hell yes!
  • all approaches reasonably close 65% vs 80%
  • quality much better
  • functionality delivered higher
  • make money – good, but hacking better off
  • time much better
  • so similar, but better way to spend money wisely
  • CONFIRMED

Finally:

Open Space – Scrum Is Evil…

Jeff Frederick ran his Scrum Is Evil session that I had first seen at CITCON in Brisbane earlier in the year. It was interesting to see that the outcomes were exactly the same half way around the world!

Agile 2009 Scrum Is Evil

Conference Banquet & Keynote User Interface Engineering

It’s very hard to take notes in a banquet with the lights dimmed, but Jared M. Spool gave a very entertaining keynote on User Interface Engineering, including some iPod vs Zune bashing and an old Apple video on future design.

Here is another post I found from this session: http://www.agilitrix.com/2009/09/user-interface-engineering-agile-2009-banquet/

The night was finished off with a Chicago Blues band and some conversation late into the night at the hotel bar!

Agile 2009 Day 3 Review

Agile 2009One of the problems of presenting a double session at Agile 2009 is that miss out on a bunch of the great talks that are going on at the conference at the same time. Added to that, the (very) last minute preparations that I was doing with Paul King meant that I only got to sit in on one session (apart from our own).

Automated Deployment with Maven & Friends – Going The Whole Nine Yards

This was a good overview by John Smart of using Maven as a build tool as well as how you might use tools such as Cargo and Liquibase and scripting languages like Groovy to automate your deployment process. I was hoping John would have the silver bullet to linking the Jira release button to a deployment script, however it appears the only way of doing this still is via a plugin for Bamboo.

How To Make Your Testing More Groovy

The session I presented with Paul King, we got a reasonable turnout for a technical double session and the session feedback forms were overwhelmingly positive. The slides are available in a separate post.

Agile 2009 Groovy Testing Paul King
Agile 2009 Groovy Testing Craig Smith

Dinner with Manning & John Hancock

I had the pleasure of having dinner with Todd Green from Manning, Greg Smith (co-author of Becoming Agile) and Paul King (co-author of Groovy In Action). As the technical proof-reader for Becoming Agile and knowing Paul King, I also got an invite for traditional deep-dish Chicago pizza.

Afterwards, Paul and I treked up the “Magnificent Mile” and up 95 floors to the Signature Room in the John Hancock Center (Chicago’s fourth tallest building but best observation deck according to the locals). The views were amazing (the pictures don’t do justice to the city lights that carry on into the distance!)

Chicago John Hancock Signature Room