Introduction to the Agile Methodology for Non-IT Teams
The corporate world has a knack of taking groundbreaking concepts and wrapping them into incessant layers of jargon, doctrines, and certifications. Sometimes, rendering them unrecognizable.
The latest concept to fall prey to this is agile methodology. You might have heard this phrase thrown around often in your office. If you are from a non-IT background, you might have wondered what it’s about. In this post, we’ll explain the agile methodology to you, in the true spirit of its founders.
Software development in the 80s and 90s used to involve heavy-duty planning. Similar to the mantra of “the more you sweat in practice, the less you bleed in war”; it was believed that the more extensively you planned, the less time you needed to spend on coding. This made perfect sense to almost everyone. After all, civil and mechanical engineering had prospered on these principles since the dawn of civilization. So what was the problem?
Software development is a different beast.
The industry requirements and trends in IT change rapidly. If you take too long to build software for your client, their requirements might completely change by the time you finish. Software developers wanted a methodology that could help them serve clients better. And do so with minimum friction.
In 2001, a group of software developers united by their frustration for rigid processes met in Utah. They drafted a set of 12 principles that later came to be known as the Agile manifesto.
Agile methodology is more of a mindset than a codified process. It’s a philosophy that seeks to put customer’s dynamic requirements at the center and meet them by continuous delivery and iteration of the software. This is in stark contrast with traditional software development approaches like the Waterfall where each stage is meticulously planned. It’s almost impossible to go back to a previous step and make changes (hence the name waterfall).
If you had to remember only one thing about agile methodology, simply remember that it’s the mindset of satisfying customers by optimizing your process for their changing requirements. All other principles are simply guidelines to enable that.
Agile methodology by itself doesn’t make any rigid recommendations. However there many specific structures that your team can adopt to become Agile – the most popular of them is Scrum. Some people incorrectly believe Agile and Scrum to be the same thing. For now, simply remember that Scrum is one of the many Agile structures that a team can use. Agile is a philosophy. Scrum is a process.
Agile was initially created for software development but with widespread globalization and increased competition, even traditional industries started looking for ways to accommodate dynamic business requirements.
For example, earlier a firm might reach out to a consultant to do market research if it plans to enter a new market. The consultant might take 2 months to finish the research and present its results. Nowadays, in those two months market conditions can change rapidly, so can the business requirements of the firm. It becomes important for the consultant to work closely with the firm, present their recommendations frequently, and iterate based on the feedback.
Agile methodology is now widely used even by non-IT teams. According to the Project Management Institute, more than 70% of organizations use agile methodology and Agile projects are 28% more successful than traditional projects.
12 Principles of Agile Project Management
The 12 principles in the Agile manifesto focused on software development. Without losing their essence, we’ve modified them to also be useful for non-IT teams.
1. The highest priority is to satisfy customers through early and continuous delivery of business services.
This means that rather than working on delivering your product or service in isolation and then sending it to customers, involve them in the process. Continuously iterate based on the feedback. This might not be possible for all industries but can definitely be done for many non-engineering functions such as – marketing, sales, and knowledge-based services.
2. Welcome changing requirements, even late in your project
The project should be structured in a way that allows you to incorporate the changing requirements of your client at any point. This can only be done if the client is kept in touch with the progress at all times so that there are no nasty last-minute surprises.
3. Deliver project milestones frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
Avoid situations where the client is kept in the dark for months at an end. Find the right cadence of delivering updates of your project. This might mean that the final results might be different than those envisioned during the planning phase. But they’ll be more suited for the client’s existing requirements.
4. Collaborate with client-facing teams daily throughout the project
If your profile doesn’t involve client interaction, then work together with client-facing teams in your organization to keep in touch with business requirements. For example, if you’re a writer working on a technical user guide for a specific client, make sure that you talk daily with the sales team to align yourself with their expectations.
5. Organize projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Project managers often get caught up in the technical details of project management and ignore one of the most important ingredients of success – motivation. Each project member should feel supported and interested in the final goal of the project.
6. The most efficient and effective method of conveying information to and within a team is face-to-face conversation.
Although team messaging and collaboration tools are immensely useful, there is no substitute for face-to-face conversation. It has the least chances of miscommunication. That’s why a lot of Agile teams have daily standups for a few minutes to discuss the progress of projects and plan the day’s to-dos.
7. Solutions that offer value to clients are the true measures of progress
A project consists of a number of moving cogs. Not all the work that you do directly offers value to the client. Some tasks are for internal processes, some for better planning. However, the progress of a project should only be measured in how much value it has given to the client. For example, a client has asked you to create high res wireframes for their app. You spend 3 hours on a meeting to plan the deliverables and then another 2 hours creating an internal project to first create low-res designs. From an Agile perspective, the project hasn’t moved an inch. If the client gives feedback and approves of the low res designs, you can then confidently say that the project is progressing.
8. Agile processes promote sustainable development
A sign of a well-implemented Agile methodology is that it maintains a constant pace throughout the duration of the project. There are no panic-ridden all-nighters towards the end and no dilly-dallying in the beginning. The project progresses with a consistent cadence.
9. Technical excellence enhances agility
Because the Agile methodology puts more trust in the teams compared to traditional project management practices, it places greater emphasis on the technical skills of the people. Only a skilled team can comprehend feedback and iterate their project consistently to satisfy clients.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
Every project consists of three kinds of tasks – 1) tasks that serve real value to stakeholders, 2) tasks that help the team internally, and 3) tasks that were created in the planning stage that don’t offer real benefit to anyone. To be agile, you need to maximize the time spent on tasks that offer real value to clients. That can only be accomplished if you reduce redundant tasks that are often offshoots of bureaucratic procedures. This is occasionally misinterpreted to mean that one should avoid all planning and documentation. That’s not true. You should ensure that every documentation or a procedural task should serve a goal and not be performed for its own sake.
11. High quality work emerges from self-organizing teams
In order to iterate rapidly and drive projects seamlessly, the team needs to be empowered to make decisions on how the project is managed. They are permitted to make mistakes and invent solutions as long as they deliver and learn from their mistakes. Micromanagement and top-down heavy planning are counterproductive to Agile teams.
12. At regular intervals, the team should reflect on how to become more effective
Agile teams continuously evaluate their processes, not just based on client feedback but also on self-evaluation. In the most popular Agile framework, this is done by having a retrospective at the end of each sprint. Sprint is one timeboxed iteration (usually 1 – 4 weeks) of the project. During this retrospective meeting, the team analyzes their sprint and looks at areas of improvement. Efforts are made to fix those areas in the upcoming sprint.
Now you understand the basics of the Agile methodology. Remember that because Agile is more of a philosophy than a process, you might get different interpretations of it from different project managers. However, its core idea remains unchanged – satisfying customers that have changing requirements.
If you would like to try out Agile methodology in your next project, sign up for a free trial on Taskworld. Kanban boards are the easiest way to organize Agile projects.