July 14th, 2022 | by Adam Skubiszewski

Everything You Always Wanted to Know About Agile (But Were Afraid to Ask)

Table of contents

Agile basics

Let’s start with some basic facts – what is Agile and where did it come from? This is a very important step because without understanding the basics, it will be difficult for us to put agility into practice.

What really is “agility”? Peeking into Cambridge Dictionary we can see that this word has three definitions:

the ability to move your body quickly and easily,
the ability to think quickly and clearly,
ways of planning and doing work in which it’s understood that making changes as they’re needed is an important part of the job.

For the purpose of this article, we’ll focus on the third one which contains the notion of change. Well, it’s safe to say that agility and change go hand in hand. In other words, agility can be described as an ability to respond to changes and view changes as an asset.

This really is the most important part of Agile and basically, we could end this article right now. But let’s dive deeper into more details!

The backstory of Agile: who, what, and when?

Although it seems like Agile has been with us since always, it’s not as old as it seems to be. The Agile software development principles were agreed upon on February 11-13, 2001 in Utah, USA.

A lot of technical people were engaged in this process. As they worked with the software on a daily basis, they knew and understood this world in-depth, including its problems. We’ll list a few most notable names (you might have heard about them) – Martin Fowler, Robert C. Martin, Ken Schwaber, and Jeff Sutherland.

But what were these problems that they were so aware of? Mostly, the software development process was unpredictable, so it was difficult to truly plan anything. And even when you made thorough plans, all could change anyway just in seconds.

They met at a party at Snowbird Resort, and this 3-day encounter resulted in the creation of the famous Agile Manifesto, now basically considered the basis of Agile.

Agile Manifesto

For developers, it’s worth getting to know the Agile Manifesto and having it always in mind (even despite being in the heat of work) because it contains the most important values and the whole Agile approach in a digestible way.

We are unconveying better ways of developing software by doing it and helping others do it. 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.

It’s important to note that, as stated in the Agile Manifesto, while there’s value in the items on the right, we value the items on the left more. And it doesn’t mean at all that the items on the right aren’t important or that we should reject them! There’s value in both sides and there has to be a healthy balance between them. This is the key to success.

For us, CSHARKers, these principles sound oddly familiar – want to know why? Check out our values according to which we work.

Agile Manifesto consists of 12 rules which you can find below. We won’t go into details about each one, but we want to pay your attention to our four favorite rules which convey powerful messages.

#1 Our highest priority is to satisfy the customer through early & continuous delivery of valuable software.

Traditionally, let’s start from the beginning. The first rule contains many keywords crucial for Agile. Customer satisfaction – it should always be the top priority in the software development process. We attain it through the fast and continuous delivery of valuable software. In short, the client is happy when he gets the software as fast as possible and the software is useful. Wow, this is practically the whole concept of Agile merged in one sentence!

#7 Working software is the primary measure of progress.

We also love rule no. 7. We could work long hours, create awesome architecture and flawless mockups, and have a plan for every single scenario… But at the end of the day, where can I click and test it? Does the product really work? What’s its benefit?

#9 Continuous attention to technical excellence and good design enhances agility.

Rule no. 9 confirms that if we’re experts who have plenty of knowledge in our area and we understand agility, in general, what we create should be of good quality and give value to the user. We can be sure of it. The better specialists in our field we are, the less we should think and worry about correctness. Instead, we should focus on the value.

#10 Simplicity – the art of maximizing the amount of work not done – is essential.

And finally, simplicity – often forgotten, but essential. Why bite off more than we can chew when we can just go with the simpler solution? This rule underlines how important it is to balance our work. We should devote exactly as much time to the project as necessary – no less, no more.

A little bit about Scrum

Scrum is essential for us because, at CSHARK, we work according to its principles. It’s a framework that allows us to create value through adaptive solving of complex problems. This methodology was proposed by Ken Schwaber and Jeff Sutherland (yes, these are the same people who have dipped their fingers in the Agile Manifesto).

In short, according to the Scrum Guide, a Scrum Master creates the right work environment for him/her and his/her team so that:

the Product Owner organizes the work to be done in the form of a Product Backlog,
the Scrum Team converts some of this work into a valuable increment during the Sprint,
Scrum Team and stakeholders check the effects of the work and adapt it to the needs of the next Sprint,
… and so on, and on, and on.

