The Bank of Agile

Throw Away Your Steering Committees!

The National Australia Bank (NAB) has recently thrown Steering Committees in the garbage and taken on a more Agile approach to product development. Australian CIOs advocating the Agile software development model have embraced a “behind the scenes” management role to facilitate faster, more flexible teams. Projects no longer involved steering committees and those C-level representatives find them a “a waste of time.”

Rob Thomsett, currently a consultant to the National Australia Bank (NAB), said the bank had adopted Management 2.0 (Management 3.0 anyone?) principles in an effort to reduce bureaucracy and improve speed to market.

“These [executives] want things to happen faster; they want to be successful, they want to trust people… Being first to market in the banking sector is a really important thing … Some of the new products that these banks are working on will blow your socks off.”- Rob Thomsett

While banking technology lasted an average of four years in the 1960s, 70s, and 80s, contemporary organisations were deploying new products in under three months, Thomsett goes on to say.

So if banks can do it… can the financial, health care, and insurance industries of America utilize Agile too? Is there no area of the world where Agile isn’t taking a hold?What can stop this undeniable force of nature that is Agile?

Stop the madness! AGHHHHH!!!

[HT: ITNews]

10 Replies to “The Bank of Agile”

  1. And who is looking after the governance aspects of spending the banks money on IT. No problem being first to market, IF you can also comply with banking regulations, federal business reporting regulations, full integrity of the data security and retention regulations, privacy, restraint of trade, and publicly traded firms reporting.

    Where is that in the “we tossed the steering committee” approach.

    1. I don’t believe they said anything about the governance being removed…

      An IT steering committee is a governance body that reviews, monitors and prioritizes major IT projects from a cross-functional perspective. The two key concerns of a technology steering committee are:

      Alignment. The committee helps ensure that IT strategy is aligned with the strategic goals of the organization.
      Ownership. The business units represented on the steering committee have ultimate ownership over the larger IT strategic decisions since those decisions will impact their processes.

      The top three activities of IT steering committees are IT project prioritization, approval of IT projects, and IT strategic planning. Organizations that operate effective IT steering committees realize better IT project priority setting as well as improved alignment with business objectives.

      I’m not sure whether the assumed roles of the IT steering committee also included governance.

      Maybe “governance” fell under the… Governance Department.

    2. I think it’s a general misconception that projects can not retrain reasonable levels of governance, while advocating for Agile software development practices. To the contrary, I think a reasonable level of governance is good.

      I read, “Executives want things to happen faster; they want to be successful, they want to trust people.”

      I did not read, “Executives don’t want oversight; they don’t want governance; they don’t want regulations.”

      I guess I am naive in believing in the best of people or looking at the world optimistically. But alas, with every silver lining, some will always be looking for clouds.

    3. That sounds like Glen heard “We’ll throw out the baby with the bathwater!” which is not what was said.

      Steering committees are a great way to grind projects to a halt. On all of the banking projects I’ve worked on, the single biggest impediment identified is “Waiting for a response”.

      If the separation of duties is handled properly (i.e. the developers can’t approve their own work) and if all of the artifacts required for compliance with regulation are included in the backlog, then an agile approach is completely consistent with the requirements of banking.

      I’ve attended training on how undertaking a full Scrum approach with professional rigor can take an organization to CMMI Level 5.

      So if you’re thinking that “agile = cowboy”, think again.

        1. You get a pretty cool hat to wear, that’s for sure!

          The short version is roughly this: by being thorough in your agile process (i.e. full Scrum, XP, etc) and using an auditable tool, you’re very close to CMMI level 3 already. Doing a gap analysis to identify what’s missing to get to level 5 (and actually, who the heck really needs to get to level 5 other toan to show off about it?) will show you that every aspect of it can be handled in ways that are completely consistent with the original agile manifesto.

          1. We keep it pretty simple: work is tracked in detail in Jira. Documentation is gathered there as we go along. Once it’s complete, everything is dumped and stored in the Project Manager’s tool, HP PPM, as the auditable document of record. Documents are also stored in our change control tool. There’s a lot of cross reference, and it’s meant that we have developed a bunch of checklists to ensure that everything gets done.

            The checklists are the basis of work decomposition (that’s a lot quicker than it sounds) in Jira, so that we are clear what has to be done, by whom, and by when, and can prove that it was done in audit.

  2. Pingback: The Bank of Agile | Agile | Syngu
  3. Pingback: Retrospective 43 – #Scrum Since 1967 and #Agile Selling | agile and then some

Leave a Reply