Episode 188: Doing Agile Right with Steve Berez & Tony Christensen

The Agile Revolution Podcast

Tony and Craig catch up with Tony Christensen and Steve Berez, co-author of “Doing Agile Right: Transformation Without Chaos” as well as from Bain & Company and they chat about:

  • Saw a lot of companies doing agile wrong and a lot of pain suffering and probably worse off than when they started – book is to try to share learning and get agile on the right track
  • The conditions for agile to flourish need to change, particularly beyond team level
  • RBS – one of the key impediments was funding, changed to funding persistent teams
  • Most organisations have a dissatisfaction with their financial process – need to have an honest conversation around the pain points of trust and process and seeing the promise of early return
  • Bosch – were not innovating as quickly as they needed to, now using Agile for product design, manufacturing process and supply change…

View original post 163 more words

Episode 172: Business Agility & DevOps Health Radars with Sally Elatta

The Agile Revolution Podcast

Craig catches up with Sally Elatta, president of Agile Transformation and the founder of Agility Health Radar and they chat about:

  • Companies struggle to get the metrics to know if their agile transformations are making a difference, hence the creation of Agility Health Radar
  • Business Agility pillars – customer seat at the table, lean portfolio management, organisation structure and design, agile framework, leadership and culture, make it stick, technology agility and agility metrics
  • DevOps pillars – faster value delivery, higher quality, culture of improvement and building the right product

TheAgileRevolution-172 (27 minutes)

View original post

Episode 159: What Colour Agile Would You Like Today with Nigel Dalton

The Agile Revolution Podcast

Craig is at YOW! Hong Kong and is sitting with Nigel Dalton, Chief Inventor at REA Group and the Australian “Godfather of Agile” and they reminisce about:

View original post 529 more words

Episode 139: Talking Agile Craft with Steve Elliott

The Agile Revolution Podcast

Craig chats with Steve Elliott, the founder and CEO of Agile Craft and they discuss:

  • Dependencies are the number one thing that kills agility
  • Scaling agility across a large organisation is a 5 – 10 year journey
  • Scrum is often disconnected from the portfolio planning layer, the scaling methods are making the program level agile and predictable
  • If you want business agility you have to hinge the technology into the business
  • Sometimes it takes a few attempts for agile transformations, like tipping over a Coke machine (and unlike tipping a cow), you need to lead with results and then work on cultural change to be successful
  • If the leader of an Agile transformation left the organisation, would they go back to the old way or is Agile part of their DNA – if they would go back they have not been transformed
  • The scaling Agile frameworks are relatively new…

View original post 233 more words

Towards The Agile Country (AgileTODAY)

AgileTODAY is a publication associated with the Agile Australia conference. In the March 2016 edition I was invited to share my vision for the conference theme as part of my role as a conference advisor.

“Towards an Agile Country means that the Agile community can truly lead the charge in transforming Australia into an innovation and technical leader. By living the Agile values and helping others to find better ways of working together, focussing on delivery, focussing on the customer and keeping up with change, our size and diversity means we have the potential to become a world leader in many innovative fields. Our challenge is to move beyond software development teams and start solving the big problems.”

Episode 25: Cultural transformations with Agile

The Agile Revolution Podcast

YoghurtCraig, Tony and Renee debate the role of an Agile Coach and how cultural transformations fit in.

Quotes:

“Management does not know what a system is” – Deming

“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small, manageable tasks, and then starting on the first one” – Mark Twain

View original post 36 more words

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 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!