anca stefanescuProject methodology expert| BRD GROUPE SOCIETE GENERALEBucharest, Romania
Hi, I am interested to know the practical experience of Agile projects in banking. The concept and theory are great, however the field implementation might be a bit different. How did you deal with this? What was the most difficult thing to do? How did you treat the documentation topic (most people believe there is no documentation in Agile)? Thank you. Saving Changes...
Practically, there are lots of ways to implement Agile concept in a project. The type and frequency of documents can be affected by the way you try to implement Agile. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Just to be clear Anca, are you looking at non-IT projects?
...
1 reply by anca stefanescu
Nov 27, 2017 10:13 AM
anca stefanescu
...
I am referring to IT projects. Not necessarily the infrastructure projects, but the projects with software development component.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I was the leader of aplying Agile in a hugh bank and the project was awarded by the PMI. In the end that´s not matter. What matters is you really understand what Agile is. Agile is not a method, not a process, not related to IT or software only. Is the only way you will be success with Agile. As an example about the inherent complexity the bank change its whole business to retail banking and the driver objective was: "the bank open 24x7 every day". If you know about banking you understand what does mean. We changed the whole enterprise architecture to Agile (that is Agile really) to gain into agility, we integrated all the core banking software without making leverage of existing system (system is not used as synonim of software), we change all the interface with the banking (with today some people name Digital Transformation) by using no-cost free tools and using DSDM as software development method (extending it to create non-software products) and lot of thing more. To understand what Agile really is there my short article I have the opportunity to publish at PM Network (http://www.pmnetwork-digital.com/pmnetwork/april_2016?pg=73#pg73) BUT my recommendation is searching for Rick Dove´s "Response Ability" book. Saving Changes...
Having spent the last four years at a large bank, the challenges are the same as experienced by most companies attempting to be agile "at scale". Legacy mindset, behavior, systems and reluctant delivery and control partners are just a few of the hurdles to overcome.
In most cases, the transformation will take years - Barclays Bank needed 5 years or more to get to where they are now with hundreds of agile teams.
It is a good idea to focus on mindset & behavior changes first before implementing a methodology or tooling.
As far as documentation goes, the key is minimal sufficiency. This usually requires a fair bit of negotiation and education with control partners such as risk and audit.
It's also important to come up with a profiling approach so that sponsors or teams don't attempt to use an agile delivery methodology on a project which is not a good candidate.
Kiron Saving Changes...
anca stefanescuProject methodology expert| BRD GROUPE SOCIETE GENERALEBucharest, Romania
Nov 27, 2017 9:37 AM
Replying to Stéphane Parent
...
Just to be clear Anca, are you looking at non-IT projects?
I am referring to IT projects. Not necessarily the infrastructure projects, but the projects with software development component. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Gotcha! The good news is there are mature agile approaches for software development. The tricky part is whether the bank is on a mainframe. (It's amazing how many still are, for security purposes.) Mainframes don't make it impossible, just a little more complex.
You've already gotten some good advice from Kiron and Sergio. I'm sure you will get some more from this community. Saving Changes...
Michael WilliamsSr. Project Manager| Itron, Inc.Spokane, Wa, United States
As you get good advice from everyone, be sure to take a small reality check. Agile is best used in circumstances where complexity and uncertainty are high. The iteration model allows you to start chopping chunks off of the project risk quickly, and then get to the expected results safely.
If you know what you're doing, and the risks are minimal, it doesn't make sense to change to Agile project delivery, as your results probably won't change due to the effort.
There are people (and I am one of them) who say that Agile should be implemented as much as possible. Before you start that process, however, you should see if you can get a few project successes using Agile before announcing to the organization that your department is 'doing Agile'. Saving Changes...
Banks are very fussy about knowing their full requirements in detail and upfront, which kind of doesn't lend itself well for agile. But there are other benefits to it's adoption than projects where requirements are not well defined or are constantly changing. Some of these unfortunately fall into the "agile for agile's sake" category. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
As I mentioned above we apply Agile in a banking holding. As I mentioned above we do not touch the mainframe core software (writting in RPG/400), we made a leverage of them. Agile is not about to apply a method or to apply iterative/incremental process. Agile is not about to deal with volatile of unknown requirements. This is a installed idea outside there. You can deal with that using any type of approach mixing it with the right life cycle model/process. Agile is about to understand that a whole enterprise transformation has to be made no matter you started applying Agile practices into one enterprise division (software for example) including if you use a method based on Agile. If you do not understand that you will fail when you try to apply Agile. Saving Changes...
Some more considerations for agile delivery in banking are:
1. Control partners will struggle with being sufficiently engaged through the lifecycle of a project or release. This can either cause issues during deployment or delays with development.
2. All the good practices for scaling agile need to be considered. For example, putting tools and methodologies out there without some basic standards will just create chaos. We had multiple teams using a common set of tools but how they captured information within those tools was inconsistent which made it very difficult to perform quality assurance activities.
3. Stakeholder change appetite needs to be taken into consideration - just because you can continuously deploy, doesn't mean you should.
4. Lack of automated test repositories for most legacy applications really hampers the ability to deliver quickly and with quality as you will be relying on manual testing.
5. Many banks have long term contracts with consulting firms (on, near and offshore) - the working model with these have to be re-evaluated in the agile delivery context.
6. It's hard to get empowered, capable, available product owners - usually you get one out of those three attributes at most!
