The secrets to re-on-board the devs in agility
Last updated
Was this helpful?
Last updated
Was this helpful?
Like we have seen in the previous article. Agility has been diverted and no longer belongs to developers. The aim of this article is to provide some keys to re-on-board developers into it.
In 2008, Uncle Bob, one the 17 from the agile manifesto, shared this kind of concerns about agility. For him agile was too much focus on the process (how to build the product fast and how to build the right product).
From his point of view developers were considered only as executes and not as caring people.
For those reasons, he wanted to add a fifth value in the agile manifesto: “Craftsmanship over Execution” (“Craftsmanship over Crap” in the first version).
The whole idea was to reduce the gap between the agile and technical world by emphasizing the importance of people’s skills when it comes to software development. He wanted to focus on technical excellence that is crucially important to deliver value.
The same year he has initiated the Software craftsmanship movement with a new manifesto: .
We need to create high quality code :
Automated tests
Business languages in the code
Simple design
Constantly improve the code
Apply the boy scout rule
We teach anyone with a willingness to learn (sharing, mentoring)
We partner with our customers to understand their business.
We do not propose solutions until we are sure we have found the right problem.
We are not factory workers, so we need to say NO when it’s for our customers good.
If we think about the way products are built with waterfall approaches everything is disruptive in a framework scrum.
We want to deliver in an iterative and incremental way, there are new roles and there are plenty of events promoting communication, collaboration and continuous improvement. Planning is handled totally differently with a product backlog, documentation is done in a “just in time” way.
Teams need to implement software development practices to support iterative and incremental approach.
To do so, there is a lot of answers in XP like :
Refactoring (the practice of improving code continuously) is at the center of everything in XP because by essence nothing is definitive, we are continuously adapting.
Developers need to be trained and coached on XP because it provides a lot of practices that make possible to build and deliver a product in an iterative and incremental way.
XP should be more pushed as an alternative to Scrum. It could re-conciliate developers with agility.
A lot of energy and money are spent by companies on new roles that emerged from frameworks like scrum (Product Owner, Scum Master), BUT what about the people that really build the products? What about technical practices and excellence?
Companies need to invest in agile technical coaching that promotes excellence and spreads the practices that are really useful for the teams to deliver a quality product.
It is what I do since many years now. I strongly believe that developers are really the key to an agile transformation and companies need to on-board them from the beginning in their agile journey.
Since many years now I have developed approach and tools that help to train and coach developers on the technical side of agility. At the time with some colleagues we have developed a card game that promote this mindset :
With agile values and principles developer’s work should be valued and they should work in an environment where they are not considered as “code monkeys”.
To create this culture, companies need to invest in a really simple but powerful tool: feedback. It’s not something people learned at school but it’s something people need to learn.
As agile enthusiasts we need to help people to give feedback to each other’s.
When you think about the skills required to be a developer at the moment (front-end, back-end, security concerns, architecture, operability, …) you easily understand how much they are keen to learn new stuff every days. Not that much jobs are like this.
Being a developer requires a lot of intrinsic motivation to learn and master new stuff every day. Developers push organizations to innovate and they should receive more feedback for doing it.
Developers should be proud to be developers but in many companies the peter’s principle is applied:
A very good developer has success, so he is promoted as tech lead
As a good tech lead, he is promoted as software architect
As a good software architect, he is promoted as CIO of the company and at this position he fails.
He fails because skills required for a CIO position is not technical ones, is more about management skills and maybe this developer was only a technical guy that wanted to work on technical stuff.
It’s sad to see that human resources processes are still founded on this kind of archaic principles. If people want a raise they need to go up in their companies, they need to have a huge job name that does not mean anything for anyone. There is often no alternative.
Sometimes people are lost in a job that do not fit them only because this kind of culture.
As agile enthusiasts we need to help HR to change and really promote this culture of being proud of being developers. We need to help them revisit career path.
Often agile has a bad image in developers mind because they have only met agile dictators/evangelists that crucially lacked pragmatism. Those kind of people have negative impact on team’s health (self organizers).
Because agile coaching is pretty new, companies do not really know what to expect from it. So they are confident in theirs partners to do the right stuff and often the right stuff for agile coaches is to push agility to the extreme without any pragmatism and sometimes by forgetting the heart of agile.
We need to spread the idea that agile coaches are not evangelists nor dictators but pragmatic people.
Agility requires pragmatism, so we must demonstrate it and incarnate it everyday.
This movement still exists, and some books have been written on it like the best-seller “” from .
: an extreme approach to software development that ensures every line of code is tested because before writing any line of production code you must start with a test.
: 2 developers on the same computer to write code collaboratively (improve quality, knowledge sharing and reinforce the collective ownership feeling).
: integration of the code in a central repository every day multiple times.
