Again I find myself contemplating the problem with setting IT organisations on the “right path” with regards to transformation. It almost seems that out of politeness and I suppose an obligation to some pretence created before my arrival. There is a common pattern to the “Digital transformation” get in some tools, an issue tracking system, a continuous integration platform, maybe some kind of orchestration, a version control system, etc… normally these will all be the “likely suspects.”
At some point, someone will say something like “I feel we’re creating solutions for the unknown” at which point I will look at them somewhat at a loss for words. Not because I disagree but because I deeply understand that they are likely right, it isn’t very smart to go “yes I know, but this is what the organisation has asked for and as such that’s more or less what we’re going to do.” What would I do for most of these organisations if given carte blanch? Firstly I wouldn’t set about putting in place tools until we had to, remember “Do just enough so that you can get started.” I suppose I take the most issue with the process and management side of the whole thing. Version control is likely the only thing that’s a no-brainer you go with some flavour of hosted git, which one? I don’t really care.
The last thing I’d ever commit to is a computerised issue management system whether it’s VSTS, Atlassian or Kanbanize, why? Because that way leads to creating a “solution” that doesn’t make any sense. There will be loads of features you never use and as many that don’t fit the business and given the business doesn’t even know what it wants yet you’re in a sticky place.
By the way, I really dislike the word solution, as I tend to find that today’s solution is tomorrow’s embuggerance. I’m very much a believer in the Toyota view of “countermeasures” this is what we’re doing until we find a better way of doing it and we will constantly challenge ourselves with finding a better way of doing this.
So I would say the best thing is to stick to using sticky notes, large bits of paper, whiteboards, bits of string, felt tip pens, and A3 reports. I’d suggest talking every day and changing things every week or so. Engender PDCA and robust problem-solving methodology. Then maybe after six months or a year, you’ll be ready to commit the current state to a computer system of your design. Don’t buy COTS as it’ll have lots of things you don’t want and it will lack lots of things you do want. You can use the time saved by your new processes to do this development work if you do go for a standard packaged piece of software look for the one that sets the least level of constraints. You can’t trust that a third party piece of software won’t do something your company can’t accept.
I honestly think that this would drive far better practice and adoption in almost all organisations. Though we wouldn’t get to deliver nicely packaged “solutions.”