Episode 187: Domain Driven Yak Symmathesy with Jessica Kerr

The Agile Revolution Podcast

 

Tony and Craig are at YOW! Conference in Brisbane and chat to Jessica Kerr, software developer, consultant and symmathecist (look it up or listen to the podcast) and apart from our first live podcast sneeze they talk about:

 
  • YOW! 2018 keynote “The Origins of Opera and the Future of Programming
  • YOW! 2018 talk “Shaving the Golden Yak
  • Great teams make great people – if you want to become great as a developer, focus on the team
  • You can’t document what is obvious to you – whenever you say the word obviously, replace it with “I cant explain it, but…”
  • Yak shaving – all the tasks that you do that get in the way of your work
  • If you are an agile person but you wish agile had more code in it – go to the Domain Driven Design community
  • We need to embrace complexity…

View original post 34 more words

Episode 161: State of Agile in Singapore with Stanly Lau

The Agile Revolution Podcast

Craig is at YOW! Singapore and catches up with Stanly Lau, organiser of the Agile Singapore conference and the Agile Singapore meetup:

  • Bas Vodde was one of the early advocates for Agile in Singapore
  • The state of Agile in Singapore has progressed from “doing a standup” in 2010 to now many companies thinking about how they develop software better
  • A lack of knowledge in design principles by new software developers seems to affect how they tackle problems
  • The art of being able to sit down and pair in a team is an art that is being lost in the Agile community
  • You can learn a lot about a team by looking at their codebase
  • Good agile development practices require know-how and habit – does not come by nature

TheAgileRevolution-161 (26 minutes)

View original post

Geoff Wilson and Amanda Stockwell on Agile Agencies and UX

InfoQGeoff Wilson and Amanda Stockwell from 352 Inc talk about the advantages of Agile in a digital agency, approaches to user experience and the redevelopment of planningpoker.com.

Geoff-Amanda-largeSource: Geoff Wilson and Amanda Stockwell on Agile Agencies and UX

Agile Australia 2012 Day 2 Review

Day 2 of Agile Australia 2012, and another busy day of MC’ing and attending sessions.

The first (hastily rescheduled) keynote session was from Roy Singham from ThoughtWorks.

From Agile Australia 2012

The second keynote was supposed to be Mark “Bomber” Thompson from the Essendon Football Club but he was an unexplained no show. After an impromptu thankyou speech from me and breaking the conference for an early break, James Hird arrived to substitute and did an impromptu talk. As a result of the scheduling changes, I unfortunately did not get to see much of either session.

From Agile Australia 2012

How Lonely Planet Used Agile With SAP and Delighted Customers

I sat in the back of this session delivered by Ed Cortis from Lonely Planet. His slides are available here.

From Agile Australia 2012
  • failed, needed twice as many people after implementation
  • ran net promoter scores internally, -40!
  • attempted Agile customer management – planning meetings took 3 hours, attendance dropped, SAP team became prioritisers
  • NPS dropped to about -35
  • changed team structure and in-sourced, positive NPS
  • got agile working – 4 week sprint, 40 minunte presentation, stakeholders turn up because if you are not there you don’t get prioritised
  • developed a prioritisation matrix – business value versus effort, colour coded cards for skillset, sets order for prioritisation
  • pre work is required for the meeting – know how many points of effort for every available person
  • prioritisation board – built the backlog as part of the session
  • no spreadsheets!

The Trouble With Time Machine

I was MC for this session delivered by Matthew Hodgson from Zen Ex Machina. He gets extra marks for working Doctor Who and bow tie references into the talk. His slides are available here.

From Agile Australia 2012
  • UX people are time travelers
  • time machine pattern – work an iteration or more ahead of the development team
  • UX is primarily about design, we are in two different worlds
  • embed the time machine pattern within Scrum
  • personas – focus on the pragmatic face of our users (David Hussman) – synthesise what we understand at the moment
  • added to GWT… Given I am a role AND I VALUE, When… Then…
  • grooming is the forgotten ceremony
  • involved the users in planning poker – got clear perspective in the context of their environment]
  • demo became a cognitive walk through

Emerging Paradigms in Software Testing

I was MC for this session for Kristan Vingrys from ThoughtWorks. I have known Kristan for a number of years, and I resonate very closely with his views on testing and testers. His slides are available here.

