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.
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.
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.
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.
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?
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.
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.