Ever since its initial inception back in the 70’s by the pioneer Dr. Winston Royce, the Agile Project Management methodology has been the standard, go-to method, of implementing a software project. Nowadays, IT businesses have to compete on constant innovation and fast deliverables of high-quality products and the iterative nature of Agile, that allows constant product tweaking without disrupting the overall flow of the project, is one of the reasons every modern organization strives for agility.

Not only does Agile talk the talk and promises faster and more qualitative deliverables, increased productivity and a transparent, visible, project catered towards the final users’ needs increasing their satisfaction but also, walks the walk; the 13th Annual State of Agile Report claims that 6/10 businesses have indeed been reaping the above-mentioned benefits since they first implemented Agile processes.

What about the other 4?

The majority of businesses in the Information Technology sector have been quick with adopting Agile practices but, alas, not all of them have been using the methodology effectively. Using Agile methodologies in your organization and being an Agile organization are two completely different things and in this article, we will try to offer some points for consideration (and a handful of Dilbert comics) in case your Agile practices have yet to be 100% fruitful.

1) Check The Manual

Image by Lynne Cazaly

The Manifesto for Agile Software Development was created in 2001 by a group of Software Engineers and serves as a declaration of what Agile stands for; the commandments of Agile Software Development, if you will. By carefully and methodically re-reading the 12 Principles written in the Manifesto, there is a good chance you find that your organization does not abide by them at all or that it follows them blindly.

The truth lies somewhere in the middle as the manifesto is neither a strict set of laws that Agile entities have to follow no matter their environment nor a list of scribbled notes that you can completely disregard.
It simply serves as a set of general guidelines that explain the paradigm of the Agile Project Management and that you can take notice of and properly adjust to your organization’s and business units’ individual characteristics and needs.

This brings us to our next point.

2) Check your Culture

Source: Dilbert.com
You better check yo self before you wreck yo self - Ice Cube

After carefully re-reading the Agile Manifesto and before disregarding Agile practices altogether, consider if your business can support them. Conduct Hypothesis Testing and Needs Analysis to determine whether or not a more robust approach towards project development, meets your company’s culture, your customers’ requirements, and your units’ needs. It appears that Agile is more effective in companies that follow a less top-down and more leveled organizational structure, regardless of their size.

You may find out that your organization is built to operate with more bureaucratic processes, that is risk-averse with attention to micro-managing to avoid mistakes and offering more standardized products to its customers via waterfall-esque projects and if that’s the case, your first step would be to try to re-wire the cultural blocks that have probably plagued every Agile project you’ve ever initiated. Such a process will be long and tedious and it would require training and coaching on every organizational level but, it is something your company has to go through to gain the most out of Agile implementation.

If a cultural change is not something you can go for in your organization, instead of brute-forcing a change, consider outsourcing your projects to an already Agile team. After all, hastily enforcing practices that are not in tandem with your company’s culture without proper Change Management first, results in low user acceptance and may be the reason why your Agile Organization, is not very agile.

3) Check your Communication

Source: Dilbert.com

Another important point you need to look into in case your projects are not delivering what you initially thought is your communications. The success of an Agile project relies on constant, crisp and transparent communication with every stakeholder. Establish Communication Standards (DDD anyone?) as people from different teams may have a different interpretation of your abbreviations.

Having said that, cut abbreviations and jargon altogether as they do not offer much and instead explain every process, every story, every requirement, as simply as possible so that every team is on the same page. Your Project Manager or Product Owner must be able to align the project’s scope with the goal of each individual story and each individual sprint otherwise the development team won’t be able to see the forest for the trees effectively tarnishing the quality of their work.

Moreover, embrace both formal and informal communication and design a workspace that allows for team collaboration and discussion both during work and during breaks. That means cross-functional teams and no silos, open and welcoming spaces filled with whiteboards, Kanban boards, and post-it notes as you want ideas to thrive and flow freely and challenges to be tackled in a collective manner; as a team.

Last but not least, along with checking the quality of your communications, you also have to care for their quantity. Embrace daily stand-ups, for your teams, where everyone's tasks will be explained and aligned with others’, introduce weekly meetings with every team to discuss blockers and have everyone try to offer solutions and also, communicate with your stakeholders before your next iteration.

There is no such thing as over-communication when it comes to Agile practices and timely and to-the-point discussions can make it or break it for your project.

4) Check your Product Quality

Source: Dilbert.com
Continuous attention to technical excellence and good design enhances agility.  - Agile Manifesto

Just because you are not a Six Sigma expert, that doesn’t mean that you can let defects go through; testing should be a priority. This is a common mistake many Agile teams make in their projects as, sometimes, they can be too focused on delivering the product as soon as possible, that they disregard its quality. Every task, every sprint and every iteration should be tested before being implemented and perceived as finished. Finally, as discussed above, your cross-functional teams should include testers in them in order for them to be briefed on the current stage of a project (rather than backtracking) and in order to proactively resolve mistakes so that you can save time from the overall project.

5) Check your Priorities

Source: Dilbert.com

Your Project Manager or Product owner should be able to prioritize when it comes to backlogs and break down every task into smaller ones in order to increase team efficiency and, as a result, team morale. Failing to do so, will result in longer sprints that will lead to overworking and dissatisfaction and to the belief that Agile does not really work.

6) Check your Team

Source: Dilbert.com

Building self-sufficient teams that can work well together is not an easy task but, it’s something pivotal and necessary for an effective Agile project. From the Project Manager to the Product owner and down to the last developer and tester your teams should function as a unit and every member should complement the others by improving upon their strengths and covering their weaknesses; a group of like-minded people that can think and act like one person.

Kinda like these guys!