Agile Project Management: Building Your First Application Using Agile

I don’t want to scare you but as an entrepreneur debuting in the world of digital products, you’re going to face lots of challenges. When operating in the tech environment, you need to adapt to highly dynamic market changes and adjust business requirements almost on the go. It makes even the nearest future quite unpredictable but you still need to make the most important decision at the outset of the project (when knowing the least about your app). To soothe these concerns and answer the most burning issues of the industry, the Agile methodology came to life. 

It seems that everyone in the world of technology is either implementing an Agile approach or at least trying to be agile. It’s the most prevalent development model in the software world and the one that we recommend and work with. 

But does it mean this methodology is right for you? And if you think it is, how to apply it effectively? 

When outsourcing the process of building your app, it’s a bit easier as your vendors should advise you on the proper development flow (at least we take this hurdle for you). But when hiring the in-house, you become responsible for guiding the team. In both cases, the knowledge of the Agile methodology beforehand is a must, either for applying it into practice or for supervising the process from the client’s side. 

It’s better to take a closer look at his subject. After all, it’s YOUR application that they’re developing and the way it will be created influences its overall success. 

Shall we start? 

What is Agile Project Management? 

Agile vs. Waterfall

Before we delve into the specifics of this method, let’s spend a brief moment on its roots. Agile management has grown out of the best aspects of various frameworks used in software engineering in the ’90s and ’00s. It is contrary to the Waterfall approach, and the term was introduced in the Agile Manifesto in 2011. What makes these two approaches differ is the outcomes delivery timeline.  

The Waterfall approach implies building software in a step-by-step way where you move on to the next phase once you finish the previous one. So you go through all of the phases to build a ready-to-go version of the product, then test, deploy and finally launch with a big bang—ideally. Coming back to the beginning of this article about a highly dynamic environment, this approach seems a bit outdated and risky if you ask me. Because, how to make sure that the app will be successful if the end customer can’t interact with it until it’s fully complete? 

Let this question be in the air while I’m moving to the Agile background idea. 

Agile project management is based on the empirical mechanism including three elements: inspection (we do a reality check), adaptation (we adopt to achieve the goals better), and transparency (we make sure we operate on real data). When building such complex products as software, the empirical mechanism plays a crucial part as it allows for staying nimble to adapt to changing requirements, project goals, timelines, and budgets. 

So, Agile project management refers to any process that aligns with the concepts of the Agile Manifesto. This flexible framework focuses on an iteration of every phase of the project before moving on to another phase while collaborating closely between the development team and the client side. 

The flow of work is not sequential but operates in repeatable life cycles comprising 5 stages: requirements, design, deployment, development, and testing. Once the cycle is finished, you evaluate the outcome and if it’s not perfect yet, you go back to the previous stage and repeat this procedure until achieving the desired result. 

The below-pictured illustration should make it all much more clear:

When Is Agile Project Management the Best Fit?

Technology

If you’re working with emerging technology in an industry that’s not highly regulated and where there are very few initial requirements, Agile should be your go-to technology. Working with a legacy product that’s aimed at a sector with many regulations, and a long list of requirements at a company where organizational processes are strict and need to be followed accurately may call for a Waterfall approach though, so assess it carefully before deciding which methodology to follow.

Time

Again, there’s a sweet spot for using Agile against your time limitations. If a project is scheduled for only 4 - 5 weeks, you may not be able to divide it into 4 - 5 small iterations and you should use the Waterfall approach instead. On the other hand, if you need to release a Minimum Viable Product or a beta version of a product and the development process will take a bit longer than a month, then it’s definitely worth looking into Agile as your methodology of choice.

People

Before you dive into Agile methodology head first, it’s important to remember that this approach will require you to be more hands-on and involved in the project, especially when working with an outsourcing technology partner. You will need to fill the Product Owner role and work very closely with a Project Manager/Scrum Master.

If that’s not something that comes naturally to you or not something you can do due to your workload or the type of your work, then Waterfall when you see the results at the end of the lengthy development life cycle may be a way to go. 

