The goal of any new process is to solve a problem. If you are not able to solve a problem with your process then you have introduced a new problem to your team, one they probably didn’t need. Make sure you know the goals, before you build something new (that might not even need to exist).
Software that is stable. Software that delivers on the features that you downloaded it for. Software that is simple and intuitive to use. Do the core features work from release to release? Those are the basics of any software solution that from release to release should always be there. Everything else is an add-on bonus, but the core, the core should never be buggy.
Multiple Teams can have multiple processes and systems for what they do. This isn’t a bad thing – build the process, methodology or system that fits the team for what they are doing. The Agile methodology for software is built around tenets to accomplish goals and not implementation details itself. If you are working with multiple teams with multiple ways of doing things and each team is performing well the question should be are you…
Every process has to create value, otherwise, why are you doing it? TPS Reports are an example of a process that creates no value and/or the value it creates might be restricted to one (and not the person having to do the work surrounding the process). The tricky part of any new process is getting everyone to understand what it leads to. It’s entirely possible they might not get it because they don’t see the…
Everyone has a different style of getting something done. Whether leading people, coding, testing, strategizing or writing requirements. No one does it exactly the same way – and that’s great because then we can learn from each other. When your style collides with someone else’s, the immediate reaction will be – “I do it this way and I know my way works” – because… well… it has. But the second thought you should have is…