Agile, Methodology, Scrum, Software Development Insights, USA

Certified Scrum Product Owner

March 15, 2020October 2, 2021 Bjørn T. Nøstdahl

Having worked as a product owner for years, I finally decided to take things to take the next level with a certification training known as a Certified Scrum Product Owner.

A CSPO course is an interactive course that would last for two 8-hour days. During this course, we learned basic things about the scope of Scrum and the functions of a Scrum Product Owner. We were taught using case studies, exercises, and discussions. More importantly, topically treated included how to identify user needs, backlog, how to manage stakeholders, an overview of sizing in Scrum and how to create, maintain and order a product.

The CSPO Training was conducted by Chris Sims. He’s a certified scrum product owner, agile coach and C++ expert that helps companies run efficiently and happily. He’s also the founder of Agile Learning Labs and a co-author for two best-sellers, namely; The Elements of Scrum and Scrum: a Breathtakingly Brief and Agile Introduction.

The CSPO training session was held in Silicon Valley, midway between San Francisco and San Jose, at the Seaport Conference Center. The facilities here were perfect for the setting of the training, and as a bonus, we got to see the towing of a drug houseboat (that was our theory at least).

seaport

A Scrum Master works to help an inexperienced team get familiar with the operations and effects of Scrum. In comparison, a Product Owner Owner priority is to make sure that customers are satisfied with the quality of service they get and usually helps to create the product vision or order for a Product Backlog.

At the end of the training, a CSPO is equipped with the skills to serves as a product owner in a scrum team. The role of the product owner is vital to make sure that the product can offer the desired amount of satisfaction to the customer when required. This is possible for him in a number of ways if you consider the resources available at his disposals such as the team, business stakeholders and the development process adopted by the organization.

A CSPO is trained to take on the role of the product owner in a scrum team. The product owner is a vital element in ensuring that the product can offer optimal value to the customer in a timely manner. He can achieve this in a number of ways if you take factors such as the team, business stakeholders and the development process of the organization.

The responsibilities of a CSPO

The first is the development and writing of the product vision. To do this, he’s to work with a clear mind about the functions and benefits of the product to the consumer. It also includes writing a list of product features. Basically, product features are product requirements written from the user’s perspective. These features are usually written as a detailed description of the capability of the product in the hands of the customer.

The CSPO also helps to compile a list of features into the Product Backlog. It’s important that the product owner has the ability to make the team understand the scope of the project and work together to get things done. He also reviews, tests, and assesses the final product. A CSPO can also request changes to the product if there are any issues with it.

Getting a Certified Scrum Product Owner® (CSPO®) certification exposes anyone to a lot of benefits. Firstly, the CSPO certification will expose you to more career opportunities and it becomes easier to work in different industry sectors that adopt the use of Agile. This will expose any expert to different companies and occupational positions. Also, it shows that your expert in Scrum. This way, it’s easier for you to let your employees and team members know of your capabilities.

On another note, the certification will teach you the history of the Scrum Foundation and the role of a Product Owner. The classes to train you for the certification will orientate you on the roles and duties of a product owner. It also takes you into close contact with Agile practitioners who want to improve their skill level. A CSPO certification is a sign of a product owner’s reliability.

Scrum teams operate at a level of efficiency and speed that may be a problem for traditional product management. Learn about the skills adopted by product owners to lead their team and achieve optimal results. Anyone who takes part in a CSPO training will be a part of exercises and simulations related to Business value estimation, Product strategy, an overview of product owner role, Release planning, Effective communication with stakeholders, story splitting, acceptance criteria, user stories, product strategy, lean product discovery and Artifacts including burn charts.

Working with Scrum for quite a few years now, I have assembled a set of methodologies and syntaxes on how to write good requirements for your team. Below I will share the requirement format and lifecycle I use in my daily work, and I hope it will help you too working in an Agile team.

Epic

Software development teams work on very complicated projects. It is crucial to understand every requirement and feature required by the customer.

