This article is part of our project management methodology series.

The Agile method is based on an incremental and iterative approach to project management, and  the easiest to adopt in a software development setting.

We will show you how our team embraced Agile thinking into developing the Yanado software, through both theory and practical examples.

The Agile Manifesto

A group of experienced software developers got together in 2001 to throw out the stiff traditional approach and came up with the Agile Manifesto, which describes 4 important values.

The 4 Values of Agile are essentially the preferences and guidelines for using this approach, and they are based on the viewpoint that while there is value in things on the right, we should value the things on the left even more.

1. Individuals and interactions > processes and tools

Agile facilitates interaction and communication. You have a team of developers working on different modules on their own, and then working together to integrate all of these modules into a cohesive piece of software. You need your team to work like a team, meaning that timely communication is paramount.

“You win with people” – Coach Woody Hayes

Tools and processes are important, but your team is more important. It is people that work on projects, and people that solve problems, not the tools they solve them with. When the deadline strikes, it is also people who define whether the project was successful or not.

Because of this, we have to put in the time to determine processes that are mismatched to the project needs, the junk and the unpredictable factors. When you cut away the excess, you can efficiently put the time and energy of your team into actual work.

2. Working software > comprehensive documentation

Using your time well at the start of a project is essential to having enough time at the end. If you use this period to write comprehensive project documentation, you are not working on the actual project.

Documents have no value to your end-user. Feed your clients and your users with value every step of the way by getting that minimum viable product out as soon as you can. Or you can waste your time, postpone the deadline, and compile potentially useless documents in one turn.

Do you remember the “Use Case”, “Sequence”, “Class”, “Deployment”, and other such diagrams? While we were creating Yanado, we avoided wasting time on those. Instead of paperwork, we focused on creating a working software that we could make available to our users as soon as possible.

That way, the only paperwork we had to deal with was user feedback, and we had a much better idea of how to continue developing. I’m not saying you should abandon all documentation, but know how to tell a waste of time when you see it. We did write out technical documentation eventually – once we were absolutely sure our tool was working, and worth the paperwork.

3. Customer collaboration > contract negotiation

When have you ever worked on a project which didn’t go through obligatory major changes right when you thought it was too late to change anything?

Changes will happen, they just hurt less when they don’t come out of the blue.

Contracts are a double-edged blade. Preset rules are quite rigid, and without continuous negotiations, the limitations can hurt both sides.

Alternatively, when you are bound by a common goal, rather than a contract, you can establish a partnership that will use its strengths and limits more efficiently.

We worked on the Yanado mobile application in collaboration with another team. We knew (or predicted) most of the functionalities we wanted the app to include, but we didn’t bother with details in the contract. We knew the final result will change considerably, according to the end-user needs.

So we ironed out the details with the other team throughout the development process. We were the customers in this instance, and our constant collaboration is what made the project successful. It’s the difference between Being Right and Doing the Right Thing.

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” – Dwight D. Eisenhower

4. Responding to change > following a plan

Agile works best in a project environment where the development team needs to respond to changes in requirements in a rapid and effective manner. The whole project can be reduced to the following pattern:

• Plan
• Develop
• Ask for feedback
• Apply changes
• Repeat

Yanado’s beginnings were never based on fixed specifications. We worked with proposals which we validated with end-users after each development phase. Our final goal was to create functionalities that satisfy the needs of our users. All else was excess.

To better understand how these values reflect on your project efforts we will follow you up with a dose of common sense that is associated with how they act in practice.

Working software and satisfied customers are the only measures of success

The greatest value of Agile project management is how it brings fresh working software frequently, with short waiting periods. You have continually functional software from the early days of your project, and your job is only to help it evolve and meet its full potential – that which the client ordered.

What that actually means? It means that the working software is the only measure of success. If you haven’t shipped the working piece of software, you haven’t moved the needle.

Developers need to make sure their code is working. Test the edge cases, test the Sunny Day Scenario, make sure it’s working. Only then they can move on and claim their victory.

