Top 5 Tips: Improving your Agile team


If you have been a developer or a program manager at any point within the past 20 years, you have probably been introduced or exposed to the phenomenon known as agile methodology. You have probably run across people who praise the benefits of it at any opportunity possible. Likewise, you have probably talked to people who will say it is just the current popular flavor in the developer industry. Whatever your stance on the topic may be, there is no doubt that there have been proven benefits for projects that implement an effective agile development team.

To describe it succinctly, agile is a way of developing where teams embrace consistent change within their development processes and focus on customer engagement. While this post will not go into great detail the differences between more traditional approaches, I have to mention that the other methods used by teams have been wide ranging, especially in the planning phase. That being said, you may encounter the phrase “pure agile,” and wonder what it means. At its basic roots, pure agile means that the development team remains focused on the basic tenets of the Agile Manifesto, and do not let things like certain software tools, processes, or preferences distract from the manifesto.

Photo by NESA by Makers on Unsplash
unsplash-logoNESA by Makers

In this post, I will discuss in greater detail five great tips that can improve the effectiveness of common agile development techniques. Ranging from customer engagement, stand-ups, to management style, these are not meant to blindly be followed, as that of course would not be considered pure agile!

To describe it succinctly, agile is a way of developing where teams embrace consistent change within their development processes and focus on customer engagement.

5 - Effective Stand-ups

At its core, stand-ups are a recurring event, normally daily, for a development team where the team comes together for a brief amount of time, normally less than 15 minutes, and discusses what each person has been doing, what they are having trouble with, and what they will be doing. In this event, the other developers listen and chime in where they can help. Otherwise, stand-ups are used as a “formal” means to get a team’s entire status update on a project in a sort of “informal” setting (standing up around desks, normally).

So, what’s the issue then? For the most part, stand-ups aren’t a major problem area for agile implementations. Even if stand-ups were improperly handled, they are still typically only a short amount of time each time. However, the problem arises when they stop becoming short or the frequency of their occurrence makes them inefficient. What I mean is this: stand-ups are meant to be borderline-informal. This is so that they aren’t seen as full-blown meetings in need of preparation and planning. In an earlier post, I discussed the difference between the maker’s and manager’s schedule: as a developer, we need longer blocks of time to fully tackle our jobs effectively. Because of this, if stand-ups become drawn out or more serious, they can start to bring about an inefficient process.

The other consideration to make an effective stand-up for an agile team is perfecting the frequency in which they occur. Some teams are very modularized, self-driven, or are focused on separate projects. Bringing the whole team together has its obvious benefits in information sharing and collective problem solving; however, if the team is modularized enough to not need consistent daily meetings, why impose them on the team? If the team only needs sparing intervention from the scrum master or project manager, why cause unneeded stress? As you can see, daily stand-ups are meant to improve the team’s efficiency—if they ever begin to make things complicated, they must be dropped or re-evaluated.

4 - Communicate with the Customer/Product Owner

Another core characteristic to agile is its customer-focused approach to software development. The realization that the development of an application or program is ultimately for end-use by the customer is an important one. Without it, a slippery slope would arise where the program management team or even the development team would make the decisions and judgements on critical features that only the users and customers could realistically know.

So, where can this go wrong in agile development? A customer focused approach is typically the best way to implement agile; however, things can become murky if your customer, end-users, and product owner are different people. If you find yourself in this situation as a program manager or even as a developer, you will need to steer discussions and feature requests towards one focal party. For the sake of typical development teams, these new features should be funneled to the Product Owner. From there, the Product Owner can properly evaluate legitimate requests from spurious feedback, prioritize upcoming stories for a sprint for the team, and be a critical conduit for communication between the development team and users.

3 - Find the right, adaptive management style for your team

There is no perfect one-style-fits-all for management. Anybody who tells you otherwise either hasn't managed in the past or is lying. For developers this is especially true, as managers can sometimes be barriers between them and productivity, hearkening back to the differences in the maker’s and manager’s schedule. Even amongst developers, there is an entire spectrum of what kind of management is best. Some developers need and appreciate consistent feedback from a management team, whereas some developers thrive best with little to no supervision.

The worst thing that a project manager can do to a development team is assume that all developers can be managed the same. In an optimal environment, managers should be seen as people who developers can rely on for help when their help is needed. This mutually beneficial relationship can foster a great atmosphere where developers feel their work is valued and is not being hindered while managers get the results and progress they desire.

Photo by rawpixel on Unsplash

2 - Success through People, not tools or processes

Ultimately, any progress made on a project rests on the shoulder of the developers who create it and the managers that enable their success. You could have some of the best tools in the industry, the biggest company name backing you, or the most skilled project management software to support an application, but all of that combined will not necessarily create the project by timeline. Development efforts need to be allocated towards the right people, and investments need to be made to grow developers into efficient contributors.

Part of this issue finds its roots in when management expects results for a given development team. They might be able to provide the developers the tools and physical workspace needed to thrive, but if they forget about the human-factor in the developers then a project can run into issues. Take for example the common misconception that a developer can be a master of all hats, be it Database programming, front-end designing, back-end development, system administration, or application architecting. This is simply a lot of different roles to expect a developer to be able to fill; if a program management team thrusted these varied responsibilities upon each developer with lofty timelines, you can begin to see a breaking down in the relationship between developer and manager. Such an environment where work begins to feel unvalued or expected with no reward can severely reduce a team’s efficiency.

Development efforts need to be allocated towards the right people, and investments need to be made to grow developers into efficient contributors.

1 - Embrace change

This last tip is perhaps the most important and consequential facet of agile development. When there is controversy in a team on how to proceed with a dilemma, an option that should always be on the table is to change how the team operates. Perhaps your team’s daily stand-up is becoming cumbersome or a waste of time? If that’s the case, drop it or at least change the frequency of it. Maybe your team isn’t reacting well to pair programming and all the developers would prefer to code by themselves and then code review? Try it out next sprint and evaluate the results in the sprint review! The only constant in an agile team should be its ability to change and adapt to requirements, feedback, and obstacles.

Photo by Javier Allegue Barros on Unsplash
unsplash-logoJavier Allegue Barros


In pure agile, everything should be up for change and reconsideration if the old way isn’t working out. Perhaps these tips aren’t helpful or applicable to your development team? That’s perfectly fine! At the end of the day, there is no template, cookie-cutter way to implement an agile development team. Simply put, that’s not and never was what agile was meant to be.