Also, if it’s difficult to find external Agile experts or hire an in-house Agile team in your local area and the requirements of the projects include working on-site, choose Waterfall instead of Agile.

Specification  

As mentioned above, the number of initial requirements and how detailed they are will be a deciding factor for a methodology that you’ll need to follow. If there's little space for changes and creative solutions due to industry regulations, i.e. in automotive or medical sectors, you should probably resign from following Agile methodology or use a hybrid approach instead, mixing the former approach with Waterfall.

Budget

There are two most important limiting aspects to consider when it comes to the budget for your project and using Agile methodologies. If the budget is set in stone and there’s no wiggle room for any changes, go for Waterfall. If budget and potential increases are not something you’re concerned about, choose Agile as it prioritizes the speed of development and delivering more features.

To sum it up: Agile management often occurs when technology is changing, teams are changing, or the goal of the project is changing. The essential aim of Agile is to stay nimble and be able to adapt to changes rather than being forced to execute against a plan which may be obsolete.

When planning an Agile project, understand that the process may be non-sequential and the time frame could also be fluctuating as well. For exploratory projects or projects that are long, Agile management can deliver quick wins and have success keeping on track as small iterations are evaluated at the end of each “sprint” or segment of the project.

The Agile Offspring—SCRUM 

The Agile family bore a few variations of this methodology such as Extreme Programming (XP), Feature-driven development (FDD), Crystal Clear, and more. But let’s focus on the two most popular as they will probably be your matter to deal with when building the first software product. 

Of all the possible Agile frameworks used by companies, 66% are Scrum or Scrum variants. The tool allows for organizing work into weekly (or two weeks) sprints during which the team completes the assigned tasks and prepares them for review. Changes in the meantime are highly discouraged as they hinder delivering on time. SCRUM predefines the roles of each member assigning one Scrum master and product owner. 

Speaking of sprint, deliverables, and product life cycles, it’s high time to throw some light on the wording matter. 

As with any other methodology, agile conceived its best practices and terms which are widely used among project managers. As a client, you should have general knowledge of this jargon to stay on the same page and feel confident when talking to your team. Let’s take a whiff of the most popular expressions: 

• Sprint/iteration—it refers to short periods of time, spanning from one to two weeks dedicated to developing assigned tasks.

• Daily standup—a 15-minute team meeting organized daily to coordinate their activities, share progress, and report impediments. 

• Product Backlog—a list of the new features, changes to existing features, bug fixes, and infrastructure changes based on the customer’s needs. It’s used to prioritize features and understand which features to implement first. 

• Requirements—brief descriptions of required functionalities that combined translate to the customer desired product. 

• Estimation–evaluation of the effort necessary to finish a given development task, it’s usually expressed in terms of duration.

• Planning Poker — a “game” aimed at estimating every task in the given sprint by showing cards with numbers. 

• Release—we all want to get there, it’s the final delivery of a software product after the completion of multiple iterations or sprints.

• Retrospective - to read more about how we run Retrospectives at Monterail, go to: 

  Introduction To Agile Retrospective: Dos and Don'ts For Project Managers

If you have an inner voice saying that there’s more to the words-table, you’re right. The official glossary consists of almost one hundred terms that will enhance your overall comprehension of the Agile process. Don’t worry, I won’t leave you flat-footed in this area, and questions you might have. 

What is Kanban in Agile

Kanban, on the other hand, refers to the visual side of the work, it aims to limit the work-in-progress stage and reduce the time needed from start to finish while enhancing efficiency. Besides, it encompasses small, continuous improvements. It encourages the team to collaborate and there might be no project manager involved. Deliverables are determined on an as-needed basis and changes during sprint are allowed. Fun fact, the term comes from Japanese and means “visual sign” or “card” which explains its nature more explicitly now. 

Actually, you don’t have to choose between Kanban and Scrum, they can go hand-in-hand and complete each other in areas where they fall short. Anyway, both frameworks will help you build better products(and services) with fewer headaches. 

