Join us at the watercooler. The CA Gen community is here.

iStock_000014820352XSmall

The watercooler – the place to be

Picture the scene.  The watercooler in the corner of our CA Gen development centre bubbles away, as four or five of our team members take a break from their development work – coincidentally all at the same time.

The topic turns from Christmas shopping to last night’s “I’m a celebrity…” (for those outside the UK, this is a TV show, you’re probably glad you’ve never heard of).

A few more people join this ‘watercooler moment’ and – as you’d expect – the topic of discussion changes again.  One of the team members reveals they have had a ‘eureka moment’ with a CA Gen modernisation project.  The conversation then becomes frenzied and work-related, with all discussions about Christmas shopping forgotten.  This has become a classic ‘watercooler moment’ and shows just how valuable these informal work get-togethers can be.  Everyone gets back to their desk, encouraged by the fact that someone has achieved something above and beyond their normal remit, and given the customer much more than they’d expected.

pouring a glass of water

More than just water. The watercooler is the hub for office banter.

This happens everyday in companies across the world  – so why are we obsessing about it here?  Well, during our most recent ‘watercooler moment’, the conversation inevitably turned to the topic of the CA Gen community.  It’s a phrase used widely – and, as you’d expect from such a legacy system, very affectionately.  Which started us thinking; if we could get the entire CA Gen community around our watercooler, what would everyone talk about.  The need for more cups, obviously, but it became the subject of a heated debate.

With no consistent agreement on the big subjects, we decided to find out – in the only obvious way. We’d ask.

