People talk about agile all the time at work these days! What does it mean to be agile though?
The Oxford Dictionary defines "agile" as:
1. Able to move quickly and easily, ex.‘Ruth was as agile as a deer’
1.1 Able to think and understand quickly, ex. ‘his vague manner concealed an agile mind’
So, do agile teams all gallop around the office like deer? No! But the spirit is the same. An agile team is fast, responsive, collaborative, and generally awesome.
Origins
The origins of formal agile development can be traced back to 2001 to a group of developers who got together to discuss the best way to, well, develop! They wrote what is called the the Manifesto for Agile Software Development. Despite its archaic title, it's a very readable and simple document.
According to the Manifesto, here's what agile software development is all about:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Let's break down some of these principles.
Individuals and interactions
Viewing humans as the key to successful products and development is a fundamental part of the agile workflow. Getting lost in a labyrinth of services, formal processes, and arbitrary things to do results in bad experiences. Layers and layers of tools disconnect the development process from its ultimate users: human beings.
This is why it's sometimes easier for small startups to adopt an agile workflow than for enormous corporations. There is less infrastructure and more possible mobility. Implementing agility within behemoth teams that already have existing processes is very difficult. Depending on project needs though, it may be worth it!
Lisa wants something done -> Linda files a request -> Linda waits for approval -> Linda gets approval -> Linda must formally request time from her collaborators -> Linda needs a new service so has to file a request with the finance department -> Linda waits 6 days for her request to be approved -> Linda finishes building her project -> Linda sends it off to the QA team to have it tested, but the tool that communicates with the QA team bugs and takes 3 days to be fixed-> Linda gets the green light from QA 3 days later -> Linda releases the project.
Linda wants something done -> Linda involves collaborators she knows are free and interested -> Linda uses the company expense account to immediately buy the service she needs -> Linda and her collaborators test their code themselves -> Linda releases the project.
Working software
This piggybacks off the preceding point! It's better to have code that works than code that took weeks longer to ship because of heavy process and documentation.
Let's not mistake this point for saying that documentation is bad though! Writing great documentation can be an engaging and helpful way to involve others in your code projects. It can also help clarify project needs and clear up misunderstandings between collaborators. Just find the right balance!
Customer collaboration
Customer collaboration is a fascinating and unique part of agile software development. Try to think of some benefits of having customers (or "users" if you prefer) involved in a project-building process.
Firstly, involving users as early as possible in the process means that project needs are aligned immediately with the person benefiting from the project. Projects with user input are often more intuitive than projects built just by developers.
Secondly, user-input can harmonize different features because the features are destined for the same person. Even throughout multiple iterations, a feature's development remains guided by its destiny: the user!
Responding to change
Everything on the web is transient and changeable. Think about your favorite websites; odds are they look nothing like they did even 5 years ago! Things move fast (which explains the famous Facebook expression "Move fast and break things!").
A key word in agile development is iterate. Iterating means constantly updating and improving a feature. It's okay to ship a first version of a feature even without every single functionality. They can always be added later, and a good, fast feature release is better than a perfect one that takes 2 years. Ship it!
Another component of agile development is the sprint. We'll see more about sprints in the next chapter on scrum methodology, but generally a sprint is a defined timeframe in which certain things must be shipped. Say there's a 30-day sprint system; this means that at the beginning of a 30-day span, projects (small and large) are defined for the sprint, and boom. It's off to the races!
What's the magic feature shipping rhythm?
This totally depends on your team and projects. Consider your developers, company, product, and users. Having a global vision of these elements can hopefully let you define a shipping/release rhythm where, every __ days/weeks, there are new iterations and features put out.
Extreme programming
"Extreme programming" doesn't mean we're all going snowboarding and coding at the same time. 🏂💻
It's actually perhaps the purest and simplest form of agile development! The word extreme comes from its emphasis on taking the best parts of programming, like iterations and pair programming, and taking them to an extreme level.
Described by Kent Beck in 1999 in his book Extreme Programming Explained, the practice of extreme programming encourages openness to change, automated/widespread testing, simplicity, and collaboration, among other things! The book has been released as a second edition as well.
Extreme programming mechanisms
Which mechanisms allow for this? Many programming concepts that you already know, such as pairing or standup meetings, actually foster agility and play into the extreme programming model!
Watch this video by Clean Coders for a fun and interesting introduction to Extreme Programming (done by Robert Martin, who was one of the coauthors of the Agile Manifesto):
Check out how these extreme programming/agile concepts all play together:
Whether you call your workflow agile, extreme, or something else, constant collaboration and acceptance of change is a revolutionary thing in a development team. Some teams rigorously subscribe to agile methodologies, taking them as gospel 🙌 while others integrate a little agility here and there. It depends on the team and their needs.
There are even more workflows that tap into these practices that you'll see in the following chapters!
