Jekyll2022-06-06T19:29:26+01:00http://www.riccardos.net/feed.xmlRiccardos.netRiccardo M Bennett-LovseyAutodesk Interview: Our Digital Journey2022-03-13T20:00:00+00:002022-03-13T20:00:00+00:00http://www.riccardos.net/blog/2022/03/13/autodesk-interview-our-digital-journey<p>The good people at <a href="https://www.autodesk.com/">Autodesk</a> were kind enough to interview me following the tremendous progress our team has made as part of our digital transformation.</p>
<iframe src="https://www.linkedin.com/embed/feed/update/urn:li:ugcPost:6904000058229149696?compact=1" height="315" width="560" frameborder="0" allowfullscreen="" title="Embedded post"></iframe>
<p>The original recording of the interview can be found <a href="https://www.linkedin.com/feed/update/urn:li:activity:6904000304707440640/">here</a>.</p>Riccardo M Bennett-LovseyThe good people at Autodesk were kind enough to interview me following the tremendous progress our team has made as part of our digital transformation.Iasa Global Interview: Becoming an Architect2018-12-10T20:00:00+00:002018-12-10T20:00:00+00:00http://www.riccardos.net/blog/2018/12/10/iasa-global-interview-becoming-an-architect<p>The good people at <a href="https://www.iasaglobal.org/">Iasa Global</a> were kind enough to ask me to take part in their Executive Interview Series.</p>
<p>My own personal journey towards becoming a softare architect was nothing particularly special. However, there were a number of lessons I learned along the way that may be of some insight to others.</p>
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/97ALNPlFkAI" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
<p>(For the record: I <em>am</em> working on trying to appear less nervous in front of the camera!)</p>Riccardo M Bennett-LovseyThe good people at Iasa Global were kind enough to ask me to take part in their Executive Interview Series.London .NET User Group: December 20172018-01-14T14:27:00+00:002018-01-14T14:27:00+00:00http://www.riccardos.net/blog/2018/01/14/london-net-user-group-december-2017<p>Just before Christmas I gave a presentation at the <a href="https://www.meetup.com/London-NET-User-Group/">London .NET User Group</a> on neurodiversity in the technology industry. It was quite a difficult subject for me to talk about, which unfortunately comes across in my obvious nervousness, but I am very grateful to <a href="https://www.dylanbeattie.net/">Dylan Beattie</a> (and the whole of the LDNUG) for encouraging me to go through with it.</p>
<p>I am not sure how much I will be talking about this sort of thing in the future, but I am glad to have gone through with it at least once.</p>
<p>The original recording of the talk can be found <a href="https://skillsmatter.com/skillscasts/11325-riccardo-bennett-lovsey-on-neuro-diversity-literally-thinking-differently">here</a>.</p>
<p>The slides from the talk can be found <a href="https://www.slideshare.net/countincognito/neurodiversity-literally-thinking-differently-84529316">here</a>.</p>Riccardo M Bennett-LovseyJust before Christmas I gave a presentation at the London .NET User Group on neurodiversity in the technology industry. It was quite a difficult subject for me to talk about, which unfortunately comes across in my obvious nervousness, but I am very grateful to Dylan Beattie (and the whole of the LDNUG) for encouraging me to go through with it.Digital Transformation: Going Back to Basics2017-07-18T22:02:00+01:002017-07-18T22:02:00+01:00http://www.riccardos.net/blog/2017/07/18/digital_transformation_going_back_to_basics<h2 id="what-does-digital-transformation-actually-mean">What does “Digital Transformation” actually mean?</h2>
<p>The phrase “Digital Transformation” seems to be everywhere these days. A quick Google search yields in excess of 11 million results, which is rather good for something that regularly markets itself to punters as being “niche”.</p>
<p>Attempting to define “Digital Transformation” is a story in its own right; above all else, there is choosing the angle from which to approach it. More than enough has been written on it from the business perspective, but comparatively little attention has been paid to what it really means for my own discipline (software development).</p>
<p>Examining “Digital Transformation” through the lens of software development still does not get us much closer to defining it. Fortunately, there exists a <a href="https://en.wikipedia.org/wiki/Digital_transformation">Wikipedia article</a> dedicated to the subject — a fairly reliable rule-of-thumb indicating that something is at least worthy of discussion. The top of the article broadly defines “Digital Transformation” as:</p>
<blockquote>
<p>the change associated with the application of digital technology in all aspects of human society</p>
</blockquote>
<p>which can:</p>
<blockquote>
<p>enable new types of innovation and creativity in a particular domain</p>
</blockquote>
<p>Over the years I have heard similar definitions thrown around for phrases like “E-commerce Transformation”, “Cloud Transformation” or “Mobile Transformation”, plus numerous others. So, does this high-level notion of “Digital Transformation” really represent anything new, or is this just another instance of our mammalian brains falling for a clever case of rebranding? My instinct leans towards the latter: humans have a terrible habit of exaggerating anything that feels remotely novel, no matter how minor the difference may be. Unfortunately, we also have a habit of believing our own hype, and as a result we tend to ignore occasions when history repeats itself.</p>
<h2 id="what-constitutes-real-change">What constitutes real change?</h2>
<p>That said, genuine change on a scale that can impact the whole of humanity is nothing new either: it happens more often than one may think, and increasingly more regularly than it did in the past. So much so, in fact, that there is a specific term semi-reserved for historical context: <em>revolution</em>. Not “revolution” in the political sense, but one that represents a documented epoch during which time human civilisation was elevated to another level, primarily through significant advancement in an eponymous area of technology.</p>
<p>The most well-known of these is of course the “Industrial Revolution”, of which there have been at least two in Europe alone. However, since the end of the Renaissance there has been a new technological revolution at least every one hundred years, and over time they have increased in frequency (and, more recently, concurrency).</p>
<p><img src="/assets/images/blog/2017/revolutions.png" alt="Revolutions" /></p>
<h2 id="technological-revolutions-are-more-common-than-you-may-think">Technological revolutions are more common than you may think</h2>
<p>What constitutes a <em>revolution</em> is also an interesting matter for debate, though (as always) <a href="https://en.wikipedia.org/wiki/Scientific_revolution">having</a> <a href="https://en.wikipedia.org/wiki/British_Agricultural_Revolution">a</a> <a href="https://en.wikipedia.org/wiki/Industrial_Revolution">Wikipedia</a> <a href="https://en.wikipedia.org/wiki/Chemical_revolution">article</a> <a href="https://en.wikipedia.org/wiki/Second_Industrial_Revolution">dedicated</a> <a href="https://en.wikipedia.org/wiki/Green_Revolution">to</a> <a href="https://en.wikipedia.org/wiki/Digital_Revolution">it</a> is at least a good starting point. However, there are two factors that could be objectively considered common:</p>
<ol>
<li>Dramatic and far-reaching impact on human society</li>
<li>New avenues of innovation and creativity being opened and exploited</li>
</ol>
<p>These points (broad though they are) sound disarmingly familiar to the high-level definition of “Digital Transformation” from above. So, perhaps the concepts it encapsulates are even less original than previously thought.</p>
<p>What does this mean with regards to where software development is today? Specifically, what does it mean in the context of the technological revolution we are currently experiencing: the “Digital Revolution”?</p>
<p>To my mind, the answer is simple: the concept of “Digital Transformation” is merely a reiteration of the change and innovation in which the software industry has been participating since the invention of the first digital transistor. In some ways the term is largely redundant: can anyone demonstrate a time when digital technology has not been transforming the world? If anything, dramatic systemic change should be considered business-as-usual for software development.</p>
<h2 id="what-are-the-challenges">What are the challenges?</h2>
<p>What does it say about our industry, caught in the middle of a revolution, when the mere act of instigating change is somehow considered marketable? That in itself is an implicit indictment of how the world perceives us, and (more tellingly) how we perceive ourselves. For one thing, we are one of just a couple of disciplines that are considered to be “in crisis” due to lack of quality, reliability, maintainability, cost efficiency, etc., for the products and services we provide. Not only that, but the moniker has been with us for more than half a century (1968 to be precise — once again, <a href="https://en.wikipedia.org/wiki/Software_crisis">Wikipedia FTW</a>).</p>
<p>So what went wrong? When assimilating positive change within an industry is demonstrably more difficult than it should be, it tends to be symptomatic of deeper problems. Rather surprisingly, these often include: lack of manageable standard operating procedures or established best practices.</p>
<p>It may seem counterintuitive, but stable working processes can actually drive business agility and the ability to accommodate change reliably — they provide foundations upon which innovators can let their imaginations run free, a soft landing when experiments fail, and accommodating frameworks when they succeed. Toyota realised this in the late 1940s when they began establishing the Toyota Production System (arguably the spiritual progenitor of modern Agile methodologies). By making stability the foundation of their business practices, within a generation the company was transformed from a bit-player in the Japanese market to the single most successful automobile manufacturer on the planet.</p>
<p>As practitioners and technologists, most of us will have at least some experience of working in an environment where <em>real</em> technological change seems to happen at a glacial pace, and for some of us this will sadly be the norm; here I distinguish “real” change as being something meaningful, productive or concordant with adding value, as opposed to superficial window-dressing or attempting to initiate change through uncritical, dogmatic witchdoctory (yes, Agile I am looking at <em>you</em> — just kidding, <a href="/blog/2013/07/27/thoughts-agile-part-1-fear-and-loathing">I</a> <a href="/blog/2013/08/18/thoughts-agile-part-2-manifesto">love</a> <a href="/blog/2013/10/20/thoughts-agile-part-3-principles">you</a> <a href="/blog/2014/07/12/agile-development-and-project-design">really</a>).</p>
<h2 id="what-does-it-all-mean">What does it all mean?</h2>
<p>If the notion of “Digital Transformation” really is redundant in software development, then the issue it was intended to address (i.e. present day shortcomings in the way a company manages digital technology) could be construed as a distraction, whether by choice or by accident. It is often marketed as a silver bullet to solve the problems in digital strategy by catalysing necessary change, but let us assume for a moment that change itself is a natural consequence of business-as-usual in the software industry. If transformation is the target, and change is inevitable, then perhaps the real weakness is in how companies themselves conduct business-as-usual; and (given the fact the “software crisis” is still alive and well) that is probably not an unreasonable conclusion to draw in many cases.</p>
<p>The lack of consistent best practices for quality assurance, code reviews, integration testing, rapid prototyping, test strategy, risk assessment, project design, architecture, version control, release management, instrumentation, user experience, or documentation across companies says more about the state of our craft than most would care to admit. How can this still be the case after more than 50 years of trial and error? Perhaps because a frighteningly large number of software engineers have a hard time accepting good ideas that they did not think of themselves (a derivative of “Not Invented Here” syndrome); individually we feel the need to put our personal signature on answers to problems that were solved years ago, and thus continue the cycle of wheel-reinvention — frantically turning whilst somehow managing to remain stationary. Design Patterns are the closest thing we have to universally agreed standards, but even they can only get you so far.</p>
<p>Few would argue that software development does not still suffer endemic problems, whether they are: projects running over-budget, projects running over-time, low quality deliverables, unmet requirements, or simply projects never reaching production. Despite this, the basal pace of technological change has for a long time shielded us from the cold truth that a large fraction of our industry still struggles to deliver projects on time, on budget, and/or on quality, without cutting corners. The fact that we are consistently failing to fulfil these basic criteria should have us standing back in astonished self-reflection, but that never happens because we know that in 12 months time we will be working on new paradigms, stacks, and frameworks, whose sheer novelty provides us with renewed reasons as to why we will always need “just a few more sprints”.</p>
<h2 id="what-can-we-do-about-it">What can we do about it?</h2>
<p>I was a computational biologist in a previous life, and I often find myself revisiting my observations on biological systems as a guide to how humans tend to behave, even without realising it. As a species we are often so impressed by ourselves that we forget that nature has been winning at this same game for much longer than we could ever imagine. It is truly amazing what can be achieved with a billion year schedule, globally redundant resources, and an endless supply of expendable labour!</p>
<p>Whatever your take on the natural world, a sad fact of life is that change is difficult, and few ever get it right the first time. However, change is also necessary in order to avoid demise or stagnation. Even at the coalface of software development the same holds true: many cling on to the idea that making changes to software <em>must</em> be easy because (unlike other fields of engineering) we are not carving stone or welding metal. They either forget or ignore the fact that, in all cerebrally creative disciplines, any degree of change requires great care regardless of the substrate. If making changes to software really were a trivial matter then we would have no need for regression testing, contingency planning, or even the term “brownfield”.</p>
<p>Despite all this, the irony is that systemic change is unavoidable: for better or for worse, change will happen inside and outside your company whether you like it or not, and that makes harnessing the benefits of the change around you a necessary part of everyday practice for organisations who wish to survive. By resisting change for fear of the unknown, we risk being left behind when the wave finally passes.</p>
<p>Unfortunately, systemic change is also slow: any attempt to break homeostasis in the short-term will inevitably be met with resistance spawned from either strategy, culture, people, process, technology, or analysis (but mostly people — never underestimate the nullifying power of ego). Even something as basic as task estimation can rapidly descend into the realms of cargo-cult and wishful thinking without careful oversight; but attempts to suggest an alternative are routinely resisted with claims that anything else would be “too difficult” or “more work”, as if these were somehow valid excuses for lack of improvement. Just because something is difficult to do well is no reason to avoid trying.</p>
<h2 id="a-word-of-warning">A word of warning</h2>
<p>For any change to succeed it must, above all, be simple to assimilate. Even if the reasoning and theory behind it is complex, the implementation must be easy enough for anyone to grasp; not everyone needs (or wants) to understand why something is happening, and sometimes <em>no one</em> will understand why something is happening! But that is okay: development teams may be smart, but they already have a difficult job to do; indenturing them with false burdens, with no demonstrable value, does nobody any favours. Any individual ant may not know about the machinations of its colony, but by doing its job well and in harmony with its cohort it can fell trees, build bridges, and construct underground cities of astonishing intricacy with just a simple set of rules to follow.</p>
<p>Similarly, successful change is <em>coordinated</em> rather than controlled, especially when it consists of highly intelligent actors. You would be hard-pressed to try and <em>control</em> any group like that. Some liken managing a development team to herding cats — I prefer likening it to herding attention-deficient cats with their own egos, anxieties, characters, passions, ambitions, insecurities, aptitudes, and talents, all whilst simultaneously shielding them from a pack of circling pitbulls. I still have the marks to show for it.</p>
<p>If these observations are correct, then it quickly becomes clear that complex change can only begin from the ground up, and must be built from a library of small, stable, and repeatable steps. While it cannot always be predicted, macroscopic change can at least be steered through targeted adjustments and careful monitoring of progress. Only through these micro-level alterations can reliable macro-level changes emerge, and once they do emerge they will self-sustain (ask any ship’s captain when they try to change course). Top-down proclamations or transformations through diktat rarely gain traction, let alone success.</p>
<p>Finally, and above all, we (the software development industry) must revisit the basics and master those that can help address the problems of today before worrying about next year’s big trend, otherwise those problems will simply continue to persist beneath the veneer of those shiny new toys. Basics like: proper system design (not just lip service); proper project design (no more “wet fingers in the air”); no more compromise on quality (better development, more testing, system-wide quality assurance, zero tolerance for defects); transparency with customers (being prepared to say “no” to unrealistic expectations); gauging risk and being ready for it (not just hoping it will never happen); and continuous improvement (acknowledging mistakes and embracing them as chances to learn).</p>
<p>Personally, if could wave a magic wand, and pick just one thing from my mental wish list to transform overnight, it would be to stop treating testing like a second class facet of software creation. No development manager in the history of anything has ever slapped their forehead in despair at the thought of having too many testers on their team!</p>
<h2 id="final-thoughts">Final Thoughts</h2>
<p>Tolstoy once said:</p>
<blockquote>
<p>Happy families are all alike; each unhappy family is unhappy in its own way.</p>
</blockquote>
<p>To put it another way: in any task there may be a million of ways to get things wrong, but only a handful of ways to get things right. This is especially true of thought-intensive disciplines like software. While there may be some hitherto undiscovered best practices the industry could one day universally adopt, for now the problem is incumbent upon each of us to solve for our own situation. The first step is to acknowledge that the problem exists. At the moment we are still perpetually captivated by the brilliant new technologies coming over the horizon, and the challenges they will bring, that we neglect the need to master the basics of our craft for the challenges we already face.</p>
<p>If we truly want to be the best we can be, then perhaps the first step is to swallow our pride and be willing to admit that we cannot hope to revolutionise our craft until we can reliably learn, adapt, and (above all) teach how to fulfil the basic responsibilities expected of true professionals.</p>
<p><a href="https://medium.com/bigradical/digital-transformation-going-back-to-basics-5fbef9dca0b8">This post originally appeared on Medium</a></p>Riccardo M Bennett-LovseyWhat does “Digital Transformation” actually mean?Technology and Friends: Episode 4832017-07-11T22:15:00+01:002017-07-11T22:15:00+01:00http://www.riccardos.net/blog/2017/07/11/technology-and-friends-483<p>Whilst I was at <a href="/blog/2017/06/23/devsum-2017">DevSum 2017</a> I was lucky enough to be asked by <a href="https://davidgiard.com/">David Giard</a> to appear on <a href="https://technologyandfriends.com/">Technology and Friends</a>.</p>
<iframe width="560" height="315" src="https://www.youtube.com/embed/8JFwXT4qwVM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
<p>The original recording of the interview can be found <a href="https://www.youtube.com/watch?v=8JFwXT4qwVM">here</a>.</p>
<p><strong>Edit</strong>: the blog post promised in the interview can be found <a href="/blog/2017/07/18/digital_transformation_going_back_to_basics">here</a>.</p>Riccardo M Bennett-LovseyWhilst I was at DevSum 2017 I was lucky enough to be asked by David Giard to appear on Technology and Friends.DevSum 20172017-06-23T20:38:00+01:002017-06-23T20:38:00+01:00http://www.riccardos.net/blog/2017/06/23/devsum-2017<p>This week I had the pleasure and the privilege of presenting my talk on “Digital Transformation: Back to Basics” at <a href="http://www.devsum.se/">DevSum 2017</a> in beautiful Stockholm.</p>
<p>The slides from the talk can be found <a href="https://www.slideshare.net/countincognito/digital-transformation-back-to-basics">here</a>.</p>Riccardo M Bennett-LovseyThis week I had the pleasure and the privilege of presenting my talk on “Digital Transformation: Back to Basics” at DevSum 2017 in beautiful Stockholm.Iasa ITARC London: May 20172017-05-30T20:38:00+01:002017-05-30T20:38:00+01:00http://www.riccardos.net/blog/2017/05/30/itarc-london-2017<p>Last week I had the privilege of presenting at <a href="https://www.iasaglobal.org/itarc-london-may/">Iasa ITARC</a> on my thoughts surrounding the future of software architecture and the role of the “Software Architect”.</p>
<p>The slides from the talk can be found <a href="https://www.slideshare.net/countincognito/future-role-of-the-architect">here</a>.</p>Riccardo M Bennett-LovseyLast week I had the privilege of presenting at Iasa ITARC on my thoughts surrounding the future of software architecture and the role of the “Software Architect”.Agile Development and Project Design2014-07-12T22:34:00+01:002014-07-12T22:34:00+01:00http://www.riccardos.net/blog/2014/07/12/agile-development-and-project-design<p><a href="https://en.wikipedia.org/wiki/Agile_software_development">Agile development</a> has found itself under a fair bit of <a href="https://blog.assembla.com/AssemblaBlog/tabid/12618/bid/87899/Seven-Things-I-Hate-About-Agile.aspx">criticism</a> <a href="https://michaelochurch.wordpress.com/2014/06/20/on-programmers-deadlines-and-agile/">in</a> <a href="https://news.ycombinator.com/item?id=5406384">recent</a> <a href="https://www.itworld.com/article/2828943/enterprise-software/why-agile-isn-t-working--bringing-common-sense-to-agile-principles.html">years</a>, from both managers and developers alike: managers tend to complain about Agile’s apparent lack of accountability, structure, and ability to deliver on schedule or budget; while developers tend to complain about pretty much the same things (just from a different angle). In truth, it is hard to blame anyone for becoming disenchanted, given how badly Agile tends to be practised in the real world: the chaos spawned from leaping to the keyboard at the merest whiff of a specification change; the seemingly wilful disregard for quality assurance (“We’re doing Agile - we don’t have time to test - just make sure you write it without any bugs”); and the almost pathological fear of committing to (literally) anything. Why should anyone have faith in Agile, especially if it gives you an in-built excuse to never think ahead? Regardless of what some would have you believe, a business of any size needs a plan. A business without a plan is little more than an expensive hobby, and the same goes for any significant software project.</p>
<p>Here is a quick thought experiment: suppose you had an idea for the next big “killer app”, one that you felt was certain to make you the next <a href="https://en.wikipedia.org/wiki/Bill_Gates">Gates</a>, <a href="https://en.wikipedia.org/wiki/Larry_Ellison">Ellison</a> or <a href="https://en.wikipedia.org/wiki/Mark_Zuckerberg">Zuckerberg</a>; what would you do? You would probably pool your life savings, remortgage the family home, maybe even take out a loan on top of that just to fund a business venture into which you were ready to pour your heart and soul. Wouldn’t you want to know how that money was going to be spent? Wouldn’t you expect the team you hired to have a well researched plan of action? Wouldn’t you expect them to have mechanisms in place to deal with the constantly shifting needs of the market place? Of course you would. So why treat your company’s money any differently? Or worse, your customer’s money?</p>
<p>As I have mentioned <a href="/blog/2013/07/27/thoughts-agile-part-1-fear-and-loathing">in</a> <a href="/blog/2013/08/18/thoughts-agile-part-2-manifesto">previous</a> <a href="/blog/2013/10/20/thoughts-agile-part-3-principles">posts</a>, the real victim in all this is the good name of Agile, and the way in which many practitioners drag its reputation through the mud every time they dive into a project with complete disregard for what it actually says.</p>
<blockquote>
<p>Planning? Architecture? Research and requirement gathering? An Agilista craves not these things.</p>
</blockquote>
<p>I would challenge anyone to demonstrate where in the <a href="https://agilemanifesto.org/">Manifesto</a> or the <a href="https://agilemanifesto.org/principles.html">Principles</a> is says that an Agile project cannot have a plan, an architecture, a proper phase of research and discovery, or a deep understanding of business requirements (note: I said “business requirements”, not “software requirements”). In fact, I would go as far to say that every one of those things is actually a strong prerequisite for an Agile project.</p>
<p>No system, no matter how elegant or robust, can be considered well-designed unless it can be properly built. So, much in the same way a software architect would design a system, the project to build that system must also be designed. Only then can you provide a practicable estimate of its eventual cost (resources), schedule (time), and functionality (results).</p>
<p>However, it is crucial to understand that any project is only as valid as the information available at the time; so when requirements change, as they inevitably do, so must your project design in order to accommodate those changes. Think of it like charting the course of a ship across the Atlantic: constantly monitoring and replotting the trajectory of travel as the surrounding elements jostle and jolt the vessel in all directions. Just because you cannot control the elements does not mean that they should control you. Remember: “responding to change <em>over</em> following a plan” does <strong>not</strong> mean “<em>instead of</em> following a plan”.</p>
<p>The progenitor of Agile, the <a href="https://en.wikipedia.org/wiki/Toyota_Production_System">Toyota Production System</a>, explicitly states that <a href="https://better-operations.com/2013/01/27/toyota-production-system/">stability and well-understood working practices</a> form the very centre of its foundation. From the middle of the 20th century, and within a generation, Toyota went from being <a href="https://en.wikipedia.org/wiki/History_of_Toyota#Postwar_growth">a third-rate Japanese car producer</a> to the <a href="https://www.telegraph.co.uk/motoring/car-manufacturers/toyota/10594637/Toyota-still-the-worlds-biggest-car-manufacturer.html">most successful and efficient</a> manufacturer of automobiles on the planet.</p>
<p>By making (what we would now recognise as) <a href="https://agilemanifesto.org/principles.html">Agile Principles</a> part of their lifeblood, they didn’t just <em>do</em> Agile, they <strong>became</strong> Agile. At any given point, they knew exactly what their plan of action was, how long it would take, and how much it would cost. The instant a requirement changed Toyota were perfectly placed to harness that change, replot their course, recalculate their schedule, and redetermine their budget. The difference was that they could do this 12 months in advance of the original deadline instead of 12 hours, giving them plenty of time to work out (a) whether the change was feasible, (b) whether it was worth doing, and (c) how they could make it happen.</p>
<p>Agile is not about building software more quickly; Agile is about ensuring that building good software takes as long as it must take, but no more (even in the face of changing requirements). While change is inevitable, no-one ever said that it has to be free - all change comes with a cost, be that in time, money or both (and to pretend otherwise is just plain dishonest). However, through technical excellence, good design, and a deep understanding of the business requirements, it becomes possible to minimise the cost of change while sustainably harnessing it for competitive advantage. By doing this in the framework of a well-designed project, not only can you bring real Agility to your planning process, but to the whole of your development lifecycle.</p>Riccardo M Bennett-LovseyAgile development has found itself under a fair bit of criticism in recent years, from both managers and developers alike: managers tend to complain about Agile’s apparent lack of accountability, structure, and ability to deliver on schedule or budget; while developers tend to complain about pretty much the same things (just from a different angle). In truth, it is hard to blame anyone for becoming disenchanted, given how badly Agile tends to be practised in the real world: the chaos spawned from leaping to the keyboard at the merest whiff of a specification change; the seemingly wilful disregard for quality assurance (“We’re doing Agile - we don’t have time to test - just make sure you write it without any bugs”); and the almost pathological fear of committing to (literally) anything. Why should anyone have faith in Agile, especially if it gives you an in-built excuse to never think ahead? Regardless of what some would have you believe, a business of any size needs a plan. A business without a plan is little more than an expensive hobby, and the same goes for any significant software project.Thoughts on Agile (Part 3): the Principles2013-10-20T00:18:00+01:002013-10-20T00:18:00+01:00http://www.riccardos.net/blog/2013/10/20/thoughts-agile-part-3-principles<p>In my <a href="/blog/2013/08/18/thoughts-agile-part-2-manifesto">previous post</a> I went over each line of the <a href="https://agilemanifesto.org/">Agile Manifesto</a> to see if I could find a deeper meaning in the language. To summarize, my general conclusion was that <a href="https://en.wikipedia.org/wiki/Agile_software_development">Agile</a> is as much (if not more) about <em>business efficiency</em> than it is about software development, encompassing principles that can be extended to any problem-solving field of industry where rapid response to change is a key aspect of adding value for customers. I also said that I believe it is possible to <em>plan</em> for maximum agility, in a sustainable and predictable way, and that the <a href="https://agilemanifesto.org/principles.html">12 Agile Principles</a> reinforce this possibility (amongst other things). This time I want to go through each of the Principles one by one and explain my take on them.</p>
<h2 id="number-1">Number 1</h2>
<blockquote>
<p>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.</p>
</blockquote>
<p><strong>Meaning:</strong> the customer is king and our top aim is to provide our value for their money.</p>
<p><strong>Note:</strong> it does not just say “give the customer what they want”, it specifies the delivery of value in order to satisfy. By extension, what the customer wants may not always be valuable, and what the customer needs may not always be what they want. So be prepared to exercise your creativity and judgement to maximize the value you can provide.</p>
<p>Also, note that this principle emphasises the delivery of <em>valuable</em> software “early” (i.e. <a href="https://en.oxforddictionaries.com/definition/early">before the usual or expected time</a>), and <strong>not</strong> “immediately”. When done well, the value of software emerges as a manifestation of the components you build, and cannot be forced simply because the sprint deadline is in two weeks. Likewise, you should demonstrate the software you build when ready, and not build your software for the purpose of an arbitrary demonstration. Contrast this with Number 3.</p>
<h2 id="number-2">Number 2</h2>
<blockquote>
<p>Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.</p>
</blockquote>
<p><strong>Meaning:</strong> change is inevitable, so embrace it and realize that changes to requirements are what keep us gainfully employed. Being able to harness change and leverage the value added by late changes is what makes a process Agile.</p>
<p><strong>Note:</strong> a prerequisite for harnessing change is being able to contain it, i.e. ensure that change (even last minute change) does <strong>not</strong> reverberate throughout your project. Make it a strength of your team to be able to respond to change rapidly and efficiently without incurring medium- or long-term cost.</p>
<h2 id="number-3">Number 3</h2>
<blockquote>
<p>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.</p>
</blockquote>
<p><strong>Meaning:</strong> break your project up into manageable deliverables, keep your timescales rapid and focus on meeting your targets. Stretching your timescales out to multiple months, or even years, before you have anything worth delivering <a href="https://en.wikipedia.org/wiki/Duke_Nukem_Forever">is no good for your customers or for your team</a>.</p>
<p><strong>Note:</strong> this principle emphasises the delivery of <em>working</em> software “frequently” (i.e. <a href="https://en.oxforddictionaries.com/definition/frequently">regularly or habitually</a>). In this case, “working” simply means <a href="https://en.oxforddictionaries.com/definition/working">functioning or able to function</a> (i.e. not broken). If your software project is accumulating bugs and cutting corners for the mere sake of expediency, then all you are doing is compounding technical debt. Contrast this with Number 1.</p>
<h2 id="number-4">Number 4</h2>
<blockquote>
<p>Business people and developers must work together daily throughout the project.</p>
</blockquote>
<p><strong>Meaning:</strong> your team must gel and interact, no one person is above or below helping the team reach its project goals.</p>
<p><strong>Note:</strong> it does not state that “developers should listen to business people every day”, it specifically talks about both business and development working together as peers in a two-way conversation. So development must not lose sight of the business needs to be met, and business must have an appreciation of the technical challenges to be overcome. Neither will benefit without co-operation from the other.</p>
<h2 id="number-5">Number 5</h2>
<blockquote>
<p>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.</p>
</blockquote>
<p><strong>Meaning:</strong> make sure you hire the right people, give them what they need to do their job well and let them do that job. Do not micro-manage.</p>
<p><strong>Note:</strong> understand what you are doing and why, and find good staff who will share your vision and passion. If you give smart people a goal to believe in and they will <em>want</em> to follow you.</p>
<h2 id="number-6">Number 6</h2>
<blockquote>
<p>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.</p>
</blockquote>
<p><strong>Meaning:</strong> in our natural state humans are master communicators, and we can convey more understanding in a 20 minute conversation over coffee than we can in a dozen pendulous emails.</p>
<p><strong>Note:</strong> efficient and effective communication is about establishing a clear understanding between people. Even if that understanding is wrong, then at least it is <em>better</em> to be wrong than vague. A vague understanding makes it impossible to learn from ones mistakes.</p>
<h2 id="number-7">Number 7</h2>
<blockquote>
<p>Working software is the primary measure of progress.</p>
</blockquote>
<p><strong>Meaning:</strong> your business will not achieve sustainable success without delivering at least minimum viable quality. Any success in sales will quickly flounder if quality is found to be lacking.</p>
<p><strong>Note:</strong> the distinction between “working” and “valuable” was made in Numbers 1 and 3. Here we recognise that software must work before it can even begin to add value. Any perceived value that software may provide will instantly be lost (along with the goodwill and patience of customers) as soon as it breaks!</p>
<h2 id="number-8">Number 8</h2>
<blockquote>
<p>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.</p>
</blockquote>
<p><strong>Meaning:</strong> burnout will lead to disenchantment and failure. Regularly grinding your team into the ground is a sign of poor management and/or insufficient resources. If you have to pull out all the stops as part of your standard operating procedures then those procedures are <strong>not</strong> Agile!</p>
<h2 id="number-9">Number 9</h2>
<blockquote>
<p>Continuous attention to technical excellence and good design enhances agility.</p>
</blockquote>
<p><strong>Meaning:</strong> agility does not happen by accident, and sustainable agility emerges from high-quality design, technology and development.</p>
<p><strong>Note:</strong> this is my favourite Principle because it is the most ignored! The idea that Agile is simply responding to change as fast as possible, without any consideration for the consequences, is alarmingly common. Altering software may be materially simple but it is conceptually complex, especially when considering how a single change in one area of code can have a ripple-effect throughout the system if appropriate checks are not in place. The need to constantly revisit and refactor your code because it was done poorly/haphazardly/”without any real idea what we were doing at the time” could not be considered <em>agile</em> by anyone, but seems depressingly common in many Agile environments.</p>
<h2 id="number-10">Number 10</h2>
<blockquote>
<p>Simplicity - the art of maximizing the amount of work not done - is essential.</p>
</blockquote>
<p><strong>Meaning:</strong> keep your process lean, and avoid wasting time, resources or money.</p>
<p><strong>Note:</strong> since change in inevitable do not resist it, but do be resilient to it. Localised changes that require further work beyond the boundaries of the original problem space are not just wasteful, but also avoidable. Contain and accommodate change with minimal impact in order to achieve maximum agility.</p>
<h2 id="number-11">Number 11</h2>
<blockquote>
<p>The best architectures, requirements, and designs emerge from self-organizing teams.</p>
</blockquote>
<p><strong>Meaning:</strong> no person is an island in a development environment, regardless whether they are a manager, developer, product owner, business analyst, architect, project manager or stakeholder. Once a team reaches the point where it can no longer self-organize (either because it is too big or too dispersed), then quality of output can only deteriorate. Thus by working together in small, well-connected and efficient teams it is possible to gather the best requirements, create the best designs, plan the best projects and implement the best architectures.</p>
<p><strong>Note:</strong> the word “emerge” can mean various things, but in its simplest form it just means “comes out of”. It does <strong>not</strong> imply anything about the mechanism by which that emergence might happen, and certainly makes no suggestion that it should just occur by magic without any creative effort!</p>
<h2 id="number-12">Number 12</h2>
<blockquote>
<p>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.</p>
</blockquote>
<p><strong>Meaning:</strong> record-keeping, coupled with regular feedback, frank honesty, and self-correction, is the essence of a self-organizing team.</p>
<h2 id="summary">Summary</h2>
<p>Going back to the question posed at the start of this post: is it possible to <em>plan</em> for maximum agility, in a sustainable and predictable way, and do the Agile Principles reinforce this notion? Well, as the first Agile Principle highlights, the top priority of Agile Development is and has always been to satisfy the customer through early and continuous delivery of valuable software. The other Principles simply highlight key areas on which to focus in order to maximize your team’s agility: customer service, business management, communication and interaction, product quality, feedback and self-improvement.</p>
<p>While both the Manifesto and the Principles are deliberately broad in their advice on being Agile (there can never be a “silver-bullet” solution to solve every problem), there are three Principles that specifically describe what constitutes Agile or agility (2, 8 and 9): they state that, in order to be Agile, a process must be able to add value by harnessing change in a sustainable way, and that this can be augmented with a regard for technical excellence and good design.</p>
<p>I would add to this that the acid test for any degree of agility is being able to assimilate change with minimal overhead, i.e. making an unexpected change to a project should be as simple and safe as pulling a feature request off a sprint backlog. This is also an essential essence of good software design: encapsulating areas of potential change in your software in order to decouple the rest of the system from any impact resulting from those changes. Only with high-quality software design, project planning, technical excellence and a well-integrated team can you be sure to make agility an integral characteristic of your development lifecycle.</p>
<h2 id="other-posts-in-this-series">Other Posts in this Series</h2>
<ul>
<li><a href="/blog/2013/07/27/thoughts-agile-part-1-fear-and-loathing">Thoughts on Agile (Part 1): Fear and Loathing</a></li>
<li><a href="/blog/2013/08/18/thoughts-agile-part-2-manifesto">Thoughts on Agile (Part 2): the Manifesto</a></li>
</ul>Riccardo M Bennett-LovseyIn my previous post I went over each line of the Agile Manifesto to see if I could find a deeper meaning in the language. To summarize, my general conclusion was that Agile is as much (if not more) about business efficiency than it is about software development, encompassing principles that can be extended to any problem-solving field of industry where rapid response to change is a key aspect of adding value for customers. I also said that I believe it is possible to plan for maximum agility, in a sustainable and predictable way, and that the 12 Agile Principles reinforce this possibility (amongst other things). This time I want to go through each of the Principles one by one and explain my take on them.Thoughts on Agile (Part 2): the Manifesto2013-08-18T00:54:00+01:002013-08-18T00:54:00+01:00http://www.riccardos.net/blog/2013/08/18/thoughts-agile-part-2-manifesto<p>In my <a href="/blog/2013/07/27/thoughts-agile-part-1-fear-and-loathing">previous post</a> I let off a little steam by talking about some of the things that frustrate me about <a href="https://en.wikipedia.org/wiki/Agile_software_development">Agile</a> (or rather, how many people choose to interpret it). To summarize, one of the ways I see Agile positioning itself is as a shift away from the rigidity of older software development styles, such as <a href="https://en.wikipedia.org/wiki/Waterfall_model">Waterfall</a>. Unfortunately, humans being the dumb animals that we are, the philosophy of Agile also gets used to promote narrow, pre-existing notions of software development, or simply as an excuse to not think ahead (or actively avoid thinking ahead).</p>
<p>For a long time I thought I understood Agile, but later realized that I was making the same mistake of taking it purely at superficial face value. My guess is that this sort of behaviour is a good example of a wide-spread <a href="https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect">Dunning-Kruger effect</a>: since the <a href="https://agilemanifesto.org/">Agile Manifesto</a> is so short it only requires a minute’s concentration for someone to read it through and think they know it, at which point it becomes insanely easy to disregard any new idea or suggestion simply by saying “that’s not Agile” or “that’s not in the Agile Manifesto”. In order to understand how I could get the most out of Agile, I decided to go back to the Manifesto itself and see if I could spot a deeper meaning in the wording.</p>
<h2 id="the-actual-contents">The Actual Contents</h2>
<p>Here is what the Manifesto actually says:</p>
<ol>
<li>Individuals and interactions over processes and tools</li>
<li>Working software over comprehensive documentation</li>
<li>Customer collaboration over contract negotiation</li>
<li>Responding to change over following a plan</li>
</ol>
<p>The first thing to notice is that each line is a prioritization statement, simply stating that one thing in particular is more important than another thing. For example, the second line says: “Working software <strong><em>over</em></strong> comprehensive documentation”. Categorically it does <strong>not</strong> say “Working software <strong><em>instead of</em></strong> comprehensive documentation”, and yet I am sure we all know at least one person who was willing to dismiss all four of the right-hand-side attributes because they have followed that interpretation.</p>
<p>Secondly, the word “software” is only mentioned once, and even then it is almost incidental; the second line could just as easily say “Working <em>products</em> over comprehensive documentation” and the meaning would be virtually the same. Finally, there is absolutely no mention in the Manifesto of “estimation”, “features”, “user stories”, “testing” or even “switching the computer on”, but that does <strong>not</strong> mean that they cannot be part of the process.</p>
<p>There is a tendency for practitioners to focus overly on what they think Agile is <em>not</em> rather than what they think it is. This leads to processes being stymied and developers becoming disenchanted because they feel that their hands are being constantly tied. The simple fact is that nobody can say whether Agile includes or excludes any one thing in particular, since it is basically a list of recommendations rather than strict diktats (it is meant to be <em>agile</em> after all).</p>
<h2 id="line-by-line">Line by Line</h2>
<p>Breaking down each line of the Manifesto separately, it quickly becomes clear that the concepts behind Agile are more (substantially more) about business efficiency than they are about software development:</p>
<blockquote>
<p><strong>Individuals and interactions</strong> <em>over</em> processes and tools</p>
</blockquote>
<p>This is about the importance of people and how they work together to achieve success, which could just as easily be applied to any type of business. In other words: having a well-oiled team that can gel and self-organize is more important than having the latest buzzword methodologies or development environments at your disposal. You would be better off with a group of smart, relatable team-players, who can communicate well and solve problems with a pen, a whiteboard and a jug of coffee, than a bunch of socially-immiscible mavericks armed to the teeth with 64-core workstations and Visual Studio 3000 (of course, if you can have the proper tools as well then so much the better).</p>
<p>When it comes to communication efficiency and human engagement, I also see this principle extending beyond the boundaries of the development team itself and encompassing product owners, business analysts, architects, project managers and stakeholders, all of whom are vital cogs in the development lifecycle.</p>
<blockquote>
<p><strong>Working software</strong> <em>over</em> comprehensive documentation</p>
</blockquote>
<p>Obviously the primary goal of software development is to add value by creating a working product or service; without that you are no longer part of a going concern within your company and you run the risk of finding yourself in the unemployment line. So clearly the priority here should be about creating working software. There is little point in documenting something that is half-complete or worse, broken. But, again, this does not mean one should completely dismiss the need for effective documentation (note that it specifically says “<em>comprehensive</em> documentation”, not just “documentation”); once you have a working solution you will clearly need a way to communicate how it works to your customers, and there are a number of adequate ways to do this in the early stages other than written pages (e.g. e-Learning, consulting, in-house training, presentations, or even phone calls). Plus, by its very nature, software will change and evolve as requirements inevitably do, and having to go back and rewrite a thick tome of fully covered user instructions whenever new features are added will rapidly lead to resource haemorrhaging.</p>
<blockquote>
<p><strong>Customer collaboration</strong> <em>over</em> contract negotiation</p>
</blockquote>
<p>When I first saw this I asked myself how customer collaboration and contract negotiation could possibly be related, but with a little extra thought I started to get an idea of where it might be coming from. Both are about customer interactions and, by extension, whether we regard our customers as allies or adversaries: contract negotiations are generally competitive (two parties focussing to secure the best individual deal for themselves) while collaborations are generally more convivial (two parties focussing to secure the best deal for everyone).</p>
<p>In an Agile environment, requirements and plans can change every day (sometimes every hour), and a team that works with customers to create the best product in a fluid manner will be maximally efficient when compared to a team that gets bogged down in finickity (and rapidly outdated) procedural details. Does that mean that contracts are unimportant? Absolutely not; all vital cards must be laid out on the table from the start so that both parties know where the boundaries lie, but those battles must be picked carefully so as not to waste time, goodwill or money.</p>
<p>While the wording is specific to (perhaps the most) important types of customer interaction, the general message is sound in its advice: treat customers as partners rather than obstacles, recognize the times when you must be flexible and when you must be firm, and work with them to determine the best solution for everybody.</p>
<blockquote>
<p><strong>Responding to change</strong> <em>over</em> following a plan</p>
</blockquote>
<p>I suspect this line to be the single biggest cause of dissatisfaction with Agile: the perpetuation of the idea that Agile development cannot (or <strong>must</strong> not) follow a plan. Because who really needs a plan anyway? Software is easy to write and easy to change, and if something breaks at 3am on a Sunday then we can just wake up one of the code drones to come and fix it in production. That is what Agile is all about anyway, right? Well, I am glad to say, categorically <em>no</em>. But I have met those who think that having any sort of a development plan is nothing short of <em>anti</em>-Agile, and that jumping to the keyboard at the merest suggestion of a change in requirements is the only way to do <em>real</em> Agile.</p>
<p>This is obviously an extreme view but it is also a dangerous one: designing and implementing a good project plan is difficult and requires attention, practice and skill, so naturally it would be much easier to dismiss the need for a plan and to not have to worry about any long-term cost to the business. The project is going to exceed its budget and overrun its schedule anyway, so why accept the responsibility for the inevitable failure?</p>
<p>The fact is that any business, regardless of size or shape, requires some form of plan (remember that the key phrase here is “over”, not “instead of”). A business without a plan cannot be a going concern, and a business that is not a going concern is dead in the water; you may as well turn off the lights and go home. Plus, anyone who has worked in brownfield software development knows that software is <strong>not</strong> so easy to change (at least not reliably or safely) without some form of planning or consequence management behind it. There is a reason we reserve the term “brownfield” specifically for describing this type of activity: partly as a warning to would-be stakeholders, but also as a recognition that there are additional challenges to be faced when compared to greenfield work. The real question is how best to plan a project and orchestrate for maximum agility, if such a thing is even possible?</p>
<h2 id="summary">Summary</h2>
<p>Agile is not just about responding to change for change’s sake. Software requirements are living, evolving creatures that do not stay static for very long, so being able to react efficiently to those changes is a vital facet of development. However, disregarding the need for occasionally stepping back, thinking, asking questions, productive discussion and challenging conventional wisdom is detrimental to the success of a business. Blind and immediate reaction to changing requirements leads to poorly defined features, over-emphasis on rapid output and unsustainable attempts at flexibility. This, in turn, damages long-term efficiency and the ability to manage workable commitments.</p>
<p>The take-home-message of Agile is a series of very simple but effective priorities. The Manifesto itself may have emerged from the software industry, but to me the concepts are more about <em>business efficiency</em> than anything else. Going over the contents in detail, I can picture it applying equally well to any field of business where rapid response to change and logical problem-solving are core requirements. The real question is how best to maximize a team’s agility and is it possible to do so in a predictable way, so as to provide sufficient structure to fit into a sustained business strategy? I believe it is possible to plan for this sort of agility, and I believe that the <a href="https://agilemanifesto.org/principles.html">12 principles behind the Manifesto</a> emphasize this possibility as well. An idea that I will expand upon in <a href="/blog/2013/10/20/thoughts-agile-part-3-principles">Part 3</a>.</p>
<h2 id="other-posts-in-this-series">Other Posts in this Series</h2>
<ul>
<li><a href="/blog/2013/07/27/thoughts-agile-part-1-fear-and-loathing">Thoughts on Agile (Part 1): Fear and Loathing</a></li>
<li><a href="/blog/2013/10/20/thoughts-agile-part-3-principles">Thoughts on Agile (Part 3): the Principles</a></li>
</ul>Riccardo M Bennett-LovseyIn my previous post I let off a little steam by talking about some of the things that frustrate me about Agile (or rather, how many people choose to interpret it). To summarize, one of the ways I see Agile positioning itself is as a shift away from the rigidity of older software development styles, such as Waterfall. Unfortunately, humans being the dumb animals that we are, the philosophy of Agile also gets used to promote narrow, pre-existing notions of software development, or simply as an excuse to not think ahead (or actively avoid thinking ahead).