The Agile Tribe

The Reality Gap between Business and IT – Let’s build a bridge!

Author: Robert McDonald

I believe software use in a company fits into an overall process rather than just being an end in itself. I have had long experience in Banking branchland and it occurs to me that the distance between the technicians and coalface staff is an area where organisation but certainly in banks where we can improve. Having worked on the Service Desk for a large financial institution, I found that throughout the company there was an issue with collaboration or should I say “ a lack of it”. It is either a blame game or just a total absence of empathy.

I feel that we could all benefit by closer relationships with our colleagues particularly where we have interdependencies. I suggest that we need to expand the experience of the technical staff to include the business processes rather than just working in a vacuum on the application. The difference between an application and a process is that the process is the overall activity of the staff member(s) which may include the application.

If a customer comes into a branch to withdraw $1000, the process includes greeting the customer, use of an application, determining the denominations required by the customer, counting the money, possible marketing opportunities or alternatives (BPay?) etc. The IT system used at the coalface is merely one small part of the overall process.

Understanding the full process of each normal banking activity is important to make the application fit with what is desired rather than having the process work around the application. The focus is on the business need rather than what IT can provide, and the change is very subtle, but important. I am not saying every teller should be able to dictate requirements to IT but there is certainly a Reality Gap between how the technical support for an application, the staff member using it and also how the end customer views the application as part of their overall experience.

It does exist and is the result of the lack of communication and true collaboration. In a company that boasts an Agile approach to their work where these two features are key principles, in my humble opinion, we need to build a bridge and get a regular thoroughfare going with our technical support staff going out to the branches and call centres on a recurring basis, so they can improve both their understanding of the many steps of the process and also how they can collaborate better with the bank staff.

This should also work the other way as well, allowing bank staff to understand where the technical support staff are coming from and what may be influencing their ability to assist as well.

Support people need to be in their internal customers’ pockets , not just at the higher levels of management. I would like to see a couple of our technicians working from a branch for a few days, or from a call centre for a day or two a month, to see what it is like to “walk a mile in their shoes!”.

Banks are large complex environments, but I think if we bring in this as a ongoing culture change (as we have with other major changes successfully) we can make it work, with all the attendant benefits which smaller companies have in this respect.


Mental Note: Co-location implies dedicated resources

Author: Andy Marks

For some people, co-location is a non-negotiable aspect for successful Agile teams. Yet sometimes barriers to having an entire team sit together come from somewhat unexpected quarters. For example:

I’m currently a tester working on three different projects. Each of the projects are on the same floor. There is a strong desire to co-locate teams to improve collaboration and communication.

But which project do I sit with:

  • The most important?
  • The one closest to delivery?
  • The most challenged?
  • The team I like working with the most?
  • The team with the least testing resource?
  • Do I time share – 33.3% time each day per project?

And the most important questions to answer: what is the root cause of the problems? The impracticalities of co-location? Or the problems with multi-tasking?

1 Comment »

Apologies to the Scrum folks …

Author: Andy Marks

I had the pleasure recently of spending some time with Martin Fowler talking about Agile Adoption. One of the topics we covered was the importance of experienced people to a successful adoption and how time is a necessary but not sufficient prerequisite to gain this experience. We used Malcolm Gladwell’s thesis in Outliers to provide some extra support to a notion I think we all fundamentally believe in.

Part of this topic included a lighthearted snipe at the CSM certification from the Scrum Alliance and how ridiculous it is to assume any competence in Scrum after only two days of training, let alone having the audacity to apply the term “Master”. Thankfully the audience in all these sessions saw the tongue-in-cheek nature of these comments and we managed to draw a number of chuckles each time.

However, because I see no correlation between being CSM0-certified and having any level of competence in applying Scrum…

  • This does not imply that all CSMs are complete nuff nuffs. “No correlation” means that you cannot make any statement about one given the other. I’m sure lots of gun Scrum people are CSMs, but it’s got nothing to do with the CSM training in isolation.
  • I hold nothing against Scrum itself. Applied appropriately and with the correct amount of technical rigour in the trenches, I think Scrum can be as useful to a project as any other form of Agile.
Leave a comment »