Agile Adoption in the Banking Industry

I was organizing my email today (large backlog as usual, need to put in a policy where I purge things after 6 mths) and came across a summary I had from an agile adoption survey a few of my colleagues conducted with several large banks. This is by no means a scientific survey, just one that was conducted with senior leaders from several different banks. Thought it was interesting to share. Here are the key findings:

1) Banks are using agile in tactical ways

2) Their usage is largely limited to applying two practices “iterative development” and “co-located teams”

3) Architecture is not interested

4) Business and development are interested with QA on the fence

5) Compelling reason is reduce time to market

6) Main barrier is cultural, looks like there is a strong culture factor against it

7) Key challenge is estimation, they are unable to apply it within their current budgeting model

8) Key success factors are executive sponsorship with appropriate coaching

This aligns with a general observation that I have noticed as well. The movement is largely developer driven with business wanting to get in but challenged by their budgeting model. Architecture and QA are largely not bought in.

Value Stream Mapping Session Gone Awry

During one of our lean client engagements, we conducted half a dozen value stream mapping sessions with various groups and project teams from the client organization and this session was an interesting exercise. The session involved a large cross-functional team responsible for maintaining a very large-scale system and we wanted to get representatives involved from each stream / discipline (PM, BA, Dev, Test, Training, Architecture, Service Management, Infrastructure) to get the holistic picture. We ended up with a group of ~20 people and one of our facilitators (i.e. Jeff Anderson) decided to facilitate using a decentralized approach and handed out stickies to everyone and asked everyone to come to the wall and map out their specific processes in the value stream. This is what we ended up with:

Needless to say, I am having a "fun" time transcribing this into a visio diagram (we promised the client we would capture the value stream and give it back to them as a deliverable). Next time we have such a large group, I think I will use a different approach (lesson learned).

Architect Police vs Architect Leads

A classic problem I encounter in various IT organizations is the massive divide between Architecture and Project Delivery. Most organizations today have recognized that architecture is important to the organization and as a result have established some form of Enterprise Architecture Governance (Architecture Review Boards, Advisory, etc). This is a good first step, as having a central body that can provide holistic and strategic oversight and advice can help consolidate the maze of systems and designs that has been inherited from past bad behaviours and move organizations towards a rationalized portfolio.

However, in an effort to provide "independence" these governing bodies often suffer from the classic ivory tower syndrome and have evolved themselves into a "policing" role. As a result, project delivery teams looking to deliver cheaper, faster and better for their clients find themselves at odds with Architecture which they look at as a speed bump to their work.

This "architecture policing" anti-pattern tends to produce the following results:

• directing scarce and valuable experienced resources into producing conceptual and logical architectures that provide little value to delivery teams
• emphasizing "policing" over "advising" and "leading" resulting in architects that are out of touch with the client requirements, project context and implementation decisions
• mandating high ceremony checkpoints with heavy documentation and review that slows down project delivery while adding little value to the team and clients
  

Instead of playing the role of police, architects can provide much more value to an organization by decentralizing themselves back into project delivery roles and taking ownership of delivering solutions to clients. During my attendance at the IBM Impact Conference 2010, there was a great success story with a Leading Canadian Bank that delivered an enterprise wide service bus architecture and framework with working code led and owned by their architects. The organization established Framework Architects that were responsible for designing and evolving their ESB framework and assigned responsibility to channel and business facing Solution Architects to extend the framework for their specific client needs.

I am hoping to see more organizations continue to follow the approach of embedding architects in delivery and leading the development of core frameworks and assets for reuse / extension by the organization. Architects leading by "doing" is always a good thing.

KANBAN Overview - created on my iPad

Upon getting my iPAd the first thing I did was create a mock up of a Kanban board using the omnigraffle diagram software. The board is based on several chapters of David J Anderson's great book "KANBAN - successful, evolutionary change for your technology business. I think the results turned out pretty well. Feel free to use and reuse, btw I highly recommend getting David's book, it's a game changer IMHO...
















- Posted using BlogPress from my iPhone

Getting to Lean Principles

I had the opportunity to work with some IT execs who wanted to look at Lean thinking as a method to improve the way they were delivering value to their business customers.


Lean ideas was certainly not something that was embraced by the org, and certainly not all of the execs were bought in to Lean ideas, or even had a real understanding of how lean thinking could even be applicable to their problems. In preparation for a one day visioning session, our team sent out a questionnaire asking the execs to match specific organizational objectives to various possible activities.

Here is an example question:

The IT organization should manage process changes through:
- a specialized and dedicated process governance group
- empowering people on the ground doing the work
- assigning process change authority exclusively to middle management
- Senior executive oversight

While the "right" lean answer ( in quotes because no answer is exclusively right) may seem obvious to most readers of this blog, I thought it was important to test the beliefs and opinions of this group to see if anyone would be challenged philosophically about lean thinking.

All to often I've encountered belief systems that make it really difficult to have even a cursory conversation of how lean can help IT liver better value.

I was pleasantly surprised about the answers I received. While they weren't unanimous, the majority of responses indicated an intuitive affinity with a Lean way of thinking amongst most of the execs. With a little bit of grammatical restructuring we were able to take these answers and use them as the basis for a set of transformation principles that would guide this organizations journey to a different way of doing work.

Below are the principles, which I think are good ones for any org looking to adopt elements of lean thinking..


Empower process changes through: people on-the-ground doing the work

Leadership and Management should: coach, empower and enable

Manage priorities and requirements by: partnering with the client and collaboratively defining product roadmaps for each LOB

View automation as: a priority across all projects and applied to all aspects of the delivery lifecycle

The key measure of team success should be: client satisfaction of value delivered vs. time to deliver

Handle work based on: structuring work into small batches that can be released quickly

Build value through delivery by: getting resources working collaboratively and in cross-functional teams throughout the process

Approach quality: by investing early on and building in quality

How-to Conduct a Remote Agile Daily Stand-up

Physical objects tend to help teams perform, communicate and operate more effectively. We've seen this trend with iteration planning boards, kanbans, continuous integration orbs etc. So, we thought how we can make daily stand-ups with a distributed team more effective? Here's our answer.