Today, enterprises need software competency to deliver good digital experiences in a hyper-competitive world, and great customer experiences. They need to attract and keep great talent to do that. Agile development is how enterprises get there.

Agile Process Flow: How to Start Step-By-Step

None of these beautifully listed actions and development milestones won’t happen without the right people. This is one of the most important elements in your first experience with an Agile project. The construction of the team working on the software product may slightly differ depending on the project’s specification however team members must have all the necessary skills to achieve the result and be enthusiastic about implementing Agile. To make your agile project work, you will need the following roles:

Agile roles: Who do you need on your team to start

Product Owner	Scrum Master  (or Agile PM)	Development Team	Business Analyst	Customer
A person who represents the client’s interests by understanding the users, and providing knowledge of the marketplace and competition.	It’s not obligatory but recommended to have this type of leader who helps the team perform at their highest level and align with the Agile methodology.	A tight-knit team composed of developers working on your app. The projects team sometimes involves quality assurance (QA) engineers, designers, and analysts.	A person who ties business and technology. She gathers and elicits requirements for a particular project and prepares estimations.	Well, they’re not really a part of the team but remain an important element of the process. A customer gives guidelines and dictates requirements to the product owner.

 

So, you have the right people on board and processes in place. Now, let’s put theory into practice. What does Agile look like in real-life projects? Whether you started cooperation with the outsourcing development company or you supervise your own team, the process will look similar. 

Sprint 0. 

This phase is called a project before the project and will serve to solve all the problems and issues that may arise. From a vision of the project, order what is necessary for the product to prepare the team for Agile work, and determine the size of the sprints.

It’s time dedicated to figuring out stuff before getting down to work on tasks. The list might include assembling the team, setting up hardware, determining which tools the team will be using, and creating the first backlog. Sprint 0 also includes the kick-off meeting which is the official initiation of the project. That’s when the whole team meets to get to know the business goals, possible benefits, and the flow of work. To avoid making it a time-consuming phase, it’s recommended to keep this stage as lightweight as possible. 

Sprint 1. 

Day 1. 

The first sprint is the day of the sprint planning meeting where the team decides on the scope of work for the iteration lasting a week or two. That’s when you create functional user stories which means defining clear benefits of each feature to be developed in your initial sprint. The most useful scheme to do that is the following:

As a <user>, I want to <name of the feature > so that <the reason>.

Doing it this way guarantees building features that make sense and bring benefits to the end user. The team puts all user stories into the backlog according to priority. Then, the team estimates each task (remember planning poker?) by bearing a card with a number that illustrates the level of difficulty and time-consuming aspect. The size of user stories is evaluated in comparison with other user stories. After some time, the team knows how many a sprint can embrace and can plan more easily.  

That “first round” shouldn’t be filled with a plethora of tasks, yet they should still deliver some business value for the client. It’s a good time to test frameworks and processes and to ensure that all environments are set up.

It’s like a warm-up before the run. 

Source: Aha!

Day 2, 3, 4…

During each day of the sprint, the team meets for a daily roundup to coordinate their activities, share progress, and report impediments. This 15-minute exercise should provide answers to the following questions:

• What did I do yesterday?

• What will I do today?

• Do I have any problems or concerns?

Of course, these are just basic questions and you modify them in line with your team’s needs and type of project, with other examples including:

• Are we closer to achieving the sprint goal?

• Do we see any risks to achieving it? 

As mentioned above, these stand-ups should not take longer than 15 minutes every day, and the format is repeated day after day until...

Day 14. 

It’s the end of our exemplary fortnight sprint. After each iteration, the team makes a reality check to define what practices stay and what should be improved. The fruit of this time is a little but functional element of the product that could be tested on the potential user. Here’s where the agile part is the most visible—even this little element can be tested and if not passed the test, improved or removed. 

...and still day 14.

