Posted on

How do you relate the Agile Manifesto and principles to what you have learned so far in this program

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.
Posted on

What are the problems with the Agile project Management model?

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.

Posted on

What extra challenges/possibilities does adaptability post for a leader ?

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.

Posted on

What is the difference in how the project team would be managed in an Agile vs. a traditional project?

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.

Posted on

How is customer value viewed differently in Agile and traditional project management models

The aim of conventional projects is to deliver a product within three constraints: scope, costs and time. The focus is highly likely to fall on the delivery process itself and a project’s result will be deemed successful provided that all the constraints are met (the projects delivers everything of what it said it would, on schedule and within the agreed budget). In an Agile project, however, the focus is on creating value for the customers.

In the traditional projects it is believed that teams have no control over outcomes and value and should not be held accountable for them. As a result, they become focused only on the requirements (that are held fixed throughout the project) thus failing to deliver real business values. On the other hand, in agile setups the teams should focus on outcomes (product vision, business objectives, high-level product functionality) – everything that defines a releasable product – and on quality objectives. The other constraints (cost, time, money) still matter, but their importance comes after the values.

In essence it is the customers that define the features or the capabilities of a product, thus they are the ones defining value. The customers are also the end-users and also those evaluating the product hence, the final results will be measured against their expectations. Since the expectations can be rather abstract, intangible measures, agile project management models promote close cooperation between the development teams and the customers. In traditional models, there is hardly any interaction between them which often lead to teams delivering less value.

The activities that create value are innovation (creating new products or services, setting up new processes, reducing the development time), focus on delivery, execution and learning (not on planning, control and correction, like in traditional models). Nevertheless, agile methods encourage quick and incremental value (working product features) deliveries during the project’s life cycle, unlike traditional methods that deliver everything only at the end with  high risk of discovering major issues.  In the end, simplicity – or maximizing the amount of work not done – is another value-adding aspect of agile methodologies. The reason is that simplicity is a prerequisite of reliability, enables speed and hence reduces costs.

Posted on

What is Agile Project Management ?

In order to succeed on today’s market, the companies need to create new and innovative products, reduce the development time and customize them based on their customer’s demands. The traditional managerial practices, although highly structured and stable, do not favor innovation and are too rigid for responding quickly to the changes in the business environment. Agile project management on the other hand, is a modern approach to managerial practices that distances itself from the traditional, process-centric approaches by encouraging innovation, a shorter time-to-market and by anticipating the changes created by the customers or competitors.  

Agile project management encompasses a collection of practices, with clearly defined objectives, a set of values for the leaders and practitioners and also a life-cycle framework consisting of five stages (Envision, Speculate, Explore, Adapt and Close) . Beside this, Agile project management replaces entirely the traditional “triangle of balance” of time, cost and scope and redefines the performance measurements according to a new set of goals that reflect the Agile principles and values.

So, the agile project management practices are steered by five main objectives:

  • Continuous innovation: by replacing the authoritarian, structured environments with adaptive cultures, based on self-discipline and self-organization, agile project management will foster innovation while still fulfilling customer requirements and delivering customer value
  • Product adaptability: agile project management strives to to deliver on future client requirements by designing adaptable products
  • Improved time to market: agile project management tries to improve the time to market by employing an iterative process, focusing on the value-adding activities while eliminating waste and overhead.
  • People and process adaptability: agile management encourages learning and aims at building teams that that are comfortable to variations; the learning process is not seen as an expense but rather as an part of delivering value to the customers
  • Reliable results: agile management values reliable process over repeatable ones when aiming to deliver a valuable product to a customer

Regarding the values of agile project management – the Declaration of Interdependence and the Manifesto for Agile Software Development highlight the values for project leaders (value over constraints, teams over tasks, adapting over conforming) and developers/practitioners respectively (interaction over processes, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan).

When it comes to the project life-cycle, the agile approach replaces the traditional Initiation, Planning, Execution and Closing phases with other five phases: Envision, Speculate, Explore, Adapt and Close. These  are more suitable for supporting a more realistic development process that evolves the product  based on the knowledge gained in time and customer’s continuous feedback.

Last, but not least, the performance measurements of an agile project change compared to the traditional one. While the traditional performance indicators were scope, cost and schedule in an agile project the indicators are value value, quality and constraints (building a releasable product, having a good enough quality and acceptable costs and time).

Posted on

Differences and similarities between Kanban and Scrum

Both Scrum and Kanban are well-known Agile software development methodologies. They are both flexible processes that promote small, iterative changes and promise enhanced productivity and a better quality of the final product. Of course, they both have their advantages and success stories when adopted in software projects therefore, the decision of which framework to embrace usually belongs to the development team. In the followings I will go through some of the similarities and differences between the two frameworks as they were presented by Henrik Kniberg in his book “Kanban and Scrum, making the most of both”.

So, as I already stated, both processes follow the Lean and Agile principles, are empirical development methods and approach large work packages in the same manner: by dividing the total amount of work into small, manageable work items and delivering them as early and as often as possible. Both methodologies use pull scheduling and set limits on the WIP (work in progress) but, while Scrum indirectly limits the WIP by means of time units, or iterations, Kanban limits the WIP directly, per workflow state. Nevertheless, transparency is ensured by both methodologies with the purpose of improving and optimizing the process.

In terms of differences, Scrum is more prescriptive compared to Kanban. For example, a striking difference is that while Scrum requires specific roles (Product Owner, Scrum Master and team), Kanban prescribes none. Also, in terms of teams, Scrum prescribes cross-functional teams but Kanban sets this as optional and allows as well specialists teams. Unlike Scrum, that uses and advises for time boxed iterations, Kanban can be very much event driven and have separate cadences for planning, release or improvement. Moreover, both estimation and commitment are optional in Kanban while in Scrum the teams must always break down the items, estimate them and commit to a specific amount of work during each iteration. Another difference lies in the boards: while the Scrum board belongs to one team only and resets at the beginning of each sprint, Kanban boards are persistent and can be owned by several teams.

