Agility fragility

Everyone says they are but are they really?

I'm talking about - agile - that's in the systems development sense of course. Though when I think of agile my analogy is of a footballer who has the ball and is running down field avoiding tackles changing direction etc. That's agile in my mind - making changes and looking for opportunities to gain an advantage on-the-fly.

In software and systems development the term agile seems to be cropping up everywhere I look. Agile development, agile design, agile management, agile this, agile that. However, the question in my mind is, is the systems engineering industry really ready or 'real' agile.

A few worrying issues are appearing. Firstly the industry is developing an 'Agile Standard', certificates the lot! Doesn't seem to fit very well with the concept. Having worked over the past few months with leaders in system development. There is a willingness to embrace the concepts of 'agile' but we are all struggling letting go of our background in structured approaches to systems development. Which now, given the speed at which things are changing definitely looks like an 'industrial era' approach to design.

When I check my font of all knowledge Wikipedia its not much better - a thousand and one versions of what people think agile is - very well presented though! High level concepts fair enough but where the rubber hits the road not much cop.

The journey continues......

When do you stop....

So when do you stop?

That's requirements gathering and defining and modelling and verifying and ...

At some point you need to get on with it and start designing and building. But when is the right time to begin - we just need to check we have the requirements in from planet zog and then we are good to go!

There is also a bit of Parkinson's law going on in this phase of the systems engineering lifecycle. A bit of of well we have a few months (years) left to go lets have another cup of tea and think about some more requirements. Just when do you have enough requirements?

What's the answer - nobody knows! There will be a tipping point in every project and then the muck hits the fan and off we go - then its - what requirements - I'm too busy building stuff!

You would almost be better off starting by creating a 'Compelling Event' milestone in your project plan - by plan I mean a high level plan - not the Primavera I've planned everyone's tea break's for the next 5 years type plan. The 'Compelling Event' might be something like when we reach 100 requirements that's it we are going into build or it could be if you don't have something working by now then you are all sacked.

Either way, this would provide a point of reference for everyone to sign up to and then focus on. There obviously needs to be an incentive scheme associated with the CE or it will be just a 'so long thanks for all the fish' point in people's lives ;)

Sort of on optimised Parkinson law!

Top of the pops......

Well the Top 5 focus activity reported in the last post seems to be working very well indeed - surprisingly given the shaky start to it all!

Focus, focus, focus in all areas is paying dividends and  we all finally know what is needed to deliver the Top 5 in all areas including;

1. Planning arena around development of the programme plan,
2. Data modelling, what, when type questioning,
3. Process modelling activity, business change etc related
4. Contract-ITT developments, what's in and what's out of the contract,
5. Business benefits, what and when released by the Top 5 areas.

all starting to align in terms of the overall approach.

So its looking pretty good for this equifinality approach - much to think over - can we get to an end game with it though?

Only time will tell.....

Complexity is .. er.. complex!

I seem to be mired in complexity these days - very exciting though must admit - closet (or not) problem solver at heart you see.

In past posts have focussed on how on the current project we are going about defining the requirements for a very complex revamp of an asset management system. This has used the concept of 'viewpoints' to build up the requirements and ensure as comprehensive a coverage of system functionality as possible. What was than new word I learned - ah yes - equifinality!

All well and good but then the question was asked - what does all that mean - which seemed reasonable to me. What do I get and when do I get it? Which means having to think through the outline design and high level system architecture - to answers the "what I get" question- and production of an outline programme plan - when to I get it. Logical again!

But - where do you start? How do you then start to put an outline design together? The design team all have different views on timescales and exactly what can be delivered when. Data team running ahead of architecture team running ahead of process modelling - not to mention how are we going to control and manage acceptance of whatever it is is produced! Just where DO you start?

The answer again - equifinality - starting to like this word even more! This time though used in a different context. This time used as a focussing tool - a lens as one of the team explains it - to help focus in on particular aspects of the system design and build. Trying to specify the design of the whole system in one go or even think about how the whole works just blows your mind - yes, but, if this, and if that, and if the other - people disappearing up their own exhaust pipes left right and centre - others sat there fish like, mouth open, eyes agog, what does it all mean, anyway what's on the telly tonight.

So to drive the thinking a Star Trek Management decision was made - a Top 5 would be selected for the team to focus on - make it so number one. A Top 5 what though? The Top 5 'things' of course - go and find out what they are! This has cause a lot of hand wringing, what Top 5 - that's the wrong Top 5 - we don't have the right priority Top 5. However, miraculously, running numerous workshops over the past could of weeks has shown that there actually was a consensus on a Top 5! Key items and dependencies drove everyone to the same set of Top 5 'things' - you could have written them on the back of a fag packet in Top 5 minutes but the real value I have seen is in rallying the team around some common themes - driven by a final outcome - equifinality focussing in action!

So we are now up and running putting together outline timescales for delivery of our Top 5 and drawing boundaries around what can and can't be delivered in these timescales.

There could of course be another Top 5 next week ;)

Onward and upward.....

Not quite there yet ...

