Let's have a look on Developers and their drivers today
My experience is that developers are striving to deliver high quality results, to improve their skills, the working environment and tooling. Feedback, collaboration with peers and education are important aspects to succeed. Scrum supports exactly this. Feedback and collaboration is built into Scrum by default. Additionally Scrum uncovers missing skills in the team. Pairwise programming is a mean to spread skills an of course the demand for trainings might pop up. That's why developers trend towards Scrum. Scrum guides individuals to form and act as a team, to strive for business value and to permanently improve the production process. Developers honor it to be treated as individuals.
There are downsides of Scrum as well. Still developers tend to misinterpret Scrum like this: No documentation anymore, managers are expandable, any regulations or standards of the organization can be neglected, the environment can be setup free and I can take any tool I like to.
Of course this is nonsense if these statements are taken literally. As these statement are threads for managers let's have a closer look on them.
No documentation needed. That clearly is nonsense. Vision documents on different layers of abstraction deliver value. User stories and storyboards are new techniques and result in some kind of documentation as well. Even comments in source code is documentation or automated acceptance tests written as source code. And for sure the organization has the right to demand additional documentation - because of regulations, compliance or security issues and such like. In Scrum we would add a demand for this last type of documentation eventually to the done criteria. If I look around only a very few developers would neglect this. So the statement "no documentation needed" clearly can be rebutted in case managers try to play that card.
Managers are expandable: Of course agility changes the job profile of managers towards creation of business value and foster the team. Change, especially under the stress of a middle manager always is threatening. The statement "managers are expandable" rather should be interpreted that command and control managers have to change towards a lean mindset. A new generation of managers is expected to grow. This new generation of managers cares for shaping common understood and by the team shared and supported vision(s). They care for training and skill sets. They care for a working environment and of course they care for education and development of each individual in the team. Yes, managers, i.e. persons taking responsibility will be there in the future, hopefully! Unluckily my experience is that a pretty high percentage of developers still believe that "managers are expandable". My personal impression is that one out of five delevopers follow this mindset. These are enough so that managers feel under pressure.
Any standards may be neglected: yes there are some rare examples of developers that prefer to work in chaotic state. I have to say I work with developers that care for a healthy set of standards. Standards that make sense. Even establishing architecture patterns in development is kind of a standard. This is the argumentation base to discuss with the few developers that neglect that standards exists. And yes, of course there are organizations where most of developers claim about standards within this organization. In this case I would like to challenge whether the existing standards really support the organization or whether the organization is just over-regulated and should start with lean thinking and avoiding waste. In over-regulated organizations often a manager was the seed of this by pushing in a compliance or standardization idea that escaped and turned into an unstoppable over-regulation carnivore.
Wouldn't you agree that these are scenarios and mindsets that exists out there?
No wonder that developers love Scrum and manager - hmm - at least have respects.
Let' have a closer look on managers in my next post.
No comments:
Post a Comment