Most people go their whole lives without encountering a Target Operating Model (TOM). If you are one of the unlucky few who have to work on a TOM this post provides some hints and tips. I hope it will help you survive the experience and even get something useful out of it. Enormous amounts of money and energy go into TOMs so we should get more value out than we put in.
My previous update on Backlogs provided an introduction to the term. This post provides a little more detail on how to work with Backlogs.
People would love it if we could predict the future. We get this all the time in our work: How much is the project going to cost? When will it be finished so that we can go live? We are really busy so how much of Dave’s time do you need next month? We only get the actual answers to these questions after the work is done (occasionally years later) but people need estimates, forecasts and indications to help coordinate people and activities. Agile ways of working do not immediately remove these needs but techniques like Scrum can help avoid some of the common pitfalls.
Think about the last time you bought something at a shop or online: Did you care what brand of vehicle delivered the goods? Probably not! In the Cornwall Council IS team, our products exist to help people get things done and they, in turn, are helping other people get on with their lives. Often, as long as these people can do what they need, the details of how our products work do not matter very much to them. User stories are a way of capturing the needs of our users and leaving out the rest of the details. They are very efficient, easy-to-use and have become the typical way for agile teams to define their products in the product backlog.
In this post, we’re taking a closer look at another agile term: Backlog. The dictionary definition is: an accumulation of tasks unperformed or materials not processed In agile working, backlogs are a list of things that a team still has to do. If you are struggling to get started, brainstorming a list of what a team needs to do is a good first step.
I don’t think the people behind Scrum and other agile methods participated in sports very much. They seem to have borrowed a lot of sporting terms but haven’t used them very wisely. The phrase “Sprint” is a good example of this. In athletics, a sprint involves individuals trying to run faster than everyone else over a short distance. This might be how your team feels at the moment, but it probably isn’t a good picture of where we would like to be.
I gave a presentation at the recent British Computer Society (BCS) Enterprise Architecture Conference. A replay of the talk is available and this post is an outline of the main points. Over the last few years I have worked with many architects and quite a few are unhappy. Executives might appreciate the efforts that go into models and designs but things move on so quickly that, often, the architect’s work does not keep pace with events or arrives too late to be useful. The architect might sadly slope away, loaded down with copies of densely packed designs which are now only good for the recycling bin, or they might become angry at being ignored. Either way, it is not a pleasant situation. I shared with the conference some ideas about why this is happening and offered some suggestions of how to respond.
…but developer productivity and commercial flexibility are bigger This post goes into technology a little more than usual so the TL;DR version for busy CIO’s is: Please make sure some of your teams are experimenting with serverless technology from Amazon or other providers. The rest of this post explains why Amazon is leading the transformation of software development with an obscure bit of technology from Google.
I recently noticed that I have been using @CIOPortfolio for 5 years now and that got me thinking about what has changed for CIOs over that time. Although digital technology is renowned for its frenetic pace of innovation (here we go again!) you could argue that not much has changed. Surprisingly, that is a terrifically useful insight for CIOs.
You could be forgiven for thinking that the agile movement is taking over the world. For example, Amazon is famously agile and because it can make changes to its software every second it can maintain its lead in existing markets whilst conquering new ones. But look more carefully and, of course, things are more complicated than that. In many respects, leading digital businesses are not as agile as they seem.
Thanks to the 100 or so people who have taken a look at the IT Portfolio survey app so far. I am still looking for more feedback so that I can improve both the content of the survey and the way the app works. If you want to help just pick your favourite phone/tablet/PC, point your browser at the site and start moving the sliders around with your finger/stylus/mouse. The app looks best on a large tablet but I have used it on a compact mobile phone held in landscape mode. Let me have feedback by adding a comment below or you can get in touch via Twitter Update I am still making changes and releasing new versions of the app. The app is now based on serverless technology and I have written another blog post about making the migration.
This is quite a long post so here is the 30-second version: organising services around calendars and clocks is generally a bad idea it is much better to organise around outcomes and risks this is now a practical option because of new technology CIOs can take the lead and help the whole enterprise. Sarah Wilkinson, CTO for the UK Home Office, recently wrote a post about breaking away from some long held traditions in IT. The article includes some great advice but I think we need to go further.
Why has IT management become so cursed with Binary Thinking? No. 7: Changes and projects can be delivered in an agile or waterfall way Binary Thinking: Traditionally people commissioning a change have carefully specified their requirements and then left a project team alone for months, or maybe years, to develop and deliver a capability to fulfil the requirements. This disciplined, structured approach has been largely discredited in the IT domain as the cause of many high-profile project failures. Alternatively changes can be made in an agile way which means delivering basic capabilities in days or weeks and working closely with commissioners to add further capabilities iteratively over time. These days everything should be done using an agile approach.
Bluesky
