Earlier this year Karsten Kempe enjoyed a double premiere: he became a Visual Studio ALM MVP, and he then participated in the ALM forum for the first time. While several people from Red Gate did attend the forum, Karsten’s write-up of the 3-day event is thorough and republished here in English with his kind permission.
Originally published on April 2, 2014
The ALM Forum offered participants a platform to exchange ideas on the current challenges of modern software development, and so it touched on topics at several levels of the software process. For example, my highlights of Day 1 were the keynote by James Whittaker - "A Future Worth Wanting" - and the Birds-of-a-feather session by Steven Borg - "What's Git got to do with it". But first things first...
The many faces of Agile
The opening keynote - "Disciplined Agile Delivery: The foundation for scaling agile" - was hosted by Scott Ambler, the Co-Creater of the Disciplined Agile Delivery (DaD) framework. Scott presented excerpts from the framework, which is a possible answer to the question of how large organizations could develop software in an Agile manner. Essentially, the framework enables an Agile mind-set, making it easier to pick out the best approach and thinking for your organisation from all the available agile models. The basic principles of DaD are neatly encapsulated in Scott’s slides:
Since the DaD framework is simply too powerful to be packed in a keynote, there was an opportunity in the evening for each participant to get a signed copy of Scott’s book, "Disciplined Agile Delivery". Nice!
Unfortunately, I felt that the topic and the presentation of the opening keynote wasn’t rousing enough but, on the plus side, James Whittaker’s presentation was significantly better.
James Whittaker was the second keynote speaker, and addressed the somewhat philosophical topic of "A future worth wanting". In a very entertaining way James whisked the audience into a future in which my apps and devices are not transmitters of just any old information, but of exactly the information that interests me as an individual. In James’ future, apps serve to pool and recycle user-specific information, much of which already exists (for example) in the huge data stores of the likes of Facebook or Google. Leaving aside the topic, if you have a chance to hear James Whittaker present, you should take it. The man is an awesome speaker.
Another really great session was run by Steven Borg, co-founder of Northwest Cadence and a Visual Studio ALM MVP, on the theme "Metrics that matter: Improving lean and agile, kanban and scrum". Probably the most important comment of the whole presentation came at the very end: Metrics are like fire! Powerful but very dangerous!
This sentiment seems to me to be both very true and very important, because every metric used has both positive and negative consequences. Pulling an example from Steven’s presentation, consider a call centre that wanted to measure the number of telephone calls made by staff each day. The result might be that customer calls were quickly answered, but just as quickly hung up. Thus, although the number of answered calls have been multiplied, the quality of each single call would be greatly reduced.
The lesson here is that you should choose your metrics incredibly carefully, and they should have four characteristics: they should be Simple, Honest, Comparable and Actionable.
We are familiar with the main metrics of Scrum (Velocity, Burndown) and kanban (WIP, Lead Time), but what is remarkable is that the Scrum and Kanban models usually get by with JUST these few metrics, and that’s because these models operate through another, more powerful metric - feedback!
In the agile world it is much more important to gain regular and timely on you work (in order to know whether it is what the customer expects) than to measure exactly how on-time and in-budget we are. What use is my software is halfway on-time and in-budget, but unfortunately nothing like what my client has requested? That’s right – none at all.
In Steven’s option, the "one metric to rule them all", the key to agile success, should be to reduce the "time to feedback". This actually makes a lot of sense with relatively little assessment: the sooner we can get feedback, the faster we can intervene in any wayward processes, and the greater our success. Try it out!
Birds of a feather
Finally, I’d like to mention a slightly different form of knowledge transfer which I hadn’t previously encountered, called "Birds of a feather" (BOF) – a colloquialism that means something like "like-minded people". The BOF session which I attended was also convened by Steven Borg, and was called "What's Git got to do with it?", and I thought it was excellent. When Steven realized that many of the people in the session were Git-interested, but with little actual Git experience, he quickly organized for the Git experts in the group to give us a short Git workshop with highlighs. That’s what I call interactive!
I also had the opportunity to visit another Birds-of-a-feather session on the second day of the event, on the subject of "The Fundamentals of Lean Software Delivery." I really enjoyed this personal and interactive way of exploring a topic: First, all participants presented and shared their expectations of the BOF session, and then these expectations and the emerging questions were then written on a whiteboard and discussed by the group.
Birds-of-a-feather is a great way to learn from the experiences of many, and not just benefit from the opinion of a single speaker. If this sounds like fun, I can also recommend you look up Open Spaces events.
The highlights of day 2 were definitely the opening keynote from father-of-Scrum Ken Schwaber, and the closing keynote from Steve Denning. The two speakers tackled the questions of "How is the success of agile techniques measurable?" and "How can traditional management be convinced of the value of Agile?" respectively, to the delight of the audience.
In his “State of Agile” keynote address, Ken Schwaber (the co-inventor of Scrum) pursued the question of hard evidence and business metrics that can be used to demonstrate the success of agile practices.
That agile frameworks such as Scrum or Kanban have positive impact on business processes is now well understood in the software industry. In a 2013 survey, Forester Research found that agile companies can develop successful complex software faster, and make more money, than those who work according to conventional non-agile principles.
But the big question is how can the success of agile practices be argued and demonstrated without relying on conjecture, anecdotes, and self-referential metrics? What immediate proof or data can we point to?
In an effort to make some progress on this, Schwaber is currently investigating an approach called "Evidence-Based Management" to make the success of Scrum measurable, or rather to find out which agile practices exert real influence on software development.
Evidence-Based ManagementEvidence-based management seems like a sensibly consistent system and should, in principle, anchor management practices in social and behavioural science, and formally link retrospectives and evaluations to actions or events as a compelling basis for further action. - http://en.wikipedia.org/wiki/Evidence-based_management
I, for one, am very much looking forward to seeing what evidence he can produce. Moving on!
I also enjoyed an impressive presentation on "The Principles and Practices of Continuous Deployment" by Mike Brittain - Director of Engineering at Etsy (an e-commerce platform for the buying and selling of handmade products). Here’s a remarkable piece of information to start with:
At Etsy, any change that ends in a successful build is automatically delivered to the production system. The result of that process is that, on any given day, there are typically more than 30 deployments performed to production.
Etsy has reached this degree of sophistication with the help of a very well thought-out release pipeline and the use of configuration flags. For example, changes are tested in an exact copy of the production environment, and configuration flags allow the enabling or disabling of incomplete features (or features being tested) in the production environment.
Naturally, the way this process is developed and delivered at Etsy is fully tailored to their deployment process. Off-the-shelf tools are useful in this field, but they have to be customised and adapted to fit your needs – don’t try and dramatically change your practices to fit the tools. In terms of adapting for purpose, it’s worth bearing in mind that the only things that count for Etsy is the ability to keep its website online and the reaction time between record bugs and getting fixes into production, and so everything is optimized for one of those two results. I’ll come to this in Day 3.
Day two was rounded off with Steve Denning’s session on "Transforming management through Agile". Steve has worked for the World Bank for many years, is a renowned author, and was one of the ten most admired Knowledge Leaders worldwide back in 2000. Overall, an impressively smart man. He illustrated the impact of so-called “traditional” management on a company and its employees, and how this way of thinking is unsustainable in the long term, ending in the downfall of the company because it simply cannot keep up with more innovative competitors.
In Steve’s opinion, every management practice derived from the traditional goal of "shareholder value" should be cast aside or evolved to achieve the highest possible customer satisfaction – meaning an enormous rethinking of the management level of enterprises!
It’s a fine ideal, but unfortunately I thought he did a lot of hand-waving, and not enough concrete discussion about how these hard changes might be achieved - he only gave us these five tips along the way:
Nevertheless, I found Steve’s style of persuasion and presentation to be outstanding, and if I took one piece of advice from the session, it was: "If you want to convince a manager, then you have to talk like a manager!"
All good things come to an end. Three days packed with informative lectures, interesting discussions and lots of coffee, and once again two sessions on the final day of the event really stood out for me: Roy Osherove with his very exciting "Notes to a Team Leader", and Dave West who impressed with his knowledge of "Lean ALM".
But first! The kick-off for the last day of the conference was Sam Guckenheimer with a session that I’d already encountered - "Transforming software development in a world of services". For those not familiar with the presentation, Sam was basically reported on the experiences that Microsoft has had on the way to a very agile process.
I actually summarized the contents of Sam's talk in more detail in my earlier post about the ALM Days in February, so I recommend picking up the details there (That post is written in German, by the way).
Continuous Deployment: The Return
The second talk I attended was the continuation of Mike Brittain’s keynote from day two of the conference. In "Advanced Topics in Continuous Deployment", Brittain described how the deployment process at Etsy has been improved step by step, ultimately resulting in the capacity for up to 30 deployments per day thanks to four essential elements: Config flags, automated deployment processes, semi-automated release management and progressive schema changes. Let’s take a look at those in order…
Only the use of config flags make the continuous deployment of new code into the production environment possible. Basically, these allow you to turn sections of code "on and off", meaning that changes can remain hidden from the users through the configuration, testing or even development phases.
Next, only when the deployment is fully automated can it be done quickly and smoothly. So for its production environments, Etsy always provides a live cluster and a "dark" cluster. Deployments are always first rolled out on the dark cluster, thoroughly tested and, only when everything is in order, the cluster traffic is switched via a config flag.
Carrying on down the pipeline, Brittain describes semi-automated release management as a user-controlled release process – i.e. any developer who wants to roll out a change must collaborate with other developers (up to a maximum of seven) and coordinate the deployment process. According to Brittain, total automation is not desirable because individual and context-dependant decisions must often be made that differ from the standard procedure.
As for Schema changes, they’re treated as interface changes, always proceeding as follows:
It was an interesting inside look at a working continuous delivery process and, along the way, Mike Brittain also gave attendees some tips on how Continuous Deployment can be achieved. It’s best to start small to introduce the idea with just a few config flags, test automation and monitoring in the production environment. It’s also essential that you develop a robust fall-back strategy for emergencies if a deployment goes wrong! For more details, check out Mike’s deck on SlideShare.
Software Team Leadership
Roy Osherove - author of the book "Notes to a software team leader" and blogger on 5whys.com - presented an idea that resonates strongly with the attendees. In his session he wrestled with the question of which tasks should have a team leader, as well as the fact that, in his view, the main task of a leader is to make their team better. They should motivate [their team] to seek out challenges, because the greatest potential for improvement only appears when we’re lured out of our comfort zones.
Autonomy - Adaptability - Transparency - Collaboration
Finally, I want to talk about the closing keynote by Dave West, the Chief Product Officer of Tasktop. In "Lean ALM: Making Software flow from idea to implementation" West described four key factors that he’s found will separate success from failure when dealing with increasingly complex software and trying to practice lean software development: Autonomy, Adaptability, Transparency and Collaboration. Let’s break that down a little:
As is well-described in Dan Pink's "Puzzle of motivation", giving teams autonomy leads to greater performance and motivation. Autonomy is crucial in a world of knowledge workers, but how does it fit into an ALM process, with specified and measured values? Well, that requires a lot of subtlety and skill from the managers to find the right mix. West didn’t have clear answers, but he did pose some excellent questions for us to dwell upon.
Being agile also means always adapting to existing conditions. West showed that in today's software development environments “Agile” more often means a hybrid model where requirements engineering, planning and a cyclical approach play a major role. He called this model the "Water-Scrum-Fall" approach to software development.
As entertaining as this sounds, the difficulty of "Water-Scrum-Fall" is that there are different cycles between the different artefacts that need to be somehow brought together at the end of each development process - even between long-established requirements and very quickly forced through "Developer Tasks".
Transparency is important in the agile process and, in ALM, it should be almost inevitable. I won’t dwell on it for long as West didn’t share any particularly startling insights in his session, and I think it’s well-understood. After all, only if all process participants have transparency at all times can complex systems can be built and made manageable.
The final important factor necessary to allow us to cope with the increasing complexity of systems is cooperation. Software development is a team effort. Only well-established and highly-collaborative teams achieve high performance. This too, was uncontroversial in West’s presentation, which went on to say that companies which can fulfill all of these internal goals have the best chance of keeping pace and succeeding in the challenges of modern software development.
As I said at the start of these write-up, the ALM-Forum is designed to share ideas and knowledge relevant to every level of the software development process. The main observations for me centred around a few key ideas:
- Agile practices need to extend up to the leadership and management, and that feedback and learning are more important than staying on-budget / on-time etc.
- Continuous Deployment is the ultimate expression of agile practices, but it takes a lot of work to get there. You need to have confidence and clear goals in mind when you decide to start that journey.
- If you’re doing to adopt or change any of your practices, you need to think about what outcomes you’re aiming for. In other words: what are your metrics? We instinctively believe Agile to be an inherent good, and the research suggests that it is a highly effective pattern for managing (software) teams. However, you need to pick your metrics with forethought and planning because, if you’re not careful, you’ll quickly end up optimizing for those metrics in ways you may not expect or like.
- One main principle of being agile is to visualize your process and the trend of your development. Almost every exhibitor at ALM Forum demonstrated how their tool could simplify and visualize the development process, but no tool would help if your mind is not agile enough. Ultimately, the whole practice is all about transparency and honesty, and acting like that might be not as simple as it seems at first.