An epic is a large body of work broken down into several tasks or small user stories. It always denotes a high-level descriptive version of the client’s requirements. As epic is the description of the user’s needs, its scope is expected to change over time. Hence, Epics are always shipped in the form of sprints across teams. While, Epics often encompass multiple teams on multiple projects, and can even be tracked on numerous boards. Moreover, epics help the team break down a main project’s work into shippable pieces without disturbing the main project’s delivery to the customer.

Format

For a <persona> who <has a painpoint> the <product or solution> is a <type of solution> that <solves an issue in a certain way> unlike <the old solution or competitor> our solution <has ceirtain advantages>

Acceptance Criteria

Success criteria <> Acceptance criteria <> In scope <> Out of scope <>

Lifecycle

An Epic can only be created and moved into the backlog by the Product Owner. When all sub-tasks are Resolved, the Epic can be resolved. When the functionality of the Epic is delivered to the end customer, the Epic will be Closed. It is a complicated task to create an Epic. The following steps should be followed to develop an agile epic.

They are starting with the user Recording / Reporting, which includes drafting the epic for project managers and the team. Second, comes the Description where the process of achieving the proposed project is described. Next is the Epic Culture, which denotes the epic team’s size based on the company culture. Finally, the most important one is the Timeline or Time Frame, where the team decides on how long they take to complete the project.

Feature

When a developer team develops one extensive software system, there will be lots of requirements gathered from the customer to understand what is precisely the customer’s requirement. The customer might not have an understanding of how the gathered requirements are used, but the development team knows that these requirements are finally the features of the system being developed.

A feature is a small, distinguishing characteristic of a software item, which is also a client-valued function. Features are small and typically can be implemented within a sprint. When we describe a feature, we use the same format as a User Story, but with a broader scope.

Format

As a <particular class of user> , I want to <be able to perform/do something> so that <I get some form of value or benefit>

Lifecycle

A Feature can only be created and moved into the backlog by the Product Owner. When all sub-tasks are Resolved, the Feature can be resolved. When the functionality of the Feature is delivered to the end customer, the Feature will be Closed.

A feature can be added to a system as per the customer’s requirement even after development is completed or during the development phase. The user creates a feature, and the features are added to the features inbox. The product team sorts the features and adds them to a feature list for the feature team for elaboration. The feature manager contacts the appointed teams to start inspections. After implementing the feature by the engineering team, it is added to the release tracking page, and once it is completed, the QA team will carry out the final testing. The feedback team starts feedback gathering, and the feature moves to Aurora and Beta. Finally, the feature is released.

User Story

When working on a complex project, the development team must ensure that they have fully understood the customer’s requirements.

In software development and product management, a user story is an informal, natural language description of a software system’s features. User stories are often written from the perspective of an end-user or user of a system. Furthermore, user stories break down the big picture into epics that are more user-focused and in a way that the engineering team clearly understands the product requirements.

Format

As a <particular class of user> , I want to <be able to perform/do something> so that <I get some form of value or benefit>

Acceptance Criteria

Given <some context> When <some action is carried out> Then <a particular set of observable consequences should obtain>

Lifecycle

A User Story can only be created and moved into the backlog by the Product Owner. When all sub-tasks are Resolved, the User Story can be resolved. When the functionality of the User Story is delivered to the end customer, the User Story will be Closed.

The stakeholder gives the idea in the form of a change request or new functionality, captured by the product owner as a business request, and creates the user story. Then the user story is added to the backlog, and with the help of the sprint team, it is groomed by the product owner. The user story is then broken down into acceptance criteria for prioritization. However, whether the owner accepts or rejects the story depends on the acceptance criteria. Finally, the user story is recognized as complete and closed and returned to the backlog for future iterations.

Task Story

The Task Story work item is more technical than an agile User Story. Instead of forcing the User Story format, it is better to use a Feature-driven development (FDD) process, describing what is expected more technically. FDD blends several industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality perspective where its primary purpose is to deliver tangible, working software repeatedly on time.

Format

<action> the <result> by/for/of/to a(n) <object>

Example: Send the Push Notification to a Phone

Acceptance Criteria

Given <some context> When <some action is carried out> Then <a particular set of observable consequences should obtain>

Lifecycle

A Task Story can only be created and moved into the backlog by the Product Owner. When all sub-tasks are Resolved, Task Story can be resolved. When the functionality of the Task Story is delivered to the end customer, the Task Story will be Closed.

