We have a cowboy coder in our team i.e. he likes to take advantage developing some new features or tools that are not always requested nor useful. We use scrum/kanban for development, and it is quite common that when he gets an item from the board, he takes a long time to finish it and comes out it the solution and "something more". Now thinking by the human side, I always try to fit someone to do what he/she likes the most, so I would like some advices on how to make him feel motivated doing the stuff he likes, at the same time that he delivers useful features and share his "something more" stuff development with the team.
-
3Ideally they should add "something more" to the feature backlog so it can be vetted by the team. It shouldn't be part of the product if it doesn't have a tangible business benefit to some user. If the benefit is tangible to developers and you're focusing only on customer stories (devs are users too!), then this might be an area of focus missing in the existing process.– Merlyn Morgan-GrahamCommented Jan 4, 2012 at 3:58
-
Are you using burn down charts to track the team's velocity using story points, doing daily stand ups and sprint planning sessions? If you are, you could mention that the teams velocity is slow during daily stand ups based on the story points for a task.– bobo2000Commented Jun 15, 2016 at 11:04
Add a comment
|
7 Answers
By the sounds of it you have isolated this issue to the developer and that (imo) means you need to modify your process to ensure issues like this don't continually occur or modify the interactions with this developer.
On a side note, don't count out the tasks / stories on the board as being a potential cause of this scope creep.
Scope creep is resulting from a poorly understood user story:
Have you INVEST'ed in writing good user stories?
Do your stories have clearly defined acceptance criteria (Acceptance criteria are the requirements that have to be met for a story to be assessed as complete) ?
If your answer to these questions is yes, then you may want to talk to the team about modifying the process when a team member picks up a task from the board to include a discussion with the Product Owner (or whom ever is representing the PO). This discussion is simply intended to make sure the developer has a clear understanding of what "Done" means.
Scope creep is a symptom of the developer and not the process:
You need to have a candid discussion with this individual. They need to know that the scope creep they are adding to the stories they work on is affecting the project and the desired outcome of the story. If they have "ideas" you should encourage that they bring them forward but not blindly code them into the story.
If their behavior does not change after having this discussion then I would remove them from the team.
Scope creep is a symptom of the teams definition of done:
How are stories accepted as done on your team? By the sounds of it you are saying that when the story is moved to "done" is has a large amount of bloat added to it, but it is still moved to done and "accepted".
On any team I have worked on, if the "bells and whistles" did not add to the user story (or sometimes even if they existed) I would have rejected it and moved it back to in progress until the acceptance criteria had been met for that story. You do this a few times and it become pretty evident to individuals they should be developing the bare minimum that meets the stories acceptance criteria
Scope creep is a symptom of the individuals design:
Is design being vetted by the team prior to a developer coding on the story? If not, this could be something you add to your process in the form of a design session. Be sure to include the PO or PO representative to ensure that the proposed design is the bare minimum to meet the stories acceptance criteria. Note, that this design session could simply be an ad hoc discussion in front of a whiteboard.
-
4+1 for a good identification of the problem (scope creep) and sources of scope creep in Agile. Also: bair = typo Commented Jan 4, 2012 at 3:48
-
Thanks, very well explained. Clearly, the scope creep comes from the developer, in my case. So I will try having a conversation with him and, as Clayton suggested, use pair-programming.– eMgzCommented Jan 4, 2012 at 19:37
Individuals and interactions over processes and tools
I would have a conversation with individual, bring it up in retrospective or perhaps even standup. Don't spend too much time trying to figure out how to solve this problem via the process. For all you know this person might be doing all this gold-plating because he thinks it's required to "look good" in the eyes of management. Don't assume.
I'd suggest pairing (pair programming) with this individual the next time he grabs a story off the board.
-
7
Last time I was working with a cowboy coder I let her take full responsibility for the "something more":
- she had to integrate, deploy and release it alone
- when somebody else was unable to test, integrate or deploy her solution, the team stopped working, so did she, and she had to fix the problem
- when management asked us about the spent time she had to explain the "plus" including the delays I mentioned before
It may sound harsh, but cowboy coders feel that they can do whatever they want to do, while in the background somebody else does the legwork. As soon as they have to do the legwork they "calm down" and be part of the team or they ask for leaving.
-
If approached correctly (given as tasks) rather than as humiliation/punishment in front of the group (unless they're a robust enough personality), this sounds like it could work sometimes. Tho there is a third possibility: They take this as a given in the process, rather than an exception, and that they can get any feature into production if they want badly enough, as long as they're willing to put in the legwork. Commented Jan 4, 2012 at 3:52
-
I agree, it definitely should be the part of the process for everyone, and it shouldn't sound like a punishment.– ZsoltCommented Jan 4, 2012 at 8:46
I read the answers and I have a feeling there is some little insight you should be aware of.
Investigate. What is the source of a cowboy coding behaviour?
As a manager you are supposed to know your team(s) and peoples motivation. One of the possible problems was mentioned by @Jeese and it may be the most probable one. But please remember that in order to find proper solution you should be sure what you want to cure.
(alternate motivations: cowboy like to show herself in a good light / she is a creative person / she cares for the users more that product owners / your organisation lacks care for inventions and she finds it the only way to introduce some / etc.)
Make it a win-win
@Jeese also said a very important thing: If they have "ideas" you should encourage that they bring them forward but not blindly code them into the story.
It may be that there is nothing wrong with the task scope, but the coder is a very highly creative person. The worst thing would be dumping her joy of work and her creative output. You could not stop creativity, it will happen not matter what. But she can create other stories for the ideas and separate the current work from additional improvements.
Measure and decide
@David said important thing: Good things could come from a rogue human resource but many bad things will come from him
... and I would add that: probably many good and bad things are already coming from her.
Over a time you should decide if your total ballance is a possitive or negative one. You are the one to decide if you have a time for making it win-win in your project's situation. What are the costs of the problem, is there a good outcome and what are the forecasts?
answered Jan 4, 2012 at 10:14
If you had a fully automated task that "takes a long time to finish it and comes out it the solution and 'something more'," would you tolerate that? Or, would you find the offending component and fix/replace it?
Good things could come from a rogue human resource but many bad things will come from him, too, things like scope creep, gold plating that is ultimately rejected, increased schedule, increased costs. So you are balancing what might happen good with what will happen bad.
Not worth it, in my opinion. Find the offending component, fix or replace.
answered Jan 3, 2012 at 20:58
-
Therein lies the challenge of being a leader. To make unpopular, unemotional, and cogent decisions where humans are involved, to objectively analyze a problem keeping in mind humans are capability enablers just like a hammer, yet treating them with respect and dignity, unlike a hammer. If it makes your stomach turn, then the job is not for you. Commented Oct 8, 2012 at 15:14
-
Luckily for me, in my 10+ years of experience as a programmer, I have only met a PM that treated me like a hammer once, and he lasted a very short time doing that job.– user4771Commented Oct 8, 2012 at 15:18
-
That's right, yms, talented leaders know how to make tough decisions while treating their team with respect and dignity. Ones that don't know how to do that may not last that long. But don't kid yourself, the analysis to which you are apparently not privvy is cold and unemotional. Commented Oct 8, 2012 at 19:22
-
Actually, yms, every industry and domain require innovation, research, and development for continued advancement. And there are investment type projects for just such work. And in those projects, those scientists and practitioners can brainstorm, create, and experiment all they want. Out of that comes new ideas that a customer purchases through a development project, where all that is in scope is to develop it. NO customer should ever have to pay for some practitioner to chase an idea, unless the customer agrees, in which case it is no longer rogue. Commented Oct 9, 2012 at 10:02
-
What you need to do is a get a job where you have accountability for capability performance against mission, where you are responsible for EVERYTHING: costs, revenue, supply chain, people, tools, EVERYTHING. Do that for five years--no, make it three years--and then let's have this discussion. BTW, the original OP called the coder a "cowboy." The coder earned a nickname. I don't know how you can read into this and determine that, in this scenario, it might be a good idea to keep him. You need to understand scope management and the bad results of gold platting. Commented Oct 9, 2012 at 10:07
How about employing an integrated carrot/stick methodology:
Stick: explain to him that stories taken from the board need to be implemented as described, in as timely a manner as possible. If an enhanced/expanded version of the story is implemented, not only does it skew the estimation, it creates a testing/deployment/maintenance overhead that the project as a whole has to bear. Put pressure on him to finish the task within the estimated time, and if he still manages to do more than is required, push down the estimates. Give him a hard time about running over the estimated time.
Carrot: explain that if he thinks of any additional functionality while he's implementing the story, he should make a note of it and present it at the next story meeting. Encourage this behaviour with praise for good ideas, discussion of their merits, etc. Make him and his idea the centre of attention for a few minutes, and make sure that at least one or two of them actually get implemented, even if only in an amended form.
Hopefully he will get more out of contributing the stories in a public forum than he currently gets out of implementing them on his own.
You just found a great candidate and a futur manager. That man has his own ideas. His has the caracter to sand for them. He is not afraid to do what he thinks his the best thing to do. He his not afraid of taking some heat, etc. I wonder if he is simply bored and if he needs a new challenging projects or tasks? You should challenge him. Give him something very difficult to do or nearly impossible. Give him a short deadline to do it. Plan an honest reward if he succeed and tell him in advance. I would talk to your manager about that man and appoint him a mentor. If he collaborate with all of that and prove his abilities; he will be a great asset to your team and compagny.
