Basel 1, 2, 3

 

BASEL I

=======

• Issued in 1998
• Focuses on Credit Risk and Risk Weighting of Assets
• Assets of banks are classified into 5 groups according to credit risk:
• 0%: (for example cash, bullion, home country debt like Treasuries)
• 20%: (securitisations such as mortgage-backed securities (MBS) with the highest AAA rating)
• 50%: (municipal revenue bonds, residential mortgages)
• 100%: (for example, most corporate debt)
• No Rating: 

Agile problems with AAG

Like most other companies, AAG too has been on the path to Enterprise Agility for several years, which is quite evident in the ways of working (Purple) of teams. Most teams have some sort of autonomy, are multi-skilled (full stack developers at least), and the deployment releases are fairly regular (with excellent CI/CD tool usage) and predictable. The feedback from the business too has been early, and adds value to the unit of work delivered. Encouragingly, it's fairly a widespread phenomenon, unlike in other companies where excellence is limited to certain pockets. 

While those are the positives, the negatives aren't too few, nor something that can be disregarded. Here I list some of the things that could still be improved with intent, right mindset and responsible leadership.

1. Lack of demand funnel. 
2. Program level prioritisation is cowboy-style individual feat (in that the heavyweights have significant say) than a collective exercise.
3. Leadership may not be democratic and likely non-aligned with goals and aspirations of teams.
4. Constant team flux, changes, team-movement.
5. Frequent ways of working model changes. 
6. Poorly defined feedback mechanisms for contractors. 
7. Perception-based judgements. 
8. Over-reliance on business analysts who double up as iteration managers.
9. Not an open culture in some teams, and fear lurking on the flanks with respect to team bigwigs. 
10. Last but not the least, Business agility is still in the stone age.

How to implement a Data Science project [Krish Naik]

 

Self confidence

 

Pre-planning, sprint planning, Elaboration sessions

 

• Planning event

• Go through in-flight user stories, check what statuses they are in, whether they can be completed in the current sprint, which ones need to be carried over to the next sprint.

• Daily stand up

• Each associate plans for the current day

• Dependencies if any

• What help is required from the team

• Anything else that needs discussion.

• What bugs are there, why, what happens, etc. etc.

• 2 Catch ups with BAs every week - Backlog refinement (No elaboration sessions)

• Three Amigos

• PO

• Developer

• Tester

• Outcome is a clear understanding of the functionality to be delivered.

• Clear acceptance criteria.

• Documented test scenarios.

• Should happen as soon as a developer picks up a user story from sprint backlog.

• User Story Handover meeting

• Explain what the user story is (after three amigos).

• What acceptance criteria is

• What testing is required

• Any other questions / queries around the functionality.

• User story points

• Sprint review / showcase

• Retro event

What is expected →

SPRINT PLANNING

Planning itself can be split into three activities:

• Pre-planning / backlog grooming

• Who - PO, SM, BA and key team members

• When - mid sprint

• What

• 10 to 15% of time

• Add new epics and user stories

• Extract stories from existing epics (refinement).

• Estimate effort in T-shirt sizing

• PO identifies candidate user stories (based on priority) for the next sprint.

• Team helps PO prioritize / re-prioritize based on tech feasibility.

• Sprint planning

• Who - PO and entire team

• When - beginning of every sprint

• What

• PO and team negotiate on which user stories will be tackled in the sprint

• Time boxed to 2-4 hours

• PO describes highest priority features to the team

• Team may split user stories to tasks

• PO answers questions, clarifies acceptance criteria and may renegotiate.

• Team sizes user story in story points.

• Result is 

• A SPRINT GOAL

• A SPRINT BACKLOG

• Elaboration session

• Who - PO, Developer, Tester

• When - addressed progressively at various points in the sprint.

• What

• Big user stories are progressively broken down into finer user stories and filled up with more details. 

• Elab ensures that unanswered questions are answered.