Our brain sees cause-effect relationships where there are none and does not notice problems where there are some. We try to explain the inexplicable and are interested in details and hierarchies. Therefore, when “everything is difficult,” you must look for flexible approaches – and here Agile comes to the rescue.
With the idea that everything usually happens according to our plans, we owe our innate tendency toward determinism. It argues that “future events inevitably flow from previous ones by the laws of nature”.
Determinism allows enterprises to design, plan, and predict the behavior of their end products in real-world conditions of use. If for a moment you are distracted from programming errors, operating system failures, electrical outages, unqualified users, and other risks, then it can be said that the predictions are very often accurate.
Engineers and other technical-minded people are especially susceptible to ideas based on manageability. But determinism-based systems are effective only if it is a question of repetitive operations that do not require much thought. But they do not work in situations where flexibility is needed.
Therefore, it would only be fair if the engineers dragged us out of the management swamp into which they dragged us.
Agile to the Rescue!
Agile is a flexible project management methodology that has taken root in both IT and non-IT. Agile is a flexible management philosophy, not at all like the determinism so convenient for our brain. The basics of Agile are described in the “Agile Software Development Manifest”. At the foundation of the concept are four basic values:
- People and interaction are more important than processes and tools;
- A working product is more important than comprehensive documentation;
- Cooperation with the customer is more important than agreeing to the terms of the contract;
- Willingness to change is more important than following the original plan.
The principles of the Agile approach transformed the process of project management and gained respect. The modern world is greatly accelerated – dozens of new services and digital solutions appear every day. Agile allows businesses to be fast enough when developing new products, and project and portfolio managers planning to keep up with this fast rhythm and as soon as possible give users and customers something that will solve their problems.
But even successful approaches are overgrown with their signs, stereotypes, superstitions, and mythology. Together with the popularity of Agile came its formal interpretation. Let us analyze the myths and stereotypes that make it difficult to see the essence of the flexible approach and get more from it.
Myth 1. Agile is for IT only
“Agility comes in different forms, but basically it’s the ability to quickly adapt to or even anticipate and lead change. Agility in the broadest form affects strategic thinking, operations, technology innovation and the ability to innovate in products, processes and business models”. © professor Michael A. Cusumano of MIT Sloan School of Management
You can use agile outside software development, in real business. The roots of Agile lie in lean manufacturing and organizational learning. These ideas originated outside IT in the first place. Many practices in agile also originated outside software, such as stand-up meetings, prioritization, and visual management.
In fact, these practices are so common; it is hard to say where they originated. Lean start-up is largely test-driven development at a company level. Agile is about change, speed, and dealing with the unexpected and unpredictable; it involves technology and innovation and ranges from operations all the way up to strategy.
Myth 2. Agile – not for projects with a fixed budget
On a fixed budget, you can work very differently. The question is, what is the relationship between the performer and the customer. If you use Agile, then you need to focus on what solves the problem of the customer. In other words, if at the start the customer and the contractor together plan and highlight the main priorities of the product, then nothing will prevent them from determining which part of the product is as useful as possible within the limited budget. And if we also stipulate regular demonstrations made to the customer, then it is quite possible to correct the process for short periods and, accordingly, to adjust the costs of the project.
Myth 3. Agile is a panacea for business: Go Agile, and something will improve
This is a simplified and very harmful view of things. All cases and businesses are different, and you need to choose the right approach that will help in this case. Certainly, Agile is not needed but the key to success is following a clearly defined algorithm of actions. For example, in the work of the call center, where, for better service, operators should talk on “scripts,” i.e., pre-written communication scenarios. There is no field for experiments, and they may even be harmful here.
So, Agile in the activities of call center operators is not needed. Agile will be harmful where the cost of “processing” or “reworking” a product is enormous or may even be associated with human victims. Say, during the construction of a nuclear power plant, it is obvious that we cannot build it iteratively and incrementally, as Agile dictates to us.
Myth 4. Scrum, Lean, and Kanban do not overlap
Methodologies and tools should be separated. The methodology is an algorithm for building a workflow. Tools are those “bricks” that are used in this algorithm. Different methodologies may include the same tools but in a different layout.
You can often see how, when implementing Scrum, they use XP (extreme programming) or Kanban tools. And this is normal, as they all meet the values of Agile, and allow you to make the workflow of creating a product flexible.
If you talk about the specific Agile approaches that are now most common, then this is certainly Scrum and Kanban. Others – FDD, XP, RUP, and so on, either left the stage or are rarely used entirely, but some tools from their arsenal are involved in the implementation of Scrum or Kanban.
Myth 5. Scrum is a way to quickly and cheaply make a product
As for “fast,” everything is correct, but about “cheap” – not so much. Judge for yourself: you need to form a full-fledged team, highlighting in it the necessary competencies at 100%. These people will be engaged only in the development of the product entrusted to them and nothing else, which means that they will have to either hire such specialists or “tear them away” from some department. The same applies to the business part: if you want, you do not want it, but you will need to allocate the owner of the product, who will spend 50–80% of his time only on this team and its product.
Besides, it will be necessary to bring them all together, in one room, provide them with their own space, props for team activities, and so on. Plus, you need to keep in mind that at least eight hours per sprint will be spent on communication, as Scrum involves a series of mandatory meetings lasting one to two hours. You must invest in any case, but the final gain in speed and quality that Scrum provides is very large.
Sprints: Sprint includes four mandatory meetings: planning, implementation, release, and sprint review with a retrospective. Also, short-term meetings (stand-up meetings) are held every day, at which team members in a single format “check the clock” and coordinate their actions. It is impossible to add new tasks to an open sprint – this teaches the team to plan and insures against the emergence of managerial chaos.
Myth 6. Kanban is about boards with tasks hung on them
Not at all! Boards are just the first, easiest step in Kanban. But it is not limited to them. At the heart of Kanban is a complex mathematical apparatus based on statistical data. Therefore, equating Kanban to boards means not looking beyond its facade. In a nutshell, the main point of Kanban is to:
- Make the current workflow transparent and cover all stages – from the emergence of the task in the head of the business to its implementation and shipment of the product to the consumer.
- Manage your workflow, identifying the wasted time and eliminating it. In this way, we make our workflow predictable.
- Make management decisions based on metrics, not sensations.
And it is obvious, that with the need for PPM when implementing Kanban principles, you should have a tool, that provides visibility and control on every stage. PPM Express is a SaaS platform that enables an organization with a full portfolio and project visibility by aggregating project-related information across groups, portfolios, and systems. It’s pride and joy the unmatched visibility levels. The other “selling point” is the level of control over both – portfolios and projects within portfolios available to users.
Myth 7. Scrum and Kanban can be planted in any project and companies
Agile is about working with people. It would be more correct to talk about “instilling” a new philosophy of thinking in the team. At the same time, Scrum and Kanban grafting algorithms are different.
The success rate of using Scrum depends on the company’s corporate culture. In a rigid hierarchical structure, where every piece of paper needs a piece of paper, no efforts to “grow” Scrum will succeed without the support of top management. We’ll have to build a new, parallel structure based on a team approach. A kind of “reserve Agile,” which will protect some of the managers of the highest echelon.
In such conditions, it is possible to show a quick result in three to four months. But there will be a more difficult task ahead – to extend this culture to the whole organization. How long it will last is extremely difficult to assess. But if a new approach has covered 30% of the company, then it begins to spread itself, and it no longer needs protection “from above.”
The implementation of Scrum generally requires major changes, both in the structure of the organization and in contracting with contractors (a time & material contract is needed), and in budgeting (stage-by-stage budgeting), and everything else.
Kanban does not require such a radical change. He suggests: “Start with what you have and start evolving to improve.” The rate of change will be significantly lower than in Scrum, but all changes will be based on statistics and have a clear rationale.
Myth 8. Scrum is designed only for projects that are made from scratch
There are different cases; there is no hard and fast rule that Scrum is intended only for development from scratch. Transferring existing projects to Scrum is not only possible but often advisable. It all depends on the willingness of artists and customers to restructure their work to speed up development. If they are ready, everything is achievable.
For example, Jeff Sutherland one of the creators of Scrum, in his book “Scrum: The Art of Half the Time”, recounted how he applied Scrum to develop an automated FBI data accounting system. When he took up the project, the development was going on for the fourth year, not a single function was brought to release, and neither the end nor the edge was visible to the project. Jeff was able to speed up development and make it transparent to customers drastically.
Six months later, the first working version of the product saw the light, and within two years the development was successfully completed.
Myth 9. When introducing flexible methodologies, conflicts with representatives of the traditional hierarchy are inevitable
If everything is done correctly – separate the team from the traditional hierarchy, give the budget to the owner of the product and hire a truly skilled Scrum master – then there will be no conflicts. But this is not always the case. It is often impossible to combine these two structures, so there is only one way out. You can skip the bureaucracy and get your data free of hustle.
The problem of interaction between agile teams and corporate bureaucracy is that they have different reporting cycles and forms. And because of that teams must report the same thing several times. PPM Express solves this problem. PPM Express is not about building any new structure, but to provide Visibility for different structures in one place.
Major benefits of adopting PPM Express include:
- Adding transparency and flexibility
- Enabling Repeatable Success
- Minimizing Risk
- Maximizing Resources
- Proving the Value to Stakeholders
As a result, you get to foster a collaborative environment, where decision-making is easier and more fruitful. It is also humanely maximizing human resources effectively and allows for the repetitive use of the proven successful project in future initiatives.
Myth 10. – Agile Portfolio Management is impossible
We define a portfolio as a grouping of work under consideration, and that aligns with investment strategies. The active part of the portfolio is funded and possibly underway.
The work that is funded has varied names: Product Release, Program, Initiative, Epic, Project, and even Feature to name a few. If a portfolio is overly complex, it may be “too big” or “too small.”
Artificially ranked work is a sign of too many dependencies. The portfolio may have been sliced artificially. Organizations that make everything the highest priority cannot articulate real priorities.
In the world of infinite demand with constrained capacity, who knows what the true strategy is?
- Operate on “good enough” data.
- No one has detailed data for all portfolio items at the stage decisions need to be made.
- External demand for artificial precision indicates planning is uncoordinated.
- Certain levels of detail in one area do not necessitate expensive-to-obtain detail in other areas.
- Near-term capacity is fixed.5 Simple Rules-01
- We cannot hire and bring knowledge workers up to speed fast enough to influence the outcomes of Portfolio Management for three to six months, at least.
- While there may be exceptions to this rule, they are far rarer than funding managers want to acknowledge.
- Each unique value-based delivery capability has a portfolio.
- An isolated component team can not deliver realizable value without other contributions.
- Subdividing a portfolio further reduces transparency, which undermines the purpose of connecting work to strategy.
- Each portfolio has one “Intake System.”
Strategic decisions in a portfolio should have full visibility into the entire scope of work required to innovate, build, release, evolve, support, and sunset technology.
Agile Portfolio Management employs an Agile mindset to provide real business value:
- Business Value focused
- Shorter releases
- Ability to reprioritize when needed
- Highly transparent
- Rich data
- Quiet when it is going well, noisy when it is not
- The mindset of continuous improvement
- Sustainably more productive
- Happier people
Portfolio management is not going to be Agile if it violates the Values and Principles in the Agile Manifesto. Lean Thinking, such as flow, pull, and eliminating waste, is also important but deserves a treatment separate from this article.
The key to successfully using Agile is based on small, dedicated, persistent, and cross-functional teams. Using teams as planning units and considering them as assets, we can focus on “Return on Team.” This team-based unit of capacity simplifies planning and allows for better alignment with the business strategy.
The rules for agile portfolio management are simple. They help us create a more agile-friendly environment by helping us align ourselves better. Like all rules, they serve as a good starting point. The Agile mindset fosters continuous improvement, so adjusting them based on your experience allows for an evidence-based rationale.
These rules do not encompass the entire scope of Portfolio management, such as considering flow over batch processes. Still, since they help us shape what a good portfolio is, it helps us successfully implement portfolios pragmatically.