In the software industry, project management is facing a number of challenges. The main one is being able to release products and functionalities matching the real users’ needs. But it’s also the most complex one. And that's because the environment is ever-changing, the project horizon is far-distant and human forecasting abilities are limited. As a result, needs are difficult to express accurately upstream.
Moreover, each and every IT project is inherently unique, making it impossible to industrialize processes based on past projects and put the future ones under control. Unfortunately, there’s no “recipe” to ensure project success.
That said, the software industry has to find alternative ways to design products. And there are two different approaches to that: heavyweight, focused on controlling risk and suppressing change, or innovative, “lightweight” approaches that take advantage of the postulate “projects are alive and unavoidably evolve.”
Being agile, what is it?
The standard approaches (that is to say sequential) like Waterfall or the V-model have shown some limits on projects with high functional and technological added-value. The deadline, budget and quality equation often seems impossible to solve. Both the team and the client face the “tunnel effect,” which leads to frustration - they can only see the result in the end and the progress is hard to assess. User standpoint is only taken into account at the beginning of the process, on the basis of ideational and non-concrete elements. Yet matching the client needs and user requirements is key.
Sequential approaches offer a rigid upstream specification process: stakeholders tend to over specify initial needs, consider them from a technical standpoint only, and don't take enough into account business aspects that shift really quickly. Moreover, quite often, only small and marginal adjustments can be performed, whereas the more complex the project is, the more modifications are likely to occur and to be important. And last, the sequential approach is optimal for defined processes, such as mass manufacturing of physical goods when software development is an empirical process… So many factors increasing the failure risk.
In the 90’s, several software development players took the opposite course of existing approaches, and developed new methodologies, bringing in a major shift in the way projects were managed. In 2001, the founders gathered and redacted a shared manifesto stating the common philosophy lying at the core of their approaches, which values:
- - Individuals and interactions over processes and tools
- - Working software over comprehensive documentation
- - Customer collaboration over contract negotiation
- - Responding to change over following a plan
These four initial postulates were then translated and expanded into twelve principles applied to project management.
To sum up, an agile methodology is an iterative and incremental approach with a collaborative mindset, where formalism is kept basic. It produces high quality products while taking into account that client’s needs evolve. It’s important to note that iterative doesn’t mean agile, but agile implies, among other things, an iterative process.
The comprehensive view of the project is macroscopic – both the team and the client know the big picture and have an idea of the total duration. The project is then broken down into evolvable features and tasks that are scheduled as the iterations go along. Detailed and precise projections are done on the short-term, i.e. where the team has visibility. Depending on progress, results and feedback, the project’s management can be adapted quickly and whenever necessary in order to ensure the best results possible.
Simplicity – meaning the skill to minimize the useless work – is crucial in agility. This concept implies for example keeping documentation to bare bones, creating only the needed indicators, developing the features that have a real added value, but also using the simplest solutions and code.
The key priority is to meet the client’s expectations by delivering added-value features quickly and regularly. At the end of each iteration, which can last from some weeks to a few months (but shorter cycles are better to leverage all the agility benefits), the delivered product has to be operational. This is the main progress criterion for a project. Closeness and collaboration between the client, business and technical teams help keep the project’s end-user perspective over technical considerations.
Products developed with agile approaches are usually high-quality products, because they take into account that client needs evolve, and each iteration is tested and validated. Agility also promotes smart innovation: by accepting change, the team is ready to look for innovative solutions to get around obstacles if the existing solutions don’t solve the actual problem satisfyingly.
Scrum, one approach within the agile galaxy
There is no Agile, but there are agile approaches. The following are some of the approaches that comply with the four manifesto postulates, even if opinions on the classification of some may diverge: Scrum, XP (eXtreme Programming), Crystal Clear, DSDM (Dynamic Software Development Management), and FDD (Feature Driven Development). The most known and used to date are Scrum and XP.
Each of them has distinctive characteristics on implementation and available tools. XP for example provides teams with several tools and development practices, such as TDD (Test Driven Development) and continuous integration. However, most of these tools can also be implemented within the scope of other agile approaches. Crystal offers several versions, depending on the project size and criticality, based on the assumption that you don’t manage the same way a project involving five or fifty people. Regarding Scrum, the approach we use at af83, the way it handles the iteration sequence and its focus on the added value for the client are really interesting.
Scrum has its own precise vocabulary. It’s very efficient in ruling out any understanding issues and differences in the frame of references from one organization, team or person to another.
In Scrum, the team is made up of 4 to 7 cross-functional people, the Scrum Master, who’s in charge of the team’s life and ensures good conditions for the project, and the Product Owner, the client in charge of working out the needs and approving the delivered product. The client is, hence, a full team member. He’s in charge of the Backlog, a list of features corresponding to the estimated needs, and prioritizes the features depending on their business value. The main interest of the Backlog is that it can, and will, evolve as the project goes on, depending on feedback and new needs.
The project is divided in releases (successive product versions), themselves divided into sprints lasting from one to six weeks that are made of working days. During a sprint, the goal is to produce the set of features defined at the beginning of the iteration with the Product Owner. The project is therefore sliced into self-sufficing operational features. Every sprint begins and ends with meetings, allowing setting objectives, assessing their fulfillment, and having feedback on the sprint’s progress. Precise ceremonies and artifacts are used for each level of the cycle.
Finally, Scrum praises transparency, inspection and adaptation. Indicators set in place must be constantly visible to everyone – the customer, team, and management. They are regularly monitored and analyzed, and enable to correct the project course with relevant actions. Particularly, the Scrum Master is attentive to inefficiencies.
Rethinking relationships and firm organizations
Agile approaches can really improve project management and results. But to achieve agile, it’s necessary to integrate an actual culture of change. Change is not negative or worrying anymore; if changes occur, they are “natural” and the team has to blend them in its organization and processes. This perspective shift is not easy to set in place. Wrongly explained and understood, it can be a source of blocking and conflict. And because it may not be fit for everyone, switching to agile requires paying special attention to the human factor.
Agility is not only about rules. Above all, it’s a particular mindset, a (team and personal) culture that requires a certain type of behavior. Therefore, becoming agile can’t be decreed, and such an approach has to be understood and supported by every member of the organization. In addition, this approach can’t work without a true relationship of mutual trust between the client and the development team. The game rules have to be perfectly known, and information spread in an open manner. These two principles are essential to the project success.
In charge of decision-making and validation, a customer working with an agile supplier must be highly available and strongly involved in all the steps of the project. It’s also of paramount importance that its delegate (for Scrum, the Product Owner), arbitrates between the different, and sometimes opposite, objectives and expectations of the various internal stakeholders, and speaks as one.
Several points are important for organizations that have chosen to become agile. They must provide the team with the necessary environment and support and rely upon it for reaching the goal (it’s the team that’s responsible for the project success). Finally, empowerment and collaboration are the catchwords of agile organizations. Pair programming, daily meetings, creating a positive contradiction atmosphere and group commitment on results are some of the many collaborative practices that help bring about team agility.
Agility is also characterized by a large autonomy and group responsibility, with decisions based on consensus within the team. In this perspective, the “traditional” project leader has to review his role and behavior, as he’s no longer the decision-maker or team leader. On the other hand, self-organized agile teams need advice as well as active and protective support to be able to reach their goals. Instead, the “project leader” will have to focus on facilitating the mission and creating a collaboration-enabling environment.
Agile approaches generate new roles in teams and organizations, such as people in charge of team vitality (not control anymore), or customer/user spokesperson. They also tend to challenge strong hierarchical structures, which can be a source of problems, particularly in big organizations. However, a growing number of companies are becoming aware that they need agility at every level of their structures.
It’s somewhat interesting to note that, if agile approaches are, by virtues of their design and first implementation field, turned toward software development and IT projects, strategic, organizational and human dimensions of agile are at the heart of shifts in companies – realization that man more than technology creates added value, and of all stakeholder co-dependencies, pursuit of reciprocity and progress along with the environment, pursuit of lasting customer satisfaction inside an ethical and open relationship, and more.
- 1. Choose the approach that fits you best
- Depending on the type of project, client, and organization, some approaches will be more or less relevant. Methodology efficiency depends on the project adequacy to its “sweet spot.” Carefully choose the approach that will be the best fit, after taking the necessary time for a thorough comparison. Finally, stick with the selected approach; don’t juggle with multiple approaches. Use one approach, but use it well, and master its subtleties and benefits.
- 2. Be in one’s sweet spot
- Even if you’ve chosen the approach the most suitable to your context, you’ll have to take into account every single element straying from its sweet spot and diminishing its efficiency. That’s why you have to set in place some mechanisms and tools to reduce this gap, or try to offset it – being aware that, if the gap is too important, you won’t be able to make up for it. In this case, it might be a sign that the chosen approach doesn’t fit.
- 3. Play by the rules
- The rules established by all the existing agile methodologies may appear basic and even simplistic, but they weren’t expressed randomly. They appeal to strong underlying mechanisms, related, for example, to development or team management issues, and aim at minimizing risks. So change them the least possible – only when you know what’s at stake and why you change them.
- 4. Have a good command of your code
- Agile approaches imply continuous refactoring of the code. In order to ensure optimal quality, you have to be able to easily delete and add code without damaging the general quality of what has been produced. You also have to have the ability of rapidly deploying the changes, checking if they’re functional, and carrying out tests to ensure they don’t produce bugs. For that, you must master continuous integration and TDD (Test Driven Development) principles. Having a development team with a majority of seniors is also crucial.
Here are some resources about agility
- The agile Manifesto
- Scrum alliance, the website of the eponymous organization promoting Scrum
- Ken Schwaber and Jeff Sutherland blogs
- The reference book for a first dive in Scrum: Agile Software Development with Scrum, written by Ken Schwaber and Mike Beedle
- An article on Scrum and agile limits
Using Scrum for big projects
Ideally, Scrum is designed for projects involving 5 to 9 people teams. So what can you do if your project requires bigger teams? Cut it on sub-projects, each one with a dedicated team. The meeting called Scrum of Scrum allows for gathering the spokespersons of every Scrum team (either the Scrum Master itself, or members of the team in turn), taking stock of the progress, using other teams’ work, and coordinating them all. The goal is to circulate information, know what can be useful to several teams, share field experience, and not to redevelop existing code. For more details, read Conducting Scrum of Scrum meetings.
Usually, in this type of projects there are several Product Owners (most frequently, a Product Owner a team). This ensures the owner’s optimal availability for the team, but can lead to disagreement on standpoints and priorities. In this case, it’s important to name a Chief Product Owner accepted by everyone, whose goal will be to lead to consensus, and if needed, to take decisions in last resort. However, this scenario must be used the least often possible.
Coming from the Toyota Production System, Lean is a school of production management originally used in manufacturing, and particularly in the auto industry. However, its principles have since spread out beyond. The approach has four major postulates that are, for some of them, close to the agile philosophy:
- Redefine the concept of value: The added value of a task contributed to a process must be set from the customer standpoint.
- Develop new production patterns, such as building respectful relationships with suppliers encouraged to switch to Lean themselves, or continuous pursuit of excellence.
- Develop original management behaviors, such as encouraging employees to suggest improvements, or finding and removing deep-issue causes, as soon as they happen.
- Set long-term strategies by giving priority to long-term stakes, explaining the global objective, and drawing it up durably into the future.
Signing agreements for a Scrum project can be difficult as there is no fixed and defined date, or precise perimeter. Ideally, a “Time and Materials” agreement renewed at the end of each sprint allows answering the specificities of agile. In this case, a first “trial” sprint will help knowing the velocity order of magnitude.
When one has to answer Calls for Tenders where price and time are fixed, he’ll have to pay particular attention to explaining the approach and its interest: visibility on the project progress and option to stop it at each sprint-end, functional product delivery, and possibility to make changes without major impacts. Given that projects also follow the 20/80 law, which states that 80% of the added value comes from only 20% of the functionalities, the client can choose to stop once that 80% is reached. From this perspective, the product backlog and the planning release will serve as a basis for client-contractor negotiations.