After every sprint, an Agile team takes part in the retrospective meeting. As the name suggests, it allows them to look back on past events or situations to draw conclusions for future projects and avoid mistakes. It is also aimed at creating improvements to be enacted during the next Sprint. 

The so-called retro is conducted after every iteration, the team can spot and fix bugs on the go without hindering further development. It’s also the event during which the work during the sprint is discussed and the finished increment is shown to the customer. 

Source: TeamRetro

Day 168. The release. 

It’s important to acknowledge here that while an Agile project can have a definite ending, each sprint can be considered a separate project and should finish with a release and delivering business value. We aim for a shippable feature each and every time, and the last sprint is no different. It ends with a review, a retrospective, and an unofficial celebration - you’ve crossed the finish line!

You may wrap things up by preparing a backlog for maintenance or a product improvement project as with software development, the work is never completely done and dusted.

Tools For Agile Project Management

Atlassian JIRA

Source: JIRA

Pros: Well-known project management tools, JIRA is equally loved and dreaded by developers, project managers, and the like. It can be integrated with a code development environment which makes it particularly suitable for software development projects. 

Cons: It can feel overwhelming when you’re a JIRA newbie and doesn’t offer many collaboration features.

Pricing: 14-day free trial and a free basic plan for up to 10 team members.

Asana

Pros: Asana is yet another project management tool that’s perfect for streamlining Agile processes and has a user-friendly interface. Its differentiators are the ease of use and the ability to create dependencies between tasks, teams, and projects.

Cons: There’s no in-built time-tracking feature, and tasks can be assigned to one person only.

Pricing: Free for up to 15 team members, then it’s USD 15 a month.

Trello

Pros: A simple and intuitive Agile development tool, Trello is one of the easiest-to-use solutions out there and one that encourages team members to collaborate with each other. You can also assign more than one person to a task.

Cons: You can’t integrate it with Google Calendar and the tool is not ideal for large teams with multiple projects developed at the same time.

Pricing: Free basic plan and paid plans start at USD 5.

ActiveCollab

Pros: ActiveCollab is an affordable project management software, ideal for smaller projects. It has an intuitive interface and a great feature-to-price ratio.

Cons: You can see your project’s progress in timeline mode only and not as a Gantt chart.

Pricing: Starting at $8 per user/month.

Is Agile Project Management Possible When Outsourcing? 

To give you a short answer: it is and we’ve got 390+ projects to prove it. Agile is the primary software development methodology that we work with and the one that our Project Managers prefer - you’ll hear from them directly later in this article.

The longer explanation is that Agile can be successfully used for building software even - or even especially - if you outsource your development services. There are a few rules that you need to follow to ensure that your project will end on a high note:

• Choose an Agile technology partner: It’s a no-brainer: look for a technology partner who’s focused on continuous improvement, has an open-minded perspective, and already knows the ins and outs of the Agile approach.

• Be proactive and serve as a Product Owner: As stated a few times in this article already, Agile requires you to stay engaged throughout the development process and become a middle person between the outsourcing company and the client’s side - please note that you may need to fill both of these roles.

• Frequent team visits and get-togethers: As it is with daily standups and other Agile ceremonies, in-person meetings and team visits are as important and part of the Agile approach process.

• Communication is key: Daily feedback and checkups with your team are crucial in Agile, and they’re essential parts of the process.

• Evaluate your team’s performance rather than individuals’ work: While it may be tempting to only rate individual contributors’ skills when forming an Agile team or blame one person when things don’t go to plan, you should avoid all of these things at all costs. The Agile approach is all about how well the team works in unison, rather than how valuable are each team member’s contributions.

Agile Project Management - Benefits to Your Product

1. If you don’t use the Agile approach right from the start, important issues in the product's design and code may go undiscovered until release. Not the ideal scenario if you ask me. 

2. The iterations allow for the team to be diverted to (and productive in) another area of the project while a blocking issue is resolved.

3. Intervals and feedback - This, in turn, gives the team constant opportunities to build, deliver, learn, and adjust. 