Besides, remember that Scrum is an empirical process that consists of iterations.

Customers often don’t fully understand the role of the Scrum Master – it can be intangible for them. That’s why it can be hard for clients to pay for a person whose scope of responsibilities is a bit unclear from their perspective. But the Scrum Master is a vital part of the team, watching over the process and caring about the work environment.

Scrum Master also makes sure that the Scrum pillars and values apply in practice, not only “on paper”. Let’s discuss them to better grasp their importance, starting with the pillars that hold Scrum together.

Transparency – continuous transparency for the team and stakeholders.

Everyone (the stakeholders, the organization internally, the team) can see what we’re doing and how our work is going. There are no hidden parts because we have nothing to hide. Transparency is also crucial when it comes to delivery – it means that the product and its value are constantly visible and easily accessible.

Inspection – artifacts and progress towards the goal are under constant inspection.

Everything we create is subject to constant inspection. Why? So that we can quickly improve what we do and steer the product in the right direction. Warning: Inspection doesn’t equal control. It’s definitely not about checking whether we’re running late or working too little. The point of inspection is to check whether what we do is still valuable for the client. Thus, we can say that the purpose of the inspection is…

Adaptation – we adapt as quickly as possible (preferably right away).

On the other hand, Scrum’s core values are:

Commitment – we trust each other and we can count on ourselves.
Focus – we’re focused on the sprint goals and product goals.
Openness – we’re open to change, innovation, and ideas.
Respect – we respect ourselves, our work, and our opinions (which often differ).
Courage – we have the courage to say and do the things that are sometimes uncomfortable.

In plenty of situations when we have a conflict in the team, it later appears that we’ve just made a mistake, the cause of which stems from Scrum’s pillars and values.

Sounds trivial? Maybe, but if we ask ourselves a few questions and look once more at the values, it often turns out that we weren’t fully focused on the goal of the sprint as a team. Or maybe we saw the damage coming but didn’t have the courage to communicate it?

Scrum Master is a person who should help to solve such conflicts (although he/she is a member of the team and may also be part of the conflict). All in all, Scrum Master is, in a sense, the team’s “psychologist”. This role is difficult, and the more you delve into its true meaning, the more you see the need for such a person in the project.

Scrum process

In Scrum (similarly to what we learned from the Agile Manifesto), the people are over the processes, but that doesn’t mean that processes aren’t valuable. Scrum can be described as a light framework with a light process that you can see in the chart below.

I want to bring your attention to Sprint Planning. We understood it as a meeting during which we first need to define and visualize the sprint goal. Next, we have to judge whether this goal is achievable or not. By the goal of the sprint, I mean an increment that we imagine to deliver to the client and show him during the review. Importantly, the sprint goal must obviously present value.

A mistake often made is viewing the Daily Scrum as a meeting whose purpose is just to answer 3 basic questions:

What did I do yesterday?
What will I do today?
Are there any impediments in my way?

While in fact, the Daily Scrum is the moment to inspect and adapt. Ask yourself: Are we heading towards the sprint goal? Does what we’ve planned for the Review actually have a chance to happen?

Remember that you should work hard as a team – there may be situations when you’ll have to abandon your task and help your colleague. Or there’ll be a significant blocker in your way and you’ll have to focus on solving the problem. Yes, it’s not easy and requires you to leave the zone of your task as a single backlog item, and enter the area of what we have to deliver at the end of the sprint.

Scrum team

Since 2020, according to the Scrum Guide, the Scrum Team consists of the Scrum Master, the Product Owner, and the Developer(s). A stakeholder is part of the process but is outside of the team.

This entire team is responsible for ensuring that the increment is provided to our stakeholder(s) and that it has value for them. For example, the Product Owner is just as responsible for delivering value at the end of the sprint as the developers are.

This is extremely important and emphasized in the Scrum Guide. Also, the first thing that the good Scrum Master should do is to put emphasis on teamwork, and on the fact that the team should organize itself, be respectful, courageous, open, and remain focused on the goal to be delivered.

It’s a challenge that requires a lot of work because Scrum is easy to learn, and hard to master – precisely like Tetris or chess.

Scrum Guide

The entire Scrum framework has been described in the Scrum Guide, available to read on scrum.org in most languages. The Scrum Guide is one concise document of 13 pages that basically contains everything you need to know about Scrum.

