The Agile Manifesto (https://agilemanifesto.org) revolutionized software development with its focus on flexibility, collaboration, and delivering value to the customer. But what happens when those Agile principles need to scale to fit the complex needs of a large enterprise? That’s where …
Cryptography (from Ancient Greek κρυπτός “hidden” + γράφω “I write”), as a science of methods ensuring confidentiality, data integrity, authentication, and encryption, serves as one of the most crucial elements enabling modern cryptocurrencies and blockchains.
However, the cryptographic methods in use today are nothing but the result of an incredibly long history of development. After all, people have been using cryptography to transmit information securely since ancient times.
Ancient Roots of Cryptography
Cryptographic methods have been used since ancient times, with early civilizations using symbol substitution as the primary form of encryption. The earliest example of symbol substitution was found in the tomb of Khnumhotep II, an Egyptian nobleman who lived 3900 years ago. It was used to enhance the linguistic appeal of his name rather than to conceal information.
Around 3500 years ago, Mesopotamian scribes began using cryptography to protect confidential information, such as concealing the formula for pottery glaze on clay tablets.
Cryptography was widely used in later periods, including Ancient Greece, where messages were encrypted using parchment and cylinders.
Romans achieved advanced cryptography with a shift of letters by a certain number of places in the Latin alphabet for encryption and decryption.
Development in the Middle Ages and the Renaissance
In the Middle Ages, cryptography gained significant importance, with substitution ciphers like Caesar’s cipher being widely used.
However, cryptanalysis—the science of codebreaking—had already begun to develop, necessitating more complex cryptography. Around 800 CE, the Arab mathematician Al-Kindi introduced frequency analysis, making substitution ciphers vulnerable to decryption.
In response, in 1465, Leon Battista Alberti developed the polyalphabetic cipher, using two different alphabets for encoding, making frequency analysis ineffective. This significantly increased the security of encrypted information.
Additionally, during the Renaissance, new encoding methods emerged, including the biliteral cipher, invented by Sir Francis Bacon in 1623.
Achievements of the Last Centuries
Cryptography, as a science, continued to progress over the centuries. A major breakthrough in cryptography was described by Thomas Jefferson in the 1790s. His invention, known as the “Jefferson disk,” consisted of 36 letter rings on rotating wheels that could be used for complex encoding. This concept was so advanced that it served as the basis for American military cryptography up to World War II.
An excellent example of analog cryptography in World War II is the portable Enigma encryption machine. Similar to the wheel cipher, this device had rotating wheels for message encoding, making the message practically unreadable without another Enigma.
Cryptography in the Computer Era
The advent of computers led to significant progress in cryptography compared to earlier analog methods. Modern encryption is based on robust 128-bit mathematical encryption, surpassing the security of ancient and medieval ciphers. In the 1990s, computer scientists began developing quantum cryptography as a new form of encryption to further enhance security.
Cryptography has played a crucial role in the creation of cryptocurrencies. Technologies like hash functions, public-key cryptography, and digital signatures are used to protect data stored in blockchains and authenticate transactions. Cryptocurrencies, such as Bitcoin, use the Elliptic Curve Digital Signature Algorithm (ECDSA) to enhance security, ensuring that access to funds can only be obtained by an authorized user.
Cryptography has made significant progress over the last 4000 years and shows no signs of stopping. As long as there is a need to protect confidential information, cryptography will continue to evolve. Although cryptographic systems used in modern blockchains represent cutting-edge technologies, they are based on a rich historical tradition that traces its roots back to the history of humanity.
The term Web3 (also known as Web 3.0) is now familiar to many. What is it? Let’s delve into it.
The term “Web 3.0” was first introduced by Ethereum co-founder Gavin Wood, immediately after the launch of the Ethereum cryptocurrency in 2014. At that time, Gavin expressed the aspirations of many users who did not trust large private companies controlling the Internet.
Timothy John Berners-Lee, the developer who created the World Wide Web, described Web3 as a semantic web. He envisioned it as an intelligent, self-sufficient, and open Internet that uses artificial intelligence (AI) and machine learning (ML) to function as a “global brain” and interpret content conceptually and contextually.
Before moving forward, let’s take a quick look at the recent past and understand what Web 1.0 and Web 2.0 are.
Web 1.0: Read-Only (1990-2004)
The Web 1.0 era spans from 1990 to 2004, after Timothy John Berners-Lee developed the protocols on which the World Wide Web subsequently operated. Websites were mostly static, owned by various companies, and interaction between users and websites was almost nonexistent.
Web 2.0: Read-Write (2004-Present)
The Web 2.0 era began in 2004 with the emergence of various social networking platforms. These platforms provided users with the ability to publish and exchange their content and interact with each other. During this period, more people actively started using the Internet, and a few major companies took control of a significant portion of the traffic, dictating their terms. The model emerged where revenue was generated through advertising. Users created content but did not own it or always monetize it, unlike large companies controlling social platforms.
Web 3.0: Read-Write-Own
Web 3.0 has become the accepted term for defining a new and, according to its creators, a better Internet. Essentially, Web 3.0 uses blockchains, cryptocurrencies, and NFTs, providing users with ownership of their content.
Key ideas of Web 3.0 include:
Decentralization: Instead of large centralized organizations controlling and owning most of the traffic, content creators and users own it.
No permissions required: Everyone has an equal right to access and use Web 3.0.
Own payments: In contrast to the often-centralized infrastructure of banks and payment systems, cryptocurrency is used for payments and transfers on the Internet.
Web 3.0 is anonymous and better protects personal data: Various technical means are used to store data in the user’s crypto wallet, not in third-party data centers.
Drawbacks of Web3
Unacceptable content: Some experts see a danger in decentralization as it opens access to almost all content without control and moderation, some of which may be unsafe or unacceptable.
Technical means: To make the technology accessible to a larger number of people worldwide, the capabilities and quality of user devices need to be expanded.
Novelty of technologies: Web3 technologies and products are relatively new and not always ready for mass adoption.
What’s Next and What Are the Perspectives of Web3?
Some experts consider Web3 a bubble, while others call it the future of the Internet.
According to various sources, around 20,000 developers were working on Web3 in 2022, and fintech organizations are already implementing and integrating these solutions.
Here is a non-exhaustive list of Web3 technologies and products used globally:
InterPlanetary File System Protocol (IPFS): A peer-to-peer distributed file system that connects all computing devices into a single file system.
DeFi wallet: A decentralized wallet where you are the sole owner of your wallet and crypto assets.
Brave: A web browser based on the Chromium browser with an open-source code, announced by the co-founder of Mozilla Project and creator of JavaScript, Brendan Eich.
Unstoppable Domains: A service that ties a specific user domain to addresses of your crypto wallets.
DTube: A decentralized video service on the blockchain rather than a central server.
Secretum: A decentralized application for exchanging encrypted messages built on the Solana blockchain platform.
Sapien: A decentralized social news platform.
IDEX: A decentralized smart contract exchange based on Ethereum supporting real-time trading.
In Conclusion
Web3 is young and actively evolving. It’s already here, and it seems to be here to stay.
Decentralization, security, and transparency will contribute to the development of Web3. Perhaps, at this very moment, we are witnessing the birth and establishment of a better Internet.
Dependency is a potential obstacle that slows down or blocks the work of a Scrum Team.
There are three main categories of dependencies that a Scrum Team encounters, and each category of dependencies differs in complexity.
1. Intra-team Dependencies
The least complex scenario of dependency is when one team possesses all the skills needed to create a backlog item (PBI) that is potentially ready for deployment. The team has no external dependencies. However, team members may still face:
Backlog items dependent on each other, and/or
Tasks in the sprint that depend on each other.
In any case, a self-managing team with a skilled Scrum Master should be able to understand these dependencies independently. If such dependencies are identified, developers clarify technical dependencies to the Product Owner (PO), and the Product Owner uses this information to reorder the product backlog. Regarding dependencies between tasks in a sprint, developers are responsible for coordinating actions on these tasks.
What can help:
Rework and decompose backlog items to make them more independent. This is best done before sprint planning, during Refinement, but can also be done during sprint planning.
When planning a sprint, it’s essential to understand potential risks created by dependencies and agree on how they will be resolved. For example, the choice between Path A or B for Element 2 cannot be implemented until Element 1 is completed. Carefully monitor these dependencies during the sprint.
2. Inter-team Dependencies
The next, more complex category is inter-team dependency, arising in a multi-team environment where more than one team works on the same product. Each team can take and deliver product backlog items as they complete them, but control over the sequence of delivery or technical coordination between teams may be required.
You can start with something simple – coordination between self-managing teams.
What can help:
To minimize conflicting information, there should be only one Product Owner.
Ensure that the Product Owner works with teams and understands how to distribute work. For example, if you assign all high-priority tasks to Team A and lower-priority tasks to Team B, it may result in less value if Team A fails, compared to a situation where both teams work on tasks with the same priority.
Choose one or two representatives from each dependent team as representatives. These representatives will be responsible for coordinating with representatives from other teams. This activity will be carried out within the Scrum of Scrums – a regular meeting aimed at exchanging information and solving coordination issues between teams.
Using Scrum of Scrums, team representatives can also coordinate actions before and after sprint planning and Sprint Review.
Remember that Sprint Review is open to any interested party, and members of dependent teams may attend. Don’t forget to invite them.
3. External Dependencies
This is the most complex case – when the Scrum Team cannot complete all the work required to deliver a sprint backlog item. They need help or support from:
Another Scrum Team,
Another department, or
An external supplier.
Do the external parties on which the team depends practice Agile and Scrum?
If yes, they understand what is expected of them, and you can coordinate work plans at the product backlog level.
If not, and you cannot change this yet, the Scrum Team will have to plan its work according to the schedules of external parties. Ensure that tasks for monitoring and working with these dependencies are included in the team’s capacity.
What can help:
Request delivery confirmations from external parties. Get information on work volumes and specific dates.
Monitor the situation. Invite external representatives to the team’s daily Scrum meetings. Regularly check the agreed delivery schedule. Instead of checking the progress of work, periodically ask: “Are there any reasons why you cannot meet your commitments?”
Conduct a Retrospective on the performance of the external party. Were they reliable? Can you rely on them to deliver what they promised on time? If not, what will you do differently next time to reduce risks?
Finally, do not add a task to the sprint if there is an external dependency without specific delivery commitments. Since this is a business issue, Product Owners must be fully engaged and obligated to provide any assistance needed to manage the external party or another department in your organization. Product Owners have the authority and levers that can be very effective when used correctly.
Remember that dependencies can disrupt the continuous delivery of value. Do not think of dependencies as just how things are but instead consider them as potential obstacles and make efforts to eliminate or mitigate their impact.
One of the most significant challenges for entrepreneurs is how to turn their ideas into plans. You might have a good idea, but describing and working through it can be much more complicated. From ideas for a new business to creating a cohesive plan and concepts for new products and services, it can take weeks or even months.
Lean Canvas is a planning method that helps you understand the essence of your idea. This method places all the information on one page, helping to outline the necessary key points without unnecessary details.
What is Lean Canvas?
Lean Canvas, the “Lean Business Model Canvas,” is a one-page business plan method created by Ash Maurya, adapted from Alexander Osterwalder’s Business Model Canvas.
The plan has several blocks that will help you mark key points to transform your business idea into something more concrete.
Lean Canvas is specifically designed for entrepreneurs to make it easier for them to get a clear and straightforward idea of what they plan to implement.
Structure of Lean Canvas
Below are the sections of Lean Canvas with explanations:
Customer Segments: Understanding who your customers are is a crucial step. You can’t understand their primary problems if you don’t know who they are. In the “Customer Segments” section, you need to identify who your target audience is, which may include several customer segments.
Problem: It’s essential to understand the key problems your customers face. This section is used to list the main problems you intend to solve, faced by customers from different segments.
Revenue Streams: Where will your money come from? How do you plan to set prices for your products or services? Your pricing model is a crucial part of what you offer, and you’ll need to study and test it. How much are people willing to pay, and what is the minimum price you can set to achieve your goals?
Solution: What solution to your customers’ problems do you plan to offer? You won’t always have the perfect solution immediately, but the goal of creating a business plan is to help you start this work. If you want to find a solution to your problem, don’t assume it will come to you. Talk to your customers from different segments to find out what they want and need.
Unique Value Proposition: This section is in the middle of the page because it’s what you offer your customers. It specifies the unique value your business can provide. You need to think about what sets your brand, product, or service apart from others trying to solve the same problems as you.
Channels: What channels do you plan to use to attract customers? These are marketing and advertising methods you plan to use, from digital marketing such as SEO to more traditional channels like radio, print, and television. Remember that different generations use different communication channels.
Key Metrics: Your key metrics are what you will use to monitor the effectiveness of your business. You can identify some key indicators that you will closely monitor to understand how people interact with and use your business and its products or services.
Cost Structure: These are the costs your business will incur to launch and sell your product or service. This may include market research, technology, personnel expenses, and more. Having an idea of your one-time and periodic expenses, you can roughly estimate how many customers you will need to break even.
Unfair Advantage: Your unfair advantage is what you have that none of your competitors do. It’s something that can’t be copied or bought and will help you stand out. This is the final step in the process and often the most challenging. Your unfair advantage can be many things, from unbeatable personnel to an existing customer base.
You don’t need to spend hours filling out Lean Canvas. In fact, you should be able to outline some ideas in about 20 minutes. Of course, you won’t have all the necessary information immediately. But this plan will help you determine whether your business idea is justified and what your next steps should be.
And don’t forget that Lean Canvas is a flexible plan that can be adjusted later on.
If you work in an organization that is adopting or has already adopted Agile, you may have come across terms like Squad, Tribe, Chapter, and so on.
These names are not mentioned in the Scrum Guide, and it’s not entirely clear where they come from.
In reality, these are terms from the Agile model used by Spotify.
Spotify, a streaming service founded in 2006, allowing legal streaming of music, audiobooks, and podcasts without downloading them to the device.
Spotify is a 100% Agile company that started with the Scrum framework. However, as their teams grew, they noticed that some elements of the Scrum framework didn’t work for them. Therefore, they decided to change some Scrum roles, artifacts, and events.
Spotify’s engineers understood that Agile is more important than Scrum, and principles are more critical than specific practices. As a result, they renamed the Scrum Master to Agile Coach because they wanted more of a “serving leader” than “process masters.” They also renamed Scrum teams to Squads, and so on.
The structure used by the company for the flexible scaling of different teams located in different places became known as the Spotify model.
Squad
A Squad is a small, cross-functional, self-organizing team, usually consisting of fewer than eight people. Team members have overlapping responsibilities, and they work together to achieve their long-term mission. Autonomy is a key factor in Squads. The team doesn’t have a separate team lead, but there is a dedicated Product Owner.
Each Squad decides independently what to develop, how to develop it, and how to work together during development. However, the Squad must operate in line with the Squad’s mission, product strategy, and short-term goals.
How Squads Work at Spotify?
As Spotify has many different Squads, they needed to create some structure. Each Squad is grouped into a Tribe, which has a head. In this setup, you can change the composition without changing the manager. They also have a Guild, representing an interest community that uses a mailing list or another informal method of communication within Spotify.
Now, a bit more detail about the Spotify structure.
Tribe
A Tribe is a group of Squads linked by the nature of the work they perform. For example, several groups working together on the same product function or closely related product functions/one product in the portfolio of different products.
The recommended number of people in a Tribe, according to Dunbar’s number, is about 100. Dunbar’s number is a hypothetical limit on the number of stable social relationships that can be maintained, depending on the volume of the neocortex. According to Dunbar’s calculations, it was considered to be 150.
In a Tribe, there is a Tribe Lead responsible for creating a productive and innovative environment for Squads. The Tribe Lead may also be part of a Squad.
Chapter
A Chapter brings together specialists in specific disciplines/technological areas within a Tribe. For example, QA engineers, database specialists, front-end and back-end developers, UX/UI specialists. People performing these functions in several Squads of one Tribe come together in a Chapter.
Each Chapter regularly meets to discuss its achievements and issues in their respective knowledge areas, for example, QA Chapter, UX Chapter, DB Chapter.
In a Chapter, there is a Chapter Lead who can guide different Chapter members on “how” best to accomplish a task. The Chapter Lead can also be the direct manager of Chapter members, performing traditional managerial duties such as people development, career growth, etc. The Chapter Lead is also a member of one of the Squads in the Tribe, allowing them to understand issues from within.
All Chapter Leads in a Tribe usually report to the Tribe Lead, and the Tribe Lead performs all managerial duties for Chapter Leads in their Tribe.
Guild
A Guild is like an “interest community” covering Tribes throughout the organization, where people gather and share knowledge in a specific area.
Imagine an organization with three Tribes, each located in three different places. Depending on the location, each Tribe may have its QA Chapter. It is necessary for the members of the QA Chapter of one Tribe to exchange processes and knowledge with the members of the QA Chapter of the other two Tribes. The Guild serves precisely this purpose.
Henrik Kniberg, one of the contributors to the development of the way of working within Spotify, in response to the growing popularity of the Spotify model and its copying in other companies, claimed that the Spotify model is not a team scaling framework. Also, he stated that the Spotify model is not strictly a “model” as such but rather an example of how work is organized in a specific company.
Since its inception in 2015, the PMI Talent Triangle has constantly evolved, reflecting changes in project management.
Published in early 2022, the new PMI Talent Triangle reflects the realities of the modern market. Project leaders must assess:
Project needs
Organizational culture
Skills of their project team
To help project management professionals navigate this changing world and employ more effective ways of working, PMI has updated the facets of the PMI Talent Triangle. This allows professionals to focus on:
Ways of Working
Whether it’s forecasting, flexibility, design thinking, or new methods yet to be developed, it’s clear that there is more than one way to get the job done today. That’s why PMI encourages professionals to master as many ways of working as possible so that they can apply the right technique at the right time and achieve successful results.
Power Skills
These interpersonal communication skills include collaborative leadership, communication, innovative thinking, determination, and empathy. Teams possessing these skills can maintain influence over stakeholders, which is critical when managing changes.
Business Acumen
Professionals with business acumen understand the macro- and micro-impacts in their organization and industry and possess functional or subject matter expertise to make the right decisions. Professionals at all levels must be able to cultivate effective decision-making and understand how their projects align with the overall picture of organizational strategy and global trends.
In project management, the work environment is dynamic and often tense. For this reason, various conflicts are unfortunately a common occurrence. If you are managing projects, it’s crucial to understand how important it is to manage conflicts.
What is Conflict?
Conflict is a clash of opinions between disagreeing parties, which can be individuals or organizations, in resolving various issues.
Conflict management is the process of timely identifying and resolving conflicts that arise during project implementation. Conflict management is one of the key tasks of project managers.
Types of Conflicts: Constructive and Non-Constructive
Constructive Conflicts: These conflicts lead to well-founded decisions and contribute to the development of relationships between conflict parties.
Non-constructive Conflicts: These conflicts hinder making informed decisions and effective interaction between conflict parties.
Thomas-Kilmann Model
The Thomas-Kilmann model defines five different conflict resolution techniques. The model is based on two parameters: assertiveness level and cooperation level.
Competition
Involves making opponents accept one’s point of view by ignoring their opinion. This behavior can be effective in conflict resolution but might suppress team members’ initiatives.
Avoidance
Involves avoiding conflicts in any situation. The side effect of this approach is low initiative among team members, possibly resulting in the absence of an optimal solution to tasks.
Compromise
Is an approach where conflicting parties partially accept each other’s decisions. This allows quickly reducing conflict intensity but may lead to suboptimal decisions.
Collaboration
Helps resolve conflict situations most effectively. Opponents must be open to dialogue and strive to understand each other’s reasons for disagreement. This approach aids in developing the best solution to the problem.
Accommodation
Is an approach where one party unconditionally accepts the opponent’s opinion, disregarding its own. In this situation, conflicts may accumulate and eventually escalate into a more serious confrontation.
Conclusion
The most productive way to end a conflict is through collaboration, where both opponents gain something. Unlike compromise, where each party is forced to make concessions, collaboration’s main task is to find a solution that fully satisfies everyone.
And most importantly, remember that conflict is a kind of progress engine.
“As a whole, humanity will never be able to completely get rid of conflicts,” says historian-political scientist Elina Zurapova. “It is, if you will, a kind of driving force, an ‘impetus.’ It is that cargo on the scales that mai
We all know that one of the four values of the Agile Manifesto states:
“Responding to change over following a plan.”
However, this doesn’t mean that if we work with Agile, we don’t plan at all.
Here’s what is stated:
So, without denying the importance of what’s on the right,
we still value more what’s on the left.
Thus, planning your work is an important and integral part of Agile.
Characteristics of Agile Project Planning
Let’s explore different levels of planning mentioned in the “Agile Planning Onion.”
It’s crucial to understand that Agile planning is applicable at every layer of the “onion.”
We use planning not only at the team level (daily, iteration, release) but also for product management, portfolio management, and Agile strategy management.
In the Scrum framework, Agile planning is iterative. This means that we develop and adjust our plan at the beginning of each sprint. The goal is to invest time in planning at the optimal moment and easily adapt to changes during the execution phase.
However, besides this, there’s top-level planning, preparing a product roadmap at the very beginning, outlining major releases and corresponding features. This is also planning, though at a higher level.
After top-level planning and initial task estimation based on teams’ Velocity information, we can forecast the time required for tasks or the entire project.
Planning in Scaled Agile Environments
In scalable Agile frameworks, planning is more extensive.
Let’s take SAFe as an example, with an event called PI (Program Increment) Planning.
PI Planning is a face-to-face event based on a cadence, a regular event that serves as the “heart” for the Agile Release Train (ART), unifying all teams with a common mission and vision in the ART. PI Planning is crucial for SAFe; it’s considered that if you’re not doing it, you’re not doing SAFe.
“Those who do the work plan the work.”
Offline planning has its advantages, and the unwritten SAFe “rule” is: “Those who do the work plan the work.”
However, when physical presence is impossible for all participants, as seen during COVID-19, technical means for virtual meetings can be utilized. Many teams have successfully created a hybrid situation where several teams join both online and offline.
A Bit More Detail on PI Planning
PI Planning has a standard agenda, including a presentation of business context and vision, followed by group planning where teams create their iteration plans and goals for the upcoming Program Increment (PI). Teams specify when they’ll complete the discussed tasks.
All teams’ members participate in this event within the Innovation and Planning (IP) Iteration.
PI Planning extends for two full days. If participants are in multiple time zones, this time is often extended.
Business Benefits of PI Planning
PI Planning provides numerous benefits for business, including:
Establishing direct communication among all team members and stakeholders
Aligning development stages with business goals, context, vision, and team and program goals
Identifying dependencies and engaging teams in collaboration
Aligning requirements and team performance, eliminating redundant work
Facilitating quick decision-making.
Participants
PI Planning is a significant event that requires preparation, coordination, and communication.
Among the participants: business owners, product managers, Agile teams, architects/system engineers, and other stakeholders.
PO Sync is a time-limited (usually 30-60 minutes) weekly or more frequent meeting whose goal is to synchronize the Product Owners of individual teams in achieving common objectives.
In “The Scrum Guide,” this meeting is not mentioned and, accordingly, is not one of the Scrum ceremonies. Nevertheless, in some organizations working with Scrum, this ceremony is conducted.
PO Sync is used in scalable Agile frameworks, such as SAFe or Scrum at Scale.
PO Sync is somewhat similar to Scrum of Scrums (SoS), but the participants are Product Owners and Product Managers.
In SAFe, the organizer of this meeting can be the Release Train Engineer (RTE) or the Product Manager.
Among the discussed topics:
Functionality, performance, and compatibility
Work volume and schedule adjustments
Task prioritization
Checking task prioritization in team backlogs
Coordination and identification of interdependencies between teams
Team progress in task implementation
Task decomposition to align with the release
Definition of MVP (Minimum Viable Product)
Plan for subsequent actions
In SAFe, this meeting is mandatory. Sometimes PO Sync and SoS are combined, and such a meeting is called ART Sync.
Is it worth conducting PO Sync in organizations using Scrum or, for example, Kanban?
It all depends on the goals and tasks set by the Agile Office/PMO. If the purpose of these meetings is clear, participants and the agenda are defined, then why not. Otherwise, it will complicate processes and be a waste of time for all participants.
Let’s not forget about one of the values of Agile:
Individuals and interactions are more important than processes and tools.