Bug

Any software development team can come across faults in the product they are working on, and these faults are identified in the testing phase.

Errors, flaw, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or behave in unintended ways is called a software bug. The process of finding and fixing bugs is termed “debugging” and often uses formal techniques or tools to pinpoint bugs, and since the 1950s, some computer systems have been designed to also deter, detect or auto-correct various computer bugs during operations.

Format

Found in <module> summary <short description> reproduced by <reproduction steps> result <what happened> expected <what was expected to happen>

Lifecycle

The Bug work item can be created by anyone but is usually made by QA or Operations via a customer. When the bug is fixed, it should not be closed until confirmed by the creator.

There are six stages in the bug life cycle. When the bug is created and yet to be approved, it is in its New stage. Next, it is Assigned to a development team. Now the development team starts to work to fix the defect. When the developer fixes the bug by making necessary changes to the code and verifying them, it can be marked as Fixed. When the code is in the fixed state, it is given to a tester to retest until the tester tests the code in a state called the Pending Retest. Once the tester has tested the code to see if the developer has successfully fixed the defect, the status is changed to Retest.

Spike

Although we have epics and user stories to break down complex projects and make it understandable to the engineers, there can still be confusion.

A Spike aims at gathering information to sort out the unclear sections the team comes across in the user stories. A spike can be known as research, architectural, or refactoring spike. When the group comes across such confusing situations, they have to create a functional or technical experiment to evaluate. It can be any type of research the team does, the final goal is to solve unclear requirements.

Format

In order to <achieve some goal> a <system or persona> needs to <perform some some action>

Example: In order to estimate the “push notification” story a developer needs to research if Azure services meets the requirements.

Lifecycle

A Spike can be created by anyone, but can only be moved into the backlog by the Product Owner. The print team has the responsibility to create acceptance criteria. When Spike’s goal is met, it can be Resolved or Closed, depending on the owner’s decision.

Task

Stories are written in a way that is easy to understand by the customer, and there are no technical terms or instructions related to development. Now the story has to be converted to a detailed instruction list that is easy to understand by the developer.

A Task is a piece of work for the developers or any other team member. It gives the developer an idea about what should be done during development, such as creating tests, designing something, adding codes, the features that should be automated, etc.

Format

There is no specific format for a task, it can be written in the format of a note or a todo list.

Lifecycle

A task can be created by anyone, but it is typically created by a developer as a child to a User Story or a Task Story.

A New task can be Created as a user action or part of process execution, and Candidates are set to groups of people. Next, individuals are directly Assigned as a part of process execution or if requested by API. Sometimes an assignee might want to Delegate a part of the work. Once the requested work is resolved the assignee will want to pass the work back to the original owner. Finally, the task is Completed.

Issue

An Issue is a description of an idea or a problem. It also can be outlined as an improvement that should take place in the product. If resolved, it would increase the value of the final product or reduce waste in development time.

Format

There is no specific format for an issue, it is more like a note and can be written in the format of a User Story or Spike.

Lifecycle

Anyone can create an Issue, but only the Product Owner can convert it into a User Story or a Spike and put it into the backlog. The life cycle of work can be defined by setting an issue workflow as follows:

When an issue is created, the time is taken to resolve, it will be decided to depend on the issue’s size. When an issue is created, it is in its Open state. Usually, a QA will create an issue and assign it to a developer who can solve it. When the programmer is working on resolving the issue, it is in its In Progres state. After the issue is solved, it goes to the Resolved state. An issue can go to its Closed state only if the creator is happy with it. However, when an issue goes to its closed stage, it does not mean that it is completely solved, but there can be chances for it to arise again. Then the issue is Reopened, and the same process takes place to figure out the issue and fix it.

Concluding this post, I want to say that Chris’ training skills were at the top level and all of his stories about Silicon Valley, how he started Agile Learning Labs, and his career as a product owner, engineering manager, scrum owner, software engineer, musician, and auto mechanic – and there were impressive lunchtime discussions.

To learn more about the role of a product owner, you can contact me at bjorn.nostdahl@nostdahl.com.

