• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Software Craftsmanship: Partial Agile Transformations

 
Marshal
Posts: 14053
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(emphasis mine)

in his book "The Software Craftsman," Sandro Mancuso wrote:
Agile coaches did practically nothing to improve the skill set of people working on operations, production services, or QA. The technical disciplines, in the vast majority of Agile transformations, were totally forgotten or dismissed. There was this very naive assumption—almost unprofessional (from some incompetent Agile coaches)—that companies had developers who were great at writing code and the only thing they really wanted was to work within the Scrum framework.

... However, the principles behind Agile were forgotten. Process became more important than technical excellence. Technical excellence, which is assumed to be in place by every process-related Agile methodology, is normally ignored by managers and ill-prepared Agile coaches.


This is so true. If weren't for my constant beating on that drum, TDD wouldn't even be part of the conversation in the Agile Transformation effort in my group at work. Everyone is so focused on the process management side of things and leave the developers to go about doing things the same old crappy way. And we didn't stop there. I have collaborated with other development managers who came from the technical side and we have established the infrastructure to support Continuous Integration, Test Automation, and Continuous Delivery. Many engineers still don't fully comprehend what CI and CD encompasses though and they still write crappy unit tests and hence still produce crappy code. And there are yet others who still don't write unit tests at all. Sigh. One battle at a time.

I have said this to managers and developers alike: "No matter how much agile process management you wrap around our software development organization, if the developers don't step up and do their part to improve their technical practices, then you'll just be wrapping crap code in gold foil. Sooner or later, that negligence is going to come back and bite us and everyone is going to blame Agile. That's just not fair."

This is why I give my workshops on TDD to any development team that expresses interest in it. Unfortunately, some managers get wind of this and start wanting to send their whole team to this training, regardless of whether the developers themselves want to or not. This is another battle I have to fight.

Thanks for putting that in the book, Sandro.
 
author
Posts: 12
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for reading the book and for all your great comments in the other topics.
 
Bring me the box labeled "thinking cap" ... and then read this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!