what theodox said.
Also, know your customers / project teams!
Their expectations, attitude, experience also plays a role in how to develop tools. There's a difference if you make stuff for a junior team of games artists or senior animators in film (we got both here where I work).
Try to find out before you start developing:
* Know if the users want intuitive interfaces (sometimes at the cost of flexibility), or if they can deal with complexity. Senior and film folks seem to do better with "power user" enabled tools.
* Know if they are okay with beta versions of your tools (sometimes a beta tool can be worth more to them than no tool at all).
* Find out what your release schedule should be. Some project teams prefer ASAP (especially when they ok with beta tools), others want a more predictable model. Both can work, as long as everyone involved is aware of the consequences.
* Get your use cases right first. Don't implement use cases you, or your team considers useful - the clients must find them useful! i.e. run ideas via your clients first, if necessary prototype.
* Check how many users of a tool benefit from a feature. Sometimes people suggest features just because THEY like them, but nobody else in the team cares at all. Obviously, focus on features that benefit most people and which are requested by most users.
* Based on your analysis of features, you can rank them, add them to your backlog and start implementing in an agile fashion.
* Have some change control process in place that evaluates requests to the tool in terms of how many people benefit from the change, if it supports the main goal of the tool (or if its better to spin it off into a separate tool), and how much work it will cause you, and of course, if it's possible to implement this at all (some people have crazy ideas what we TAs should be able to do!)
Requirements = everything requested before development starts
Changes = anything after agreement on requirements has been reached. Avoid lots of uncontrolled changes once development starts. This leads to scope creep. Instead evaluate changes and add to backlog (except for bugs)
Once your tool is done:
* Find a way to inventory your tools. Don't follow the "let's dump every script into a common" folder method that I've seen at quite a few studios. Add at least some info what the script is supposed to do, what dependencies it has (e.g. 3rd party modules) and for what software it was originally developed. If you want to do it properly, invest time in documentation and versioning. This helps with re-use. It let's you browse if you already have a similar tools.
* Have a feedback process TO the art team. People will stop giving you feedback if they get the feeling you're not listening. i.e. explain why some changes may not be implemented, update users on new features, fixed bugs etc. (keeping a changelist.txt or similar is useful). Depending on the art team's professional maturity you may have to communicate a lot to remind them you're listening
* Think about training - does your tool require it? How to ensure everyone knows about the capabilities and limitations of the tool? e.g. readme.txt, short demo to the team, ppt, built-in help, video, wiki?
Be wary of management designated product owners.
Wrong: management assigns a project owner who doesn't care, doesn't have time, is selfish about requested features. Your team then treats this guy as the Scrum PO.
Right: designate your own PO. Scrum doesn't say the client necessarily has to be the owner. If the owner can't provide value to the project then it is okay to have someone as PO who "acts in the best interest of the client" and who represents the client. This could be someone from your team, who ensures that the wishes of the PO designated by management match the requirements of the project team. This way you can deal with selfish/lazy/busy POs - they may even be happy that you do all the work.
(when I first did agile, I did it the wrong way quite a few times results were wrong features, lack of feedback and in general a horrible delivery and feedback experience because the PO only provided very little value).