“It isn’t what you do, but how you do it” – John Wooden
Agile software development can be described by a myriad of different adjectives. Customer-friendly, flexible, transparent, outcome-oriented… But to be all of this, it has to be – in the first place – efficient.
Efficiency is the founding stone of agile, as it gives agile software developers an undisputable advantage over their colleagues working in more traditional methodologies. It is usually this above-average efficiency that becomes the bargaining chip and convinces customers to go for working with an agile software development agency.
The agile methodology comprises of dozens of little habits which, put together, allow for a fluid and harmonious functioning of a software development team. On the surface, it seems that those habits are precisely what makes agile approach such an efficient one. But in reality, there is something even more important.
All the productive habits of agile software developers derive from a particular type of mindset, a way of thinking that allows one to work efficiently by default. Some of this mindset’s features might come across as contradicting the common logic at first – but don’t be fooled. We dare to say that the agile way of thinking is one of the most reasonable and efficient approaches to work (and software development in particular) that humanity has come up with so far.
Do you want to learn what it means to think agile? Below, we describe the most important features of an agile mindset. We have been incorporating them into our own workflow for many years, to make sure we build good quality software efficiently.
What is more, these mindset principles do not only apply to software development. Incorporating them in any project or business will bring you a noticeable increase in efficiency – especially in the long run.
The common belief is that in order to be efficient, one has to follow the preconceived plan with as few modifications as possible. This is only partially true.
Of course, if you have each of the steps planned ahead and you simply cross things out of your to-do list without reflecting on them – you will get through the list fast enough. This will be efficient and you may feel like you are accomplishing a lot just by following a fixed plan. And in some types of workflow, this may indeed be the best way to go about certain goals.
But… what if, after having gone through all the steps on your list, you realize that this wasn’t actually the list you should have been following? That instead of arriving where you wanted to, you arrived somewhere close – but not close enough? You will most likely need to review some of the actions you have taken and redo them. Take a few steps back and correct the course. And this doesn’t sound that efficient anymore.
In software development, it happens all too often that the initial to-do list keeps evolving as the items on it are being checked off. In other words – the feasible way to achieve the end product might look different at different stages of a software project. And this is where agile thinking becomes of help.
Agile mindset assumes that things will probably look very different in a few weeks – in comparison to how they are now. That’s why agile development teams create a working structure at the beginning of a new project, but then they put a lot of impact on monitoring the progress and getting feedback on their work as often as they can. This way, they are able to adjust their next steps and carry out projects more efficiently.
The flexibility of the overall work plan is often extended into the flexible work schedule of each individual. Many studies show that employees (including software developers) who are in control of planning their own work are found be more productive, display greater job satisfaction and produce higher quality work.
– Monitor the project constantly, to be up to date with what needs doing at the moment – instead of relying on a plan made yesterday.
– Meet with your team daily and allow time for discussing current goals and issues.
– Maintain the culture of transparency in the workplace, so that employees feel safe enough to tell the truth about how the project is unfolding. More on the importance of trust and transparency below.
As Paul Blair stated on the Stack Builders blog – “Software development runs on trust”. As an agile software agency, we couldn’t agree more.
According to an article by Stephen M. R. Covey and Douglas R. Conant, there is a direct link between the level of trust in an organization and the speed at which things are achieved. When the trust goes down – the efficiency will inevitably go down as well. This can easily be illustrated by examples:
When a lead developer doesn’t trust her team in estimating the project, she feels compelled to review the estimations herself every time. When a product owner doesn’t trust the development team to deliver on time, he will make extra effort to micromanage their schedule. In both of these situations, the lack of trust leads to wasted time and resources, because people engage in redundant activities.
This means that, as Covey and Conant put it, “[trust in the company] is not a nice-to-have; it’s a must-have.” At least if you want to have an efficiently operating business.
Trust in around an organization is very much connected to being transparent. Usually, the more you trust somebody, the easier it is to be transparent and honest with them. But it also works the other way around – if you make all the work transparent for your business partners and/or employees in the first place, you will receive a higher amount of trust.
For efficient agile development, the meaning of trust and transparency is two-fold. Firstly, you want to be completely transparent with your client(product owner) about how you are planning to carry out the project. There is no room for hiding the solutions you are using or trying to cover up unexpected complications – they will be revealed sooner or later anyway. What works much better is building mutual trust by keeping an accessible project documentation everyone can refer to and by communicating openly both about accomplishments and obstacles in the project. We found that this is the best (and simplest) way make the cooperation as efficient as possible.
The second important aspect of trust in agile software development is maintaining trust as a high value in the company’s culture. It has been proven that “employees who perceive they are trusted are more likely to engage in behaviors that support the organization’s goals.” And it only seems natural that this is so – team members who feel confident to take responsibility for their work will obviously produce better results than someone who is constantly being controlled.
Creating a culture of trust should be among top priorities of any manager, team leader or CEO. By adopting a “high-involvement” management style (as opposed to “control-oriented” one) they can empower developers, designers and other employees to perform at their best. Again, this can only be achieved if they are feeling trusted.
High level of trust also infuses a collaborative spirit in the team – read more about it in the next paragraph.
– Keep proper documentation of your projects. Recording all the agreements and outcomes of your meetings creates a point of reference for everyone involved. It also saves you conflicts about “what was said before, but what no one really remembers”.
– Be open to communicating about problems and possible delays in software projects – also with your clients. Informing about obstacles gives everyone a heads-up on what to expect and saves you a lot of tension.
– Allow the client a possibility to monitor a project’s progress and share information with your employees. By allowing information to be accessible and public, you give everyone a non-verbal message that nobody is hiding anything here.
“Respondents place a strong value on working in a collaborative environment, where they feel their voices are heard and they have the ability to make decisions about their work.” – GitLab 2018 Global Developer Report
You might have heard about the collectively written book Tribal Leadership– an overview of 5 different stages of organisational culture. In the view of the authors, the companies that evolve into the 4th, and especially 5th stage of their work culture, value collaboration much more than the competition as a general approach to their goals. These are also the organizations that are capable of making a truly wide – even global – impact.
A competitive spirit can only take a software development company so far – and it becomes particularly visible if you work in agile. If one wants to make agile software development as efficient as it gets – there needs to be safe space for collaboration provided. A team can accomplish more than a bunch of individuals.
Why do we mention the “safety” aspect? Because if people are to collaborate openly, they have to feel that there is no need for them to compete among themselves in order to “survive”. For example: if a developer is to ask for help (which is an important part of the collaboration), she needs to allow herself to be vulnerable. She must be sure that reaching out for help will not threaten her position in the team – or in front of her boss.
This aspect is much the responsibility of the management – they need to create conditions in which employees don’t feel the need to constantly prove their worth and fight for the CEOs or managerial approval. In the words of David Mizne: “company leaders must create a context for behaviour instead of micromanaging individuals.”
As cliché as it may sound – in order to collaborate efficiently, software developers have to be able to be themselves at work. With as little pressure as possible, they will be able to not only produce their best work results – but also to move towards a common goal together with their colleagues. Agile software development facilitates such collaborative team spirit by incorporating various types of meetings into the workflow, encouraging transparency and open communication about what everyone is working on (and struggling with).
A big part of it is also being open to receive users and product owners’ feedback, ready to improve the product. The recurring cycle of “design-build-get feedback-improve” is the core of iterating and is one of the most important building blocks of agile. And in order for this cycle to keep going – a certain level of safety, vulnerability, and readiness to take critique is also required of software developers.
– Organize meetings in which everyone can update everyone else on what they are doing (i.e. daily stand-ups)
– If you manage a team – do not rate employees based on their outcomes, but rather – their engagement. In software development, the results can often be arbitrary and not reflect the effort put into the job.
– Make people work on tasks together – a great idea to do that is to implement mutual code reviews among developers. This makes people feel responsible for the same piece of work and facilitates collaboration.
Software projects are always complex, and for the development team, it can be very easy to get lost in the never-ending thread of tasks, research, coding… But, as you can imagine, getting lost is not a very efficient way of building software. Being able (and willing!) to focus on one thing at a time is a much better way to go about it.
Multitasking at work has been a praised skill for a long time. People would even include it in the soft skills sections of their CVs. But for the last few years, science has been revealing that multitasking is actually an unnatural thing to do for humans. Here are a few negative ways in which trying to do many things at the same time can affect employees – and their overall productivity.
Findings of psychology and neuroscience are unambiguous – anyone who wants to work efficiently needs to stop striving to multitask and learn how to focus on one thing at a time. First, it requires the willingness to do so and abandoning the idea that you can (or should) do many things at once. Second, it requires a systematic approach – especially in high-complexity jobs, such as software development.
In agile software development it all starts with breaking projects down into milestones, then epics, and eventually –specific tasks. Assigning each task to a particular developer (and keeping a transparent backlog) removes the confusion about who does what in a complex collaborative project. Additionally, clearly defined tasks give employees an incentive to work on one thing at a time until it is finished – and only then moving on to the next one.
Systematizing the scope of work through agile approach ensures that even a very complex project is under control. Each developer knows what they are doing and in which order – that saves them the trouble of having to coordinate their tasks WHILE they perform those tasks. The possibility to focus on one thing at a time is what really makes agile software development efficient.
– Break the project down into graspable pieces of work: milestones, then epics, then tasks. Use of checklists. Systematize the work. This will allow developers not to get caught up in the complexity of their work.
– Hold daily stand-ups: they allow everybody to stay focused on what needs doing in the next 24 hours – without getting distracted to do other things that can wait.
– Make sure you and your team take sufficient amount of breaks from work. This will allow you to keep your brain in good condition and will improve your focus in general.
If you want to learn how we implement the agile mindset at Ideamotive – stay tuned for our Whitepaper, which we are putting together just now. Request to receive a copy as soon as it is published by filling our contact form.
View all author posts
Patrycja Mach 15 min read
Michał Rejman 6 min read
Miłosz Kaczorowski 9 min read
Michał Rejman 9 min read
Michał Rejman 9 min read