There’s more information about agile in my articles on Social Agility and Agile and Scrum Methodology Workshop.

Agile, Customer Journey, Innovation, Methodology, Reflections, Software Development Insights, User Experience (UX)

Customer Experience and Customer Journey Mapping

November 17, 2019November 23, 2019 Bjørn T. Nøstdahl

After working in Sweden for 5-6 years I took the train from Gothenburg to Stockholm for the first time to attend a workshop on Customer Experience and Customer Journey Mapping. Since commuting across the country was a new experience for me, I chose to be 30min early for the train only to find the doors of the coach locked. Standing outside freezing, I took the time to find my ticket. I had received an SMS with my details a few days earlier, but to my surprise it said: “This is not your ticket”. So my customer experience with SJ prior to arriving at the Customer Experience and Customer Journey Mapping workshop wasn’t really a superb one.

While puffing and rumbling through the Swedish countryside, I had some time to prepare for the days to come. As a Product Owner it is of course imperative for me to understand everything about our product to deliver impeccable features and functionality to our customer. However in a complex market the complete customer journey has become more important the recent years and my expectations for the next two days was to gain insights of processes and tools on how to improve my work on Customer Experience and the full Customer Journey when purchasing our services.

The workshop kicked off with an introduction of the participants and their roles, following a thorough explanation of what Customer Experience and Customer Journey Mapping is. The workshop was divided into six parts, all aiming to make content customers and employees: Strategy, Insights, Design, Measurement, Management and Culture.

The way to interact with customers and the focus on customer experience has significantly changed during the last 100 years. Back in 1913 when Woodrow Wilson was president, and USA went through the Progressive Era the focus was mostly on the product itself. However in the 1950’s the focus moved more towards the american dream and a very strong brand focus and transitioning into stronger customer relations through the 1970’s and 1980’s.

The focus on Customer Experience as we know is today started for real around the millennium, where new technology became available to both understand and interact with the customer. Also the consumers matured and expected more than just a product, introducing terminology like retailtainment and entertainmerce.

At its core, Customer Journey Mapping is a methodology that enable insight and understanding of customer’s with the aim of developing products or services that support innovation and business development through earning the satisfaction and loyalty of your customers. In a nutshell, I would call it a form of result oriented customer service.

The workshop was tailored to serve a wide range of people, specifically people responsible for customer experience, others were business managers, business developers, support and customer service managers, marketing managers and marketers, strategists, and product owners. Learning about Customer Experience together availed is the opportunity to create connections and offer each other insights relating to our various fields.

Customer Experience Management is a strategy, methodology and process to manage a customers exposure, interaction and transaction with a corporation, a product/service and a brand. The discipline that is about developing service and business models that prioritize the customer in all of the company’s business processes, thus creating favorable conditions for growth. One of the fundamental aspects of CX is taking time to understanding the customer’s experience and contact points with your company. It involves careful documentation and recording of all forms of contact between a customer and the company to the extent that at a glance the customer’s journey can be visualized and understood easily; A Customer Journey Map if you will, which is a documentation/mapping of all the customer’s contacts with you as a company.

During the course of the two-day workshop on learning about Customer Experience, we created a Customer Journey Map for a fictitious company and integrated the results into our respective businesses. We started off by understanding Customer Experience as a business discipline and it’s concepts, what makes up a customer experience and how to understand it. We then proceeded to Customer Journey Mapping, creates models with the aid of working methods, practical steps and guidance. A large part of the workshop was focused on “learning by doing”.

We moved onto Persona and Empathy mapping, gathering customer insights, customer needs and behavior, contact points and channels. This part was more about how to appropriately gauge a customer’s response and feelings when they make contact with our business. We were also taught how to effectively record these to facilitate these to facilitate business growth modeling. Happy customer = better business!

Our knowledge on the workshop was then put to the test by presenting us with practical exercises on creating Customer Journey Map and how to measure the progress of our services linked to Customer Journey Mapping.

The final part of the learning curve was the most delicate: Business development and business management with CX and how you can introduce change to our business specifically. We were made to understand that without actual measurable growth, the aim of the workshop would not be met. So in essence, all CX and Customer Journey Mapping should lead to measurable growth.

