Investment Banking - Agile Principles applied

Principles remain the same across all industries, business models, and technology domains. But the way a field adapts to the Agile nature of deliveries can be different across businesses. One such industry is investment banking. After a good five years spent with different investment banks, gaining basic ideas about their different approaches, business models, and rapid vision changes, it is time for me to pen my observations and better practices about this field. This article has its focus on investment banking and touches on other industries to draw comparisons and explain how they are different.

Let's take a look at the 12 Agile Principles from a viewpoint applicable to all industries, but with more focus on investment banks. All you need to know as a prerequisite to reading this article is that Agile is not a methodology but a framework.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Customer satisfaction is a key to success in any industry; investment banking is no different. It is important have a Definition of Done and validate it with all stakeholders. Which means that our highest priority is to satisfy the customer, and satisfy all of them. Any stakeholder dissatisfied or missed will add to the number of change requests raised post-product delivery or Production Go Live.

For instance, let's consider the case of building a complex trade-capturing system. This system has become so big that it is difficult to find a conference hall that will hold all the stakeholders for a review meeting. Suppose we miss a single stakeholder from the Infrastructure Department (servers and maintenance), one who would have suggested how to use your system accounts with proper privileges. That would create a huge rework of the project. Agile welcomes change, but not those changes surfaced due to improper attention. This is where Agile gives us a provision through early and continuous deliveries to review what we built, how we built it, what we missed, and how we missed it. Agile gives us a platform to recover from an undesired state to a more anticipated state, similar to a Catch block in your C# code snippet.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
Embracing change in the XP world -- that is the essence of Agile, which other frameworks embrace to a greater or lesser extent. Agile teams welcome change and they have the courage to bin (throw off) a prototype and build a new one, as long as it doesn't come out as a surprise or a shock. We all understand that surprises are not good for business. The Cone of Uncertainty (described by Steve McConnell) explains it in simpler terms: When you are close to the narrow end of the cone, if you learn that the requirements are far from accurate it is not good for any project.

Especially in the investment banking industry, surprises are not good for regulatory or audit projects. The product owner needs to be more cautious and should provide regular updates to the team. The PO also needs to make sure he or she meets up with regulatory bodies frequently and presents those learnings to the team.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This principle highlights the importance of iterative and incremental project deliveries. The more often we validate our deliverables, the less exposed we are to surprises. It is the team collectively that needs to find out what should be the duration of an iteration/sprint. The same applies to banks, and the duration differs from project to project.

4. Business people and developers must work together daily throughout the project
It is very important to make sure your business people have a clear idea about Agile. Make sure they are part of your organizational Agile culture; educate them and provide trainings if required. Schedule workshops if that is what it takes to transform your business to adopt Agile. Once you get everyone on same page, core problems will be identified, and solving them will help cut down on waste in your processes -- a procedure that we normally call business excellence.

It is a mixed team dynamic we are dealing with. The delivery team will build a set of features during a sprint, the quality analysts will test them during SIT, and business people will assess them in UAT. We need those SIT and UAT cycles, but they should happen as ceremonies. Representatives from all of those departments (delivery team, QA, business, etc.) should take part in them.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
It is always people who build your systems; tools and practices help them build effectively and assess quality. If we are still thinking about those X and Y theories of managing resources, the time has come to change. That change first came when these Agile principles were identified. People are the greatest assets organization can have. And talent is not something that we can acquire for compensation all the time. Free people from directions, trust them, and you will soon discover that you have a team capable of developing space science out of the box -- if you haven't already.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
We can keep a discussion short if we communicate in person, but it is not always possible to have face-to-face discussions when we are geographically distributed. A Web conference can help in those circumstances. You can ask team members to pick a set of features based on geographic locations, then schedule introspection meetings during the call to integrate those pieces of subdeliveries. Moreover, inspect the best approach that works for you and adapt, review the approach, change, and inspect and adapt again.

7. Working software is the primary measure of progress
Working software is what we started this project for. Set the Definition of Done and strive to meet that objective. Identify those tools to scale your software, measure them, and deliver the best as described by the Definition of Done. Frequent feedback post-production release or sprint delivery is also an important factor of progress. It can uncover how useful those features are to your business and what other value we can add in next sprints.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
In your retrospectives, your team may suggest that estimates need to be reworked, and the sprint burn-down can show the state of the team. If that is the case, you need to look at this principle. The team will forecast what they think they can deliver at the end of a sprint. Business, the PO, and the ScrumMaster should work with them and address their needs to meet their forecast. Burned-out teams may produce value, but it will always be less than the minimum of what a happy team can produce. Pay attention, and identify what workload your team can deliver while adding maximum business value.

9. Continuous attention to technical excellence and good design enhances agility
In banking terms, for almost all application software, we have a support team we named RTB (Run the Bank). We have another good name for development and other teams: BTB (Build the Bank). Once BTB delivers a piece of software that is accepted by business, we will have hand-over sessions for RTB, who will support them. It is important to have a good design that allows extendability and changes to be integrated easily. We need to involve the right people to get a good design. A design can be good for business and the delivery team but be a nightmare for the RTB that supports it. Identify and involve your stakeholders and pay attention to continuous technical excellence.

10. Simplicity -- the art of maximizing the amount of work not done -- is essential
Identify which part of a feature constitutes the majority of business value. Identify what needs to be avoided or can be presented differently to add business value. Avoid gold-plating; break down those features to task level, assess them against business needs, rate them by value, and discuss the necessity of lower-value items with business.

11. The best architectures, requirements, and designs emerge from self-organizing teams
We all have best practices. When a new practice is introduced and treated as best, previous bests will drop to "better," and we move on. It is the team that adopts a practice; any external sources can try to force them to adopt one but may fail to get their buy-in. Being a banker, just think about executing a trade when you know it has a negative potential. You will lose clients. Let the team decide on the best architectures, requirements (business is part of the team; they work with the team), and designs to deliver what they are best at.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
As I mentioned at the beginning of this article, Agile provides a framework for us to build on. Teams will inspect and adapt the processes that should be kept in place for supporting organizational business. In our change-management world, we have a PIR (Post-Implementation Review), which can be barely a change request for a defect or can be a new version with a new set of features. It gives us a chance to assess what we could have done differently. In Agile terms, we have retrospectives to assess the outcome of a sprint to help us to improve. Identify or define a ceremony that meets your needs to become more effective. Inspect the process, adapt, and adjust your (team) behavior accordingly. Remember, when we call for the "team," it is not a division in your organization but a group of people who can influence the "how" part of your project execution.