Agile approaches are spreading like wildfire. There are those who like it and those who reject it, but whatever group you belong to, it's clear that it's at least worth knowing the mindset. Yes, a mindset and not a methodology, as we will discuss later. For those of you who have not yet encountered the agile project management mindset, we have summarised the most important things to know in order to clarify the misconceptions and contradictions we have encountered. In this post, you can read about the following topics:
Content
Project management basics and its evolution
Project management is not new. As early as the 1960s, the need to manage the creation and development of a large, typically unique product or service according to a controlled process was recognised.
The internationally accepted definition is that project management is the application of knowledge, skills, tools and techniques in performing activities to meet project requirements. However, we prefer the simpler "art of getting things done".
Like so many professions, project management has evolved over the years, sometimes organically, sometimes consciously. In the beginning, project management did not exist as a profession in its own right, it was often just a 'hat' given to an individual working on a project (even if not called that). However, over time, and as the complexity of the tasks increased, it became a fully-fledged role in its own right.
Whatever the project, there are three main factors that affect all such tasks. These are scope (what to do), time (when to deliver) and cost (how much it costs).
To this day, with little exaggeration, all projects are moving in this triangle, trying to balance and satisfy the customer's needs (everything, fast, cheap).
With the waterfall approach, which became widespread in the 1970s, the success rate of projects has increased considerably. This was because success could be achieved through conscious planning in a relatively predictable environment, which was then not changing too rapidly compared to today.
However, in the 1990s, this proved increasingly inadequate, with technology advancing rapidly and the number of projects increasing, more and more work was subsequently found to be unnecessary and more and more delays and cost overruns occurred.
This recognition has given rise to a variety of methodologies other than waterfall.
Project management methodologies, trends
With the development of project management, different trends have emerged, which have been embodied in different methodologies. A project management methodology is a set of practices, techniques, processes and rules used by those involved in projects.
Today, an amazing number of methodologies have been developed, some "out of the box", but also some solutions developed at organisational level.
If we want to group them, we basically define 4 types of trends. This can be identified by the extent of change and the frequency of delivery, so the approach depends, among other things, on whether we want to deliver through one or two or more components, sub-products, elements, increments, and the extent of change we expect in the expectations or even in the environment, which is a common cause of these changes.
In our experience, agile approaches are most successful where we expect a high degree of change and uncertainty, and we want to manage this with, among other things, high creativity and frequent delivery, including feedback. This is where agile might be most ideal.
Agile project management: mindset, methodologies and tools
In many cases, we see that the understanding of agility and agile project management is different and often wrong. Our approach is that the tools, ceremonies and roles are part of the methodologies, and for the sake of example, the most commonly used scrum "system" is one, along with many other agile methodologies. Examples of agile methodologies include Lean Product Development, eXtreme Programming, or any hybrid solution based on the same values. These methodologies may differ in terms of roles, processes, ceremonies, but they have one thing in common, and that is a mindset and a value focus.
This is why we usually advocate that the agility is a mindset, a way of thinking, which can be embodied in the lives of organisations and individuals in many ways. These values and the principles behind them are well described in agile manifesto but although these seem infinitely simple, the way they are applied is not always clear.
To quote the manifesto "(...) we have come to value::
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
In many cases, the values described above are not sufficiently emphasized in projects, and their reinforcement can be achieved, among other things, through the appropriate application of agile project methodologies or the development of organizational agility.
However, it is always important to stress that not all projects should be managed along agile methodologies, we believe that there is still a place for traditional approaches, which we believe can be tailored along agile values.
Misconceptions and the realm of chaos
Agile methodologies are structured, organised ways of working. Chaos is the total opposite of this, which we see in many organisations whether as consultants, coaches or trainers. The following misconceptions can lead to this unhelpful state of affairs, without wishing to be exhaustive:
- Agile projects do not need to be planned
- Agile projects do not need to be documented
- Agile projects are completed faster
- Owners of the demands have less work in an agile project
- Agile approaches are right for every project
- In an Agile project, you don't need to set a goal in advance, it will become clear as you go
- We do daily stand-ups, so we are agile
- As an agile project manager, I will have less work in agile projects
The latter is also interesting because we get from many "agile evangelists" that "agile approaches do not use project managers"! This is something we partly disagree with, because although this role is indeed not formally defined and does not exist in the traditional interpretation, but with a different perception, we believe that there can be a place and value for agile project managers (although the name is not the most fortunate), in the context of agile working. with a different approach, our experience shows that there is a place for agile project managers in the context of agile working.
Differences between traditional and agile project approaches
There are fundamental differences between traditional and agile approaches. The methodologies are of course different in terms of process, roles and ceremonies, but the the main difference lies at their roots, in the way of thinking.
All the elements of the triangle cannot "move" along the triple constraints described earlier, there must be a fixed point. In traditional projects, the scope is typically defined first and the answer is sought in the planning process as to within how much time and at what cost it can be delivered. In contrast, agile approaches consider scope as a variable. That is, they consider a fixed time-box or cost-frame and try to deliver the maximum (but still realistic) value to the customer by keeping within this framework and fix the scope only for the given iteration.
Role differences:
Another major difference is in the roles. Traditional project management approaches focus on one main person, the project manager, who is responsible for planning, managing and monitoring the work. Although in most cases it makes sense to involve the project members in the planning tasks, the project manager is the person ultimately responsible for the work, so he or she has a high level of authority, can assign tasks and direct project members to carry out specific tasks.
For agile approaches, the situation is completely different. Responsibility is not held by one person, but is shared between several actors. The team is also responsible for the implementation and the choice of how it is done, so agile methodologies operate with self-organising, cross-functional teams. The team determines what they are able to deliver within a given iteration or sprint along a given priority, they define their own working method and process, they estimate task size and they also take responsibility for delivery. So there is no one manager telling the team how to work.
addition to the team, there should be an actor who represents the customer's interests, i.e. defines what the expectations are at the user or customer level and represents them. This role in scrum is the Product Owner (PO), who prioritises the "requirements", documents them and decides on the acceptance of the increments delivered by the team.The task of the PO is to maximise ROI, to define functions and increments that are of real value to the customer.
All teamwork brings challenges, and when people work together, many difficulties can arise. These difficulties are reduced and solved by the agile coach (in scrum Scrum Master). His/her role is complex, as he/she works with a kind of servant-leader approach, supports the team in working together, helping them to create the conditions necessary for effective work. A strong Scrum Master facilitates, teaches, mentors, "holds up a mirror" and also protects the team from harmful external factors. He is the actor who removes impediments, who keeps the ceremonial framework, who supports the team and the PO to work together and also develops team collaboration.
Roles thus function in networks along agile values instead of the excessive hierarchical structures of the past.
Ceremonies
In traditional projects, everyone has come across "meetings", project conferences, which in most cases are led by the project manager. These can be regular or ad-hoc meetings, depending on the project and the situation.
Agile approaches do not operate with meetings (everyone thinks of formal, boring, serious and lengthy meetings), but with so-called ceremonies. The ceremonies may vary from one agile methodology to another.
Scrum methodologies ceremonies:
- Sprint tervezés - The objective is for the team, in collaboration with the PO, to define the work to be undertaken for a given iteration along the client's priorities, commit to its delivery and plan the work for the iteration.
- Sprint - 2-4 week time cycle, during which the team works on the increments to be delivered.
- Daily scrum - Also known as the daily standup, the 10-15 minute daily ceremony is designed to ensure transparency, so that the team can see who is doing what, what has been achieved, what is still to be done and to voice any impediments that may arise.
- Refinement - To ensure that the work is sustainable, it is worthwhile to organise and prepare tasks beyond the current sprint at regular intervals. The main purpose of this ceremony is to have the right quantity and quality of tasks available for the next sprint planning, i.e. to give the team feedback to the PO whether the requirements in the backlog (for simplicity we will call it the requirements list) are clear, understandable, i.e. whether the team is able to estimate and plan with them in the next planning.
- Retrospektív - Although this is one of the most important ceremonies, in practice we see that it is the one most often abandoned by teams. The purpose of retro is to improve and develop the process and collaboration, so there is a need for strong self-reflection, learning lessons and formulating specific actions that can be taken immediately. This can be a delicate area, as people are generally less comfortable talking about themselves and mistakes.
- Review/demo - At the end of each iteration, the team presents what they have created during the iteration, and the PO decides on their acceptance in this ceremony and gives feedback to the team on whether they are on the right track with the product.
The above are the main ceremonies used by scrum, which are in the common interest to be effectively observed and implemented. In practice, we often see that teams "jump into" the sprint, there is no proper planning and preparation process before them. In business, this may also require a business case, product-level planning and release definition. The process for this can be very different, you can experience the process we use and in most cases have worked in our agile simulation.
Changes and requirements
To be successful with traditional approaches, it is essential to specify the work to be done and the product to be delivered. For this, traditional projects use requirements specifications, which aim to fix the scope of the project beyond any doubt. Anyone who has been involved in large projects has often come across specifications of up to several hundred pages. In our experience, it is very difficult to write requirements in a way that both the supplier and the customer understand and interpret them in the same way.
To address this problem, agile trends apply the principle of simplicity, they do not prefer comprehensive, lengthy specifications. Instead, they use a concise, simpler form called a product backlog. A backlog is a list of requirements, ordered by reference, which contains the customer's expectations of a given product. Its elements can vary, most often we come across user stories, epics and spikes, but we have also come across themes and features.
User story, epic, spike:
User stories are short "stories" that customers and users want to see in the product. These are often independent requirements that can be described in several forms. Regardless of the form, these descriptions also make the element testable and give it a purpose (As a - I want - to).
Epics are larger "packages", which can usually be broken down into several, and less often into a single user story. Their role is really emphasized in planning, which, among other things, helps to get started in defining the minimum viable product (MVP).
Of course, it may be necessary to carry out internal tasks in order to meet the customer's requirements, or to research a topic to see what method or technology can be used to achieve it. The team can define spikes, which of course require capacity to implement.
Estimation by the team can be in almost any dimension, in story points, in time, in pebbles. The point is that the team can compare the size of tasks in relation to each other and make a decision about what can fit into a given iteration.
How can we help?
In the past years, our colleagues with agile coaching, product ownership, development and consulting/training experience have supported dozens of agile teams and organisational agile development processes.
We are not agile evangelists, we don't believe that agile trends are the solution to everything. We believe that these tools can help in everyday life, and that incorporating this way of thinking into day-to-day work to the right extent can bring short-term success for projects and organisations.
If you want to learn more about the basics of agility, scrum or kanban, we recommend our agile project management programme.
If you are a Project Manager, Product Owner or even a Scrum Master starting out, you want to to test the planning process and tools on a specific project, we recommend our agile simulation.
We can provide support for Scrum Masters and Agile Leaders through an outsourced programme, which we plan to announce as an open programme in the near future.
If you have questions, you do not know how to proceed, contact us!
Designabc