Everything included in it isn’t accidental. It has been evolving and constantly changing for several years to remain as simple and transparent as possible. We can judge if Scrum works or not only if it’s implemented exactly as described in the Scrum Guide.

What’s interesting, Scrum doesn’t have to be used only for software development purposes and can be used in several other contexts.

What’s Kanban?

Kanban is another agile methodology, developed by the Japanese a long time ago for production management. It can also be quite useful, e.g. in large, continuous maintenance projects or in “quick” projects in which the budget is open since we create e.g. a PoC. Plus, it’s equally suitable for organizing household chores.

The concept of Kanban is based on the graphical visualization of the flow of “work items” which gives us remarkable transparency. The most important assumption is to minimize work in progress (WIP Limit). We focus on completing the tasks.

Besides, Kanban can be useful for diagnosing bottlenecks in the process. For example, you can easily see that for a particular stage of the project you’ll need more people as the tasks are blocked. It has some nice solutions as well, for example, “expedite” – a swim-line that allows you to skip the basic queue, aimed at high-priority items.

How to work in an Agile team?

OK, so who’s the developer in the Agile/Scrum context? We usually tend to associate a developer with a programmer. While in fact, in Scrum, a developer equals not only a programmer but also a tester, a designer, a data analyst, a consultant, a DevOps…

It’s basically every person who, during the sprint, produces the value that we later deliver to the client. The general assumption is that the team has everything that it takes to create this value for the customer.

Very often we encounter the case in which such an open division into all the competencies is causing bottlenecks. You may hear: “I won’t do this“, “It’s not in my scope”, or “I’ve done my portion of the task“. We close ourselves in our skill set and don’t operate as a team but as “lone wolves”.

Remember that a developer is a person who solves problems, not generates them. You have nothing to do? Then simply help your colleagues. It’s important to always have in mind that we constitute a team and we should act like one. As a team, we should work out our best method of work and division of duties to deliver agility at the end of each sprint. An agile team is primarily a self-organizing team.

Let’s imagine a perfect world: we have amazing specialists, we have a really clean & decent architecture, we always do code reviews, and operate according to GIT flow… Yes, all these things would help us immensely, but how does it look in real, everyday life?

Let’s see a couple of real examples that we tend to hear: “I have to wait for the merge”, “We were doing a refactor – we have to do the next one”, “I’ve got nothing to test”, “We have nothing to do”, “The client is changing something”, “I did my part”. What to do in such situations?

The answer is simple: we shouldn’t be focused alone on our user stories but rather work together as a team to deliver value at the end of the sprint. After all, a team is as strong as its weakest link, and working software is the primary measure of progress!

This mindset requires stepping out of your comfort zone and the zone of your capabilities – now you’re a member of the Scrum team, and you have to deliver value to the client. This outcome sounds easy but in fact, it’s very difficult to implement and is only seen in very experienced teams.

DevOps culture

In the Agile Manifesto, as soon as in the year 2001, it was written that: “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” In general, we may say that the authors of the Agile Manifesto anticipated/created the role of DevOps. But in fact, it’s not a role, it’s rather a culture (and it’s obviously agile).

DevOps creates an environment where the software can be delivered to the client as soon as possible. Even though in the Agile Manifesto we read about delivering software “frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale”, in 2019, Netflix did ~4000 deploys every day…

That means no less than 4000 bug fixes and/or new features delivered each day! It’s, without a doubt, frequent.

Responding to real-life situations

1. “We’ll do it… somehow”

Empiricism is very encouraged in Agile and Scrum. What does it mean? That is, there’s no such thing as “somehow”. Scrum and Agile are empirical. We, therefore, draw conclusions from facts, not from theories or guesses, and only make decisions based on what we truly know.

This approach scales across many different situations. Imagine this particular question in your team: “should we make such a data model or another?”. The solution is clear – list all the suggestions as a team, make a decision together, and commit to it. If we make a decision, we should all agree with it. Even if this decision turns out to be wrong, we must all take the consequences on our backs.

The good news is that it works the other way too – when the decision turns out to be a great success, we all win our laurels!

There’s, however, a critical thing to note: we have to measure what’s important (e.g. spent time, waste). For Scrum to be empirical, all the necessary facts need to be collected. It’s worth checking later during the Retro, for example, how much we planned vs. how much we did and why it happened. On this basis, we can adjust our subsequent planning and estimates. In other words, we inspect to later adapt. A couple of questions worth asking:

