Sunday, 6 September 2015

Being Agile...

Fashion is everywhere. Fashion introduces new things to us - and recycles the old! Fashion creates product and demand; it generates sales and profit; it breeds need. Even in Information Technology, we love fashion. It gives us the opportunity to create new notions and processes; it is a natural bedfellow with the rapid changes in technology that we are now seeing, inventing new ways to use those technologies and creating new ‘products’ from them.
Yet what we actually do in IT is the same as ever: we teach machines (computers, now of various favours including mobile phones) to take the data we give them and then manipulate and store that data for future processing (more manipulation) or reporting. Occasionally the data is used to control other things, like traffic lights or machinery - or even spaceships and cars! 
Ensuring that we do a good job in building the systems that make those manipulations effective, IT professionals have always invented rules and processes around the development cycle in order to try and make the end product as good as it can be. As technology moves on and the pace with which development can be carried out quickens, the volume of changes and the speed with which results are needed both increase, and hence new models of development are needed.
And so we have seen a progression of methodologies like ‘waterfall’ through ‘rapid application development (RAD)’ and on to ‘Agile’, the current IT panacea for this decade it seems.
Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. (Wikipedia)
Like many ‘next great things’, Agile will only be as good as the people and organisations that adopt it However, we might be missing a trick here. Should ‘Agile’ not be a state of mind, a philosophy, rather than a methodology or series of formal IT processes? For one thing, if a development team is working in ‘an agile way’ but the rest of IT is not, or the culture of the business as a whole is slow and ponderous, will ‘Agile’ not inevitably fail to deliver as much as it might promise to?
Take the Wikipedia definition above. The “collaboration between self-organizing, cross-functional teams” requires everyone involved to be able to work in the same way. “Rapid and flexible response to change” needs to be in the DNA or culture of the whole organisation; what’s the point in producing IT systems quickly if their prospective users do not readily embrace change?
If we think of being ‘Agile’ as being “the answer” and that it relates just to IT software development, then we are deluding ourselves. ‘Agile’ needs to be part of the corporate culture.
Agile is a cultural philosophy as a result of which decisions, actions and business solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary and incremental progress, early delivery, continuous improvement and the elimination of waste (in all its forms), effective and prompt decision-making, and encourages a rapid and flexible response to change.
OK, I know this version isn’t perfect - but doesn’t it sound much more like the kind of business we would all like to work in?! Isn’t it more inclusive and relevant to all our staff, rather than that minor percentage employed in the rarified world of IT application development? Yes, it might increase risk a little; and yes, it will demand better delegation, more accountability and so forth. But in the end, those are probably good things - and any negatives should be outweighed by overall commercial benefits.
And I expect each of us can think of real, every-day examples of where being ‘Agile’ can bring true improvement - in bottom-line, morale, responsiveness etc.
Why not change the format and content of that monthly departmental meeting so that we can focus on just the critical points and get through it in an hour instead of the four hours it currently takes?
Why not reduce the number of people needed to take a decision to those who are really affected by it so that the decision is made more quickly? And why not make decisions when a) you have 80% of the data needed rather than search for the 100%, or b) when everyone knows what the ‘right’ answer is anyway?!
Why not redesign our organisations to facilitate teams whose sole purpose is rapid response or firefighting?
Why not cull the hundreds of documents and reports we produce and focus on the very few we actually need?
Why not, why not…
Agile as a software development methodology is all well and good, but until we broaden our thinking to embrace more than just IT, we will never get the full potential benefit of taking such a pragmatic approach.
*
About the author / copyright
This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.
Posted by at No comments:
Labels: , , , ,

Tuesday, 21 July 2015

What can we in IT learn about Business Systems from ‘Minecraft’?!

From an IT applications’ perspective, you could argue that there is no way ‘Minecraft’ should be a success. After all, in these times of high-powered and sophisticated devices with their stunning graphics capabilities, a game colloquially recognised as “blocky” and without a single non-straight line in the game perhaps should not have taken off at all. Indeed, it is an interface, one might suggest, that is at least fifteen if not twenty years out of date!

But it has been a success - and a raging one at that. Millions of people play it - many addictively. A whole industry and sub-culture has arisen because of it, and we now find some of its exponents - particularly in the world of the on-line video - gaining ‘Star’ status, appearing on TV chat shows, and with more followers than Presidents, Prime Ministers, and Philanthropic and Commercial giants.

So why is that? If we strip ‘Minecraft’ back to some basic level - that of an ‘application’ with ‘functions’ and ‘users’ - then what might we uncover that can be usefully and profitably reflected back into the world of commercial business systems? Where does it ‘work’, and - more importantly - are these factors applicable to our company’s finance or logistics or ERP systems?

Take perhaps the three of the most salient points:
  • It is inherently simple. The components on which Minecraft is predicated - the cube, the straight line, the interface - are consistent and universally adhered to. Whether you are working with bricks, carpet, snow or foliage, the way you work with them is the same; and, with a few exceptions in the area of ‘redstone’, what you can do with them is even more limited. You either put them in place or remove them. Left click or right click.
  • Because of its simplicity, it is easy to learn. Once you have mastered just a few basic concepts, then you are ready to roll.
  • On one level, this simplicity and ease of use could point to a lack of sophistication - but how you play the game and what you can do within it is massively sophisticated, and that is the more important thing. This ability to create your own world from a blank canvass, where no two buildings need be identical and where no two games will ever be the same, give ‘Minecraft’ the addictiveness that comes from seeing your personalised world rise in front of you. “Just one more brick…”, “just one more minecart track…”, “just one more tree…”.
Do the business systems’ we tend to implement in our professional lives mimic these traits? Hardly. We tend to make systems that are massively complex - and as a result, difficult to learn. In areas such as financial transaction processing or warehouse management, the things businesses do - buy stuff, sell stuff, pay bills, raise invoices, put stock away, pick it out again etc. - are, at one level, simple and homogeneous. And yet company after company believes it is “different”; that systems need tweaking to fit their processes. The end result is that we tailor and customise and seek out those final few percentage points of “perfect” alignment - and in doing so, we create a monster.

And it becomes a monster even before the system is ready to use. It takes too long to build; it costs far to much money; and, in taking this approach, we are creating something that, when the software vendor releases the next major upgrade, may once again take an age to re-customise, and again cost a fortune in doing so.

Some people might argue that they are building-in sophistication; that in taking this approach, they are driving value, efficiencies and so on. If that were truly the case, then why is just about every core business processes and major business applications dependant, at some point or other, on data being manipulated in Excel? If we had done such a great job with our highly customised and ‘sophisticated’ applications, we wouldn’t need Excel. Right?

Think about it. Excel is much like ‘Minecraft’. A blank page; a relatively limited number of rules; easy to use - and the chance for us to be creative and build something that a) fits ‘us’ as individuals, and b) meets the needs of ‘the process’ as we see it. Never under-estimate an individual’s desire to make their mark. As in ‘Minecraft’ worlds, no two Excel spreadsheets will ever be the same! [There is a potential pointer here to the future of business applications - but let’s save that for another article!]

So, keep it simple; change / build as little as possible; focus on what’s really important (and what commercially adds value); and engineer something that people actually want to use.

*

About the author / copyright



This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.
Posted by at No comments:
Labels: , , ,
Subscribe to: Posts (Atom)