Doing Agile vs being Agile

We’ve probably all noticed how agile took over nearly every industry.

Everyone is so desperate to implement agile that many do it wrong or with the wrong roles.

It has been 21 years since the Agile Manifesto was published. And the spirit of the Agile Manifesto is often forgotten.

We are constantly focusing on tools and methodologies first.

This is a path of least resistance.

But this is a natural order of things.

Manifesto inspires. So that we can implement the inspirations into a reality.

In my experience, Scrum is the simplest way to get any team into agile. The framework is simple and well-documented. There's actually a manual. :) And most important, the roles are well defined. What I found a lot is that some places tend to use Scrum as a project management methodology which is not. There are several approaches to do Agile project management with different artifacts and roles. Scrum is a way to deliver incremental products. - Hlov Beyond

How does Big Tech do agile?

Apple, Amazon, Google and other Big Tech companies execute tech projects differently. Anecdotally, they mostly don't stick to a central methodology.

Another difference is that engineers are the ones that lead projects, so a dedicated Project Manager is a hard-to-find role in Big Tech. A technical Project Manager will step in if there is a more extensive project with several teams.

Project management methodologies are free to choose, so engineers can use the one that suits them, and the team, the best.

The examples you mentioned about big tech companies probably work because the team members are really senior and have mature relationships between them, but that's not the reality in most of the places where team members don't even have an understanding of basic concepts like ownership and accountability which is something that scrum definitely helps. - Hlov Beyond

Who does what in an agile team?

Project managers, Scrum masters, or Product Owners are in such high demand nowadays that differences between these jobs blur to the point even companies searching for them don’t know which is which.

In a nutshell, doing agile means practising all the processes and guidelines of agile methodology, using modern tools and technology, but without actually believing in these values and principles and without implementing them culturally.

In other words, it seems everyone is doing everything perfectly well, but things still don’t go as planned.

There are often many job descriptions for a particular position in a team in which the responsibilities and duties don't match what the job should be.

More often than not, employers want agile roles because they are popular, so suddenly, project managers become product owners, and product managers become scrum masters.

They may be looking for someone who knows something about Scrum. Still, they would also like that person to lead a project, write requirements, talk with stakeholders, sketch a solution, create a roadmap, actively manage the backlog and generally be involved in product development.

In this case, they should look for a Product Owner instead of a Scrum master.

As Daytona points out in article on effective developer onboarding, companies must prioritise culture and people over job titles, tools, and methodologies. Implementing a well-structured onboarding process that focuses on fostering collaboration, creating a positive work environment, and providing comprehensive resources can lead to increased productivity, employee satisfaction, and long-term success.

At Codeanywhere, we firmly believe that by embracing these principles, businesses can improve their onboarding experience and enable their developers to thrive within their organisations.

Responsibilities and duties of a Scrum master

The responsibilities and duties of a Scrum master are different. They should foremost be improving the team's work with the help of proven good practice and creating a working atmosphere in which the team will independently continue to improve its processes and culture.

The Scrum master stands aside because a mature Scrum team, which has fully adopted the Scrum framework, acts as a cross-functional team whose members have all the skills necessary to create value in each sprint and manage their work independently.

It's vital to have clear distinctions between Scrum roles. Mixing responsibilities from different roles, or adding extra responsibilities to a role, may affect the team's value, quality and focus, thus affecting the overall quality of the product and creating confusion and uncertainty.

So don’t implement something only because it’s popular. Implement it because it suits the team and the company and if it brings value.

Should we ditch Scrum?

The short answer is that it depends. :)

The long answer is - that it can benefit the particular type of companies and teams.

Scrum can be helpful within non-tech companies.

Those where the business doesn't know how engineering works. Usually, these teams have everything thrown at them.

Still, stakeholders are aware that a sprint cannot be interrupted, so with Scrum, they won't do it, thus giving room to engineers to continue working uninterrupted.

Another positive use of Scrum is with newly formed teams with members that still don't know each other. Going with a well-documented methodology rather than everyone picking their style is a better start, especially if team members have conflicts or differences in opinions.

Lastly, if a company wants to speed up shipping, it could be wise to implement Scrum.

What is the result of being agile?

Software engineers and teams have higher autonomy.

This gives them room to become problem solvers and not just assigned workers.

These teams are autonomous and have a clear sense of ownership, with the vision and mission of the company in their minds and the skills to achieve it.

Engineers in settings like this are more motivated, resulting in increased productivity and satisfaction.

Furthermore, these companies are no strangers to sharing documentation, data and metrics with their employees. This also helps with building a sense of ownership and relationships.

And having direct feedback contributes to better alignment and indirect project management.

In a traditional company, it is not common for an entry-level employee to have contact with an executive. Everything goes through their supervisors, and their supervisors, and their supervisors, to infinity. The decisions are much slower, which cannot be the case in an agile company.

In an agile team, the focus is on Plan > Build > Ship. And do it quickly!

As a result, the engineers are much more satisfied, less frustrated, and in most cases, have higher motivation.

The community collectively has prioritised tools and methodologies over principles.

But it should be: Culture and people over job titles, tools, and methodologies.

And we at Codeanywhere strongly believe in this!