Tag Archives: Tony Ponton

Episode 109 – The Art of Agile Fluency with James Shore

by

2

JamesShoreCraig and Tony at the Agile Australia conference sit down with James Shore, best known as for his work as author of “The Art of Agile Development” and co-creator of the Agile Fluency Model and talk about a wide range of Agile topics including:

  • “Java Modeling in Color with UML” book mentioned Feature Driven Development (an Australian Agile method!), learnt a valuable lesson to pay attention to the financials and, no matter how much you talk to your customer, seeing is not enough (they need to use it)
  • “Extreme Programming Explained“, both editions are the same problem but coming from different experiences with the benefit of seven years of experience
  • the bulk of the “Art of Agile Development” book, particularly section 2, is mostly online, the major thing that probably needs to be updated is the section on customer testing
  • Agile Australia keynote “The Reward”
  • language hunting – there are multiple levels of language proficiency and you can be fluent at any one of them – proficiency is good, but to be really good you need fluency
  • Agile Fluency whitepaper
  • the agile fluency model is not a maturity model, it is about finding the right bus stop
  • Marick’s Missing Manifesto (the things missing from the manifesto) – skill, discipline, ease and joy
  • fluency comes more from the organisational investment than the team, so if you are not seeing fluency look at the organisation first
  • one star is doing Scrum well – with dedicated effort in 2-6 weeks, two stars with mentorship in 3-9 months, three stars takes a lot longer
  • the model is aspirational, so the barriers are high
  • Gamasutra Games Outcomes Project
  • next steps for the model is to share the diagnostics with organisations to help teams compare, contrast and grow
  • “Bloody Stupid Johnson Teaches Agile” with Arlo Belshee
  • the model will work regardless of the method used, its a way of looking at where you are at and not how you do it
  • we should take anybody who fits into the values of the Agile Manifesto
  • “Let’s Code JavaScript” started as a Kickstarter, now 300+ episodes
  • Quixote project allows you to test drive CSS and refactor it

TheAgileRevolution-109 (43 minutes)

Episode 108 – SAFe from the Source with Dean Leffingwell

by

2

DeanLeffingwellRenee, Craig and Tony (with a lurking Em Campbell-Pretty) in a very busy corridor with random bells ringing, catch up with Dean Leffingwell, author of numerous books including “Agile Software Requirements” and “Scaling Software Agility” and the creator of the Scaled Agile Framework (SAFe) in a very candid discussion:

  • the journey to SAFe included as a developer building the Indiana Jones and the Temple of Doom ride and infusion pumps and generally a mission to make quality better
  • epiphony around Agile was the step change around how teams perform and how they like their work when they perform better
  • not everything that is old is stupid, “we are discovering new ways of developing software” and we need to ask ourselves are we still discovering
  • Scrum is the only method that defines what a software team is (roles and size)
  • SAFe is not a war it is a mission to improve outcomes
  • need to provide leadership to agile learning, SAFe is a body of knowledge and a set of patterns that helps simplify learning
  • the differing viewpoints on SAFe are because the stakes have gotten higher, Agile is a big business and hence other approaches need to defend their turf because we are in a competitive market
  • they don’t defend SAFe – we publish case studies, talk about it and implement it, we have to take the pragmatic approach to help people succeed
  • SAFe is versioned because we record the best knowledge we have at the time and Dean is an author, but it has also allowed change management
  • SAFe will always support two versions in the market, including courseware and the big picture, the blog is kept fully up-to-date
  • SAFe LSE was a fork for SAFe for Lean, Software and Systems Engineering and allows for innovation, most of it has been collapsed back to the main framework
  • the framework is free (and will remain so)

TheAgileRevolution-108 (30 minutes)

 

Episode 106: Turning the Agile Ship Around with David Marquet

by

3

DavidMarquetTony, Renee, Craig and special guest host Tyson Nutt catchup with David Marquet, author of “Turn The Ship Around!” and the “Turn Your Ship Around” companion workbook at the Agile Australia conference and talk about how similar a nuclear submarine and an Agile team really are:

  • leadership is not about telling people what to do and how to do it
  • all investments in human beings are long term
  • the approach spread from the bottom up, now the book is on the official reading list of two Navy’s (including New Zealand)
  • “I intend to” does not mean they get to do it – gives psychological ownership and to spark the conversation
  • thinking out loud is about saying what is going on in our head, this even works when teaching your children how to drive!
  • feed the beast – don’t respond by hiding, feed them with as much information as you can as data puts you in control
  • you can’t empower people, you can only unempower them
  • you give control while ensuring competence and clarity
  • whilst not telling people what to do can be good for their learning, sometimes you just need to tell people what to do (in the absence of competence and clarity)
  • good to have you team hold you accountable when you fall back to old habits
  • deal with the “frozen middle” by giving them decision making authority they previously didn’t have
  • when learning about a new team ask “what do you hope I will change” and “what do you hope I won’t change”, this is easy when you have not created the culture
  • “I imagine a world where we all find satisfaction in our work” – you need embrace your fears, on a submarine that can be fear of death
  • need to seek permission to proceed and embrace feedback rather than pursuing signoff
  • instead of saying “are you sure?”, ask “how sure are you?”
  • David is working on a couple of new books – a book of success stories and a colouring book
  • when talking to yourself, use the third person for motivation
  • signup for a weekly leaderhip nudge on David’s website

