Month: September 2018

The Agile Manifesto contains four value statements that should be considered while working in an Agile project. These statements are not rules but rather preferences that encourage the focus on certain areas without eliminating the others.

• Individuals and interactions over processes and tools: good products are built by teams that work together efficiently so, while tools and processes are important, they’re not as important as collaboration and effective communication. This can bind people, minimize conflicts, optimize the time spent in meetings. In this direction, the Communication in IT projects course underlined some valuable aspects: why it is important to communicate, what makes people involved in projects not communicate, what benefits does nonviolent communication bring.
• Working software over comprehensive documentation:  while documentation has an important place in any project, the stakeholders will find it easier to understand a demo/working solution rather than a complex diagram.
• Customer collaboration over contract negotiation: only the stakeholders know and can tell what they want. They’re also highly likely to change their minds and, like everyone else involved in the project, learn more through its lifetime. In this direction most courses underlined that it is necessary to know and recognize the stakeholders involved, understand their needs and, while having a contract with them is important this will not replace the need for information exchange or effective communication.
• Responding to change over following a plan: In Agile, the focus is not on planning and control but on adapting and changing (the process, the solution, even the initial plan). The traditional models, covered also in Practical Project Management course, do not adhere to this and stick to the conventional, detailed planning and favor a sequential approach.

Throughout time, project methodologies have evolved from “waterfall” or traditional to iterative and, later on, agile. The first generation of methodologies, namely the waterfall ones, were characterized by sequential actions, were strongly plan-driven and relied on the fact that, within the project the tasks are easy to identify, predict and repeat. Software projects however, are characterized by a certain degree of creativity, risk and uncertainty, therefore, the waterfall model proved itself unsuitable and sub-optimal for delivering successful and high quality software solutions. The iterative project methodologies aimed at compensating the shortcomings of their predecessor by introducing smaller, time-boxed iterations, by learning and adapting from one iteration to another and by involving the customer more often into the development process.

Although better, the iterative approach missed to deliver the expected results. As a consequence in the early 2000s, a group of software engineers and leaders brainstormed and come with a better way of working that was summarized under one document – the Agile Manifesto. The ideas exposed in here had a big impact in software development and influenced highly the way IT professionals thought about development, testing and delivering value. Unfortunately, a first problem with the manifesto and Agile project methodologies in general, is that they were defined, written and focused around software development, fact which prevented them from entering other business domains or integrating them at an enterprise level. As a consequence, there are companies even today, activating in the mechanical/automotive markets in which questions such as “why are we guiding our work based on software principles?” or “if it worked in software why does it have to work for us?” are still rather common.

In the followings, I will go through some of the problems that Agile project model has when adopted within organizations but also for IT and software development projects.

Although the Agile model was born and defined around software development, th problems faced even in this area are numerous. Some came either from a poor understanding of the Agile model, lack of training in this area or simply from a mismatch between the company’s culture and the agile principles and practices. One of the problems with Agile project methodologies is that, although they may be easy to understand, it takes time until they’re properly applied (hence, they require proper coaching and a certain level of experience) and they cannot be separated from the changes that occur within an organization or from its philosophy, culture and values. In this direction it is important to mention that Agile will more likely fail unless the company has reached a certain level in the decentralization of decision making; the focus should be on motivating the teams and enabling them to take the right decisions rather than only controlling them and holding the decision process at a different level.

The Agile project methodologies require also the right mindset in order for a project to succeed. So, for many companies that used to have their projects conducted according to the traditional model, “going Agile” can be a big challenge. Hence, this change may be met with resilience: some teams, might be unwilling to give up their old practices or may find it problematic to involve the customer in the development process. On a day to day basis, they may be overwhelmed by the number of items in the backlog, by the level of uncertainty on what shall be delivered or by the number of meetings that some frameworks (for example, Scrum) required.

Also, from a day-to-day operational point of view, Agile project methodologies encourage continuous attention to technical excellence and the promotion of good design practices. This translates into writing and evolving high-quality source code, continuous integration loops and automated tests. However, in parallel to new development, many companies have a significant amount of legacy code that has to be understood, maintained and which can be difficult to refactor or test. So, changing legacy code or getting tests automated is still a problem for many projects and requires not only experienced and skilled personnel but also a significant amount of time.

Also, a common tendency in many Agile projects is the complete focus on learning and adaptation while leaving aside anticipation. This results in poor requirements definition, uncleared architectures and later on, problems integrating with other systems or too much time spent for rewriting and retesting the code. Finding the right balance between adaptation and anticipation is also a very time-consuming process and also something that varies from one project to another.

Adaptability is an imperative trait of an Agile leader. This brings along a set of opportunities but also increases the number of challenges a leader has to face. Adaptability is one’s ability to adjust in response to altered circumstances or changes in the surroundings. Within an organization, change can occur or be initiated in various directions: people, processes and products.

When it comes to people, adaptability is mandatory when it comes to managing a multicultural diverse workforce or when relocating, as a leader, in a foreign country, for example. The leaders are challenged not only to understand different cultures but also to build effective teams that overcome the multicultural barriers. The possibilities that emerge from this are numerous: diversity implies various perspectives, more ideas and implicitly, multiple solutions.

Also, in a high change environment, people tend to lose motivation and get stuck in what change means for their ego. A challenge for a leader is therefore to motivate people and help them in finding a way through their perceived losses. This triggers the possibility of building teams that adapt quicker to circumstances or have the right attitude about change.

When it comes to products, adaptability consists in creating ones that responds to a customer need. The challenges the leaders face in this direction may be related to building teams with the right skill set, motivate them and inspire them to be creative and innovative; this is even harder when time and financial boundaries exist. However, adaptability in this case will trigger possibilities such as: better relations with the customers and more opportunities for business growth and, nevertheless a higher engagement among employees.

The traditional project management model involves thorough planning, controlling, monitoring and, in case of events that might affect the project, taking the right actions for bringing it back to the initially predicted plan and path. The approach assumes, that the future events, their consequences and outcomes can be predicted (hence the detailed planning), that one project resembles another and that everything important is measurable (hence, the always present constraints of cost, schedule and scope). The tasks and the actions to fulfill them weigh heavily while the actors involved in the development (the teams) are hardly being focused on. They are rather seen as resources that have to be directed towards meeting project’s and organization’s goals; the concept of managing the team is not at all insisted on as the project manager’s focus falls entirely on managing tasks.

Obviously, this approach can no longer face the challenges of today’s IT business world: the projects tend to grow bigger, the requirements are more elusive and always subjected to changes, the technologies to choose from are countless and the demands of the workforce are also different. The teams, at their turn have to face these challenges while keeping up the development speed and quality. Therefore, in agile practices, the focus switches towards less concrete aspects such as managing and building self-organizing teams, collaboration and decision making and developing servant leadership styles.  

Hence, the directive style encouraged and practiced in traditional project management is set aside in favor of an adaptive style: the leaders are supposed to influence and recommend and not impose, assist and counsel and not order or direct. An Agile project manager is more likely to focus on establishing mutual respect, trust and confidence with his/her subordinates rather that fixing goals, protocols and setting up clearly defined hierarchies. This is also closely coupled to another concept often met in APM, namely, building self organizing teams.

Lastly, Agile methodologies put a strong emphasis on collaboration and encourage project managers to  facilitate collaboration within the team and act as mediators between the team and other parts involved in the projects (stakeholders). When it comes to decision making, the role of an agile project manager is to decentralize decision making , encourage debate and sharing of ideas, unlike a traditional project manager who will probably try to keep the decision making process as central as possible.