Tuesday, 23 December 2014
Had and excursion into IFTTT programming (if you can call it that) - probably the sign of 'the internet of things' to come I would imagine. Anyway it turned out to be ridiculously easy. Must come up with a better challenge for 2015!
I also got to actually look at the workings of some code as part of a software QA review. It was related to a cock up that cost a lot (and I mean a lot) of money to plaster over the cracks. Was an interesting activity all the same. Showed in gory detail how easy it is to slip into the trap of thinking you know what you are doing on code creation until the complexity of it all - like boiling a frog - takes you into no-mans land. Result being that you haven't a clue what the thing is doing and have no way of checking if its right - belief system engineering.
In fact I have just seen a recent post in Forbes magazine about learning to program in 6 months. Only slightly made my blood boil. I dread to think what level of programmer is being churned out. More work for the ones who can sort out the mess, so shouldn't complain.
Agile was another theme for 2014. I was pleased that I managed to actually figure out how to publish a book on Amazon (Agile Random Walks - check it out) - which was again ridiculously easy. Now just need to start work on the next one!
All in all a good year for me for touching base with what really matters.
Onward and upward ....
Tuesday, 14 October 2014
How does the agile strategy development link to the concepts presented in the 'Agile Random Walks' monograph (ref: http://www.amazon.co.uk/AGILE-random-walks-Random-walk-ebook/dp/B00NF5J4C2 )?
If I could draw this in a diagram I would (Random Walk no. 3 concept) - but I can't, so this will have to do - sorry ;)
Element 1 - Blue Sky thinking. This effectively relates to defining the end states for your 'equifinality' approach (Random Walk no.14 concept) coupled with 'viewpoints' of the future business (RW no. 15 concept)
I think that stacks up as an approach?
Moving on .....
Monday, 6 October 2014
So what do the 4 elements look like - note the following steps need to be drawn as a diagram not written up as as loads of words - not very agile that!
Element 1: 'Blue sky' thinking (beyond 5-years) - what does the target market look like with unconstrained thinking - new tech, new processes, new people, new information .... whatever. Your change to have fun predicting the future vision for the market sector.
Element 2: Horizon planning (up to 5-years) - identify areas of your service/product that has the ability to 'touch' this sky. You don't need any detail - its still horizon planning - just think through areas which have a link to the sky. Draw in the 'touchpoints' (links) on the diagram.
Element 3: Roadmap for the Year (6-12 months hence) - bit of chicken and egg thinking - taking the touchpoint areas and identify what you need in your toolkit to get into these areas. Do you need to re-vamp (pivoted) any current services to address the touchpoints? Do you need supporting infrastructure to access the touchpoints? Do you need new skill sets to enter the touchpoints effectively? etc.
Element 4: Hear and now planning (0-3 months hence) - these 'Do you needs' are your RIGHT NOW initiatives. Where possible start small and grow into them. The key ingredient is starting something RIGHT NOW to begin entry. Maybe you have some existing projects that can help build credibility and capability in the touchpoint areas - get people on them RIGHT NOW. These projects should be aimed at delivering something in the touchpoint area within a timescale of at most 1 month. No long-term projects where people can hide for months on end only to find out it doesn't work at the end. UP - RUNNING - RIGHT NOW - QUICK - RESULTS. Fail = move on to the next project. Pass = push for the next stage of the initiative, follow on work, product development etc.
(p.s. don't take your eye off the day job - try and integrate the RIGHT NOW projects into the day-to-day as much as possible.)
If you can't do the 'RIGHT NOW' bit then forget even trying to be agile in your planning. If you find yourself in the 'lets put together a business case for presentation to blah blah ....' then you have already lost the plot before you even start. Make sure the organisation ready for such rapid fire or you will fail.
How to run a RIGHT NOW project ......
Saturday, 27 September 2014
Most business planning goes like this;
3 business plan
4 target areas
5 action plan
or there and thereabouts.
By the time you have worked through the vision and strategy (probably for the umpteenth time) everyone has lost interest and gone back to the day job. The business plan gets rammed home as you have to put together the budget for next year, targets are 'set' then the monster tracking spreadsheet (ouch - you know how much I like these things) is created with great precision to beat you up each month for doing 'plan says' stuff.
Plan not working warning, warning!
Alternative approach needed:
Rapidly changing environments around client businesses means your planning needs to be 'agile' to keep up with the times. What used to 'work' on a planning time-base of a year may now be too slow and rigid. Especially so if you actually want to present your company as being ahead of the drag curve in its products and services!
You still need a vision but how can you build a strategy that still delivers year on year, accounts for your current business capabilities and keeps pace with current trends. More of a prophet than a profit warning.
Currently working up the initial viewpoint .....
Tuesday, 9 September 2014
It is based on some of the 'agile' practices presented here in this blog over the past couple of years. Its more of a pamphlet than a book (30 pages) and I tried to make it free but failed and ended up setting it to the lowest price selectable!
Here is the link to the Amazon Kindle site:
The plan is to make it part of a series of 'random walks'. I hope it proves useful if you do end up reading it - don't forget I am a recovering dyslexic and part time computer nerd so writing is not my first language - hence the AGILE! ;)
Will keep you posted here on the next walk!
Thursday, 8 May 2014
RT @MeghanMBiro: The Relationship Between Influence and Expertise http://t.co/iuyusDjap5 via @danielnewmanUV
Tuesday, 6 May 2014
RT @ECHarrisLLP: The #UK ranks 8th in today’s @ARCADISCORPCOMM Global Built Asset Performance new report: Find out more http://t.co/XWvcvLRjTb
7 Common Mistakes Enterprise Architects Make - Simplicable | @scoopit via @pascaleMMM http://t.co/kYkmGRuPqD
The 'evolution' of leadership RT Leaders, Market Yourself! | @scoopit via @onevoicesmiling http://t.co/XHv1jIlVhN
However, as a lesson in potential for future programming its all a bit frightening - seriously impressed!
Leaving to mature for a few days ......
Leveraging the New “Natural Growth” – Megatrends, Accelerators and Risks | @scoopit via @LeadershipABC http://t.co/OzCFSWKRjN
With a bit of luck I have just connected my tweets to my blog by 'programming' @IFTTT - will be well impressed if it works!
Going to trial an app that let's you connect various social media and sensors through a simple programming language - IFTTT- standing for If This Then That.
Results of one of these programs hopefully will be posted on this blog as tweets.
Here goes - entry into a whole new level of computing!
Thursday, 24 April 2014
Sounds like a plausible approach to running a project or setting up contracting arrangements for a large project. Can you do this? It runs against the ethos of a systems approach and the systems engineering practice.
Businesses - which are effectively large systems of systems - these days are floundering towards more flat-open type management structures. This engenders emergent control within the workforce and more fluid problem solving as teams can form quickly and then disperse. Sounds agile - as long as you don't kill it with bureaucracy its an effective business model.
Can this approach be applied to engineering problems? They do tend to be a bit serious though and need project plans and costs and budgets and risk management and the like - which all sound very bureaucratic in the extreme. But, is there no way some of the more fluid principles could be applied without the project running over time and budget - wait - that's what large projects tend to do anyway even with all the bureaucracy!
I have just been involved in a large tender which carved up the engineering disciplines each being bid separately. It was evident that the difficulties of breaking up a system for tighter control led to a very restricted set of responses being asked for. Whether this is what was intended or not I'm not sure - it will certainly make marking the scripts easier - but will you be able to bring all the elements together again to form the fluid project team environments? Maybe there is some more bureaucracy we can call upon to help with that though ;)
Anyway - onward and upward.....
Saturday, 15 March 2014
Just basically had to ditch a load of old software development processes - mainly because of the growth in number of documents and variations on what to do for different computing environments was out of control. Out of control to the point where it was difficult for new entrants into the document set to understand where to start. Best option was to just start again!
Things have moved on as well - as noted in previous posts - agile developments are the current flavour. To be honest this is the approach most people take to software development too - apart from some very expensive military type developments or safety critical applications that is where you may just want to be a bit more rigorous! But for general use most people just want to get on and start coding and an agile process lets you do this in a sort of controlled environment.
This is also the problem faced by engineering projects who's aim is not code development but rather to solve some engineering problem, explosion effects, fire impacts, evacuation implications etc. The problem is most of the time getting to the answer takes a bit of coding - not everything can be worked out by pencil and paper these days. So what are the options? Do some structured programming design following software engineering standards or jump onto something like Excel and start bashing away! Well you know the answer to that one don't you. Plus add a few Macros and Bob's your aunt you have created the monster. An answer to the engineering question pops out, you write the report, and 'file' the code.
And who can blame someone wanting to do that - we are generally paid for getting the answer not for building some shiny new software code. So, the trick is to integrate a development lifecycle into this very results delivery focussed environment. Enter the agile computing frameworks - using some of the techniques from previous posts like Just Good Enough, and Test Driven Design around project timescale based Sprint's - a level of software quality assurance rigour can be injected into the delivery without the 'developer' actually realising!
How do you do this ..... more later.
Wednesday, 12 February 2014
Tuesday, 28 January 2014
2013 has been a roller coaster year for me on a number of fronts - but just how is the revival going. Well 2013 has been a bit of a milestone on the revival path. I've realised I am not as far off-piste as I thought I was when I started reviving myself. In fact, some bits don't need reviving at all they are revived and operating quite well thank you very much. However, not the bits you normally associate with software engineering!
The one thing that the past year has brought home to me is the pace of change in the industry. Frantic! Managing a business critical project in this constantly changing environment has been an exciting challenge in 2013. It just so happened that I started off the year studying for a 'certificate in complexity' at the Santa Fe Institute. Just out of curiosity, interest, development, not quite sure which. I didn't quite realise how useful this was going to be in understanding some of the issues that went throughout the rest of the year. Its a fantastic course (and book), I have said it before but say it again, thoroughly recommended. Plus its offered free, or was this past year, it was so good though that I donated to the cause anyway!
So complexity, in all its guises, is cropping up everywhere from social networks through to 'big data' and was the No. 1 theme for 2013.
The revival had started off as a wish to get back into some form of programming again. I did have a foray into Fortran a couple of years ago which basically told me not much has changed. This past year though this trail has led to specification and assessment of big-systems architectures. What started of ass an analysis of a requirements set ended up as a full on programme of work to install an asset management system for a large corporate. So a bit of a detour from the original but its a journey that I am very glad I took as it has given me an insight into both process and capabilities at this corporate system level. Something that I would normally have avoided like the plague being a more 'signal processing' guy! Although I didn't have much to offer in the big-systems front, or 'solution architect' front as it is called, I found I did on the process and management side of things. Specifically requirements and 'selection' processes and the management and engagement of teams. If you can codify what it is you are doing then you are half way to being able to explain it and indeed get others engaged in what you are doing.
So, codifying complexity in a process, a necessity to be able to focus development efforts and the team, is the No. 2 theme for 2013.
During this project there were two points throughout the year where there was opportunities to 'get on and do something'. Elements of the system could have been designed and built by the internal business software teams. That is rather than paying someone external to do it of course! However, the governance processes in the business essentially delayed activities to a point where it was then no longer viable to build internally anymore. Don't ask how this happened, safe to say that everyone was pushing for it to happen but the 'engine' couldn't turn fast enough. Which is a real shame, not to mention a costly impact on the business. The not-so-hilarious thing is that the external (big)company who was then employed to do the work suffered exactly the same issue! Blind leading the blind comes to mind. Its endemic - governance processes don't seem to have kept up with either the business environment or the agile working nature needed to service this modern climate.
So agility, not just in software development but also in decision making is the No. 3 theme for 2013.
A final thought relates to systems management - there are 'architects' at all points of the compass with conflicting advice - all very well though through of course. The trick however, is to know what the art of the possible is, and this requires clear business led management. Not IT, not any 'architecture' and not any expert system! It's engaging brain and putting in effort to understand exactly what the business needs and can handle in terms of change.
So, taking back technical management control of complex projects, not project management or cost management is the No. 4 theme for 2013.