Battlefield Agility® is a quest to make our deliveries better, more collaborative, faster and effective. It relies on age old principles from the Army to provide a holistic view of the problem landscape which a project team needs to solve and be able to succeed in this, through small, collaborative groups working in coordination to achieve the bigger goals.
Battlefield Agility® derives from the Agile manifesto and principles and adds to it, the key ingredient of individual wisdom to create a plan for a team which will help it succeed in successful deliveries . The software delivery proceeds through a series of small battles (typically 4-5 days each) where the attack parties focus to win the battle through all possible measures.Key roles:
The Project Commander® The Project Commander® is assigned a war to be won by the Executive management/ the customer. With help from his/her own experience and the Recce Party, he/she draws up a Project War Map® which describes the key problems to be conquered(called Features) and the essential ammunition and support required to win the war. The Project Platoon® A platoon consists of 5-15 troops that are experts in their area of knowledge including software development, software testing, documentation, infrastructure or any other area of expertise as needed by the team.Each Project Platoon® is facilitated by one Project Commander®. Recce Party Recce party is a small team of SMEs/Architects etc. who have expertise in the product/ development area and look into the overall architecture, design and development aspects of the software under consideration. Attack Party(or Parties) Attack parties are 2-3 member teams of troops which are responsible for a particular battle in the war. The Process:
THE PROJECT WAR® INITIATION: To initiate the Project War®, The Project Commander® and the Recce Party interact with the customer/ management/sales team to draw a list of problems/challenges to be solved by the Project Platoon®. Each problem/challenge(called a Feature) is provided a unique Feature ID and A short description ( 2 words). Each challenge can be depicted in form of a User story or a simple one liner on what needs to be achieved.
The Project Commander® and Recce Party then draw up an initial Project War Map® depicting the seriousness of challenge ( aka complexity), the distance/height to be covered ( aka Size), The priority of Features to be tackled( Front-line and Back-line and the initial ammunition and troops required. The initial Project War Map® is typically drawn 2-3 weeks before the start of the first battle. After drawing the initial Project War Map® , The Recce party starts investigating the front-line Features.
The software delivery proceeds through a series of small battles (typically 4-5 days each) where the attack parties focus to win the battle through all possible measures. The Project Platoon® prepare a Battlefield Feature Map® based on the Features identified from the Front-line and Back-line THE BATTLES: Each Battle is initiated by the Recce Party and The Attack party for the battle discussing about the details of the Features they need to attack, This discussion lasts no more than 60 minutes. After the discussion, the Attack Party starts attacking the feature. A battle update is provided to the whole the Project Platoon® at the end of the day and the Project Platoon® plans the next steps based on successes achieved on that day. The whole Project Platoon® meets every week to discuss their progress in the Project War and decide on the next steps THE WAR RULES: The Project Commander® and the Project Platoon® agree on war rules which have to be followed by the Project Platoon® mandatorily. In case a troop is not able to follow these rules , it should immediately be reported to Project Commander® and corrective actions must be taken to ensure the efficiency and success probability of the attack party doesn't get effected.
Some of the rules are as follows:
Find your mate:
- No troop works on a feature alone. Have at least one mate with you Not.
- No troop fights more than 2 battles at a time.
Flag if Stuck: If you are not able to move forward on a feature, report to Project Commander® immediately. Not 3: Each attack party should not have more than 3 troops at a time.
Feature : Each Feature should not take more than 4 work days to win.
Stop not till win: Don't withdraw from a feature unless you have won.
Minimize Loss: Not > 2 Lost features in a month. The Project Platoon® can add more rules as it deems fit for a Project War.
The Artifacts: PROJECT WAR MAP®
Project War Map® is a visual depiction of all the features and their dependencies and interlinks. This enables the Project Platoon® and the Project Commander® to identify the top challenges, the terrain and the ammunition required and available. A typical Project War Map® BATTLEFIELD FEATURE MAP® Battlefield Feature Map® is a subset of the Project War Map which shows the most important features which will be attacked in the coming week. It also shows which troops/ attach parties are working on that feature and also the Front-line and Back-line features A typical Battlefield Feature Map®
Key benefits of Battlefield Agility®
- A focused approach to software development as development proceeds through small battles to be won
- Reduced multitasking and better efficiency of team members
- Faster deliveries as the work is divied to right sized battles to be won
- Parallel efforts by team members ensure the time to market is significantly lesser
- Less process overhead as the collaboration is real time and more time is spent on the ground than on meetings
- Small teams ensure close camaraderie and collaboration among team member
- The team can even work on disparate work areas ( if required) in order to make best us of their expertise