Attending the two day workshop armed me with a lot of new skills in dealing with customers and I learnt basic understanding of Customers and experience as a business discipline. What I consider to be the most vital lesson learnt is understanding how an empathetic approach to customers can create an atmosphere that encourages sustainability and profitability in business for your company.

With all these exciting business models, I’m quite ready and anticipate implementing Customer Experience work plan!

Thank you to Camilla Lif and Johan Sjöström for a great workshop. If you enjoyed reading about the Customer Journey or have any questions or great ideas, feel free to reach out at bjorn.nostdahl@gunnebo.com 🙂

Agile, Methodology, Scrum, Software Development Insights

Agile and Scrum Methodology Workshop

June 10, 2019June 10, 2019 Bjørn T. Nøstdahl

I recently had the chance to join Henrik Lindberg from Acando for an Agile Scrum workshop. In this post I will write about the workshop and the basics of Agile and Scrum. There is so much to learn and explore in agile, and I hope this introduction will compel further reading.

Agile Methodology

Unless you live offline, you probably are aware of the latest trend in the corporate world, which is the agile approach. Agile, in recent times has grown into a revolutionary movement that is transforming the way professionals work. Agile is a methodology that keeps the equilibrium of your priorities. Thus, the work is done faster, and project requirements are with great efficiency.

Working agile, people tend to forget about the four values from the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Equally important is the twelve principles behind the agile manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Major Differences between Waterfall and Agile

The waterfall approach is a sequential model of project management. Here the development team can only move to the next stage if the previous step is successfully completed.
In the agile approach, the execution of processes is concurrent. This enables effective communication between the client, the manager, and the team.
Waterfall assumptions are not well-suited for large-sized projects, whereas agile lets you manage complicated tasks with great ease.
Agile methodology is being embraced by managers worldwide for its greater flexibility.
The development plan is reviewed after each step in case of agile, while for the Waterfall approach it will be only during the test phase.

The agile development is based on the interactive functionality, according to which the planning, the development, the prototyping and many other key phrases of the development may pop up more than once in line with the project requirements. The agile also adheres to the incremental model, where the product is designed, implemented and tested in increasing order (complexity of the task increases in the ascending order). The development is termed as finished, only if every minute specification and requirement is met.

When to Use The Agile Methodology?

In a Scenario, When You Require Changes to Be Implemented
When the Goal of the Project Isn’t Crystal Clear
When You Need to Add a Few New Features to the Software Development
When the Cost of the Rework Is Low
When Time to Market Is of Greater Paramount Importance than the Full Feature Launch
When You Want to See the Progress in the Sequential Manner

Scrum Methodology

Scrum is the latest agile framework for product success in small-to-big organizations, which is creating a lot of buzz in the present IT world. Managers’ worldwide united hold a belief that Scrum is far more than the execution of processes and methods; it plays an integral role by supporting teams meet their aggressive deadlines and complicated project demands. The Scrum is a collaborative agile approach that involves the breaking down of substantial processes into smaller tasks so that they are done efficiently in a streamline manner.

Scrum is a lightweight, agile framework that successfully manages and accelerates project development. This framework is proven to cut down on project complexity and focus largely on the building products that are in accordance with client expectations. Generally, people sometimes use Agile and Scrum as interchangeable, but there is a big difference. The agile approach is a series of steps, on the other hand, Scrum a subset of agile.

There are three principles of Scrum:

Transparency
Inspection
Adaptation

Scrum Roles

Are you interested in switching to the Scrum approach of development? Then, you must know the various Scrum roles.

The Product Owner

He/she is responsible for providing the vision of the product. The product owner will play the central role in breaking down the project into smaller tasks and then prioritize them.

Responsibilities

Defining the Vision
Managing the Product Backlog
Prioritizing Needs
Overseeing Development Stages
Anticipating Client Needs
Acting as Primary Liaison
Evaluating Product Progress at Each Iteration

The ScrumMaster

He/she is someone with extensive expertise over the framework. The ScrumMaster will make ascertain that the development team is adhering to the Scrum model. They will also coach the team on this.

Responsibilities