From Agile Australia 2012
  • you have to build quality into the product
  • ATDD is a good way to break down the barriers between developers and testers
  • need to change focus to preventing defects rather than finding defects – measure yourself that more defects is bad
  • fast feedback – embrace continuous integration, automation and the test pyramid
  • involve everyone – crowd source your problems, tests are an asset, version control your test cases
  • change focus from how I prevent this going into production onto how I get this into production
  • build pipeline- stage build to run different tests in different stages in the pipeline
  • tester needs to inform the team of quality, not be responsible for quality
  • target testing to things that are changing, not just scatter gun
  • it’s about the principles, not the practices
  • test code is code – treat it like any other code
  • it’s important to know what you are not covering, more than what we are covering (Model Based Testing)

Design Eye For A Dev Guy

I was MC for this session delivered by Julian Boot from Majitek. This was one of the highlight sessions that I attended at the conference and as I remarked when thanking Julian, it reaffirmed how much I don’t know about good design. His slides are available here.

From Agile Australia 2012
  • you gotta love it, you gotta be able to do it and it needs to deliver a bag load of cash
  • people now expect a fit and finish, design is now expected
  • people over process, not everyone is a good designer so let people play to their strengths as weaknesses get in the way of excellence – need to understand it though
  • design is related to visual processing – what we see is what we design, design can be taught
  • highlight individual items – contrast, colour, shape, white space, underlining
  • grouping – proximity, continuity, enclosure, connection
  • proportion, substance and harmony are important
  • subtle changes dramatically affect the visualization
  1. use a grid like CSS Grid and Twitter Bootstrap
  2. focus on data over labels – make the data bigger, keep your headings close to your data so you don’t get lost
  3. hierarchy of actions, but use them properly
  4. colour – use a designer, but if not use 3 colours in one shade and two others (using three grey is the best pro tip and two others)
  5. let design be your brand, don’t overuse the brand

Agile Executive: The Naked Truth!

I was MC for this session led by Kelly Waters from ThoughtWorks and author of the All About Agile blog. I unfortunately did not get to see much of this presentation, the slides for which are available here.

From Agile Australia 2012

Agile Development on Large Legacy Architecture

I was MC for this session delivered by Tony Young from Integrated Research. This session was designated as “Expert” but there is nothing in this that I could see that made it that level. His slides are available here.

From Agile Australia 2012
  • teams find it hard to focus at 7-8 people and they saw parallel development, sweet spot was 5+/- 1
  • changed because competitors moving faster and customers questioned our quality
  • used agile guidelines, not rules – had must dos and bendys
  • product team deliver using Scrum and give to a QA team that uses Kanban !
  • the peer pressure to try is key
  • use Lego board for backlog to see resource impacts

Other Stuff

One of my colleagues who presented a talk on day 2 was Colin McCririck (who is the Executive Manager of a team I coached for some time) and he spoke on Leadership Secrets for Agile Adoption).

Rosie X recorded an interview with me during the conference which was a lot of fun.

Renee Troughton and I took some time out from talks to record a podcast interview with Ilan Goldstein for the Agile Revolution.

Renee also recorded a podcast with Kim Ballestrin on Cynefin.

We also recorded a wrapup podcast.

I also did some short interviews for InfoQ, which resulted in a wrap-up story.

Agile Australia 2012 Product Afternoon Review

Agile Australia Product AfternoonAs 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!

Nigel Dalton from Luna Tractor led this session, his slides are available here.

From Miscellaneous
  •  you can’t say product you need to start saying customer
  • publishing life cycles are enormous – publishers have to wait up to 5 years to change a font
  • The New New Product Development Game – the last paragraph sums it up
  • 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.

From Miscellaneous
  • be customer focussed not customer driven
  • 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.

From Miscellaneous
  • 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

John Sullivan from Jetstar delivered this session, his slides are available here.

From Miscellaneous
  • 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:

From Miscellaneous
  • it’s hard to ask hard questions
  • 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

Agile Australia 2011 Day 1 Review

Agile Australia 2011Agile Australia 2011 was held for its third year last week at the Hilton in Sydney. Once again I was honoured to be offered an opportunity to present, be an MC for speaker sessions on both days, moderate a panel discussion and run the end of conference retrospective. The conference attracted 675 attendees and the buzz over the two days indicated to me that the conference was a huge success.