This week has been a bit of a reality check on all things connectivity related - so beware you Cloud computing evangelists.

Having said that, this past week has seen me use a remote desktop service from Microsoft pretty effectively. Well in fact I wouldn't have been able to complete the job I was working on without it. Essentially I can't load anything onto my work computer - locked down tighter than a duck's ..... - anyway safe to say it makes  Apple look almost developer friendly. However, through the wonders of the internet and the RDS service all was well, Microsoft Project, Visio you name it I could use it. Impressive, bit slow where I was due to internet speed, but full functionality at the click of a button. Only problem was the client had the same problem as me, they don't have Project or Visio loaded as standard either - convert to pdf saved the day. So all that was worked swimmingly.

The problem came when I had to go into London which involved moving hotel. From my usual cheap 'Lodge' to some very expensive place. I have to say it - the room didn't have any windows either - not sure if that's even legal? Anyway, issues began to arise around wifi connectivity. I was trying to meet up with a friend, who doesn't have a mobile phone (now there is a learning point) only a laptop for communicating via gmail. So we had set a time to check email's in order to plan meeting up one evening. However, I couldn't get onto the wifi at my hotel - life is too short to find out why, one minute it was working the next poof it had gone! So what was the backup plan for communication - well we didn't have one - so I thought, Costa's or McD's and free wifi. Off I trundle with brick of laptop looking for the nearest free connection. Made it thanks to Nero's only to find no message from my friend. What I didn't realise at the time - he was staying in another hotel - and having the same connectivity problems. So he had gone to even greater extremes to connect up. Not knowing this I thought the best plan would be to just walk to his hotel and sit in the foyer and wait for him to pass by. Long story short - we passed each other in the street - he had the same plan and was heading for my hotel foyer! Now that would have been funny.

So the lesson - don't bet your business on ropey internet connections and always have a tested business continuity plan ......

Herding dogs!

I was going to say this week has seen the herding of cats but its been more like dogs - bit easier to herd than cats but if you get it wrong you get eaten!

Its all been about a senior management workshop the focus being to pull together the structure and details to go into specification of contract wording. I wasn't running the thing - lucked out there - just a participant. Everyone else (if you read this - you know who you are ;) had run for the hills as the unleashed pack can be pretty ferocious! Anyway I though this could be fun, in a voyeuristic sort of way, as running these event is not easy at the best of times. However, shock, horror it all went pretty well, I even managed to contribute!

What made the difference? Well it was the use of a technique I came across 20 years ago, part of the now old looking SSADM toolset, but now reinvented as a six-sigma activity called SIPOC. What are all these acronyms doing in here. SSADM, in case you don't know as it was a long time ago, is Structured Systems Analysis Design Methodology - probably why it never really caught the imagination come to think of it. SIPOC stands for Supplier, Input, Process, Output, Customer - e.g. how to define an activity in the SSADM process modelling world.

The following link has a good description of what you do to fill out a SIPOC;

http://www.isixsigma.com/tools-templates/sipoc-copis/sipoc-diagram/

or check Wikipedia there must be something in there on it.

In fact, at the workshop, this process was followed very closely but with the addition of discussing the 'principles' of the contract area before launching into the detail of the 'process' part. Which provided a 10,000 ft introduction to what we were talking about and was a good feature to add.

So 10 out of 10 for SIPOC dog herding, and rock-on SSADM there is life there still ;)

Whole greater than the sum of the parts!

Realised I've been living a new word over the past few weeks and didn't even know it!

The word is 'equifinality' - what - well here is the Wikipedia definition:

"Equifinality is the principle that in open systems a given end state can be reached by many potential means. The term is due to Ludwig von Bertalanffy, the founder of General Systems Theory. He prefers this term, in contrast to "goal", in describing complex systems' similar or convergent behavior. It emphasizes that the same end state may be achieved via many different paths or trajectories. In closed systems, a direct cause-and-effect relationship exists between the initial condition and the final state of the system: When a computer's 'on' switch is pushed, the system powers up. Open systems (such as biological and social systems), however, operate quite differently. The idea of equifinality suggests that similar results may be achieved with different initial conditions and in many different ways. This phenomenon has also been referred to as isotelesis (Greek: ἴσος /isos/ "equal", τέλεσις /telesis/ "the intelligent direction of effort toward the achievement of an end.") when in games involving superrationality.

The previous post raised the issue of how to you start to define the requirements and projects for a complex system - essentially how can you make sure you have captured them all?

What you need of course is a very large dose of equifinality - you need to travel as many different paths through whatever it is the system is being designed to do as possible. These paths, of course, need to be both top-down and bottom-up and cover as many viewpoints of the system as possible.

So what sort of viewpoints are we talking about?

What about;

• Physical architecture
• Data - Information architecture
• Business Process architecture
• Security architecture
• Enterprise architecture
• Functional architecture 
• User architecture

However, you may therefore need a degree in architecture to fully complete ;)

Final thought from the complexity course I'm doing is that even if you take all these paths you will still have some emergent property that will take you by surprise!