Coaching the Team
Managing and Driving the Agile Process
Protect the Team from External Interference
Managing the Team
Foster Proper Communication
Dealing with Impediments
Be a Leader

The Development Team

This involves a panel of qualified developers those who form the core of the project development. Each individual in the team brings his/her own unique skills to the table.

Responsibilities

The Entire Team Is Accountable for the Work
They Are No Titles and Subheading
Sit Together to Communicate with One Another

Scrum Artifacts

Artifact #1: Product Backlog

Product backlog involves a sequence of fundamental requirements in a prioritized order. The requirements are provided by the provided owner to the Scrum Team. The backlog of product emerges and evolves with time, and the owner of the product is solely responsible for content & its validity.

Artifact #2: Sprint Backlog

It is the subset of the product backlog that the team will put in the hard efforts to achieve the “To Do’s.” The work in the sprint backlog is sliced down in smaller tasks by the team. All the items of the sprint backlog must be developed, tested, documented and integrated to meet the needs of the clients.

Artifact #3: Product Increment

The product increment is an artifact of Scrum with significant importance. The product increment must in line with the “Definition of Done” by the development team, and the product increment has to be approved by the product owner.

Definition of Done in Scrum Methodology

Definition of Done from varying from one scrum team to another. It is an acceptance criterion that drives the quality of work when the user story is complete. In other words, Definition of Done is the quality checklist with the development team.

Burndown Chart

The Burndown chart is a means to track the progress of a project on the Scrum. The ScrumMaster is responsible for updating this chart at the end of each sprint. The horizontal axis on the release Burndown chart represent the sprints, while the vertical one will make you aware of the remaining work at the beginning of each sprint.

Backlog Refinement

Backlog refinement is the act of updating/adding estimates, details, and order for the items in the product backlog. This improves story descriptions.

User Story

Commonly known as the “Definition of Requirement,” the user story in Scrum provides enough information to the development team so that they provide a reasonable estimate for the project. The user stories are about one or two sentences, a set of conversations that define the desired functionality.

User Story Acceptance Criteria

Acceptance criteria in terms of Scrum methodology are a set of conditions that the software product must meet in order to the acceptance by the user, customer or the other stakeholders. In layman’s terms, it is also a set of statements that determine user features, requirements or functionalities of an application.

User Story Relative Estimation

Relative estimation is the procedure of estimating task completion. The estimate is not in terms of the time, rather the items that are similar to one another in terms of complexity.

Scrum Events

There are five defined Scrum Events.

Sprint Planning

The Sprint Planning is an event in the Scrum framework. Here the team in a collaboration will decide on the task they will focus during that sprint, and discusses their initial plan to meet those product backlog tasks.

Sprint Goal

The sprint goal is defined as the objective set for the sprint that needs to be met via the implementation of the Product Backlog. The sprint goals are obtained after long discussions between the Product Owner and the Development team.

Daily Scrum

For the Scrum approach, each day of a Sprint, the team meets and holds a discussion on a number of aspects, and this meeting is known as the Daily Scrum.

Sprint Review

The sprint review is held at the end of each of the sprint. This is done to inspect the product increment.

Sprint Retrospective

The Sprint Retrospective is held between the development team and the ScrumMaster to discuss how the previously Sprint went, and what can be done to make the upcoming Sprint more productive.

In the end, after reading this entire article, you probably got a basic overview of the Scrum approach. If you want to talk about agile and scrum, feel free to contact me at bjorn.nostdahl@nostdahl.com. You can also read more about agile in this article:

Social Agility

Agile, Methodology, Scrum, Software Development Insights

Social Agility

May 10, 2017June 27, 2017 Bjørn T. Nøstdahl

Today is Wednesday, and I am on my way to the bi-weekly sprint meeting with our team from ICB in Sofia, Bulgaria. Currently, we are working on task management routines in our web and mobile application, so this meeting will be focused on adding the final features to this epic, and hopefully, we will kick off another epic if we see that time limit allows this.

The most important principle of the Agile Manifesto is to value individuals and interactions more than processes and tools. Since these are individuals who bring in impressive result by contributing unique value to software development project.

Continue reading “Social Agility” →