A friend of mine has a Client that is quite unique, and he is viewing it as a rare opportunity to see how different techniques in regard to software development resonate where there is no prejudice aside from repetition of what exists – and in this case, what exists is chaos. There are no processes in place, but knowing process, you can see where some of the pain points are before you even talk to the team members. The Client has product owners (without the title or formal role) tell project managers (who are really project coordinators) what they need – which is sometimes in sharp contrast to what the project or the end user needs. There is no analysis or discovery beyond note-taking. The project managers hold meetings and read their notes to the development team. Of course, a lot is lost in translation, and the features that need to be built are generally communicated in a way that leaves much to interpret. The developers go off, build what they think they are supposed to, and deliver it to some very unhappy stakeholders (who, even if the developers had nailed the original requirements, usually changed said requirements several dozen times since inception).
These are smart people who work for the Client. They simply have done what a lot of smallish business do: grow quickly and make whatever adjustments they need to in order to get the job done and the project out the door. Reuse, extensibility, etc., are not immediate concerns and documentation would be futile.
The first challenge – or the most obvious one – is positing team members so that their role is defined. For instance, the aforementioned product owner is only the product owner because they have veto power, and their nod grants. However, they do not carry the responsibilty of nodding, and they do not act as the decision maker until they are personally interested. Any member of the team who is of sufficient title can change a project direction without consideration to repercussions, timeline, budget, or scope and the project managers are left to try and figure it out. It is the absence of process. It is chaos. Now, over time most of these things land *somewhere* and the corporate culture sees that *somewhere* as the end result. That also has to change. It is obvious that a simple team structure with simple processes such as iterations, sign off on feature sets, prioritization, and empowering the product owner by involving them more instead of giving the illusion of power by allowing them to be removed would be helpful. And this is not even getting into the development process, which is in dire need of help.
Will update you as I interact with the team more and introduce some classic techniques as well as some more “edgy” techniques/methods. I suspect they are only edgy because they are not well established, but it will be interesting to see how a team devoid of PM education takes these different suggestions.
Until next time, thanks for reading.
Josh