For the second year, it was a great pleasure to be one of the conference advisors. As the conference was brought forward to June, there was only six months to prepare between conferences and lots of suggestions and improvements to implement from previous years. A lot of review, debate and discussion went into putting the program together and ensuing there was a good mix of speakers, variety of topics and sessions for different levels of expertise. More effort was also put into shepherding speakers. A huge thank you needs to go to Rachel Slattery and Zhien-U Teoh from Slattery IT for their commitment to the conference as well as my fellow conference advisors Phil Abernathy, Adam Boas, Keith Dodds, Martin Kearns, Dave Thomas and Nigel Dalton.

The following are my notes from the sessions I attended on the first day.

Keynote: On Beyond Agile – The New Face of Software Engineering

Alistair Cockburn delivered this keynote, the slides are available here.

From Agile Australia 2011
  • agile software development is for wimps
  • cooperative game – invention, communication and decision making
  • projects are in a position, look for strategies to move our position, no fixed formula for winning the game (competitors and the economy are some of the enemies), only three moves to invent, communicate and decide
  • communication – whiteboard discussion provides stickiness over time (can just point back to conversation) as well as proximity
  • need about 3 minutes of video to enhance the distributed conversation, becomes archived documentation to remember user point of view or architect design decisions
  • craft – a lot has changed, software development changes every 5-10 years and you need to keep up
  • people learn skills in 3 stages – shu, ha and ri
  • work in progress is decisions that have been made but have not been shipped and delivered
  • like lean we we want multiple deliveries per day – continuous integration has evolved to continuous delivery
  • in decision making, look for the bottlenecks, the person with the full inbox is the person limiting the work in progress of the whole organisation
  • knowledge acquisition – real moment of learning often happens at the end when the surprise factor occurs when we deliver work, suggest that at the beginning of a project deliver a knowledge curve ahead of the cost curve (a number of small experiments)
  • agile says deliver highest level of business value first but projects tend to always deal with the risks first – learn about your business risk (should we build it), social risk (do we have the right people), technical risk (API’s, performance, architecture), cost/schedule risk (gain knowledge about the solidity of the estimates) – you need to decide whether to deliver business values or knock off some of these risks
  • need to identify the tail to determine whether we deliver business value early or add more features later (Apple are good at this, for example shipping an iPad without 3G initially)
  • self awareness – the team is self aware when the team can talk about the team and where they are

Keynote – Is Business Ready for Agile

Rob Thomsett delivered this keynote, his slides are available here. He advised that he was going to run his talk in two sprints and check the heart beat halfway

From Agile Australia 2011
  • agile is a church of all people – the newbies through to the true believers and a few drooling old people
  • agile is not new – been going for 40 years
  • is business ready for agile? – yes and no – every company in the world is ready for agile, they just don’t know it – how do we develop agile into a broader organisational paradigm
  • we work on a set of models that were developed when the world was relatively stable
  • the average window of stability for an organisation is about 3 months, change is normal and everything changes
  • old business techniques have reached their use by date (Gary Hamel – Management 2.0)
  • 100% of C-level executives believe that project management is too bureaucratic, projects take too long, business cases are poorly developed, transparency is adequate, they expect to be ambushed, steering committees are a waste of time, reports are not accurate
  • in 1968/69 NATO held a conference to address a perceived crisis in software engineering – sound familiar?
  • software is not engineering, wrong paradigm, it is a craft
  • the closest to what we do is not making buildings but making movies
  • summary: we took the wrong model, flogged it to death so let’s throw it out
  • agile is a cultural and disruptive journey – first question to ask is are you up for the cultural challenge, for every company that says no there is one that says yes
  • business approach needs to pass the simple and transparent test – most powerful test to clean up broken processes
  • go back to work and annoy people by asking people if we can make it simpler
  • cultural values are openness, honesty, courage, trust and money
  • the people at the top are the easiest folks to get on board with agile
  • most people link budgeting to estimating – agile demands we move money around more quickly
  • sponsors must get dirty – they must be part of the process because they own it
  • PMO should exist for resourcing, not reporting

Panel – The Changing Role of the CIO

Beverley Head moderated this panel with Jeff Smith from Suncorp, Steve Coles from Allianz, Daniel Oertli from REA Group and John Sullivan from Jetstar.

