Even though we all have seen Kanban boards, many of the principles that stand out this methodology are often overlooked when in practice.
If you are working in software development, in a technological environment or in a start-up, it is very likely that sometime you have used a Kanban board to visualize which tasks are still pending, which ones are in progress and which ones are already finished.
This is the Kanban MVP: three columns, three stages: to do, in progress, recently completed.
ITM Platform’s personal board sums up the pending work with Kanban.
This simplicity has been, in some way, a blessing, because boards have become hugely popular. However, in a way it has also doomed them – many people either use them or criticize them without knowing in detail the characteristics of this method.
For example, Kanban’s usefulness for managing work that doesn’t fit into any project is commonly ignored.
This makes Kanban an excellent tool accessoryto manage a portfolio of projects, in which change demand also includes isolated tasks for which there is no formal coordinator or project manager.
Nevertheless, very few portfolio tools include Kanban among their characteristics; and very few online Kanban versions feature portfolio management.
If you fancy having both things, ITM Platform is on the of the few suppliers that can satisfy you.
In the software development world, it is common to consider that SCRUM is the best agile methodology, if not the only one. However, each methodology has its pros and cons. If you want to have a look at the main differences, here you have a helpful article.
SCRUM, for example, is only used for software projects and, in that field, it replaces traditional waterfall design methods in a much more efficient manner.
However, outside that field, SCRUM becomes very fragile, not to say useless. For example, it cannot be applied to design processes of new products that lack programming elements.
On the other hand, besides being used extensively in development (often mixed with SCRUM methodologies), Kanban has proved its utility in contexts where most of the work volume is operational. The classic example is industrial manufacturing, such as the Toyota factories where this method was invented. But the design of new goods and services of any industry can benefit from its structure.
The 3 principles of Kanban:
Visualize everything that is happening at any given moment. Each element and its stage can be seen within the context of all scheduled work, regardless of whether it’s a project or operational work.
Set caps for work in progress (WIP)There should be a maximum number of tasks that can be managed at the same time, and the visual boundaries of the board help us perceive that limitation. For example, if a quality control unit can manage a maximum of 5 batches, it shouldn’t accept the 6th one until it has one empty spot for it. This might not be very intuitive, but WIP limitation consists, precisely, on visualising bottlenecks in order to prioritise work in those areas and gather the resources required to solve them.
Improves work quantity. As soon as a task is finished, another one from the backlog is started. In order to do that, it is essential that the backlog be correctly managed, prioritised and categorised.
When should Kanban be used?
There are 4 situations in which Kanban should be used:
In operative environments where priorities change very often
When changes in requirements can be introduced any time
When work units are isolated tasks
When the incremental optimization of an already existing process is pursued.
What are Kanban’s advantages?
Maximum transparency
Continuous worflow
Equating the team’s capacity with the ongoing work
Focus on the duration of the cycle (how long it takes a task to go from backlog to be completed)
It allows assigning different WIP maximums to the consecutive stages and redirecting the work to improve the delivery time.
For example, regarding this last point, it’s very normal to have 4 stages within a programming team: To Do, In progress, Code Review and Finished. Allocating a maximum of 2 tasks to Code Review means that In Progress cannot take over more tasks right away. Therefore, programmers must spend some time checking code, a very unrewarding task that is often relegated. Thanks to this, we can avoid the bottleneck of having all the code written, but pending from review.
When teamwork and immediate communication are added to the board, benefits are crystal clear.
Receive the latest blogs directly into your inbox
A project management office (PMO) can fulfill multiple functions related to the supervision of an organization's project portfolio, often with managerial functions and with a strategic orientation that is added to the simple control and monitoring layer.
However, it is not clear what an agile PMO is or how it is structured. It is becoming increasingly urgent to clarify this aspect, since many teams and even entire organizations, especially in the field of software and application development, rely entirely on agile methodologies such as SCRUM.
Before entering into the matter, it is necessary to clarify three different senses of what can be understood by agile PMO.
Disambiguation: What do we mean by agile?
An agile PMO can refer to several situations, such as:
1. The agile implementation of a PMO
As the start-up process is long, complex and may have difficulties in demonstrating its benefits to stakeholders with a high capacity for influence, some experts advise that the start-up approach be agile and be protected from criticism towards a structure that it is not working 100% yet. In addition, it is possible that the difference stakeholders do not agree on what should be the role of the PMO in the organization, in which case their scrutiny on the development of the implementation will necessarily be uneven.
To combat this disadvantage, a PMO whose implementation is conceived as an agile project must deliver processes and functions useful for the operation of the PMO in a continuous and early manner.
The measure of the progress of the project, as is logical, is given by the functionality of the PMO itself.
An agile implementation is usually characterized by an initial diagnostic phase, followed by phases of planning, execution and closure that can be iterated several times until the PMO has the desired maturity.
However, in the first iteration of the execution, the PMO already assumes characteristics that allow it to operate in one or more of its functions.
2. The role of a PMO whose objectives is to manage the project portfolio following agile principles
It is not essential to have adopted SCRUM throughout the organization so that we are interested in benefiting from some of the advantages of agile principles at the corporate level.
For example, the agility applied to the entire portfolio of projects allows for early decisions and rectifies the initial planning of projects when the context that justifies them is modified.
3. The role of a PMO in an organization that has exclusively adopted agile project management methodologies
What happens when an organization that worked with classical methodologies or waterfall becomes guided by SCRUM or other agile methodologies?
What is the role of the PMO in this new situation? Is the mission aborted and the office deleted, or is it given a new meaning?
The cultural and change management role of the PMO can be fully maintained. In the new context, the PMO facilitates the deployment of the agile culture in the different areas of the organization.
The predominant areas are the following:
Training: includes training new people in agile methodologies, preparing meetings and workshops, deepening for key embers, as well as coaching services.
Work monitoring: although the agile philosophy is very horizontal and does not require so much external control, a PMO can support the performance of the teams helping them to manage the backlog, offering clarity in the performance of the teams through an impartial external vision, and helping to that the documentation that works in the organization is productive and does not produce unnecessary work.
Interlocution with the business: One of the fundamental aspects of the manifest agile is the constant efforts to understand the need of the client and guide the work to the delivery of utility. In internal projects, it is essential that there is a well-oiled transmission chain with those who administer the corporate strategy so that they know that the engineering teams are working on the most critical aspects and that they deliver the most value to the business.
Next, we detail better what the work of an agile PMO consists of in this last case.
The nuance is important, as our readers are well aware that managing agile projects involves ongoing guidance to customer requirements and very frequent evaluation cycles. The question is how the responsibilities of methodological guidance, centralization, control and direction of the PMO can be connected in these cyclical structures, maintaining customer orientation and business perspective.
The fundamental risk, let's face it, is to create a small bureaucratic monster that coagulates methodological demands without adding value.
Failures in the conception of a PMO
The main problem arises when, in order to achieve agile projects, an attempt has been made to establish rules of action that have merely pigeonholed and limited decision-making.
Despite falling under the range of agility, SCRUM requires the production of a lot of documentation with a very high frequency, including the requirements of user stories.
A recurring error when creating PMO in agile environments is utilizing them as centralized offices that impose internal policies and norms. Keep in mind that circumscription to certain standards at work can marry poorly with the completion of certain complex projects. There is the risk of restricting the freedom of action and the margin of manoeuvre that are fundamental to produce value in all sprints.
A PMO cannot be confused with merely a controlling body that seeks to fit agile projects into tactics, methodologies and master projects of the manager that have been preconceived without special attention to the changing nature of agile projects.
First correct interpretation of the agile PMO
In contrast to the centralized and bureaucratic PMO, the most attractive in an agile environment is the performance of a facilitation function.
This can be done by establishing recommendations to help manage the workload, distinguishing between priority and ancillary tasks, helping project managers determine how much they can rely on experts, and even set basic standards of performance and work ethics that are in line with the values and mission of the organization. So that all projects, besides providing value to the client, are oriented to the common benefit and growth and consolidation of the organization.
One difficulty of any multi-project organization is the barrier to sharing knowledge, both within the same project team and between different projects. In the first case, the difficulty is that the experience and specialization accumulated by the veterans is not limited to the tasks they perform - which would create bottlenecks; In the second, the difficult thing is that the experience in the development of a project is not forgotten with its completion, but rather to increase the experience accumulated by the organization.
An agile PMO, among other things, faces the specific knowledge challenges that hinder operational improvement in agile performance.
And one of the main goals of an agile PMO is to make all parts of the organization that take part in a project as a unit, as a team, and even as a team of teams. In this sense, it is important that whoever is going to coordinate the work of the PMO accredits the following virtues:
- Relationships. Good contact with leaders of other departments as well as people integrated into other projects.
- Trust. Openness in dealing with those who are going to influence the project is key to its success.
- Experience. Undoubtedly, having previously faced similar projects provides sufficient evidence to address future projects.
The goals of an PMO agile
Once we have analyzed some guidelines of an agile PMO , we are going to offer you the primordial purposes of these organs. Take note.
1. Manage new project entries
It makes no sense to approve projects above the delivery capacity of development teams. The PMO can function as the housekeeper to resist the temptation to start projects too soon. You have to wait to finish projects to start others of equal size.
2. Validation of the planning rules
The probability of unexpected and unnecessary changes must be reduced to the maximum, due to the overall understanding of the program.
3. Creation of training programs
Training is fundamental so that the knowledge of the equipment is truly complementary and there are no empty areas. The detection of gaps should be the basis for proposing training to members.
4. Limit waste
Only the PMO will have aggregated information on where time and effort is wasted. It is possible that different projects have similar patterns that point to the inefficiency of the processes. Drawing attention to them is the first step to rectifying them.
5. Delivery report
Reporting to consolidate an accredited view of the status of part of a project or its overall vision will facilitate the interpretation as to whether the affairs of the organization are being carried out in the most functional way. Without going further, conclusions that can be drawn from these reports may become important in the allocation of personnel for certain tasks or working schedules.
6. Business rules related to the benefits of the project
When making a commitment on a project, it is imperative to keep in mind that there are minimum results that have to be fulfilled. This duty also facilitates the adjustment to content that is compatible with existing quality projects. A uniformity that you do not have to understand as negative, but as an orientation towards excellence.
7. Validation of a resource plan
Every project requires a realistic allocation of resources. You have to keep in mind that the amount of resources of an organization will always be insufficient to delivering all the projects that can be generated, hence it is necessary to select, analyze conscientiously and not to precipitate. The allocation must be reasonable (it is fundamental to minimize the risks) and must be based on the fact that, in a final global calculation, the investment and achievement are compensated.
In short, we hope this text has helped you understand how an agile PMO has to works.
Receive the latest blogs directly into your inbox
Implementing agile methodologies (Scrum, Kanban or any of their variations) is a challenge faced by all kinds of organizations, project offices and managers. The advantages to be gained from this type of method for a great number of projects are clear, but actually implementing them is no simple task. At many organizations their implementation is often met with fear, rejection and obstacles. Here are a few keys to successfully implementing a agile methodology.
1. Start with the Right Project
It is actually possible to apply the agile methodologies to almost any type of project but the successful implementation of these methods does indeed require selecting the right projects to begin with, so as to achieve the maximum benefit in the shortest time. Trying to apply agile methodologies to clearly predictive or classic projects does not usually lead to good results, as there is a considerable sense of losing control, with teams (and management) tending to revert to methods they already know. In contrast, experimental projects: presenting a lesser defined or highly changeable scope with multidisciplinary teams and needing swift results: provide an excellent opportunity for applying agile methodologies.
2. Clearly define the Team's Role
The role played by a team in classic or predictive projects is significantly different to their role in agile projects. The Project Manager plays a leading role in the former, with control over all aspects of the project, whereas the team has a much more relevant role in the latter and the Project Manager becomes a facilitator of the methodology. It is important to clearly define the team’s role in order to implement the method correctly. An agile project requires a multidisciplinary, self-organized and self-managed team, which is a confidence challenge for many organizations that tend to apply managed and controlled methods. Understanding and building this type of team is very important. If you can build a team that consists of relationships between equals and a shared goal, a large portion of your future success will be guaranteed.
3. Estimation of Effort is still Key
One of the most common problems when implementing agile methodologies is believing that estimates no longer need to be made. Even though it is no longer necessary to make an estimate of the whole project and we can focus on the tasks for the next sprint or those with a higher priority in the product backlog, it is important to realistically estimate the efforts required for the tasks and ensure they are reasonably equal or that the size difference between them is clear. If a task has not been completed at the end of a sprint or a task is constantly shown as “ongoing” in a Kanban project, it is very likely that we have made a mistake in our estimation that should be corrected, the task should be broken down into more manageable parts and our commitments should often be revised. Flexible management will ensure that the estimate focuses on the tasks providing the highest value or that we need to tackle most quickly. However, the estimation itself is still important.
4. Know and control Limitations
Agile methodologies have limitations and they must be taken into consideration. There are scope, deadline, cost and quality factors that need to be met. It is true that priorities might be inverted or the scope might be more negotiable, but the limitations on deadline, cost and quality remain and must be managed. These methods state that tasks should not exceed a certain effort, define a maximum Work in Progress (WIP) we can manage or establish a time-box by using sprints. Limitations must be strictly maintained and not changed lightly, as they are a very important part of their model. If we make changes or adjustments and accept all types of changes, we are losing control.
5. Manage tension
Although it might seem contradictory, agile methodologies are more like a long-distance race than a sprint. Some organizations approach these methods as a way of moving more quickly - getting more done in less time – taking advantage of the fact that teams are more deeply involved. This is true, but if we want the implementation of these methods to last, we must manage team tension. Having a motivated, results-focused, self-managed and efficient team is possible with agile methodology. In order for these characteristics to last over time, we need to ensure that the team also perceives an improvement to productivity and not only a constant increase in effort and workload.
6. Metrics: “power without control is useless”
These methods are extremely powerful. They are capable of producing motivated teams that obtain impressive results in genuinely short spaces of time. Nonetheless, all this power does not come at odds with control. Agile methodologies encourage us to measure, analyze and constantly improve.
Metrics are the way to explicit project management based on real data rather than intuition, opinions or occasional emergencies. Speed, flow and commitment compliance are all key metrics that we should gather and analyze in order to streamline our processes and improve our teams.
7. Quality, Quality and… Quality
Quality means repeat business. Increasing delivery speeds, managing estimates incrementally or having a self-managed team do not mean setting quality aside. It is very important to deliver products quickly in agile methodologies but those products should also work; they need to do what is required of them efficiently.
That is why it’s important not to leave quality until the end and incorporate aspects of quality validation, revision and measurement of all the items, deliverables and products we generate during the project from the outset.
8. Remain to the methodology rigorously
Agile methodologies have few rules, standards or products. It is important to follow the method precisely, especially at the start. It is better to change nothing (or almost nothing) before gaining experience. If something seems strange, have a little patience and give it a chance. Scrum methods establish a series of roles, meetings and stages that should be preserved, experienced and maintained in order for these methods to truly work as we expect. It is possible to go from less to more in these methods, but follow their instructions precisely until you are comfortable with their use.
9. Revise and adjust the method
As soon as we have advanced significantly in the use of agile methodologies, we can consider making adjustments to them. It is important to conduct reviews or retrospective exercises that allow you to see what does and doesn’t work within your organization and make the necessary changes to adapt the method to your culture, style and requirements. However, this should always be done after having tried the standard models.
Agile methodologies are indeed flexible, very flexible, and that is why they can be adapted to almost any type of project, organization or team. With a little experience, possible imbalances can be identified and changes, adaptations or additions can be made to these methods so as to ensure they perfectly suit our needs and circumstances.
10. Maximize visibility
One of the most important keys to the success of agile methodologies is visibility. Implementing these methods is done “behind the scenes” at some organizations, almost invisibly or as if applying this type of tool were embarrassing in some way. It is important for this type of implementation to be made visible, open and public so that the entire organization can see what is being done, how it is being done and what has been achieved by doing it. Avoid using private "Kanban" methods or hiding them when the project client or sponsor appears. Be brave and show, explain and harness the most visible advantages. There is no better ally than a project client or sponsor that is involved in management, added to which agile methodologies enable maximum visibility and maximum participation from all stakeholders. An agile methodology is not an exception or an extravagance from an isolated team but something that can be applied throughout the organization.
11. Manage expectations
Many teams and organizations that embark down this path believe that all their problems will be solved as if by magic; that the client will never change their mind, that products will no longer have defects or that nothing “unpleasant” will ever happen during the project again. Agile methodologies adapt very well to changing and stressful environments but they are not the solution to every problem. Managing expectations from teams, clients and management is important to successful implementation.
The method may well not be perfect the first time around, that teams will feel uncomfortable with certain aspects of the method or that the project will encounter certain problems. This is completely normal. You will quickly see that progress is being achieved, that progress is significant and that the results are very positive.
12. Select the right tools
Using a support tool when applying agile methodologies facilitates their implementation at organizations. Having centralized support for sharing information, measuring progress and maintaining project control is highly important. With the right tool, teams will be able to work independently while the organization can maintain control over project progress, costs and revenue, efforts, etc.
Do not be fooled by tools that are free but completely disconnected from the rest of your organization. Agile methodologies are not an anecdotal or exceptional process implemented by teams with highly unprofessional tools; it is an important decision by the organization to adapt and improve. We are facing a project management revolution that is allowing us - with the right tools - to improve our performance, deliver high-value products very quickly and achieve great success.
Receive the latest blogs directly into your inbox
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
Even though we all have seen Kanban boards, many of the principles that stand out this methodology are often overlooked when in practice. 
A project management office (PMO) can fulfill multiple functions related to the supervision of an organization's project portfolio, often with managerial functions and with a strategic orientation that is added to the simple control and monitoring layer.
