Pros
I truly enjoyed many of my colleagues on a personal level. It is what kept me at Medecision as long as I did.
Cons
Medecision’s leadership does not view themselves as a software company. They see themselves as a services company and have clearly stated this in public many times. This is key to understanding the dynamics of what is occurring there and why the conflict amongst many of the stakeholders is so great. So why is this relevant? Medecision is about delivering product to their customers through technology as a service offering. However, they do not seem to care (anymore) who makes the software. It could be the internal groups, contractors, external vendors, purchases/acquisitions, etc. The point being is they are not going to manage their Dev, BA, QA and other resources in a manner even remotely like a software company. While this may seem odd to a company that develops and sells SaaS CareManagement and CareCoordination software, it explains the lack of investment in the actual technical staff - including training and staffing levels, the willingness to look outside for new development and the desire to have Sr. Development staff basically be the bandaid and bubblegum team keeping the existing stack alive until the app is re-written (much of it by external teams). The architecture team doesn’t follow any process. Again, if you aren’t a software company, then why should you bother having architects understand TOGAF, SEI, or any other process. There’s no success criteria in POCs, no architectural characteristics being evaluated, no review process. It is a dictatorship of often un-informed technical decisions. Then when this team does introduce new technology, there’s little to no hand-off to the teams trying to deliver features with it. And since architecture is in an Ivory Tower, no one vets the POC to ensure the success criteria even begin to resemble the characteristics needed for a customer implementation (we’d need an epic or user story for that). Of course, by the time the miss is discovered, it’s easy to blame the BAs or developers for not pointing out the gaps from Architecture. And don’t even get me started about how well the governance over external vendors or contractors works. It also explains how a company with a fairly decent agile process could jettison it in favor of a RAD team that basically has no process and can break pretty much any rule in order to ‘get it done’. This in of itself would not be so bad if the customer(s) actually realized it was their implementations that had portions (or all) of the QA and release management processes completely bypassed in order to meet a deadline. And should the code have worked, no one would have been the wiser… ooops. So the dates slip, the clients are over promised, and the teams are ground to a pulp trying to fix what was broken in the last release before the contract penalties kick in. Ask how many of the largest 4 projects in the last two years had actual requirements or user stories before development started (or even finished in some cases). This isn’t agile, waterfall, or any other dev process - this is throw it on the wall and see if it sticks.