From Agile Australia 2011
  • key is to turn decision making over to employees and leaders need to become coaches and create a great environment
  • The Corner Office by Adam Bryant gives advice for success – passionate curiosity, battle hardened confidence, team smarts, simplicity, fearlessness
  • role is to understand where the company is going and deliver things for them to succeed
  • relax the old techniques like governance that gave a veneer of confidence
  • need to understand and remove the barriers by becoming an active listener
  • fundamentals like attract and retain the best have not changed
  • learn the business in which you operate and realise the definition of leadership has changed (don’t be afraid to higher smarter people than you)
  • need clarity of purpose, avoid constraint of thought and don’t filter based on your experience
  • resistance at the frozen layer – middle managers are typically the blockers so need to change the communication structure (for example, using Yammer for communication to give everyone an equal voice)
  • distributed teams always need a local decision point like an iteration manager
  • leaders need to eliminate information handlers
  • offshoring value proposition – you need to decide if your assets are a strategic advantage, do not offshore things that are volatile or if the project is too big to handle yourself (which essentially means you can’t explain it to someone else), offshoring is good because it keeps us on our toes to be competitive and continuously improve
  • need to look at outsourcing from a productivity point of view and not just a cost point of view (we are not buying pencils)
  • life long learning for developers – people have to follow their own course, inject talent and different thinking, look back each year and think about what you added to your bag of tricks
  • most people are capable of learning new skills, that’s the beauty of human beings
  • what does quality mean – quality is something that is fit for purpose and testable and maintainable, quality is everything
  • pushing agile into the business – need to agree on one way of working, once you are successful people want to jump on the bandwagon

Agile Architecture & Design

I had the privilege to introduce Neal Ford for this presentation, and his slides are available here. As I had seen many parts of this presentation previously, I did not take many notes as they can be found across other posts on this blog.

From Agile Australia 2011
  • in the software world we deal with known unknowns
  • spikes are your friends, purely informational gathering
  • ckjm – tool for reporting complexity and coupling
  • don’t pay for technical debt that you may never justify

Key Metrics for an Agile Organisation

It was my pleasure to introduce Craig Langenfeld from Rally Software to deliver this presentation (originally scheduled to be presented by Mark Ortega). The slides are available here.

From Agile Australia 2011
  • cumulative flow – look at the top of the line to see what is the scope and how has it changed (total features), then ask if the team limits their work in progress by looking at the time between the boundary of in progress swim lanes, finally look at the lead times and how long it will take to deliver a feature
  • work in progress limits allow the team to move through work more effectively
  • lead and cycle time report – allows you to see where your bottlenecks are
  • stop focussing on the workers and focus on the work product – so rather than lines of code look at the the value delivered
  • productivity – understand your teams velocity, throughout mapping stories that were completed and carried over
  • earned value – useful to measure how much value we are delivering (the difference in agile is we are actually delivering the value)
  • predictability – answering the question of when we will be done – throughput chart can show you if a team is getting more predictable over time, burn up is used to show predictability of meeting scope, release burndown to show meeting a date and demonstrate additional scope being added
  • use cumulative flow to track the cone of uncertainty
  • quality – defect trends and counts, most code altered, number of changes, etc…
  • net promoter score for tracking customer satisfaction and if it is increasing
  • get customers to vote on what aspects of the product they like and don’t like
  • for cloud computing track the features that are actually used

Leading by Serving

Simon Bristow delivered this presentation, his slides are available here.

From Agile Australia 2011
  • a perfect team is one that can do anything, in control, do anything thrown at them
  • lots of teams act in an agile manner, the leader makes the difference
  • Robert Greenleaf – The Servant As Leader – others highest priority needs are being served first
  • bridge the gap – gaps when making a decision which is the unknowns, bridges the gap to the future by seeing the unseeable
  • one action at a time
  • forcing a decision on someone will engender resistance, some you must persuade – need to listen to connect at the grass roots level
  • withdraw and acceptance – step back from the team to allow them to look after themselves and accept that the team know best as they are the subject matter experts and will get the job done
  • facilitate community – need to build
  • lead using art not science – if you turn to science in agile you will turn to process

Soldering Irons, Consumer Devices and Hardware Manufacturing in the world of Agile Software

Dean Netherton and Neil Brydon for DiUS delivered this talk which was one of the highlights of the conference for me. The slides are available here.

