Mastering the transition to Agile Development in large companies… using Lego® bricks.
--
Here at TOP-IX Consortium we are Big Fan of Agile development, we believe in it like a real “Credo” and we strongly adopt this kind of approach in all our software development projects… even when the final customers have bought a more classical “waterfall” product.
(Sssst, do not say that to them!)
Agile Development is definitely not a novelty. The official Manifesto is now sixteen years old… in February 2001, in fact, seventeen software developers met at the Snowbird resort in Utah to discuss lightweight development methods in order to work better and to increase the value and the impact of their work.
Pillars of the Agile Development manifesto are:
a) Individuals and Interactions over processes and tools
b) Working Software over comprehensive documentation
c) Customer Collaboration over contract negotiation
d) Responding to Change over following a plan
Practically this means splitting big and comprehensive yearly software plan in small iterations (A.K.A. SPRINTS — 1 to 4 weeks long — each of them ready to be a working and testable release). Requirements and to-dos are defined together with the “customer” (there is a better definition of roles but it is not the scope of this article) right before the sprint starting and they will not change for the duration of this bunch of time. After the end of the sprint, the list of the tasks (developed product features) is validated with the “customer” that might decide to change direction, to adjust a wrong assumption or to stop wasting money :-)
We particularly care about the last point of the Manifesto: “Responding to Change over following a Plan”. In fact what we have learned working a lot with Innovation is that “changes” happen every single day (sometimes even more frequently) and most of all, if you are not able to change fast (experts call this “pivoting”) probably you are building the road for your own epic fail.
But we are not here to talk about the Agile Development itself, you would find tons of papers, communities, PDFs , web pages talking in depth about this topic showing all the essential components, rules of the game, different variations, and use-cases.
In fact, the main purpose of this article is discussing on “How to train Agile Development in large companies? How to help them to adopt this kind of methodology from scratch?”.
Well, if we look back at our direct experience we have started just browsing on Google, then we have asked to some good friends (and coding experts — Axant.it) to give us some hints and to support us in some real small projects… and after this it was a long, iterative, learning-by-doing process. The advantage in our case was having the chance to work on many tech startup projects. As you probably know startup is the perfect environment where to apply Agile Dev. methodology. This is because it is perfectly complementary to the Lean Startup approach… where the focus is on customer validation, fail-fast-and-soon, MVP (Minimum Viable Product) release.
But what happens if you are a large company and you want to make a transition to Agile Development?
In large companies, particularly those ones with a long story behind them, doing a transition is never easy, and software development is not an exception.
In the agile approach, developers have to be put in the condition to work without constraints focusing, for the duration of the sprint time, only on the priorities given and decided during the planning. You can imagine which are the possible interrupts in this process:
-) I need a stage area but deployment needs a multiple-step procedure, asking permissions, filling modules, waiting for other unit work, entering a not-well-defined queue.
-) I made a perfect plan for my sprint planning but then the super-Boss jump on my desk and completely changes priorities.
-) Developing Team is divided in multiple units and it is difficult to manage a daily interaction in order to keep the focus on the project.
-) Parts of the product are outsourced and the supplier does not use the same Agile methodology.
-) … feel free to add other points according to your experience.
Nevertheless there are many good and well-known cases of Agile Development applied in large companies: Spotify, Airbnb, City bank, Salesforce.com,…
so the two “worlds” may coexist!
and again the crucial point is “How to master the transformation leveraging the training”.
A funny but effective way that we have found is to share (we are not teachers by profession and by mission) our experience on Agile Development with a one day workshop that put together:
-) a bit of theory (introduction to Agile, connection to the LEAN methodology, rules, roles, tools, …);
-) some concrete examples comparing the Agile approach and the Waterfall approach;
-) an intense “hands-on” session using LEGO® Bricks to simulate how the Agile works in practice.
Why Lego?
-) Because you do not need code skills, so you can involve in the training also no-tech guys.
-) Because using “hands” helps you to keep the focus and to absorb concepts (this is the Theory behind Lego Serious Play).
-) Because building something with Lego is a good metaphor of Coding.
-) Because it is funny :-)
Is this Agile + Lego-Game training a brand-new idea by our company?
Not at all! Even in this case, other brilliant people before us did test and produced lots of useful documentations and examples from which you can take inspirations (an example here). In saying that, we can proudly assert that we are pretty good in making this “serious game” effective and engaging!
The bad news is that training is just the very beginning of the story. Through the game, people understand practically what are the pillars of the AGILE approach, but then moving to a concrete application is still a matter of hard work… “In theory, theory and practice are the same. In practice, they are not.”
Well, what are the next steps?
We haven’t found yet the secret recipe for success; maybe you can help us in this challenge, but through our experience we were able to state a set of “lessons learned”:
- ) Commitment is king! Transition to Agile (Whether you’re considering a small unit or it’s at the whole company level) requires an executive manager (or more than one) that takes the responsibility to test and put in practice the “new” approach.
-) Transition takes time: Agile is not a de-facto solution… particularly if you are using it for the first time. Take your time to practice, to acquire the new concepts, to fail and to iterate. Use iterations in order to understand your specific needs, asset and weaknesses.
-) Small is better… then scale! Be sure to make practice on small and not-mission-critical projects, you will have time to scale it on large projects.
-) Manage it internally! Outsourcing is important and needful, but being sure to have the core skills inside the “company wall” is a MUST!
-) Find your Agile Way. This is probably a suggestion that Agile “purists” do not like… but we strongly believe that having a better result is still the priority. So, feel free to adapt the original rules in order to maximize the results in your specific environment.
-) “Think” like a start-up. This is not an easy task but, using the words by Albert Einstein: “We can’t solve problems by using the same kind of thinking we used when we created them.”
Conclusions
Agile Development is nice! And actually is probably the most effective way to manage uncertainty in software development, but also in many other business processes. Nevertheless we have to keep in mind that it is just a tool, not the solution itself… so implementation is more important than following literally a set of rules and a Manifesto.
Are you a startup? No doubts that Agile Development should be your “mantra”.
Are you a large corporate approaching now the transition from Waterfall to Agile Development methodology? In this case, your way will be more complex. Consider a bunch of hours of training but, most of all, plan and design a duty-free environment (small-enough, flexible, self-sufficient, startup-like, out-of-the-box) where to test, implement and apply the approach on your business case.
