VentureDevs blog


our press

How to use Scrum to Increase Your Organization’s Agility

Now that you know how to utilize John P. Kotter’s 8 transformation steps to create a more agile company, it’s time to talk about which methods to use to implement this change.

To ease the transition, you can always refer to the basic agile methodologies: Empiricism and the Agile Manifesto. The foundational units of Empiricism - transparency, inspection, and adaptation - and the 4 values and 12 rules of the Agile Manifesto can be developed and used in all aspects of the company’s operations. This spans from your sales department to your recruiting and professional development processes or product management and all around internal and external communication.

Agile methodologies in the company should not be limited to organizational tools, such as Jira and Slack, but must include departmental procedures as well. Achieving agility is a multi-level process requiring involvement of all employees throughout the organization. Receiving input from everyone is necessary to create a collaborative environment where each employee feels comfortable contributing his/her point of view. Working together creates a feeling that the change is coming from everyone in the organization, not solely from top-level management. Using this collaborative framework ensures that more people are able to notice and overcome obstacles that may arise.

Assuming that your company has already set the goal to increase agility, it is worth using agile methodologies to also manage the change itself. One such methodology is Scrum. Scrum is the most commonly used agile framework, with 85% of the companies who employ Scrum reporting an improvement in their quality of work life.

Below are my 8 steps to utilizing Scrum to increase agility within your organization:

  • Set Roles

    To start, I suggest mapping artifacts, defining the role agility will play in your organization, and choosing metrics to inform you whether the goal has been completed. To use Scrum terminology, you can call your goals of achievement Epics in a Product Backlog. For example, in this scenario the Product Owner will be your CEO or an external associate specializing in agile transformation. The entire company will then be one single team or separate teams set apart by departments or some other form of specialization.

  • Set Goals & Metrics to Measure Those Goals

    Next, you should set the metrics to determine when your set goals have been achieved. You will break down your progress by Tasks (or your transformation goals) and you need to have measurements to determine if you are completing these tasks. Some of these measurements will be considered your Definition of Done and others will be deemed your Acceptance Criteria; in both instances your measurements should be as specific as possible. They should help you determine how you are progressing towards reaching your goals, and you should revisit them often.

  • Create Your Product Backlog

    From there you are ready to create a Backlog for your Product. Your Product in this case is your organization itself. Keep in mind, the Product Owner should ensure that the backlog is prioritized in terms of optimizing the values for the organization. To track your progress towards completion I suggest using a relative measurement, such as Story Points. Using Story Points rather than standard time estimations makes the process cleaner, as you are entering into new territory which makes it difficult to determine how long it may take to complete all of your tasks.

  • Start Planning Your Sprints

    When the Backlog is ready - keep in mind the Product Backlog will always be a work in progress, evolving over time - the team(s) should commence Sprint Planning. Sprint Planning is when you determine which tasks will be accomplished during your Sprint. It is worth setting your Sprints as short as possible in order to give the teams the opportunity to frequently inspect and adapt. This hastens the team’s learning process, which will have a key impact on the rapid implementation of improvements in subsequent Sprint iterations.

    During your Sprint, it’s important to conduct a so-called Daily Scrum with the team. A Daily Scrum is a 15-minute meeting aimed at determining the team's progress towards the goal of the sprint, in your Daily you will also set a plan for the next 24 hours of work.

  • Perform Sprint Reviews

    At the end of each Sprint, the Product Owner will assess all the tasks submitted as “complete” during the Sprint - by the team or any other Stakeholders. At this time, the Product Owner will determine whether the tasks have been carried out correctly and will then accept or reject them. This review process is called the Sprint Review. When reviewing the work completed during any given Sprint, it is worth presenting such work done in the context of the overall planned changes in the entire organization. That way you will better understand what to focus on in the work of subsequent Sprints.

  • Conduct Sprint Retrospectives

    After the Sprint Review, a Sprint Retrospective should be performed to allow the team to identify good and bad practices in order to improve upon them. It is also worth asking what the team learned during the Sprint, which may have a positive impact on further cooperation. Finally, you must formulate actions that will be taken in the next Sprint to achieve a change in the right direction.

  • Undergo Product Backlog Refinements

    The cyclic meeting of the whole team and the Product Owner is called the Product Backlog Refinement Session. At this time the priorities of tasks within the Product Backlog are checked and descriptions are refined, which also often leads to newer, more accurate estimates.

    Below I present an example of a Kanban Board (via Trello) of a project run in Scrum. It shows one week’s Sprint and the work to be done during that time. Trello is a great free tool to use when working towards the agile transformation of an organization.

When creating your Product Backlog and setting up your weekly Sprint, I suggest creating 4 columns:

  • To do - where all tasks to be carried out are located
  • In progress - where you put the tasks that are in progress
  • QA - includes completed tasks that are to be verified by other team members to assure compliance with the Definition of Done and Acceptance Criteria
  • Done - where you will move tasks that are ready for acceptance by the Product Owner

Using a Kanban board such as the one above helps keep your agile transformation process as transparent as possible. It allows any person involved in the transformation to inspect the progress towards the assumed goal. It also limits time wasted because it keeps all communication within the necessary tasks to accomplish. On top of that, it helps the team organize their work during the Daily Scrum, making sure as many tasks as possible are completed together by all team members.

Scrum is an extremely effective agile methodology. The tips above should get you started on managing your company’s shift towards agility. Utilizing such a methodology will allow you to see how your organization looks through every step of its transformation. In doing so, you will be able to divide your transformation into smaller parts and maintain results along the way. With that, you will be able to adapt quickly to new learnings or changes that may occur throughout your procedural overhaul. That way, you will achieve your company’s goal of agile evolution in the most efficient way possible.

Recent articles

Recent articles

Sign up for our newsletter
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
follow us
Sign up for our newsletter
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
follow us