Posted on

How does Scrum fit with the concept of Agile?

Agile encompasses several methods for developing software. Out of these, Scrum is the most famous and used one. A good starting point that helps us assess how Scrum fits with the concept of Agile is the Agile Manifesto together with the twelve principles behind it.

‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software’

‘Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter time scale’

The core of Scrum is the sprint, that lasts up to one month and that has as purpose the delivery of a working, usable and releasable product increment. The limited time duration enables predictability and ensures inspection and adaptation of progress towards the goal. Meanwhile, Agile itself advocates for the incremental development of the systems and for the prioritization of the functionality that gives the highest customer value. Unlike the traditional ways of building software, Agile methodologies encourage as well early feedback with the purpose of learning and improvement.

‘Business people and developers must work together daily throughout the project’

In the case of traditional project methodologies, a project’s success was evaluated based on its delivery within the agreed scope, time plan and costs. However, a successful project should also generate customer satisfaction and not only fulfill a series of formal requirements. Moreover, it should be ready to be launched on the market at the right time instance and the customer should be involved in the development process from early stages. So, while the developers have the “know-how” for building a system, the business people and customers have the knowledge related to market, timing and needs. Scrum supports entirely these aspects and promotes collaboration not only within the team but also between persons with different backgrounds and knowledge.

‘The most efficient and effective method of conveying information to an within a development team is face-to-face conversation’

Scrum focuses strongly on communication. The proof is given also by the various Scrum events (daily Scrum meeting, sprint review, retrospective, backlog refinement, sprint demo) that are meant to encourage collaboration and effective communication, to promote transparency and to offer the opportunity to inspect and adapt. Hence, it is highly likely that in an organization practicing Scrum the extensive documentation will be replaced with brainstorming sessions or meetings next to a whiteboard!

‘At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly’

Scrum is a framework that sustains continuous improvement. As such, two major events are held every sprint with the purpose to inspect and adapt the product backlog (Sprint review) and to analyse how the sprint went with respect to people, relationships, processes, tools (Sprint retrospective).

Posted on

Is Prince2 an Agile model or a traditional project management model?

Prince2 is, by far, a traditional project management model. According to its description, Prince2 has a very formal structure, with a clearly defined project organization and specific stages, roles, activities and deliverables. Its formality and strict structure can be noticed already in the pre-project phase, when the project manager not only has to put together a significant amount of information for creating the Project Brief but also has to plan in detail the Initialization stage.

Moreover, it is a model focused entirely on the managerial process/activities: the “collaboration” between the management and the board has a protocol-like structure, with request-authorization patterns at every stage and the value is created by delivering the project within the agreed scope, time plan and costs. As expected, there is no flexibility regarding the plan: this is more or less “set in stone” from the early beginning, the output of every stage is evaluated against it and, in case deviations occur, efforts are usually made to restore the project on the “meant to be” trajectory.

Also, it is a model heavily relying on documentation at all stages. As an example, during the Initiation stage only, the project manager has to prepare, besides the project plans and business case, four extra documents related to strategy; same goes on at team level where the team manager has to deliver checkpoint reports after team’s regular meetings).

So, as summarized above, the differences between Prince2 and Agile project models are obvious.  In Prince2 there is no rush to make it quickly on the market and no place for the customer in the picture: the focus falls entirely on the established requirements irrespective of the value that these create for the customer. Moreover, Prince2 is a very closed, business centric model, with a strong focus on the managerial activities performed (planning and controlling) but not on learning from mistakes, on being adaptable or innovative. Besides, the tasks and the end product have a central role while the development teams’ role is rather limited and marginal.

Posted on

What can be changed at Waterfall to make it work better in today’s IT industry?

One way to approach this would be to consider the areas in which the Waterfall model always falls short, namely: the long and detailed requirement specification phase, the extensive documentation written throughout the entire development cycle and the lack of customer involvement.

In the Waterfall model, the requirement analysis and definition is an extensive phase in which all the functions and constraints of the system are collected and analysed meticulously. The deliverable of this phase is a requirement specification document that will serve as guideline for the next phases.

To decrease the time spent in this phase and to optimize the requirements gathering, an idea would be to develop in parallel a prototype. This prototype is meant to be constantly subjected to customer’s feedback and modified accordingly until a “good enough” version is obtained.

Of course, when it comes to prototypes, one may choose from employing the so-called “throwaway prototypes” or “evolutionary prototyping”. “Throwaway prototypes” are more suitable for validating the requirements or clarifying those that have been poorly understood. Moreover, they may give hints about critical points or possible flaws and offer the opportunity to select a different design/solution that will overcome the issues. As its name implies, the prototype will be discarded and it will not be part of the final system. Therefore, once the client validates it, the workflow is expected to resume and continue with the design, implementation and testing phases.

Unlike the former one, evolutionary prototyping does not imply doing the same job twice and discarding the prototyped system after its validation, but rather using it and refining it (based on customer’s feedback) in the subsequent development phases. While a final refinement and testing are still required, it can be noted that this approach is similar to the iterative, incremental development methods.

One may argue of course that evolutionary prototyping is nothing else but a first step towards Agile and that “throwaway prototyping”, even though it has some advantages, is not suitable (due to its time and resource requirements) for today’s fast paced IT market. Therefore, I see no other ways and no possible “fixes” for the Waterfall model to succeed other than turning Agile.