Staying Agile – Part 2/4
11 min read
11 min read
by Aleksandra Stamatović
In case you’ve missed Part 1, which was an introduction to Agile, and particularly SCRUM (as the framework that we have recently implemented within our non-software development teams) – make sure to check it out!
It’s the first Monday in October, which means the time has finally come to share Part 2. Here, we will quickly recap the main points from Part 1, focus on the importance of understanding and embracing the Agile mindset on a project, team and organizational level, and our journey to tailoring Scrum to our own company needs. Also, we’ll highlight some of the most common anti-patterns, such as leaving out Scrum elements, changing the core design of Scrum and not embracing an agile approach fully, thus covering up issues and limiting the benefits of Scrum, making it pointless.
Agile is considered an iterative approach to software development, focused on transparency, flexibility, and interactivity, using small, self-organized, cross-functional teams.
It originated in software development but it can be used and it has been in use in various industries. For anyone new to the topic but interested in learning more about Agile, I recommend starting the learning journey off with the Agile Manifesto, where you’ll find the core values of Agile:
[…] Through this work, we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the things on the left more. […]
Agile is not a methodology; it is not a list of rules one has to follow to become “agile” – it is a mindset, and it takes time to understand that to become agile, one has to fully embrace the core values of the Agile philosophy.
We also spoke of Scrum, a framework based on roles, artifacts and events with the aim of helping people and organizations discover what works best for them. Just as there are core values of Agile, although less spoken about or just under-highlighted, there are core Scrum Values upon which this framework is based. They are Commitment – Focus – Openness – Respect – Courage. Although not invented as part of Scrum, these values serve to give your actions, behavior and work a sense of direction. To learn more about Scrum values, I recommend checking out Gunther Verheyen’s piece titled “There’s Value in Scrum Values”.
If done well, Scrum can increase employee productivity and happiness, improve product quality, significantly reduce time to market, and enhance stakeholder satisfaction.
The emphasis in the previous sentence falls on the “If done well” part. When implementing Scrum into an organization, it is crucial to have someone with hands-on experience to achieve positive results.
Although you may think every tech company out there is now using Agile and absolutely crushing it, you should know that many Agile transformations end up failing. Besides, there’s a long list of organizations that assume they are Agile while following something that’s closer to a Waterfall – Agile mashup instead.
Scrum is easy to understand but difficult to master.
Scrum is very well-defined and easy to understand, which doesn’t make it necessarily easy to master. For Scrum to succeed, everyone in the organization needs to accept and follow the core values of Agile. Keep in mind that having a Scrum Master title in your team, using some Scrum events while neglecting others, and sporadically using the Scrum or Kanban board doesn’t make your team agile.
Recognizing anti-patterns and common ways to go wrong with implementing an agile framework into your team will help you avoid them, so let’s go over some of the most common scenarios that can end up ruining what can be the most exciting and groundbreaking organizational change of a company.
Well, to start with, many organizations make a mistake by simply placing existing people in new roles without the proper training or guidance.
Say Jenna has been a Product Manager in your non-agile organization for a few years now. And recently you decided to implement Scrum in your team. You won’t simply name Jenna a Product Owner because those two roles are not the same. While Product Manager is a title, Product Owner is a Scrum role and this is not a “potayto – potahto” type of deal.
The same goes for Elijah, your rockstar Project Manager. No matter how experienced Elijah is as a Project Manager, putting the Scrum Master hat on and calling it a day won’t cut it.
And don’t get me wrong, both Jenna and Elijah have the absolute right to pursue their new roles in a Scrum team but they will need thorough training and likely some hand-holding coming from those who have had previous experience in working with a Scrum team.
This principle applies to the rest of the team. And, it doesn’t stop there. In fact, and maybe I should have led with this, the management has to adopt the Agile mindset, too. The entire organization needs to change the way of thinking for the transformation to be considered a success; it’s not something you can afford to do halfway because it simply won’t work.
Scrum is based on the assumption that the teams are small and self-organized. This means that within a Scrum team, there’s no particular hierarchy – the team is made up of individuals with a diverse skill set and a capability to self-organize, work together and be accountable for reaching a given sprint goal.
A Scrum team member doesn’t wait for anyone to assign a task to them and tell them how it needs to be done. And depending on what you’re used to when it comes to your work so far you may ask something along the lines: “how does the team know what to work on”?
That’s also pretty straightforward and can be explained in a few main principles:
Another area where many fail is the failure to stick to the time-boxed Scrum events properly.
As we already discussed in Part 1, all Scrum events are time-boxed to remove unnecessary meeting time, thus allowing the team to be up to date and improving productivity.
There’s a reason why the Daily Scrum is also known as a Daily Standup meeting. Everyone participating in this meeting should be standing up – because it is a quick call with specific questions every team member needs to cover and check in on the progress towards the sprint goal. It shouldn’t go over the 15-minute mark and it shouldn’t turn into a status meeting. The idea here for the team is to get up to speed, talk about any impediments and check if everything’s on track with the current sprint goal. Anything that falls out of the agenda can be discussed with interested parties only after the Daily Standup is over, so that the rest of the team can return to their tasks.
Managers and team members new to Scrum usually see nothing wrong in deviating from the Daily Scrum agenda, introducing an unrelated topic, diving deeper into a discussion that doesn’t involve the entire team or just taking the chance to discuss other unrelated news – which is a recipe for losing focus and a decrease in productivity. Unnecessary meeting time needs to be reduced to a minimum, and for Scrum to succeed, everyone on the team is encouraged to stick to the time-boxing principles.
More often than not, teams tend to skip on having a retrospective at the end of every sprint. But as consistent and continuous improvement is one of the staple principles of Scrum, this event is not to be disregarded as it serves the purpose of learning how to do better in the next sprint. Even if your team just aced their last sprint and reached the sprint goal, remember that there’s always room for doing even better the next time around.
Clearly, Scrum as a framework can be customized to fit your organizational needs but all those custom changes and edits shouldn’t compromise the core values of agile, which make the bedrock of your transformation into an Agile organization.
As a team that aims at delivering high-quality, modular solutions for Digital Advertising, Social Media, and Content Marketing, we have decided to tailor Scrum to our needs and test it out ourselves.
We started by educating ourselves and the team on Agile principles and Scrum pillars. Then, we held workshops to introduce Scrum to the team, and we made sure that we weren’t rushing into it – we took the time needed to ensure a smooth transition and 100% adoption by the team before launching.
Our main team is divided into smaller teams, each focusing on a different service that we provide to our clients.
The teams we have are cross-functional, and to put that into perspective, say we have a client who wants us to run their company’s weekly blog. To do that, we have a person dedicated to writing the content, a person dedicated to proofreading & editing, a person working on graphic design, and a person dedicated to running blog promotions and campaigns to boost the viewership. All tasks are contained on a Kanban board in our system, and everyone working on this client splits their work into 2-week sprints, moves the tasks on the board to ensure transparency and visibility for all stakeholders, and the team regularly delivers a batch of blogs and relevant copies to the client, without any hiccups.
When introducing Scrum to our team, we ditched all the long, recurring meetings we had until then and decided to stick with Scrum events – Daily Scrum, Weekly Sprint Planning, Sprint Reviews, and Sprint Retros. This has saved plenty of time spent on unnecessary calls and allowed the team to be more efficient and faster in processing tasks on the board.
Our teams react quickly to change because they understand that change is something that brings you closer to a better and improved delivery. We have a mechanism to deal with change – again, as part of an agile mindset where changes are expected and welcomed as part of our continuous learning experience and improvement.
Last but certainly not the least, the nature of our interactions have changed thanks to using Scrum – as it encourages more frequent collaboration and more open dialogue. The move to an Agile approach has the same impact on the stakeholders and customers who will also largely benefit from working and collaborating with our teams in a more agile way.
No matter if you are an HR company looking for a way to optimize work, a Digital Marketing agency wanting to try Agile out or someone looking for an organized way to approach home renovation project – rest assured that Agile is not reserved for Software Development only.
It’s difficult to have final thoughts on Agile, as it is a wide topic with so many interesting aspects worth discussing so let’s leave it at this and pick it up in November with Part 3, where we will further explore the topic and learn more about the companies relying on Agile, such as Google, Apple, Spotify, and many others. Thank you & Stay tuned!
