90 Sprints for Capital Markets – Part 1 of 4
90 Sprints for Capital Markets – Part 1 of 4
Every market and industry can benefit from an Agile transformation. Check out how to demystify Agile in the context of a capital market.
Join the DZone community and get the full member experience.Join For Free
A successful Agile process is not only possible, but is in fact highly demanded in enterprises such as investment banks. It is an environment of constantly changing business needs and regulatory requirements, where the classic waterfall approach is often insufficient. My team at GFT works on prime brokerage systems for capital markets, and in this short series of articles, I will share some experiences and opinions, as well as approach several commonplace myths about Agile.
Myth #1: “Agile is for Startups.”
I’ve hit “Start Sprint” on “Sprint 90” recently. My team’s experiences clearly demonstrate that the Agile approach is effective for a combined maintenance/rewrite project in an investment bank.
Being Agile translates into cost-effectiveness. Agile allows you to try many approaches and fail fast (and cheap) in your journey from initial requirements to actual business needs. What we also noticed is that after a short introduction, the people in product management on the side of the client are usually willing to participate in the Agile process themselves – they want to benefit from the opportunities it provides.
Myth #2: “You Need to Work in the Same Location as Your Client to Use Agile Effectively.”
We’re working from Europe for a client located in the US. The development team only has a three-hour time zone overlap with business users, but for us, that’s enough. Moreover, both client-side stakeholders, as well as development teams, are distributed across many locations. Such a scenario encourages you to put more thought into effective communication and make the best use of limited time. When you have only three hours together with the client (actually even less than that, on a busy morning in an investment bank), you have to really start planning your communication. Replace mechanical, scheduled meetings (status, catch-ups and so on) with tools such as online Scrum boards, issue trackers and others, all being accessible 24/7. I used to receive 50 emails in the morning – this number went down to five, and it turns out this is perfectly sufficient.
Myth #3: “Stand-Up Meetings Are Easy.”
They’re not. It’s easy to run these meetings mechanically. We were practicing for weeks trying to focus on commitments, achievements, goals, and plans.
A statement such as: “I was working on a new form, I’m going to continue today” does not bring much value. The actual “three questions” should sound as follows:
- What have I completed, thus helping my team achieve the sprint goal?
- What am I planning to accomplish, in order to help my team achieve the sprint goal?
- Is there anything blocking me from achieving my plans?
A stand-up is not a status meeting. Describe your goals – not what you’ve spent your day on. For example: “I’ve picked a new form task and built the basic layout. I’m planning to have a working version in two days’ time” sounds better.
Before you are able to plan a sprint or a release, learn to plan the next few days of your own work! If you know that you must spend 50% of your daily time on management tasks, just plan less development work. “I was not able to accomplish anything. I still plan to complete my task on Friday” – that is a good, fair update. Try to estimate your average unplanned disruptions – and plan for them!
Check out the article by Oscar Centeno from GFT Costa Rica for an insightful elaboration on this topic!
Myth #4: “The Most Important Scrum Meeting Is a Stand-Up.”
For us, the most important Scrum meeting is Sprint Retrospective. This underestimated ceremony is often ignored or run in conjunction with a Sprint Review. The goals and audience of these two meetings are totally different. It has proven effective for us to combine Sprint Reviews with Sprint Planning. Both types of meetings help answer questions of “What?” and “When?”.
We run a Sprint Retrospective a day after the Sprint Review without the business stakeholders as an audience. The structure we’ve found to be effective was to first review the waste log, and then group the action points in “Start Doing,” “Stop Doing,” and “Continue Doing” columns. It’s important to keep your notes complete during a Retrospective and then review them in the following session. The team needs to be open, honest and able to discuss problems with respect. Focus on fixing the process, rather than on blaming people!
Most of the findings shared in this article were subject to discussions on retrospective meetings.
Myth #5: “There’s No Such Thing as a Self-Organizing Team.”
Self-organization does not imply that no leadership is needed. The leader, whose goal is to help the team organize itself, is naturally a part of the team. It means that the team:
- manages its own work and allocates it in a “pull” fashion – rather than waiting to obtain work assignments
- takes decisions and responsibility about estimation and commitment as a group
- communicates openly with stakeholders to clarify any doubts about requirements
None of the above is the responsibility of the leader, Scrum Master or any individual person. To achieve those goals what you need is trust, respect, a sense of purpose and, of course, competency. What can be harmful to team morale and commitment is an external manager assigning individual tasks. Agile promotes servant leadership rather than a command-and-control environment.
The next step is not to rely on the team leader too much. I always suggest leaders should verify their leadership skills by…taking two weeks off (make sure you skip Sprint Planning, etc.)! Measure the time and effort you need to spend preparing for a vacation. Can you disappear anytime? Don’t pick up the phone unless your house is on fire! Once you’re back, check your mailbox. Can you safely delete all the emails? If you answered “no” to any of those questions, it means that you are the bottleneck. Don’t make yourself a person that any process relies on. If there is anything only you can handle in BAU work, focus on open communication.
A team leader who breaks down User Stories into tasks and assigns them, who handles all the communication and commits to deliverables in front of a client, cannot expect to have an effectively self-organizing team. Your goal as a team leader is to work yourself out of your job.
Of course, it is not as easy as ordering pizza and leaving the team alone. Keeping an eye on the long-term goal, helping the team stay focused – that is the role of a leader. Motivating individual team members and giving them a sense of purpose is another one. An effective tool to help with this is to set weekly one-on-one meetings in advance in your calendar with each team member. Their purpose is to listen, mentor and guide.
And, most importantly, make sure that you take action to mitigate all “Whose fault is it?” conversations. Prevent a situation of pointing fingers on individual team members, don’t allow a “witch hunt.”
A common conversation looks like this:
- Who was responsible for that?
- The Team.
- Whose fault is it?
- Let’s talk about fixing production first, and then we’ll run an issue retrospective to fix the process and avoid the problem in the future.
Make sure you don’t transform one problem, the need for software, into two problems: the need for software and the need to manage resources. Under proper guidance, your team will understand that it is their responsibility to prove that they are able to function in a truly self-sufficient and agile manner.
See you soon in Part 2, where we’ll focus on meetings, documentation and requirements, among other things!
Published at DZone with permission of Piotr Gwiazda . See the original article here.
Opinions expressed by DZone contributors are their own.