This reflects on the entire company. As a team, we can’t claim a victory if we haven’t shipped working software. If something isn’t working, go back and fix it, don’t rely on the Known Bugs list. Make it work, release early, and release often.

The trouble with not delivering continually is that two cannot play the waiting game because one of them will get bored and leave. Your potential users will need to be fed on hype or beta versions continuously, or else you’ll see a lot of them leave for greener pastures – ahem, the competition’s software. Now, what you want is to have your cake and eat it, too.

Release your software as soon as you can – don’t bother with having all the features set in place. Go with small, yet perfect increments. Let your end-users be your beta-testers, let your customer support be your feedback.

We always aimed to indulge our end-users by putting out new features and fixing the existing ones on a weekly/monthly basis. This continuous progress showed our users that we cared about their needs.

Had we done differently, had we worked toward releasing a finished product right away, our users would have had to wait for a very long time without the software that they needed – and we could have lost them.

There’s more negative traits to the waiting game: the longer you stretch out your project phases, the more room you leave for individual features to pass the point of no return.

We’ve learned that shorter development cycles led to better software, thanks to the prompt feedback we got with each version. It was also great for our end-users to see their problems fixed so fast.

A common goal is what gets everyone pulling in the same direction

If you can arrange a closer connection more regularly, you will shorten the gap between yourself and your end-users. This means understanding where the client is coming from, what is triggering those seemingly disconnected suggestions. Only then will you understand what problem your tool truly solves.

Let me try to explain by example how bringing everyone under a common goal is crucial to moving ahead. When we started monetizing Yanado, we kept a simple, if rigid, automated billing model. But it was not just simple, it was rigid.

When a particular paying user asked if he can put full-time employees on an annual contract and his contractors on a monthly contract, our CEO was all for it. When he sent the request to the development team, they were absolutely against it – too much work, too many alterations, a huge waste of time.

When everybody got together and discussed their motives, we understood that the user still wanted to pay for Yanado, but temporary contractors on an annual payment plan were just too expensive. So the developers asked if it was really that important to charge contractors in the first place? It wasn’t. But we did get a win-win solution: external users ride for free if the company has 10 paying employees.

That’s why it is important to communicate  the project  vision and to help each team member understand why they matter, and why their contribution matters. People work best when they start with a purpose and end up feeling accomplished.

You give them the freedom to self-organize and plan out their own time. Agile project management is all about ending micromanagement, and prioritizing teamwork, cooperation, and high productivity.

You don’t want your project managers to throw in their gloves, though – their new job is to guide their team members to become experts in their industry and to offer the right kind of support on their way to productivity and success. Agile project managers are Fairy Godmothers, rather than Excel-savvy enforcers.

It’s not about technology, it’s about people

At the end of the day, you win with people. Your team needs to meet and interact, and you need to make that very possible.

The Yanado team has a routine: each morning we sit down together (Skype in the remote ones), and go over what each one of us is working on at the moment. At the end of the day, we go through what has been completed, discussing possible obstacles and prioritizing them.

“If you tell people where to go, but not how to get there, you’ll be amazed at the results.” – George S. Patton

One of the agile principles is that having a self-organized teams leads to the best architectures, requirements and designs. Thinking about this brought us back to the hard times of outsourcing business.

We were given detailed specs on how certain things should be implemented for most projects. There were countless situations when we immediately noticed how bad a proposed solution was. As a team, we had much better ideas on how to approach those situations, but our solutions were constantly dismissed.

You can be the best in your line of work, but if someone sends you a list of specifications they want, you’re automatically a “code monkey”.

We had a room full of great but unhappy and unmotivated engineers. And when people are unhappy, they choose to leave. We would have achieved greater results had we had the liberty to self-organize and implement our solutions.
Talk about wasted potential.

