YOW! 2015 Highlights
Some highlights and a short summary from my attendance at YOW! 2015. All the presentations are online at the YOW! Australia YouTube channel.
Note that the section headings are linked to the corresponding presentation video. I attended the Melbourne conference, but some of the videos are from Sydney or Brisbane events.
Don Reinertsen - Thriving in a Stochastic World #
Why deliver the plan? #
Don’t focus on the plan - the plan has no intrinsic business value. The plan is a way to describe a sequence of steps to reach the business goal and provides a starting point. Of course, as agile software developers, we know to stop and inspect at small increments and adjust as necessary. The plan is a live artefact, constantly evolving with the software.
When we change the plan, we are making the assumption that the work we do has more value than the work we don’t.
Variability (a good thing) #
Focusing on the plan can reduce variability. But, this reduced variability will in fact reduce the possible pay-off significantly. This is because the delay-to-cost ratio is too high when fixated on the plan. The delay-to-cost ratio simply defines the cost of delaying doing something, versus the cost of doing it now. From an economic stand-point, this is modelled as an asymmetric pay-off function. Without variability the eventual pay-off is significantly reduced.
Dan North - Delivery Mapping #
Probably my favourite talk, along side Dave Thomas’ (pragdave) “Agile is Dead” talk.
A couple of cracking quotes including describing the current state of “Agile” software coaching and mentoring as a our own “ponzi certification scheme”. Love it!
Had a really simple proxy for using the Dreyfus mode of skill acquisition, which is working for him:
- None (never seen it, wouldn’t know what it looked like)
- Read (could read it, maybe intuit the intention)
- Write (could modify and adapt it)
- Teach (could teach it)
Intuitively, as a developer, this seems like a really nice way to measure skill. We use a 1 - 5 measure here at Readify, but I think this might be better. No good evidence for that tho …
The core of the talk was on Delivery Mapping, which I hadn’t seen before. Really interesting stuff, especially combing the skills matrix with the project and looking for gaps as well as opportunities for development and exploration. In particular, looking for opportunities where you have skills but no business need, but business need with no skills - slam em’ together and get a Cobol re-write in Python that’s faster and more maintainable. Not to mention the engagement this would bring for the employees involved. That’s a cool idea.
He also discussed Risk Adjusted Return on Capitol (RAROC). Another idea from finance that helps us software nerds understand why iterative development works for the business. By just considering sunk costs versus profit, you get an inverted triangle, with a long time before seeing a ROI. In the iterative and incremental world, we begin getting payback much sooner. That’s great and we’ve known it for a while. But, you combine this with the asymmetric payoff functions from the keynote and you get a really complete and compelling story as to why this software agility works for a business. Embrace change! You’ll be rewarded with significant gains in pay-off.
Dave Thomas (pragdave) - Agile is Dead #
I’ve seen this talk before (YouTube), but he’s certainly softened the intro a little. Still, it’s a tremendous talk and one designed to challenge us as agile (yes, the adjective) software developers. This talk was right after Dan North, making this session the major highlight of the two days (at least for me).
In essence, he believes that the noun’ification of Agile has single handedly led to some really bad stuff in our industry (ponzi certification scheme’s anyone?) as well as SAFe … really? WTF!? How did we get here …
He boils it down to the following (I’m paraphrasing here and using my own language, but the concept is the same) - as an agile software developer, who believes strongly in the Manifesto for Agile Software Development, we have three core things to do:
- Inspect - where are we? What’s our current context?
- Adapt - where do we want to go? And (importantly) what’s a small step to get there?
- Make the step, rinse and repeat.
Lastly, if faced with a choice of two things with equal value, choose the one easiest to change in the future.
Glen Vandenbourg - The Future of Software Engineering #
This was a surprise highlight for me. I didn’t know what to expect, but he made some really great points regarding the state of our industry, how we really are an engineering discipline, and how we originally made the mistake of picking the engineering discipline (Civil) that is the least like software development.
As an aside - did anyone else not know that NATO (yes, that NATO) called a world wide conference on the crisis in Software Engineering in the 50’s!? I’m not saying we have a crisis in our industry now, but we really don’t like looking back, do we?
Many engineering disciplines are based heavily on the empirical process, because they operate in systems of great variability. Industrial and chemical are two such disciplines. His main point was that this is essentially the same as software development. We work in a stochastic (another keynote!) environment, with high variability. Let’s embrace it - interestingly, Scrum is based on empirical process control. Inspect and adapt!
One other interesting point for me was how we (as an industry) often try to map traditional (Civil) engineering roles to software:
- Architect/Designers = Software Architect / Business Analysts etc
- Plans = Model (UML / ?)
- Labourers = Developers
- Building = Application
But in his view, a much better mapping is:
- Architect/Designers = Development Team (Scrum language - everyone involved in building the product)
- Plans = Code base + artefacts
- Labourers / Builders = compilers and tooling
- Building = Application
The major (major) difference being that the most significant cost in the first scenario is the labour cost to actually build the thing. In the second scenario, the major cost is the architect and design phase and the actual build is practically free (a couple of seconds/minutes to compile).
He then noted that all the process optimisations from Civil and the like are focused around the cost to build. Naturally, this is a terrible fit for software. Thus we need to look at the more empirical engineering disciplines as a better starting point for software engineering.
I’m not sold on the idea of software being a true engineering discipline, but I can’t help but agree that some rigour needs to be around the processes we use, otherwise nothing is repeatable or measurable. Without being able to measure our state (inspection) we’ll never be able to move forward with any certainty and when we are successful, we won’t know why and thus we’ll never bring any repeatability to our process.
Interesting stuff and worth keeping an eye on.
Uber - just plain broken … #
Wow, a super high energy talk! The guy from Uber just took-off and never looked back. And man, Uber is broken! But I guess it works for them :) Really interesting to see how they work (or perhaps don’t work) and how they nearly lost everything a couple of times.
I still have no idea how he managed to go from Uber, to Master / slave relationships, to Nazi Germany … too much RedBull perhaps?
Fascinating stuff though.
Aino Vonge Corry - A Comment on Learning #
Another surprise highlight was a presentation on different learning types. While its intuitively obvious that people will learn in different ways, it was quite interesting to hear about the specific ways in which learning occurs.
The presenter broke it down into a persons preference for learning (active or reflective) and a persons preference for detail (global or specific). In essence, people who are more active learners will prefer to ask questions and engage with the instructor. A reflective learner will want to go away and take time to think about the material before asking questions.
Similarly, a person who prefers global information will want the big picture details, a high-level view providing a wide context. They want to know the why of it. A person who prefers specific detail will want specific examples and much higher detail - they want to know the how of it.
Obviously, everyone is different and most people will not be on the extremes of those preferences. And they are just preferences, we can learn to use a non-preferred learning technique. But it is useful to keep in mind when designing a presentation that some in your audience may want big-picture detail and others more specifics and that you can’t please everyone with every slide (unless it’s a funny cat picture. Everyone loves them.)
Summary #
Looking back over this, I kinda feel like I’m “Agile” bashing a little. Personally, I’ve never been big on certifications. About the only one I do have is the Profession Scrum Master (PSM I) certification from Scrum.org. I loved the PSM course and it taught me a lot. But the thing I got most out of this conference was that, at the end of the day, it’s the Manifesto of Agile Software Development values that are most important to me. I must always remember to continually inspect and adapt to better understand the current context and make better choices for those small steps, in order to best serve the client and the client’s business.
Not having much (ok, any) of a financial background, I also really liked the basic economic models that support the concepts of incremental delivery. Really handy to have in the back pocket when discussing process change, to give a complete story of the benefits of agile software development (especially when the topics of risk and variability come up!)