We have been doing Agile for over 10 years now and we have been focusing on people, interactions, team building, the ecosystem. As a result, we are now working in a software environment where “processes are more important than technical practices”. This is how Sandro Mancusso started his keynote at ITAKE Unconference 2013, a talk that was very appreciated by the audience. You can watch the video or continue reading its summary.
Agile in Software Development is as much about programmers and technical practices as it is about processes. The real deliverable is the working software built with well-crafted code. “Software crafters care about delivering value with well-crafted code”.Even more, for them Software Craft means putting responsability, professionalism, pragmatism and pride back into software development.
Most of us consider this impossible to have. Why? Because we are always developing software under pressure. But are we sure we can’t overcome this hurdle? We can, if we write well-crafted code. Technical debt and bad code will always increase the time spent per feature. This increase is less noticeable in Agile because stories get sliced into smaller ones.
Agile talks about getting constant feedback. The problem is that we are considering only the customer feedback. But what if it comes late? What if it comes after we have wasted time implementing the wrong stuff? How can we find out early that we are building the right thing in the right way? We need faster feedback. How to get it? XP technical practices are known to help developers with that. You can get early feedback:
- from the client regarding the acceptance tests written before starting implementation on a feature
- from unit tests that the code is doing what is supposed to do
- from the acceptance tests that you have finished implementing the feature
- from all automated tests that no regression bugs have been entered
- from code review that the design is good
- from pair programming that the collaboration in the team is good
- from continuous integration that the deployment scripts are working
Agile talks a lot about Scrum Masters and Product Owners. But what about the programmers?
They need to be happy to be productive. When are they happy? By learning new techniques and practicing them. But how to learn new techniques, if they are always working under pressure?
There’s an underneath assumption that they need separate time and planning for learning and improving their technical skills. This assumption is wrong. Step by step, programmers can learn new technical skills by practicing while implementing new features from the product backlog. The client or the manager does not care about how the code is written, they care about working software delivered without bugs. Customers or managers are not forbidding the use of unit tests, TDD, automated tests or design patterns.
The programmer is the owner of the code and the owner of his career. She is in charge with creating well-crafted code. She has to choose to use the technical practices that help her write good quality code. Continuous improving and learning leads her to professionalism.
…“is the movement that promotes the idea of adding value to software development through practices. It’s about leading by example and showing how we can be better. It’s about continuously delivering value and avoid writing bad code.”