Scrum is a highly prescriptive framework with specific roles and ceremonies. While it can be a lot to learn, these rules have a lot of advantages. The benefits of Scrum include:

• More transparency and project visibility: With daily stand-up meetings, the whole team knows who is doing what, eliminating many misunderstandings and confusion. Issues are identified in advance, allowing the team to resolve them before they get out of hand.

• Increased team accountability: There is no project manager telling the Scrum Team what to do and when. Instead, the team collectively decides what work they can complete in each sprint. They all work together and help each other, improving collaboration and empowering each team member to be independent.

• Easy to accommodate changes: With short sprints and constant feedback, it’s easier to cope with and accommodate changes. For example, if the team discovers a new user story during one sprint, they can easily add that feature to the next sprint during the backlog refinement meeting.

• Increased cost savings: Constant communication ensures the team is aware of all issues and changes as soon as they arise, helping to lower expenses and increase quality. By coding and testing features in smaller chunks, there is continuous feedback and mistakes can be corrected early on, 

I asked my colleagues from our Project Management team what is the most appealing in agile, what is the most challenging, and why they recommend it to their clients. That’s what I heard. 

The current economic turmoil makes it particularly difficult to run a business and Agile may be the ideal methodology for the challenging times ahead. It allows you to address any changes, including funding/investment limitations, much faster than when using Waterfall. With Agile, you can build your complete product in iterations with the business value delivered right from the start. You will be able to check much quicker whether the technology of your choice is right for your product and whether your users use and enjoy the features your team has implemented, so it’s no longer an assumption-driven development approach, you’re now able to employ a user-driven process instead. I’d add that the risk of failure is much lower with this methodology than when using Waterfall.

Łukasz Pawłowski Project Manager
at Monterail

The most important benefit of working in Agile is that you become open to changes. With the ever-transforming technology landscape and the recent - at times - disruptive advances in the modern world, it’s difficult to plan way in advance, especially when it comes to software development. It’s good to have a product vision and long-term goals, but in the shorter term, you need to get used to pivoting and addressing whatever comes at you and your business, be it in the digital space or otherwise. The Agile methodology allows you to make small steps towards your far-fetched targets, save money as you can work in iterations, and stay in the loop in your project with weekly/bi-weekly goals set with each sprint. It also gives you the opportunity to find out about the best approach to your initial product concept as you go, during the development process. When it comes to Agile challenges, get ready for daily updates and feedback, communicating on an almost hourly basis with the team, and adapting the hands-on approach to product development. You may also need to extend your timeframe dedicated to the project as early estimations may not be 100% precise, especially if the scope of the project has been changing.

Joanna Kostana Project Manager
at Monterail

Again, one of the benefits of the Agile approach is that change is something that we anticipate and actually want to occur at one point or another. You don’t need to plan 6 months in advance, it’s enough if you have the next week’s schedule set and we can quickly validate how accurate it is. Another advantage of Agile is how repetitive it is - the concept is easy to grasp and follow. This methodology requires you - as a Product Owner - to participate in Agile ceremonies and stay very much engaged in the process, so you can swiftly respond to any pivots and verify what has been completed during the sprint, including its business value. If this type of engagement is not something you’re keen on, it may be overwhelming initially, and I’d advise you to move at your own pace and join in only the ceremonies and meetings that feel right to you. You also need to get used to the fact all time estimations set at the beginning of each sprint are just that - estimations that may not be exact, especially when the project has only begun.

Anna Rakowiecka Project Manager
at Monterail

Let’s Go Agile

Long story short, it is. It’s basically what we take advantage of every day as a software house and it works wonders. 

Whether you feel fully confident in the agile ecosystem already or you’re still not too sure if building your first app in Agile project management is for you, 

You could say that the first sentence of the Agile Manifesto encapsulates the whole idea: “We are uncovering better ways of developing software by doing it and helping others do it.”

When you think of Agile as a mindset, that mindset can be applied to other activities. At Monterail, we work according to the Agile methodologies in our marketing team. 

Ready to go Agile?