TheAgileRevolution-106 (40 minutes)

Episode 104: Agile Australia 2015 Vox Pop #2

by

1

Agile-Australia-2015-LogoCraig and Tony wander the lunchtime floor on day 2 of Agile Australia conference in Sydney, looking for more interesting people in the Australian Agile community. They chatted to the ones who couldn’t quite run fast enough away from the microphone including:

TheAgileRevolution-104 (22 minutes)

 

Episode 103: Agile Australia 2015 Vox Pop

by

1

Agile-Australia-2015-LogoCraig and Tony are once again roaming the floor, this time at the Agile Australia conference in Sydney, looking for interesting people in the Australian Agile community. While walking around the floor they run into:

TheAgileRevolution-103 (31 minutes)

Episode 102: The Essence of Microservices (and Agile) with Scott Shaw

by

1

scottshawTony and Craig are at YOW! Conference and in the hallway ambush Scott Shaw, the Director of Technology (Australia) at ThoughtWorks and talk about the state of microservices and Agile:

  • Scott’s YOW! talk “Avoiding Speedbumps on the Road to Microservices“
  • Microservices are just a different way to build applications that get away from monoliths
  • Beth Skurrie, Evan Bottcher, Jon Eaves case study at YOW! – “The Odyssey – From Monoliths to Microservices at realestate.com.au“
  • Essentials for microservices include Domain Driven Design, security and identity and change management
  • Simon Brown talk at YOW! – “Agility and the Essence of Software Architecture“
  • Cloud and infrastructure as code has changed the way we look at applications and have allowed microservices
  • The essence of Agile is the team taking ownership of the business success of whatever it is they are building and keeping that ownership over the longer term
  • Microservices take advantage of Conway’s Law – the teams closest to the systems should own them or change your structure to mimic the systems you want to look after
  • There should be no difference between maintenance and evolution – it is all one of the thing that goes towards the success of the business
  • Adrian Cockcroft defines microservices as “a service-oriented architecture composed of loosely coupled elements that have bounded contexts”
  • Microservices should be no bigger than a concept that fits in your head
  • Sam Newman book “Building Microservices“
  • Agile approaches that are evolving include Docker and functional programming languages (especially Scala, Clojure and Go), the importance of craftsmanship and skills
  • Defending the Free Internet
  • ThoughtWorks Technology Radar
  • Microservices in a Nutshell by Martin Fowler and James Lewis

TheAgileRevolution-102 (28 minutes)

Episode 100: 100th Episode Spectacular

by

1

100dppCraig, Renee and Tony come together to celebrate 100 episodes of The Agile Revolution, and review the journey of both the podcast and Agile in general over the last 4 and a half years and surprise themselves on how many things have changed but how many things have remained the same.

Thank you to all of our guests and to our loyal listener(s) for helping us reach 100 episodes!

TheAgileRevolution-100 (82 minutes)

Episode 99: 99, Not Out!

by

2

Malcolm-Christmas-Card-front-3-620x400Despite not feeling well, a sick Renee, a very sick Tony and a trying not to get sick Craig, get the band back together to discuss all the latest in the Agile world, including:

TheAgileRevolution-99 (65 minutes)

Episode 96: YOW! 2014 Brisbane Vox Pop

by

1

YOW_2014_logo-pngClearing out the backlog, Craig and Tony roam the corridors at YOW! 2014 in Brisbane and talk to attendees and old friends and colleagues. Despite Tony’s fetish with pineapples and the fact it took 96 episodes to get a mention of ISO-9126 they talk to:

TheAgileRevolution-96 (28 minutes)

Episode 91: Coding The Architecture with Simon Brown

by

1

SimonBrownCraig and Tony talk to Simon Brown at the YOW! 2014 conference in Brisbane. SImon is the author of “Software Architecture for Developers”, creator of the C4 software architecture model and Structurizr. We tracked him down after his talk to talk about:

  • YOW! 2014 talk “Agility and the Essence of Software Architecture“
  • Create a software guidebook as opposed to big upfront documentation
  • Tony is an old BA apparently… Explains a lot 🙂
  • If you can’t sketch out your architecture, you don’t understand it
  • C4 model was created after observations many archtecture drawings don’t make sense
  • Tony shows his age again by referencing Mr. Squiggle (video)
  • A tiny percentage of architects understand UML – do you teach them UML or teach them something simple?
  • Structurizr replaces drawing boxes in Visio or OmniGraffle, creates the C4 model from Java code and keeps it up to date, other implementations for C# have also been created
  • Suggest updating the diagrams at the end of every storycard
  • C4 starts at system context level, opens up to containers, zooms down to components inside containers and then down to the class level
  • Use the model to understand your microservices strategy versus monoliths (article by Rob Annett)
  • C4 is a drill down per system, does not have much to offer enterprise architects – can add an extra enterprise architecture layer if you wish
  • ArchiMate allows Enterprise Architects to model processes
  • We need Enterprise Architects but architects need to be involved in the day to day architecture including code (REA have a delivery engineering team that they spoke about at YOW!)
  • Roy Osherove’s Elastic Leadership – starting point is one architect but then get more people involved
  • Ask your team what an Architect does and you will probably get conflicting answers, it is a not well defined role
  • System Architect and Tech Lead are essentially the same thing

TheAgileRevolution-91 (28 minutes)