Agile Development Process at Fulcrum Rocks

Agile development methodology was first introduced to the world back in 2001 in the Agile Manifesto. 20 years later anyone who is even remotely linked to the IT industry at least heard about it. And no wonder. Agile development is a simple and effective methodology. Created specifically to deliver software products to the market faster. And to manage the development teams in a more efficient and flexible manner. In the fast-paced world of software development Agile seems like an answer to every business’ prayers.

 

But just like with any other software development model, each team has its own interpretation of it. No two teams, and no two projects are exactly alike after all. And we believe not every project requires Agile.

 

In this article we will describe how we at Fulcrum work with the Agile software development life cycle. We will thoroughly explain the process. We will show you a couple of projects we applied it to. By the end of this article you will understand the benefits of agile development. And why we don’t use it on absolutely all our projects.

The Fundamentals

The manifesto defines these guiding principles behind the Agile method:

The driving force in the Agile development process is user satisfaction. If a task does not directly impact the improvement of that satisfaction, it will be a secondary task.

 

There is a common misconception that agile development does not involve any planning, or other formal processes. While the manifesto does state that processes, planning, and documentation are secondary, it does not imply that they are to be omitted.

 

The manifesto promotes self-organizing teams. But it does not state that those teams do each of their own thing and never communicate with each other. In fact, the manifesto states quite the opposite. Agile promotes close, face-to-face, continuous communication between everyone involved in the project.

 

The most important thing about agile web development is that it is flexible and can be easily adjusted to fit any circumstances.

 

Agile Software Development Life Cycle

So, now we know that Agile focuses on user satisfaction and draws from collaborative decision making. How do these things translate into the actual development life cycle (SDLC)?

The project is divided into small incremental parts. These parts are then built in iterations. Each iteration is limited in time. Usually it’s 1-4 weeks. Each iteration results in a working product. Yes, it is not a fully finished product. But it has to be something that can be used by the users right away. Each next iteration is meant to improve the previous result. It’s very important that users and stakeholders provide their feedback during each iteration. To ensure that the development is moving in the right direction and each new feature meets the users’ needs. And the business requirements.

 

Of course, each iteration has its workflow. A typical flow looks like this:

• Iteration requirements. They are defined based on the backlogs of the product or sprint, and feedback from users and stakeholders.
• Design and development of the piece of software based on the requirements defined on the previous step.
• QA, internal, and external testing. Documentation development is done at this stage too.
• Integration and delivery of the finished iteration into production.
• Gather users’ and stakeholders’ feedback for the next iteration.

The flow is repeated until the product is finished.

 

Agile SDLC Models

Agile has been evolving for the past 20 years. A lot of new development models have appeared based on it. Now Agile is really an umbrella term for a number of iterative software development life cycle models. These models include:

• Scrum;
• Kanban;
• Scrumban;
• Crystal;
• Feature Driven Development;
• Dynamic Systems Development (DSDM);
• Lean Software Development;
• and others.

All of these models adhere to the Agile principles. But they have different patterns and practices. We will describe a couple of the most popular models so you have an idea of how they differ. At Fulcrum we mostly use Scrum. So let’s take a closer look at it first.

 

Scrum SDLC Model

As you can see from the picture Scrum model adheres to the agile flow we described above pretty closely. The development team plans, develops, reviews, deploys a new feature or update at each iteration. The stakeholders and users provide feedback. Which is added to the backlog. A product owner is in charge of the backlog and prioritizes the tasks with the team at the beginning of each sprint (iteration). The process is repeated until the project reaches a maintenance stage. Or is deemed no longer useful and is retired.

 

With Scrum the planning is a particularly important part of the process. As well as the cooperation of everyone involved. The Product Owner defines a sprint goal. And holds a sprint planning session with the whole team to prioritize the tasks. The team has daily meetings (standups) to coordinate their work. There’s a sprint review held by the Product Owner. This meeting allows the team to present their work to the stakeholders. And receive feedback on the deliverables. There’s also a sprint retrospective. Which is a great way for the team to reflect on the team dynamics and the effectiveness of their processes. And come up with improvements for the future.

 

There are three clearly defined roles in Scrum. We’ve already mentioned the Product Owner. They advocate for the user, manage the backlog, and help with prioritization. There’s also a Scrum Master who helps the team to stay true to the Scrum principles. And there’s the development team. There’s no head in this structure. The teams are self-organizing and everyone is equal.

 