So, if CA Gen forms a part of your remit (no matter how small), we’d like to invite you to our virtual watercooler for a a brief chat.  (It’ll only take you a few minutes, and it involved nothing more than clicking a few buttons – certainly with no typing required!

_______________________________________________________________________

Get involved…

Join us at the watercooler here 

and take our quick three minute survey.

________________________________________________________________________

We’ll publish the results (but not individual replies) in a forthcoming blog – so we’d really appreciate you taking the time to participate.

Thanks in advance for taking a brief break from the grind of daily life.  There’s nothing like a break at a watercooler for helping you to recharge!

If you’d like more information about our CA Gen modernisation services, please contact us.

Advertisements

Legacy modernization: How to avoid fumbling in the dark

_MG_0565Jeroen Wolff continues his analysis of issues faced by legacy modernization professionals in this latest blog post.

In our previous legacy system modernization blog, we focused on the importance of understanding exactly what your legacy system does, and how it does it – before planning your route to modernization.

This seemingly obvious process, like the subject of this particular blog, is often not given the priority it deserves.

And that takes time, as well as increasing frustration and delay.

Today, we’re talking about documentation – and the importance of creating and maintaining both user and support documents. It does sound obvious, doesn’t it? And you’d think it would be done as a matter of course. But, as we’ll see, that can sometimes not be further from the truth.

Files on bookshelves

Missing documentation – it’s not helpful

Consider the software engineering tool, CA Gen, where we have specialist expertise. The whole idea was that, being model-based, the documentation effectively WAS the model. This was a fundamental principle of the IEF, the forerunner to CA Gen. In theory, any competent person, involved in any part of the life cycle – from analysis to implementation – should be able to pick up the model, and understand how it was encoded. However, there are a number of reasons why the reality differs from the theory.

  • The theory still requires the developers to enter descriptions and annotations where necessary. Developers are, of course, not writers. They like to code, and the need to add those descriptions gets put on the back burner and ultimately become “forgotten”. After so long, it simply gets overlooked as the path of least resistance becomes a little more trampled.
  • Development methods inevitably move on and the development tools lose their synergy with the method. For example, whereas CA Gen had full support for information engineering methods, it is less suited to support current trends like UML and analysis methods of writing user stories
  • There are many people with an interest in the documentation who don’t necessarily have access to CA Gen or the skillset to find the relevant documentation within it.

The impact of all this is self-explanatory. As discussed in the previous blog, you find yourself looking at a legacy system, scratching your head as to where to start. Had there been a mindset that documentation was maintained (for both users and support staff), you’d have a much better idea of how to begin.

Tools like Jumar’s Model Analyser and Model Reporter can be used to automate the analysis of the ‘as is’ state of the applications, but having documentation to complement this means you can make even more educated decisions at the start of the process.

What, therefore, can be done?

The solution can be boiled down to a three-step iterative process, comprising improvement, extraction and monitoring:

Documentaion diagram

  • Improve the information that is within the model. Tool like Jumar’s BulkUpdate allows for descriptions and notes to be added quickly and efficiently, using Office tools. Other Jumar tools can be used to extract information from various different development tools and bring it together. For example, Jumar has experience linking different development tools (IBMs Rational, CA ERwin Data Modeler, etc) with CA Gen and vice versa, thus allowing for the full life cycle coverage once again.
  • Extract as much as possible from the models. Automation tools like Jumar’s Model Reporter and Model Analyser greatly help here. The first allows for automatic generation of User and support documents in different formats. The latter extracts all important model information to a local database where it can be queried easily. It also allows for complexity reporting so that you know where the focus of the documentation should be. It can also help in terms extracting certain business rules and problematic code constructs.
  • Monitor for quality purposes. Once the documentation is up to date, ensure it is maintained by setting up appropriate QA processes. Again, tooling can help to carry out QA activities. Especially important when supporting a system which is only updated every so often or when quick production fixes are applied.

A word of caution though; using Model Analyser and Model Reporter can be a ‘quick fix’ – but it’ll be much more cost effective for your organisation if they are used as the starting point for a concerted, on-going plan to improve documentation.

While we’ve touched on CA Gen as an example here, this is true for practically any legacy system, but is a warning that we see repeatedly going unheeded.

Case study

iStock_000016008010XSmall

The old adage. Which would you rather be? Especially when assisted by automation.

In a recent client assignment we undertook here at Jumar, one of our experienced legacy experts took six weeks to complete the documentation of a system which should have been done by its previous custodians. Six weeks may sound like a long time, but it was dramatically accelerated by the use of automated analysis tools – and this investment in time ensures that any future development within that legacy system can take place at a fraction of the time and cost than it would have done without those robust documents.

So, what is our advice to alleviate the problems caused by a lack of documentation? Quite simply, you can AUTOMATE your understanding of the system. By ‘automate’, we do genuinely mean that the process is not a manual one. There is an understandable suspicion towards claims of automation – with many thinking that there’s a low-cost development shop somewhere carrying out intensive tasks which vendors claim to automate. But the tools described here (and others within Jumar’s Project Phoenix suite of software) ARE genuinely automated – and we can demonstrate this. This will form the basis of next month’s blog – but for now, we hope this latest post shows the importance of documentation, and why now could be the time to grasp the nettle and get on top of the issue in your organisation.

We can help make it cheaper, faster and less stressful – just get in touch to find out exactly how.

Agile software development – it’s more than just sprinting and scrumming (Part 2)

Agile thumb

Watch the content of this blog on YouTube

Welcome to part two in our series of blogs about whether organisations are REALLY following the agile methodology when they claim to be.  In the our first blog (read here first, if you’ve not already) we looked at two of the scenarios in which agile techniques are misapplied.  Remember, you can watch all this in our YouTube video available here.

In this post, we look at another two.  Next time, we’ll look at three more, but for now…

Misconception 3: Scrums and sprints define Agile

1Agile 2.2

A familiar diagram

One of the most well-known features of an Agile project is the daily scrum meeting.

We have encountered several organisations which claim to be ‘doing Agile’ solely on the basis of having implemented the scrum meeting technique into their process.  But of course Agile is about much more than this.  Scrum meetings can take different forms but in the most common we ask three key questions:

  • What have you done since yesterday?
  • What are you planning on doing today?
  • What  –  if anything – is stopping you from achieving that?

The purpose of these questions is of course to make sure that everyone knows what everyone else is doing and to ensure that blocking issues are dealt with.  This is essential for an agile application development project with a fixed timescale.  The scrum meeting is very useful, but it’s important to recognise that it is just one part of the Agile process.

Misconception 4: you can use it as an excuse

Often, Agile can be seen as an excuse NOT do a whole host of necessary processes – for example:

  • not writing a proper specification
  • not writing documentation
  • not using the appropriate tools
  • and not sticking to plans
Agile 2.2

Agile is not to be used as an excuse for not doing things properly. Watch the video for more.

It can be viewed as a bit of a free for all – but at Jumar, we believe that all the above are necessary. Just because the Agile methodology allows you to change the scope during a project doesn’t mean that you don’t need to know what you’re building when you start or that you don’t need close, formal control.

When you start an Agile project, we believe that you should have a clearly defined scope, a specification and a detailed plan.  The difference with Agile is that you EXPECT change during the project and the approach accommodates for it.

Next time: user demonstrations, testing and priorities

We’ll be publishing our next YouTube video very soon covering these very topics.  Watch out for the blog version too, coming over the coming weeks.

Like to know more?

Please contact us here.

Agile software development – it’s more than just sprinting and scrumming (Part 1)

Agile

Agile – is there REALLY a lot of it about?

If you Google “Agile Methodology” you’ll get just short of three million results.  There’s clearly a lot of it about.

Well, actually, there’s a lot LESS than first impressions would have you believe – and there are a lot of people who think Agile is something that it simply isn’t.

And that’s the problem.  Lots of organisations claim to be ‘doing agile’ when, in reality, very few are.  Many are doing something they consider to be agile software development, but which could not be further from the truth.

Agile thumb

Watch our YouTube video for more on this subject

This blog post covers some of the points raised in our recent YouTube video “Are you really being agile?” (which you can watch here) – and is the first in a series of blogs covering common misconceptions about Agile.

We regularly hear people saying that agile doesn’t work – or it’s not appropriate for a particular situation – when in fact it’s just not being used effectively.

And that could mean missing out on the many benefits that a truly agile project can bring.

Before we look at the misconceptions – a recap

First – a small trip back to the drawing board, and a look at the biggest differences between agile and ‘traditional’ methods of software development (waterfall seems to be the most commonly quoted).

The three key elements of a project are:

  • time
  • resources
  • scope

In the ‘traditional’ model, it is the scope and resources which tend to be fixed.

Agile 1.1

Traditional methods mean scope and resources tend to be fixed – with time as a variable

Any change in the project which increases the scope means it’ll take more time.  Quite understandable then, that change is feared in this scenario, as it will add delay.

In the Agile model, however, we have exactly the same parameters, but it is the TIME and resources that are now fixed.

Agile 1.2

Agile approach: Resources and time is fixed, so high-priority items are included, and lower priority items form the next project.

Scope is, therefore, the variable – and it makes provision for the fact that change is EXPECTED. This methodology, therefore, allows for change – and in fact, encourages change.

Misconception 1: Agile automatically works for everyone

So – back to the plot.  How does this relate to misconceptions made by organisations claiming to ‘do agile’?

Agile 1.3

Manage expectations: ensure all stakeholders buy in to the agile concept

The first issue, surrounds ‘people’ – and by this we mean the entire team of stakeholders involved in the agile process.  We know that the time is fixed – as are the resources.

So, when feedback leads to new features being introduced, it is inevitable that lower priority items will no longer fit into the timescale, and will go onto a wish-list for a future release.   Everyone involved has to accept this – and unless there is buy-in for this concept, it could be viewed as a negative.  And this regularly happens, as users who are familiar with the traditional approach, expect the new features AND the old, and are unwilling to let anything drop out of scope.  If one gives into this pressure, the project is no longer agile.

We combat this by always holding detailed upfront sessions with users to make sure they are familiar with the benefits of agile – especially the fact that it allows a predictable timely delivery based on prioritisation of features.

Misconception 2: It takes all sorts

It’s vital that the correct personalities are involved in an agile project.  This includes not just the techies, but also the non-IT stakeholders.  For agile projects to be really effective, they need to be staffed with individuals who want to prove something, and who thrive on the challenge of working to produce the best possible result to well defined timescales.

It’s simply not for everybody.

Next time: Misconceptions 3 and 4

In the follow-up to this blog post, we look at scrums, sprints an excuses.  Following that, we’ll go on to discuss failures to manage user demonstrations, and ways to get quality feedback.  We’ll examine problems with prioritisation and failure to build testing into the process.

Want more?

In the meantime, if you’d like more information about any aspect of Agile, please contact Jumar.

New YouTube video: Are you really doing agile software development?

Doug Michael - CTO, Jumar Solutions

Doug Michael – CTO, Jumar Solutions

Often the subject of intense debate, and also regularly misunderstood, the “agile” approach to software development is a subject upon which people get rather animated.  There are all sorts of misconceptions about agile – many fuelled by organisations which claim to be doing agile, when they’re not.

Jumar’s CTO, Doug Michael, is no stranger to agile – and has lived it for many years.

In the latest in our series of YouTube videos, Doug examines the differences between agile and other more ‘traditional’ methods of software development, such as waterfall for example.

He then goes on to look at the mistakes made by organisations who claim to ‘do agile’, specifically, their attitudes to

  • fixed timeboxes
  • sprints
  • scrums

…and how these should be carried out properly in order to conduct a truly agile process.

The video is the first in a series of two YouTube presentations focusing on Agile.  Part two will be made available later in the year.  For more information about Agile Software development, please contact us.  If you’d like to speak to Doug directly, please also drop us a line, and we’ll be in touch.