stop doing stuff that does not deliver value, not laying people off
spend time doing the right stuff, not the wrong stuff
think systems, not software – Southwest think employees, customers and then shareholders
optimise the whole system (software is just a layer) – Amazon is structured around it services (2 pizza teams of 8-10 people)
a separate testing team is silly – just handoff / afterthought, need to build quality into your product
need to understand value before you deliver value – understand what your customers value, not what they want and build the right thing before building the thing right
setting up a new product is a set of learning loops
watch for what is making people uncomfortable
understand your customers not by bringing an idea but by taking the team to understand the problem
there is always demand in a service company – fix issues as fast as possible, but that is not the game
consumability – how much effort does the customer need to go through to get value?
customers decide value… and therefore decide waste
measure productivity on value delivered, not features
work in progress is waste – customers are not interested in your long list of things to do
good Agile teams have a low number of defects
map end-to-end flow to find the biggest opportunity in your end-to-end process
40-90% of the cost is maintenance not delivery, the cost of quality is way higher than the cost of building quality in, don’t put defects on a list (track them, fix them immediately), root cause every escaped defect, determine why every one happened
problem with readable specifications is that the text is not refactorable – any text page will have hundreds of ambiguities
every organisation that calls itself professional should be doing TDD
expertise takes 10 years / 10,000 hours of deliberate practice, need a teacher to challenge, feedback and dedication (The Road to Excellence)
marketing leader – for a successful product you should be able to name this person
technical leader – keep two top engineers free to roam around and give guidance
Empire State Building – on time and under budget, had to manage the flow of materials not tasks, had two alternating mills to keep up schedule and remove failure point
people who have dome something before should know how to deliver within the constraints
when managing an organisation you need to manage the capacity, you need to have a stable flow
kanban – reduce work in progress to expose problems (don’t crash your boat on the first day, keep your limits high then lower your limits and remove your problems one at a time
kanban board – every column is handover to the next column, the next column (downstream process) gets to define done
5 why’s – the cause of the cause of the cause of the cause…, The Team Handbook has good process improvement practices, as do the Six Sigma tools
product-centric development – 54% of Fortune 500 companies are heading in this direction
Here is a picture of an exercise we did to map the cycle time of a particular company (it highlighted some of the issues they are having around approvals).
Finally, a huge thank you to Nick Muldoon from Atlassian who helped me out with a space on this course. Also to one of my colleagues who reminded me that we should ask forgiveness not permission when I was dealing with some competing priorities!
As a precursor to the Agile Australia 2012 conference to be held in Melbourne, a product afternoon was held at the Hilton on the Park in Melbourne in November and had a good variety of Australian speakers. The success of the event means a similar event is being schedule for Sydney in February 2012. Here are my notes from the event:
Look What Happened When We Let Customers into the Product Development Loop at Lonely Planet!
need to avoid the next bench design problem – only ask the person on the next bench about quality, do not go to the wider world
for Lonely Planet, realisation was a competitor in the market who produced a colour guide, no sales the month they launched
went to customers 4 times in the process, took publishing from 2 years to 9 months, visualise the project
Rob Adams talks about getting the developers to do some of the initial marketing calls
Marketing is from Venus, IT is from Mars – and the Customer Doesn’t Care
Daniel Oertli from REA Group led this discussion that he hastily renamed to “5 Kick Ass Principles for Customer-led Development”, his slides are available here.
effect of marketing has changed over the last 5-10 years, we no longer control the marketing channel, need customer admiration
be a peeping Tom. Regularly – there is only one customer, the people who pay for products, none of this internal customer bull####, hard to put your business on the road regularly to talk to customers
5 on Friday – Silverback on Mac, 5 internal employees for 15 minutes and ask them to do specific tasks with your product (eg. show me how to change the default colour scheme), continue to do this every Friday as parts of the product are developed
don’t ask for the solution – to get creative you need to figure it out internally, great people create great things
day and half every quarter – hack day – off tools, schedule around it, put ideas on intranet and vote, teams form around the idea self-forming, winning team gets a cash prize and gets sponsored product into production
2 week inception process – use business canvas mapping to lay out the business drivers
democratize design – hard to get excited about something if you have not been part of the design, get everybody to draw
ready, fire, aim – Agile gives us opportunity to change things in motion but most organisations still execute iteratively what is planned up front, Agile gives you a bullet frequently, be very clear about your minimal marketable features, be ruthless about what you send to your Agile teams, you have a lot of go’s at this
teams win – good people outperform any processes, keep teams very small (6-8 people), have a mix of business fundamental understanding, lead designer and lead technologist and there for skills not core decision making, trust is essential
dealing with resistance – hardest change of all was getting business on the journey, need to get culture sorted and get teams focussed
more of what people do is outside of their hierarchy, biggest impact is dynamic thinking by thinking of type of things we will do rather than what we will do
public companies need a plan to show to shareholders, challenge is to make it more dynamic after that
engage people in their career progression – still report to a lead, but 90% of the time they live with their cross functional team – more about stretching their knowledge in their domain so have practice meetings
SEEK’s Approach to Product Innovation
Doug Blue from SEEK presented this session, his slides are available here.
put customers before profits – no display advertising on the front pages, founder would prefer to have a dollar tomorrow rather than a dollar today
build for the long term – customer core needs, competitive advantage, long term trends and shareholder value, in GFC let customers negotiate out of long term contracts
strive for a rock solid core and out innovate the competition – focussed on number of ads and size of audience, now need to focus on the product
focus – do a few things very well, carried this over to the iPhone app as well, but run business on the things that are do-able
people engagement – never compromise on engagement
data driven decisions – if we build or change something, we measure it
test and learn – put it out in market and do course correction
balancing customer needs – 3 different customers with different needs (job seeker, employer, recruiters) – came up with an invisible salary to balance the needs
on bigger initiatives, need to do your homework
A Start-up Approach to Product Delivery in a Corporate Environment
XP Explained lacked an explanation on how to communicate effectively with customers to understand what they wanted to achieve
base costs on optimum team sizes that can manage constant delivery of a number of system concerns
have no process, when problems occur, take those problems away
don’t use iterations, they constrain the customer, need to be able pick up any card and get it into Production
ideas wall – backlog for where the business is going, anyone can post ideas on it
don’t talk about what the product we are delivering should do, talk about what the business should do
challenge everything – stand ups are almost useless in large organisations – only say things what people in the circle need to know about, because they work together, so they should know
most people in large organisations are disempowered – how do I know I am doing the right thing? Just do it, everyone is the business
need to help everyone understand the market – understand what the impact of features are
whole of company showcases every Friday
need multi disciplined teams that understand the market they are striving for
Panel: Why is Customer-led Product Development so Hard?
Keith Dodds from ThoughtWorks led this panel with all of the above speakers. Some of the key learnings were:
if you have leaders that are customer focussed, everything else will follow
most organisations try to make the workforce effective and efficient by putting structures around them, need to retain a functionalised structure and stay away from specialisation
companies are introverted because traditionally they have not had access to customers
it’s hard to keep up with all of the tools out there – there is lots technology to seek out what the customers are viewing
most products are designed to be obsolete within 1-2 years, especially those that are consumer focussed
companies are not set up to evolve things, they are setup to build, the world has changed where everything is outdated the minute you deploy
grass roots movements are usually the most enduring
most companies lack the balls to shut things down when they need to
frugal innovation – constraints help you channel great ideas, would be interesting to apply some artificial constraints to hack days
what doesn’t work are artificial constraints and the team know it
next C level job will be the chief designer – targeting the customer
Agile helps to get a customer led product out, because the person who wants the product can talk to the person who builds the product
report on value delivered to the business rather than velocity
the pool of talent is not that big, how do you keep people motivated – sense of purpose, sense of meaning (problems that have currency in the real world), ability to react and shape, ability to be heard, about making a difference
where do great Product Managers come from, how do we develop and train these people
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.
Within this podcast we learn what exactly a Lean Start-up is and how it isn’t just for new entrepreneurs.
In addition to the Lean Start-up presentation Josh also did a fantastic presentation on the Limited Red Society which focuses on using metrics and visualisation of these to behaviourally change a developer so that their tests pass sooner and more often with less compilation errors.
Other than being an early pioneer in eXtreme Programming, he is also the author of the best-selling Refactoring to Patterns book and provides Agile training from an amazing technical depth of experience.
With Tony on assignment on an island, Craig and Renee talk about motivation, Renee makes a ballsy prediction about fun and we talk about dead walls, tools for walls and everything in between:
Craig, Tony and Renee get together before the Christmas and New Years break to catch up on all things Agile:
Craig Smith 
You must be logged in to post a comment.