Want to see which of our projects are done with Scrum? Well, as we’ve already said most of them are. But here’s a couple of examples:

 

SubbXi is a complex web app that allows users to create, edit, import, and export subtitles for videos. It has a strong app architecture. The back-end here was particularly challenging to create. But we dealt with it successfully. And Scrum was a big help. We wouldn’t be able to deliver this project as efficiently as we did with a different methodology.

Lastcall is a marketplace for events. It allows users to both promote their events to the general public and order tickets as an end-user. This platform is rather complex and has a lot of features to offer. And there’s also an app for both iOS and Android. This is another good example of a project that couldn’t be done as smoothly and effectively without Scrum.

Kanban Model

Kanban is a great fit for projects with a lot of incoming requests varying in size and priority. Kanban implies continuous workflow which allows the team to adapt to changing priorities faster. Generally speaking, Kanban is a bit more flexible than Scrum. In the sense that it does not require that much control over what is in scope.

Kanban provides the team with a visualised roadmap. It looks something like the picture above. Yes, there’s a board involved. The work items here are represented by cards and organized in columns. They flow from one column to the next. Typically the workflow stages are:

• To Do
• In Progress
• In Review
• Blocked
• Done

But they don’t have to be exactly that, you can customize the columns to fit your team and how it works.

 

Each column can hold only a limited number of work-in-progress items. This allows the team to be focused and identify bottlenecks in their process.

 

Lean Software Development

The main principles behind the Lean framework are:

• Eliminate Waste;
• Build Quality In;
• Amplify Knowledge;
• Decide as late as possible;
• Deliver Fast;
• Respect people;
• Optimize the whole thing;

With this model a Minimum Viable Product (MVP) is delivered to the market as fast as possible. The team learns from the end users what they like, what they don’t like, and what they would like to add. The developers use this feedback to deliver the next iteration.

 

In short, Lean Software Development is meant to deliver as much value in the shortest amount of time in the most efficient way as possible.

 

Pros and Cons of Agile Development Methods

Agile software development frameworks help to deal with the common pitfalls in a very controlled manner. The number of models and frameworks Agile offers makes it a very flexible tool. Any team can find a way to apply it that will fit their needs perfectly. Though there are still cons to using it on every project. Let’s see those pros and cons.

 

Pros:

• Customer satisfaction. Rapid, continuous delivery of useful software makes it easier to satisfy the users faster.
• Working software is delivered frequently. Which makes it easier to outpace the competition and conquer the market.
• Close, daily cooperation between business people and developers.
• Attention to quality of the software and good design.
• Easy adaptation to changing circumstances.

Cons:

• It’s rather difficult to assess the effort a project will require at the beginning of the life cycle. Especially if there are large deliverables implied.
• Lack of emphasis on documentation might lead to a mess at the end of a project.
• The final outcome has to be very clearly defined. Otherwise the project might get off track.
• The short sprints might put pressure on the teams to deliver.
• Usually the decisions required during the development can be made only by an experienced senior developer. Since everyone is equal here, it turns out there’s no place for newbies.

When We Don’t Use Agile

As you might see by now, Agile product development is a great way to deliver successful projects to the market. But not every project requires this approach. So when do we go for the more traditional frameworks like Waterfall?

We don’t apply Agile when the client is not available to take part in the close collaboration Agile requires. The process depends on consistent feedback from all the stakeholders. And the client is the most important one. So if they are not available or willing to take part there’s no way Agaile will work as it should.

 

Another case when it’s not needed at all is when the project is simple and typical, without any complex or novice features. This kind of project is better done with a Waterfall approach. Which allows for longer cycles. If the goal is clear and there’s no rapidly changing requirements in sight there’s no sense in applying Agile.

 

When the client requires a thorough documentation of every development cycle. Agile is great for constant and on-the-go adaptations without very clear documentation. If the client requires documentation for infrastructure applications the method won’t fit the project.

 

Another case is when the client has strict rules and procedures. And requires approval of every cycle. The deliverables have to go through a complicated approval procedure at every step of the development life cycle. And we get ourselves into a situation when these bottlenecks hinder the Agile process.

 

When the project’s deliverables can’t be done in short iterations. If the deliverables can not be reasonably divided to fit the short delivery periods of 1-4 weeks Agile simply won’t work.

 

Finally, we don’t go for Agile when the user feedback is not really necessary. If the project has static goals its success does not depend on the continuous improvement of the users’ needs. We see no need to go for the complex Agile process in these cases.

Agile Development FAQ