Bridging the agile gap
The agile manifesto is getting to the start of its third decade. (Follow the link if you are new to it.) About two years after its creation, I wrote my first lines of code. I have never developed software in a world without the agile manifesto. There is a lot of people who have though. And there are still a lot of the “old ways” left in the IT-industry. For the purpose of this text we have two groups. We have those who have experienced the emerging of agile, sometimes from a very disadvantaged position. We also have those taking it for granted, since it has always been there. The agile gap is about what happens when those groups meet.
When I started working I met a lot of people who had worked in the kind of projects that the agile manifesto was a reaction to. They had first hand experience of the pain that agile was supposed to fix. Often they had fled the old company before ending up in a team with me.
In my world “working software over comprehensive documentation” was a “no sh*t Enola”. But I still thought that it was a good idea to write some things down. I am quite forgetful. For those previously stuck in waterfall without water, documentation was the evil personified. The manifesto states “…, while there is value in the items on the right, we value the items on the left more.” But to some it still turned into “no processes, contracts, tools, plans or documentation!!!”. That made it very hard to be the new kid in the team. It made it hard, full stop. It actually gets very tricky to write working software, collaborate with customers, adapt to change or interact with people, without any kind of structure.
The inevitable pendulum of human culture, one could say. We do see “agile frameworks” with lots and lots of structure those days. So much processes, contracts, tools, plans and documentation that it could be argued that there is no room for agility in them. Are we doomed to the eternal circle of throwing out babies and bathwater?
My suggestion is that we put all our focus on what we do want. I believe that The heart of agile with its collaborate, improve, deliver and reflect is one way to do that. Things that we want to avoid will change with time. For me right now it might look like “Working software over extensive backlogs” “Customer collaboration over genius entrepreneurs” “Individuals and interactions over 10x programmers” (Ok, to be fair, I do not really value the right side of those, but I would perhaps miss them if they were branded as the new evil.) Being guided by what we fear won’t help us. It might even make us avoid the things we do want, like collaboration, since it is harder to collaborate without processes for retrospective or tools of communication.
Bridge the agile gap by focusing on what we do want! We can use the left side of the agile manifesto, The heart of agile, Theory of Constraints, Lean or any other teaching that share their general message. I would say that the essence is: Focus on what really brings value, do it together, optimise for fast feedback and use what you learn. And if you see an old oaf who refuses to write a readme, or a young brat who seem to want waterfall all over again, remember that you probably work for the same outcome, you just have different experiences.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about agile methodology, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.