Selection: Use of AGILE management systems require a list of elements related to: low complexity projects, medium size of a well trained team and possibility of changing functional requirements. On the contrary, if you are facing a high complex project with large teams and heterogeneous training and a sort of rigid functional requirements, you should better think about the classic WATERFALL management. In other words, is there any chance to use AGILEs in a NASA rocket construction project or in an ERP implementation project…? It seems not to be the point…
Whether or not you are taking this previous advice to select a project management method; if you finally take a chance on AGILE software development management, known as SCRUM, you should also consider some characteristics in order to reach a successful deployment.
Initial barriers: Before quicking off this methodology, one should look at hidden barriers to deploy SCRUM, i.e.:
• Hidden complexity of the project (phases, features,…)
• Lack of well estimated planification which leads to a workoverloaded teams
• Overlapped and concurrent projects which affects dysfunctionally priorization
All of these hidden barriers are modeling the whole planification task which, in SCRUM, is associated to the Burndown Chart. A Burndown Chart is a key master tool to monitorise project progress and forecast each iteration and final endpoint. So, if the inputs of the Burndown Chart are incorrect, the whole SCRUM will be inactivated.
Planification: There are many Project Management Tools; from Classical Gannt Curve used in WATERFALL, that is related to activities done (but not ready to be used) to the former named Burndown Chart Curve that is used to represent the release of each piece of work ready to be used. In addition to the commented barriers, an inflexible Project Management Tool can be also an impediment to manage a wide range of projects. Sometimes, due to the nature of work and its organization, a more flexible approach of planification is needed. For example if the IT Department has resources working at the same time with projects and also with day by day incidences. In these cases, KANBAN system is much more flexible and it can flow better over initial planification using a model that combines a ranking priorization of deliveries with “TO DO”, “in PROGRESS” and “DONE” categories. This approach permits to include unexpected incidences in the schedule reorganizing the whole ranking of the users stories in a flexible manner.
Starting on: Finally, let s assume that a well planification process has been done with a Burndown Chart or any other flexible approach like KANBAN…so you are in a position to define:
• Backlog grooming (evaluation and priorization of deliveries –users stories-)
• Number of Cycles of units (iterations) using sprint planning (sequence of a chain of users stories that encompass the IT solution)
• Sprint review (a review for each iteration)
• Sprint retrospective (analysis of what has been good and what could be improved)
• Demos meeting
At first sight, this “starting on” can look like a hangover of meetings that should be managed and balanced very well before getting collapsed by meetings…
But, beyond these considerations formerly described, if you look at the big picture you will find some others elements to take into account. We would like to mention the significant importance of the systemic view.
A systemic view (i): the role of IS. One can assume that SCRUM is not able to work alone in any inner client Department of a given organization. In this line of reasoning, IS department should embrace SCRUM and furthermore also a complementary methodology known as extreme programming (XP).
Why is that so relevant? XP improves the quality of each delivery (user story) by using:
• test driving programming (testing users story before deliver),
• refactoring (eliminating redundant program code while growing the program),
• continuum integration (integrating each iteration delivered to look for consistency and finally a well defined incremental design as a main objective)
Try to picture an IS Department where no tests are implemented before delivery, no code redundancy is eliminated and nobody looks after the whole consistency and integration of the final solution…any Frankenstein can arise from this way of working
A systemic view (ii): the role of Board of Directors. Director’s sponsorship of AGILE is relevant for success, as well as an aligned organizational culture. No success can be expected if organizational culture is against and bureaucratic; and a lack of sponsorship emerges in the apex. The standard professional bureaucracy described by Minzberg is not well suited to embrace AGILE culture, because of the weight of the bureaucracy culture itself. So promote AGILE culture and spread it through your organization, before landing a well trained AGILE parachutist in a bureaucratic jungle; because if not, they have no choice. Like any of us in Neptune.
Likewise, a Board sponsorship promotes and enforces the necessity of:
• Stability of components of the AGILE team,
• Allocation of needed resources in the AGILE projects,
• And last but not least, IT alphabetization of the whole organization, including the board of Directors that really need to understand problems, barriers and recognize success of this adventure of working “agile”. A boss that not understands operations of his own organization has lack of information, knowledge and finally no quality inputs to take decisions.
Now, after all this panoply of items showed in the guide of use; you are ready to launch for it… or so you think you are…