What is Agile and Scrum?
The software industry is going crazy on Agile matters. It is rapidly becoming the choice of software development when the climates are unpredictable or are expected to change over time.Here will try to help you gain knowledge on what is Agile, why Agile is better suited for these situations. We will also cover some of the most common Agile frameworks, like SCRUM and XP in-depth.Firsit of all we’re going to talk about Agile Fundamentals, why Agile? What is Agile? What are Agile values and principles? And what are the benefits and challenges of this approach?
After that we’re going to talk about how do you do Agile requirements and planning? What is the Agile approach to requirements? How do you write effective user stories? So user stories are something that we will learn about in Agile. How do you generate user stories?And at last we are going to talk about SCRUM which is one of the ways to implement Agile. We’re going to learn in detail about what are the practices and ceremonies of SCRUM.If we have enoug time we can talk about in this article we’re going to learn about an overview of XP and some of the practices and principles of XP.But if we dont we can talk about it in another article.Of course, while writing these, some terms may seem unfamiliar to those who are new to the field of Software Development.You can share these terms in the comments if you want and I can find extra explanation about them or they can be found easily from google.Actually agile is not a model, it’s a mindset. There were a lot of top leaders in the software industry that were building the software very successfully. And so they came together and said, “What is it that we are doing that is making us successful?” And they articulated what we call now the Agile Manifesto and Principles.
And as these Manifesto and Principles were crafted, there were models like Scrum and Kanban and XP that helped implement this mindset, that helped promote this mindset. So, you can see it’s not just these three but many other models came into being. The basic idea behind all of these models was that instead of building this whole one year cycle, you build in short cycles.So, you define little, you build, you test, and you learn, and then again, you just keep doing this. That way, you can adjust to the market quickly and then you are learning from your users quickly. And so the change became a norm because after every cycle, you may have a change.
And so, the software industry also has to learn how to respond to this change quickly and confidently. And the idea of continuous integration where a developer who is building the code, as soon as he commits the code or as soon as he finishes the code, it’s integrated with all the other components of that software. And then all the tests that verify whether the system is running are run. They are called the automated testing. So as soon as you commit the code, all of the tests are tested to make sure nothing else is broken in the system.
Now we will continue by briefly trying a few models that I think are important.
Predictive model: In this model, the customer knows exactly what she/he wants and the code is not interfered with in the process.
Adaptive model: The customer does not know exactly what he wants, he has an idea about what he wants and the process begins, but with the feedback, the project begins to take shape. The final product is created according to user requests.
Incremental model: We have an idea of what we want here, but as in predictive, the process does not consist of a single stage and we divide the stages into parts and do it. For example, you want to build a house and you make the outer walls of the house in this first incremental, you add the roof in the second, you attach the doors and this way you complete the pieces of the whole time and build the house .So here, we can actually associate it with both the Adaptive model and the Predictive model. Because if you get feedback on each Incremental piece and shape the final iron accordingly, this is similar to the Adaptive model, but if you stay fixed with the idea you started without returning, it is similar to the Predictive model in a way.
Iterative model:If we were to explain this with an example, think about if you want to go somewhere, and you need a vehicle for this, and you may decide to go with a scooter so that it will be cheaper at first, but you may decide to go with a scooter, but on the way, your mind will change and you can change it with an electric bike and then you will find the place where you want to go. You can change your mind to a car by saying that it is too far and it may rain while you are on the road. In short, you have a purpose, this is certain, but in this process, the product that will serve this purpose may change according to the needs of the user.
So what is Agile?
Now, if we refer to the waterfall method while explaining the network, I think it will be more understandable. When you look at the photo above, you will see the comparison of the agile and waterfall method. What are the common things between them? In both of them, there is a time frame to develop a product, there is a product that needs to be developed, there is a team that needs to develop this product, and there are processes such as testing and design in this development process.In Agile, processes are made in short parts and it is easier for you to understand that you need to take or take precautions in case of any disruption that may occur, new interventions (customer needs, etc.)
But in waterfall, if you have not determined the needs correctly, it is not possible in most cases to intervene in the situation until the product is released, because the intervention system to be used may turn upside down and this may cause great losses in terms of both time and cost.
If the needs are determined correctly and if the process takes a long time, people’s wishes may change this time. Besides, it is very difficult to determine the requiremnt most of the time. If a problem occurs and the problem is faked too much, the cost will be high.
Many negativities in the processes led to the development of Agile Software Development Manifesto. And these people met at a resort in Utah in 2001. They skied, relaxed, and also identified these four values and twelve principles.Because they also talk among themselves why so many projects have been unsuccessful. As you can see, they did not define a new process or new applications. They said that this is the common mentality of the method we found successful. They just defined a mindset that can help software development teams succeed. In summary, what the industry has realized is that software development is a creative process and we need adaptive methods to be successful at it. And the following 4 values have been determined.
The four core values of Agile software development as stated by the Agile Manifesto are:
- individuals and interactions over processes and tools,
- working software over comprehensive documentation,
- customer collaboration over contract negotiation,
- responding to change over following a plan
To briefly explain these items. First, “individual interactions on processes and tools”. What this means is that most of the time when there is a problem or we want to improve our processes, we always look, you know, is there an additional process that can help us? Is there another tool that can help us? And we do not focus on individuals and their interactions.Too often we don’t invest enough in individuals and interactions. Second, “software running on extensive documentation”. Like I said, that doesn’t mean you haven’t documented. You do it, you do the documentation wherever it’s critical, whatever it takes, but then what customers really care about is the software that works.Third, “customer cooperation rather than contract negotiation”. That’s why a contract is important because it defines a limit at which you should work, but only through collaboration can you understand the user’s needs and build better software. And the last one is “responding to change by following a plan”. Again, a plan is needed because it helps you stay on track. But we shouldn’t say no to change and ultimately build something that the user won’t need.
Well, Agile has no negative aspects, is it always very good? Of course, like everything else, we can’t expect it to be perfect in Agilene. It is very good in terms of process management and interaction, but what I can say negative about it comes out. For example, when we want to be able to adapt to changes immediately and are managed in small pieces, when there is constant change, we can get confused in the team and the project staff and I wonder what we are doing in the project.People say that what should we changed again and it can sometimes demoralize people.
In addition, new changes and needs in the Frontend will cause the database modeling to change constantly, which may cause developers to feel lost in control. In addition, the fact that the customer is constantly involved in the process and is in direct communication with the developers can create extra pressure on the developers. In addition, agile is not very much suitable for predictive and repeatable works. Yes it can be used here, but it can be used in traditional models or predictive models here.
Not: Predictive modeling is a widely used statistical technique to predict future behavior. Predictive modeling solutions are a form of data mining technology that works by analyzing past and current data and creating a model to help predict future outcomes.
Not: Traditional strategy development assumes that markets/industries are stable, but this is not the rule for most firms today. The strategy is built on some vital assumptions about the external environment and what the firm can control. planning, controlling and stopping.
Apart from this, there are 12 Agile Principles as I have listed below, which I will not mention in detail here. There are many explanations and resources on this subject, both on youtube and on google, you can get much more detailed information from here.
1-Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2-Welcome changing requirements , even late in development. Agile processes harness change for the customer’s competitive advantage.
3-Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4-Business people and developers must work together daily throughout the project.
5-Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6-The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7-Working software is the primary measure of progress.
8-Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9-Continuous attention to technical excellence and good design enhances agility.
10-Simplicity–the art of maximizing the amount of work not done–is essential.
11-The best architectures, requirements, and designs emerge from self-organizing teams.
12-At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Well, if this Agile is so important, you can think about which companies are using it, here are some companies that use agile; Google, Apple, Facebook, Yahoo, Spotify, Adobe, AirBnB, SpaceX,Microsoft.
Agile Frameworks
So as we know, Agile is a mindset. So the question is, how do you actually apply this mindset on a software development process? Well, the good news is that there are a lot of frameworks that are available that you can use to apply this Agile mindset for your team or for your project. But there’s no silver bullet. So you have to customize this framework to meet the needs of your team, your project, or your organization. And the key to customization is to make sure that you stay true to the principles and the values of Agile and do not get bogged down by the rituals or practices of a specific framework. So, let’s familiarize ourselves with some of these frameworks which are out there. One of the most common ones is called Scrum.
And Scrum is based on this one to four week cycle, where you take part of your project and you do your define, your develop, your design and you test your software and so your product is developed incrementally. Another popular one is called Kanban, which is based on a continuous flow model where you basically try to optimize your existing software development process. Then of course there is a combination of these two called Scrumban where you use Scrum as your primary framework. And then you use Kanban to optimize your flow within your sprint.
Another popular one which is similar to Scrum is called XP. And so XP has most of the practices of Scrum but it also defines some engineering practices which are very crucial for an Agile team. Then of course there is the hybrid of Scrum and XP. Another one which has become quite popular recently is called Lean Startup which helps you if you have a lot of unpredictable market or industry and you want to really prove your solution before you implement it. So Lean Startup helps you in that area. And there are many more. And more often than not, organizations actually end up customizing some of these frameworks to meet the needs of their team, or their project, or the organization. And if I may repeat, I want to make sure that you stay true to the Agile principles and practices and do not get bogged down by the rituals or practices of a specific framework. In terms of popularity, Scrum is by far the most popular of all. It’s about 70% of the Agile teams use either Scrum or one of its variants. And that’s how sometimes, people equate Agile to Scrum, which, of course, you can see that it’s not true. There are so many frameworks out there that you can use for your Agile implementation.
Scrum teams usually work with 2-week sprint series. Each sprint proceeds with a sprint planning meeting. The product owner and development teams also attend this meeting. And according to this meeting, the tasks are taken from the Product Backlog to the Sprint Backlog. If there is an unfinished business at the end of the sprint, you can take it back to the sprint backlog. And all the work is “todo” from the Scrum Board. It is followed from the “in progress” and “done” fields and discussed at daily stand-up meetings. In Scrum projects, a product or function is expected to be obtained at the end of the sprint. At the end of the sprint, new features are shown by making a Sprint review. In addition, a Retrospective meeting is held to improve performance in the new sprint. For this reason, it is tried to be corrected by determining what went well or not well during the sprint.
There are no two-week sprints and sprint backlogs in kanban. We can say that the work continues regularly by taking the work from the previous column of the empty columns (“todo” “in progress” and “done”). The works from the Kanban board are tracked and there is no time constraint, so the work is constantly finished. The most important thing here is to bring a work restriction to the columns. For example, there can be a maximum of 1 job in the “in progress” part. Daily meetings are held in kanban, like scrum, and new features are introduced, but unlike a certain time interval.
User Story ?
I think there is another important issue that we need to focus on is the user story.A user story is the smallest unit of work in an agile framework. The purpose of a user story is to express how a piece of work will bring back a certain value to the customer. So how should user stories be. We can summarize this under 6 headings;Independent, Negotiable, Valuable, Estimable, Small, Testable.Since the subject titles are clear, I will not go into details.I would like to point out that these titles are only for creating a perspective and emphasizing their importance. These are subject to change and extra titles can be added to them.
Story map?
One of the most popular problems faced by product development teams is the revision of requirements by customers repeatedly during development work. Although the story map makes our work easier, the dynamic and harmonious relationship and priorities of the product functions represented by these stories are simple and straightforward for anyone working on the project. To put it in an understandable way requires a separate study.
The purpose of Jeff Patton’s Story map is to visualize the needs of a product within the scope of the product in a hierarchical manner and to ensure that the overall impact of possible new requirements can be understood by all participants.Situations that can be considered technically detailed should be written in a simple and common language owned by all participants. In addition, they can be updated during the product development process. All stakeholders related to the project can be included in this study. User story It allows everyone to meet at the same point as an idea.
Scrum
As you know, the Product owner collects all the necessary inputs from users, customers, etc., and the product Backlog is created.If the team is ready, the sprint planning meeting starts. During this time, if the team has questions, the product owner answers them. Then Sprint Backlogs are created here and sprints are planned.We talked about Scrum in general terms and how it works, now we will talk about the important terms here in more detail.
Product Owner: Prioritizes the work in Scrum.Defines what needs to be done and in what order. Product Owner is going to talk to the executives, the team, the stakeholders, clients, users, and will try to define what exactly needs to be built. And so that will create something called a product backlog,which is basically a list of user stories which are prioritized and defines what needs to be done. Product owner reviews stories with the team and helps answer any questions or clarifies anything that is not clear.In short, he is the person who determines what work the Development Team will do in the Scrum Team. In this sense, he is the manager of the “Product Backlog”.Responsible for clarifying and prioritizing business requests.
Scrum Master: The Scrum Master is the person who takes part in the Scrum Team and coaches the team.Helps the team stay true to the Scrum values and principles, and then you will also notice that the Scrum Master helps facilitate most of the meetings in the team.And then if there are any roadblocks,then he will be the one who will drive the resolution of some of these roadblock.It strives to increase the harmony within the team, the harmony and communication between the team members.
Product Backlog Refinement (Backlog Grooming):It is a business process where the Scrum Team reviews the Product Backlog and makes the necessary adjustments, making sure that each item in the list is detailed and understood with all its clarity. Those are (informal meetings ) not in the Official Scrum Guide, but are often organized by the product owner.
Development Team: Do most of the building of the software, and it includes the developers and testers and everyone.Team is ready to sprint, they get together for a meeting called a Sprint Planning Meeting, where the whole team gets together and then they pick the top stories that they can work on in the existing sprint.In summary, the “Development Team” is the development team whose number varies from 3 to 9, taking as much work as it can do during a certain Sprint from the Product Backlog, which is the Product Owner’s to-do list, according to the priority determined by the Product Owner.
Product Backlog:The Product Backlog is a single list of everything needed in the product. Each item recorded in the Product Backlog is called a “Product Backlog Item.To summarize this in the shortest way, the work that needs to be done for the product can be explained as the list of features that the product should have.
Sprint Planning Meeting : Where the whole team gets together and then they pick the top stories that they can work on in the existing sprint. And the product owner reviews those stories with the team and helps answer any questions or clarifies anything that is not clear.
Sprint Backlog: The Sprint Backlog is a timed work list that keeps the content of a team’s work during the Sprint.
Daily Standup: Who participates in daily standup? What is its purpose? How can we get a good yield, now let’s talk about these a little bit.Usually the Core team and also the stakeholder can join to get information if needed or wanted.The key here is to cooperate with daily planning and check how things are going.And daily standups shouldn’t be long and everyone should be able to see the board which the works are written.This topic should be kept short, because a topic that you want to focus on may not be of interest to others and this issue should be resolved later, after daily standup. This should not waste time for others.
Sprint Review:Sprint Review is a meeting held at the end of the sprint and lasts for a maximum of 4 hours but an average of 1–2 hours. The main purpose of Review is to determine the value produced in the sprint and to update the Product Backlog accordingly.Here you start with summarizing what you planned, what you finished, what were your learnings, what were the road blocks, until you summarize what exactly happened in your sprint?You get some feedback, and based on that you can adjust your future direction. Who do you invite? Your core team members, your stakeholders and if there’s anyone else you want, also them
Stories: Stories are items that contain information about the work that a team and software developer undertake to complete during the sprint, taking into account the effort that will be spent.
Sprint Retrospective: Talk about process not about product.Not everything goes well during the process and sometimes some things need to be changed or updated. Therefore, questions arise in your mind to make the next processes better by giving good answers to them. How can we do better? What went well and what didn’t go well in the last sprint. Only the Core team participates in this.
Burndown/Burnup chart: Shows the amout of work left over the days of the sprint.Are we gona make it or not? Do we need additional help? We are going to use it for tracking our sprint.
How can we do Sprint Planning?
We can do sprint planning like this. First, we get a story (of course, in the order of priority and importance that we determined as a result of the meetings and arrangements we made before) and if our capacity is full, we start them, if not, we get the next story until our capacity is full.First of all, we determine the sprint capacity, while being realistic and making use of previous sprints and experiences. Then we ask ourselves “what are we trying to achieve in this sprint?” and we review the sprint goal, we review potential stories, the product owner shares and explains what those stories are generally.
Then we talk about how to apply the stories, what are the tasks we need to do, and we make a decision. And then if the thing is not accomplished, what was originally suggested abandons the process and then you can improve the goal. Once this is done, the entire team commits to “yes, we are ready and committed to finishing these stories”. And then once the commit is made, you put the stories on the quest wall and start executing.
Resources;