From Agile Australia 2011
  • DiUS working on a fire danger smart meter and technology for charging electric cars
  • how do you demonstrate value when haven’t built the device?
  • had to work around the vendor for the smart meter because they had a traditional process for building the device – aligned project plans around hardware drops and had to simulate the hardware in many cases
  • used wireframes to drive design but had to spend longer on design to ensure it was right – for example, can’t add a bigger battery later
  • first drop was an off the shelf component board to kick start the software
  • second drop was a bare board that was the basic board without the LCD
  • third drop was the plastics without the screen as the component had not arrived so replaced with paper
  • challenge on how to articulate stories – had to break stories own technically
  • used Cucumber to test as there was an embedded USB port on the board – helped embedded engineers assist the Ruby engineers understand how the device worked
  • did continuous integration by plugging a device into the build server, had an issue about flashing the device when the code changes
  • hardware engineers slightly change the design with each revision which had affects on software design as well as having hardware for continuous integration
  • built own hardware prototypes and used local suppliers to cut down lead times (China cheaper but added 6-7 weeks to the lead time)
  • used mocking to show users the idea ahead of hardware being available
  • planned for multiple hardware revisions to allow for late decisions
  • these days you can send a 3D model to a design house and they can pop out a prototype, design exercise ensures that screws line up, etc
  • no excuses for automated testing, in the past it was not embraced in hardware, can test the integration layer without the need for hardware
  • no benefit in running tests for the hardware design as you only get a handful of drops
  • use automated test to ensure buttons and light work, good when you get new hardware and good for checking faults on the production line
  • had to learn about the hardware stack early on which challenged whether value was being added
  • firmware development not integrated onto the story wall
  • technical tasks are OK but really understand what done is
  • luckily the stakeholders were quite technical

Putting It All Together – Agile Transformation and Development Tooling

Philip Chan from IBM delivered this presentation, his slides are available here. I failed to see a lot of agile in this talk personally.

  • established teams – communication difficult across timezones but tools make it easy, different tools used in different teams,
  • IBM agile process – 2 week iterations, 2 day inter sprint break every 4 weeks, develop for first 6 days followed by 2.5 days for bug fixing, do acceptance testing for first 6 days and 2.5 days of exploratory testing, showcase on day 9
  • test management very waterfall for audit purposes
  • using automated tests and continuous integration to assist global team optimise processes

Panel – Continuous Delivery

Evan Bottcher, Neal Ford and Martin Fowler from ThoughtWorks were on this panel.

From Agile Australia 2011
  • continuous integration – everyone in the team integrates with the mainline at least once a day
  • continuous delivery is taking the same approach as continuous integration and apply it to the last mile – decision to deploy should be business only with no technical barriers
  • continuous deployment is continually delivering on a regular basis – continuous delivery enables this if you want it
  • rare to find a company that is pulling in the same direction, so you need to automate in pockets and add manual checkpoints and then you can look for ways to automate them
  • risks – need to bring pain forward, which was the tenet of XP, not doing it is much more risky, there is pain and effort to setup, you need to look for a leverage point in your production systems to justify
  • if you do something rarely you don’t get practice, by doing it more often you improve which actually results in a process that is more auditable and gives you more confidence
  • is a good approach to shorten feedback loops, also allows you to give confidence to the business on delivery timelines
  • packaged software makes continuous delivery hard, important to look at the automation of the configuration as well as automated tests, looking for fast feedback to give confidence in delivery
  • need to push software vendors to make things more deliverable (this was a rant by Martin Fowler, that I tend to agree with)
  • make database changes with the same fundamentals – break them down into small changes and combine schema changes with the data migration and string them together into a package, tools have got more specific like dbdeploy and Liquibase support this and Ruby on Rails just supports this out of the box
  • DBA’s are the final frontier because they like to fiddle with scripts, need to bring them in or deal with smaller changes
  • testers tied to manual processing – need to separate the low and high value testing work, fear that they will be replaced by a small shell script, will make their job vastly easier, need to get buy in by demonstration
  • difficulty is always the human element – testers are moved from the backend to the front end of the process, specification by example at the front now, need to look at incentives and make them common between developers and testers
  • key is a business decision of when to delay so you can deal with business change, training, etc…
  • people are now used to the fact that websites or apps on their phones are continuously changing
  • gives the option to deploy to different types of users when they need it
  • Go was built with continuous delivery in mind, version control systems are critical because everything needs to be in there, automated testing tools are also critical, continuous integration servers can help if they have an extra build pipelines
  • Puppet and Chef both allow you to script your environments
  • need to place people in teams who believe things are possible

Other Stuff

At the end of a very long day, it was good to network with attendees at the ThoughtWorks open office.

Also, I have to send congratulations to my colleague Adrian Smith from Ennova on his talk Agile for Startups which I hear was very well received (I have attended previous incarnations of this talk).

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!