The hidden secrets to re-on-board the devs in agility
Why you should read this article
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 agility (see our previous article about the devs to understand the context).
The software craftsmanship
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: the manifesto for software craftsmanship .
Well-crafted software
We need to create high quality code :
- Automated tests
- Business languages in the code
- Simple design
Steadily Adding Value
- Constantly improve the code
- Apply the boy scout rule
A Community of Professionals
- We teach anyone with a willingness to learn (sharing, mentoring)
Productive Partnerships
- 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.
This movement still exists, and some books have been written on it like the best-seller on the topic “The Software craftsman” from Sandro Mancuso.
eXtreme Programming (XP)
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 :
- Test Driven Development: 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.
- Pair programming: 2 developers on the same computer to write code collaboratively (improve quality, knowledge sharing and reinforce the collective ownership feeling).
- Continuous integration: integration of the code in a central repository every day multiple times.
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.
Invest on technical/craft coaching
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 craft coaching that promotes excellence and spreads the practices that are really useful for the teams to deliver a quality product.
It is what we do at Agile Partner we 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 travel.
Since many years now we have developed an approach and tools that help us to train and coach developers on the technical side of agility.
It’s for us the best way to have everyone on-board and guarantee the success of our clients.
Value developer’s work
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.
Change the HR processes
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.
Avoid agile dictators
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.
Some of our agilepartner’s craft tools
Here are some craftsmanship tools we have created that you could use in your companies :
- Craft-challenges : a card game you can print promoting craftsmanship culture and practices.
- Our open source technology radar version developed with jekyll (a static site generator) allowing you to organize technologies used in your company.
- Craftsminator : an escape game with cards for developers that we use during our job interviews.
You can find details about our craft training on our company website here :
This article has been built based on our talk “Lost in agile” from Adrien Muller and Myself