It is an agile project manager’s job to understand the value of their team, and put their knowledge to good use. Your super team is the most competent to identify the problems and their solutions, and to prepare the project for further scaling. After all, no one understands the possibilities and limitations of the project like them.

The Yanado crew rose above the code monkey, encouraging a culture of self-organization within the team, and solving problems bottom up.

How do we know we’re doing things right?

Agile projects come with a lot of retrospection. At the end of each iteration, there is room for team self-evaluation. Frequent evaluation periods let you keep track of important details which would have been forgotten if you had one traditional end-of-the-project evaluation.

More importantly, lessons you learn at the very end don’t matter that much. Finding and solving problems as you go leaves room for fixing the project course. It is difficult for a single person to establish where they went wrong, but a team could do that.

Retrospective evaluations are important in every project methodology, but Agile makes room for them more often than most. With each step down the road, you learn how to smooth out your work and get where you wanted faster. The Big Picture comprises the joint perspectives of every team involved in the project.

The art of agility in acting upon change is in balance and simplicity

“If anything is certain, it is that change is certain. The world we are planning for today will not exist in this form tomorrow.” — Philip Crosby

We cannot stress enough how important it is not to feel threatened by change, especially if you work in a field like software development, where you know that changed requirements are inevitable. If your client isn’t already suggesting alterations, ask them first.

Communicate with your client, let them understand the anatomy of your development process. If they know how your project is evolving, they will also have better ideas for further development. And most importantly, their suggestions will be timely.

As we worked on the Task details design, we started out with an idea that seemed perfect at that moment – until we got to use it. And it was horrible. We couldn’t make head or tail from it, let alone our end-users! So we tweaked the design around until we got it to a solid, working version. With each iteration, we got a few steps closer to the design that would benefit the user the most.

Simplicity is complexity resolved

Our software is a project management tool, and it has all the features such a tool ought to have, yet all of them find their place under the 80/20 rule. Users spend 80% of their time using 20% of the features. Why would we spend time and resources to work on implementing every feature when we could just focus on the core 20%.

Complex systems are often unreliable, and Agile is all about simplicity. You start out with the bare bones – the Minimum Viable Product – as your first release, and you build up from there, as you get feedback.

It is only when you have satisfied the actual needs of your user, that you can start thinking about “nice to have” things.

“So many people think good enough is good enough. It isn’t. Every word matters. Every pixel matters. Details dominate. Average loses. Own it.” – Mark Suster

Our team is easily irritated by details. They usually couldn’t understand why certain elements of the design had to be exactly as we specified them. Move a few pixels left or right, what does it matter, yeah? It does matter at the end. A few discrepancies will go by unseen. But a few discrepancies can easily grow into 50 discrepancies, and what you’ve got is one ugly interface.

It goes the same with writing code. A messy code will do the job, to the point where it stops doing the job. If you’ve got a lot of poorly written code, you’ve got yourself a house of cards – the fragile one, not the TV show.
BUT, if you constantly work on the quality of your code, you’ll end up with a fine, stable, scalable application.

Now, you don’t really need to burn out trying to accomplish all these things.

People like to talk about how overtime work got them very far. There isn’t an Elon Musk waiting to happen in each one of us, and we can’t actually follow this tempo without burning out. Putting project goals over the health of your coworkers is a no go. It spells out disaster, and it is the main reason perfectly talented people leave companies. Burnout is the White Plague of Startupland.

When we’re in a tight position between deadlines, it is better to realize how we got here in the first place. We use this knowledge to create a predictable roadmap for the future. And don’t forget that deadlines look much scarier as you approach them. Think of all the trains that have left the station in your life – how many of them were really as important as you thought they were in the moment? Just adapt and move on.

…

In this article, we tried to explain the principles of Agile with a few examples from our own experience. Let’s say that we talked about agile features, and barely touched the benefits.

The next article in this series will talk specifically about the benefits of using Agile methodology. What we really gained by being Agile.

If you want to know more about Agile and other project management methodologies, and you haven’t subscribed yet, sign up below!