Confessions of a software development manager

Part 3 - The Re-Inventor

 As the blinding light of detection shines on the skulduggery, malpractice or general deception that was the original estimate, the overworked shield of refactoring fails to deflect the piercing arrow of truth.

The plan to create a new world order has failed, miserably, leaving the re-inventor gasping for breath, desperately looking for a viable excuse for his iniquity.      

The distant memory of the design meeting, that triangle of collaborative sanity, hangs heavy, the albatross that haunts his every waking hour.

The re-inventor can be, if not recognised and managed, one of the most dangerous, even damaging, types of team member. The most devastating weapon in the arsenal of the unrestrained re-inventor within an Agile team is his (mis)use of the Agile manifesto to validate his actions combined with his complete disregard for  Agile principles, in particular " Simplicity--the art of maximizing the amount of work not done--is essential."

The re-inventor is at best an unwilling participant in the meddling of lesser humans and at his worst the antithesis of all things Agile.

 A re-inventor may easily neglect process and singularly decide that he need not inform anyone of his decision. Even worse, they may be a dual solution practitioner, someone who has a secret solution, the "real version" that they work on privately knowing it is not what was agreed, avoiding any discussion, hoping it will turn out right and on time.
He may completely redesign things under the guise of sustainability or technical excellence, ignoring both plans and agreements from previous interactions, without documenting or conveying clearly his new ideas or solution, all while failing to deliver the task at hand.
If that task is a change integrated with other pieces upon which other team members are relying it can be catastrophic. Even the smallest of cogs when missing or broken will prevent the machine from working properly.

One tactic to use when guarding against this is the informal peer code review during the development phase. This allows peers to question the purpose and direction of the code, and is also a great platform for both teaching and learning.

If you employ pair programming as a tool, the checking is performed as you are going along, although even in those circumstances there can be rare occasions where the re-inventor goes unchecked by a less experienced team member.
If you are using pair programming, be sure to guide the pairing of the re-inventor toward a strong partner, technically and mentally, if possible. Something as simple as "I'd like you two guys to collaborate on this, I think together you can..." is fine. You can say you are "tinkering with new ideas to enhance the agility of the team" and you will be telling the truth.

I was once asked "I thought we were supposed to be a self-organising team?"
My response was "We are!"
The concept of a self-organising team is much too big a subject to discuss here but suffice to say as a development manager you should be an active member of the team, helping to guide decisions, helping to collate both positive and negative feedback from retrospectives, helping the team adapt to change. 

Aim for a balance within the team where nobody feels accused and where you are not damaging people's confidence, hurting their feelings unnecessarily or alienating them.
The endgame of the development manager is to help the team to continuously improve and achieve, while keeping everyone happy.

Changing code unnecessarily is a major trait of the re-inventor. In an Agile team, he will first try do so under the banner of "refactoring". 
Refactoring is about improving a portion of the system without changing what it does, even slightly. The serial re-inventor cares little about this and will quite happily make sweeping changes, sometimes even re-writing code that has only recently been produced, and not always their own, in an effort to make it meet the demands of his new brainchild. In his eyes, he will be "responding to change over following a plan"

If the re-inventor has changed a portion of the system that wasn't included in the original agreed solution, their excuse will be something along the lines of "If it had been designed and written properly in the first place..." 
This is another characteristic of the re-inventor, his belief that he is somehow, and for some, in many ways, superior to everybody else and that no matter what the problem, he cannot possibly be at fault. 

This is one of the more troubling problems for a team.  There are many ways to approach this and the process followed will depend not only on the team and your management style, but also on how amenable the re-inventor is to your specific brand of persuasion. 
Someone who cannot see any error in their performance or output will only serve to introduce a blame culture into the team, damaging the team's overall confidence, along with that of some individuals. All team members deserve to be treated with respect, and to not have their work subjected to malignant criticism by other team members.
 I prefer to use a rational argument when putting forward my case. Logic is a most valuable tool when trying to convince.  Failure to convince the re-inventor to conform to the agreed practices will, however, have further repercussions both for your relationship with them and the balance within the team. If a common ground cannot be met, their position may become untenable, and a stronger strategy may be required. 

The re-inventor can be the biggest obstacle to a team delivering, and the failure to deliver some incremental value at the end of each sprint is the end result all Agile teams should try to avoid. The value may well be a new piece of functionality, but it could just as easily be cosmetic or performance related, in some cases it may be the building blocks on which the next sprint will be based. All are perfectly fine as long as the customer, internal or external, is aware of, and happy with, the value being delivered.

Always be careful when you are measuring the perceived value of a software delivery. Consider the example of a system heavily reliant on data. It can be as stylish and slick as you like, but if the figures are wrong, the end user whose job is to work with those figures will only see the fact that they are incorrect. To this user, the inherent value of the system is all in the numbers and what you have delivered, for all its finery, is inadequate.

Beauty, after all, is in the eye of the beholder, as you will discover further in part four of this series - Mr Greenfield.