Computers have been around longer than I have, but what I'm writing about today has not. Despite being relatively new, however, agile development has quickly become the holy grail of software development methodologies. It's here to stay and to grow.
The best place to start with any discussion of agile development is to define what it is. That could be a lengthy article in its own right, and the Agile Manifesto would likely be of little help to most. Still, everyone familiar with agile development has a sense of what it's supposed to be, often stemming from the word agile itself: It's about flexibility, speed, and reactivity in meeting or serving some need.
Agile is simply a development methodology that allows business requirements to be gathered from the end user and expressed to software developers so that they can understand what's being asked of them. In a sense, that's all that software development really is.
How you approach gathering these requirements, interacting with the business, and interacting with your team is what determines which methodology you are using. This might not be a watertight definition, but it is a good working framework: Agile is about change, speed, and dealing with the unexpected and unpredictable; it involves technology and innovation and ranges from operations all the way up to strategy.
Agile allows for increased customer satisfaction by promoting early and continuous delivery of valuable software. In the early days of development, change was hard and would not always fit. Agile allows for change and welcomes it, even it the late stages of development. Agile is fast, delivering working software in weeks (as opposed to months) through increased meeting, co-location, and direct business interaction.
That close, daily participation amongst all the business groups works wonders for development. Increased interaction brings trust among the groups and business partners and allows for daily standups with continuous delivery of code, changes and tweaks. Simple design allows self-organizing teams that reflect on what they do to become more effective and adjust their processes accordingly.
How to learn about agile development
So how would one go about learning an agile method, like SCRUM or any of the associated practices, that could help them at their workplace? The truth is that learning Agile is easy, as a practice. You get a group of people, you assign their roles, you create a burn-down-board, and you move forward with having daily standups. There are so many ways to get trained on this subject.
First, and arguably best, is on-the-job training. There is nothing better than sitting with a group of people and having them show you how something is done, learning from others or even learning all together. Next, you could use a traditional university — most now offer entire degrees in the field of agile development.
You could also learn agile development from online course offerings like this six-week course, available via edX and led by a Boston University professor and a Boston University fellow. This particular course gets into the differences between, and advantages of, various agile-adjacent management approaches: lean, design thinking, waterfall and agile itself.
The course focuses squarely on agile from a product manager's perspective — not that of a software developer or project manager. Students can expect to devote between four and eight hours per week. It is available as a standalone course, or as part of Bostin University's larger online Digital Product Management MicroMasters sequence.
No matter what other resources you choose, you could always grab a good book on agile and become an expert overnight.
Applying agile principles outside of software development
Can you practice and/or apply agile principles outside of software development? Most experienced agile practitioners will instinctively want to shout, Yes! Of course! — and I agree. If you look at the roots of agile software development — lean, agile manufacturing and organizational learning — then the answer is obviously yes. These ideas originated outside software in the first place.
Many other standard practices in agile also originated outside of the software realm, such as stand-up meetings, prioritization, and visual management. The team-oriented environment is something that any team structure lends itself to. In fact, many of these practices have become so commonplace that it is hard to say where they originated.
Some practices that originated in software development have been exported. For example, lean start-up is largely test-driven development at a company level. Other practices, usually technical ones like continuous integration, are restricted to software development — but even here analogous practices can sometimes be found elsewhere.
I have a good example from my own company, where the senior management team adopted quarterly offsite meetings. The regional managers from around the United States would fly in and the team would evaluate progress and execution, review and adjust strategy, and then prioritize and decide on next actions.
At the end of the week, the managers would return to their bases and follow through on the agreed tasks. This is agile on a large scale, with senior managers operating three-month iterations via weeklong planning meetings.
It is quite easy to implement agile outside of software development. All it takes is to understand the generic practices and have in place a team willing to make it happen.
The list of agile or agile-adjacent certifications is long. Any of these credentials will help you understand the methodologies and toolsets of agile, but more than they will prepare you to succeed and thrive in the modern business world.
The first one to consider is Certified Scrum Master (CSM) from Scrum Alliance. I have this credential and can vouch for it. Professionals with roles like developer, product owner, and business analyst can all benefit a strong background in Scrum. CSM gives you access to the essential agile system, as well as Scrum Roles, occasions, curios, and practices of the Scrum Framework.
Next up, you have Project Management Institute's Agile Certified Practitioner (PMI-ACP) credential. I have PMI's Project Management Professional (PMP) cert and can vouch for the overall excellence of their program. ACP certification conveys an elevated level of expert uprightness, as it is a blend of light-footed chipping away at agile undertakings and looking at agile basics and apparatuses.
Then you have Scaled Agile Framework or SAFe, which is the broadly utilized Scaling Agile system around the world. The SAFe Agilist (SA) certification program is for administrators, supervisors, and agile change operators who are answerable for driving lean/agile change activity in a huge programming venture.
You could also consider becoming an Agile Coach. ICP-ACC authentication could be a distinct advantage for you. It helps you to create proficient instructing aptitudes by being able to separate among preparing, tutoring, and training. Undivided attention and amazing addressing are the key capacities for a mentor.
Training abilities give you access to building a group that can discover answers to problems themselves. ICP-ACC needs three days from a licensed foundation and doesn't require any assessment, as the attention is more on plentiful utilization of talks, case studies, and hand-on practices in a homeroom session.
No matter how (or whether) you choose to pursue certification, if you are looking for a career change or just to help out at work, then agile may be the way to go. Check it out and, as always, happy certifying!