What can go wrong?
What are we doing this for?
Have we done that before?
How long did it take?

Some more imaginative examples include:

Since we estimated 3 User Stories in 30 minutes, how are we going to make it on time with the planning?
If THIS task took us THIS time, why would THAT task (similar one) magically go faster?

2. “Everything is fine, so why change it?”

As they say, the better is the enemy of the good. However, software development is one of the most complicated things humans have invented. We don’t even brush against “fine”, let alone “perfect”.

We have to accept that:

Change is a normal situation in our everyday life. It’s what we do.
Without continuous development, we go backward (that’s why there’s a need to constantly inspect & adapt, even on a daily basis).

The sooner we (also as an organization) accept the fact that change is perfectly normal, the sooner it won’t be difficult for us. Change should become our asset, and its direction should be of course determined empirically, based on facts and data.

3. The trap of cascading agile things

We often take a backlog and start implementing it step by step, user story by user story, one by one. And suddenly it turns out that we’ve made half of the product or even just a quarter. That’s why it’s essential to start with the core of the product to deliver the minimum value to the client.

What can we understand as the core? It may be addressing one specific need of the user thoroughly. Or a demonstration of what this product will look like in 3 months. Or a live implementation of lo-fi/mockups from the design team, so that the client can actually “click” through the product.

The clue is that we should create the functionalities in a cross-sectional way, not one by one in a full manner. Thanks to this approach, we’re getting the flow of how the software will soon work.

It’s important because the customer can start to use the product quite quickly and begin to think about (or even search for) the business value. It provokes new ideas and changes.

Glossary of important Agile concepts

And finally, in the last part of this article, we’re going to explain some vital concepts which are often used in the context of agility – unfortunately, not always in a correct manner. Use them this way, and you won’t go wrong!

Acceptance criteria: go/no-go for the user story. Clear guidelines on whether the user story can be accepted or not (by the tester, developer, stakeholder).

Definition of Done: “default” acceptance criteria. A common understanding of what we perceive as completed. The client may understand it differently from the organization, the programmer may understand it differently from the tester, etc. This concept is introduced to make communication more consistent. It can be part of the organization or specific to the product on which the Scrum team works.

User story: the smallest amount of work to be done, expressed in terms of a goal.

Timeboxing: the art of focusing on the most important things.

INVEST: a set of criteria used to assess the quality of a user story.

Independent → Can we do it regardless of the order in the backlog sprint?
Negotiable → Does it leave room for invention and discussion?
Valuable → What does it bring in terms of the sprint goal and the product goal?
Estimable → Can we estimate it? If not, why not?
Small → Is it impossible to divide it into smaller sections?
Testable → How do I know the user story is “done”?

Be Agile!

Be like Arnold Schwarzenegger who showed what’s “agility” in the movie “Predator” which launched in 1987. He adapted perfectly to the situation by using his surroundings and reacting quickly in order to defeat an enemy stronger than himself. He also presented “technical excellence” because if he hadn’t been a trained commando with a lot of muscle mass, he certainly wouldn’t have succeeded. Two things went hand in hand – the ability to adapt & inspect + technical excellence.

Be like Iga Świątek who plays tennis, and inspects and adapts in fractions of a second during the game. Depending on how successfully she does it, she either wins or loses the match. As we know, her skills of inspection and adaptation are outstanding, so it’s safe to say that Iga’s agility on a micro-scale is great.

In fact, if we were at least partially as agile in our teams as the professional athletes, we would be launched into space when it comes to the quality of the software we create, the value, and the satisfaction of the client.

This article was written on the basis of CSHARK TechTalk #1. Wondering what’s TechTalk?

It’s a meeting organized for our entire company on the last Thursday of each month during which the speakers talk about some (more or less) interesting topics from the field of software development. We organize it with a couple of goals in mind:

equalizing knowledge between teams in various areas, including in the field of technology, IT project management, or methodology,
exchanging knowledge and experience from both technical and non-technical subjects so that the entire organization can learn,
promoting self-development and encouraging learning,
integrating different teams and getting to know more people from CSHARK.

Adam Skubiszewski

Head of Software Development

Head of Software Development at CSHARK. Has over 80 projects behind him in every possible role (some of them even ended with successes).

linkedin List of publications