DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Exploring Leading Software Development Methodologies
  • Adopting Agile Practices for Workforce Management: Benefits, Challenges, and Practices
  • Agile Frameworks in Action: Enhancing Flexibility in Service Delivery
  • At What Point Do Agile Teams Allocate Time for Innovation?

Trending

  • Distributed Tracing Best Practices
  • Spring Boot and React in Harmony
  • Automated Testing Lifecycle
  • Wild West to the Agile Manifesto [Video]
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Agile Monkey Methodology

Agile Monkey Methodology

Agile is not about moving faster, it's about adapting to change quickly.

Phillip Kruger user avatar by
Phillip Kruger
·
May. 10, 16 · Opinion
Like (8)
Save
Tweet
Share
5.43K Views

Join the DZone community and get the full member experience.

Join For Free

Image title

The PM becomes a scrum master, MS Project (or something similar) is replaced by a Jira account, Dev teams have stand-up meetings every day, hooray! We have done it! We are now agile!

Agile. Possibly the most misunderstood methodology in big corporate companies today.

I think the problem, as with many things in a big corporation, is that growth/progress does not happen naturally. It's orchestrated with new teams, more people, and more money.

So when we decide to "go agile" the first thing we do is to get a consultancy company in to help transition the old waterfall team into an agile team. (The second thing is an Atlassian licence)

We learn how to become agile, rather than what agile is, and what we end up with is some mixture called water-scrum-fall.

Define Agile

Able to move quickly and easily.
"Ruth was as agile as a monkey"
    Synonyms: nimble, lithe, supple, limber, acrobatic, fleet-footed, light-footed
    Antonyms: clumsy, stiff, slow, dull

So the main goal of "going agile" in your company is to be able to move quickly and easily.

If you have already gone agile, and you are not moving quickly, easily you have done something wrong.

Lets forget about how. Forget about scrum masters, sprints, stand-up meetings and yellow post-it notes on the white board. All of that are merely suggestions on how to potentially become agile. If you blindly implement this it becomes a ritual — yet another process. Lets start with the agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Or, let me put this in my own words:

  • Individuals and interactions over stand-up meetings, sprints, and Jira
  • Working software over signed-off BRD
  • You have to involve business!
  • It's OK to change your mind. It's OK to do it wrong initially.

Most of the time we are just a waterfall team in agile clothing.

Including Your Business Unit

Usually the business units hear about this thing called agile that will get them their solutions quicker. Of course they want that! Who would not?

They do not really want to know anything more: "Just deliver quicker please. Use agile!"

You have to (really have to!) involve business if you want to become truly agile.

In fact, I would argue that breaking down the line between business and IT will do more for your agility than any sprint or stand-up meeting.

It's Not About Speed

Image title

Over time, there might be no difference in the speed of the delivery if you compare waterfall to agile.

Who knows? (It will be very hard to compare.) But let's say for example that you know exactly what you want. You:

  • Plan for a month
  • Do some analysis and specs for another month
  • Create some architecture documents for another month
  • Implement the solution in 2 more months
  • Do a month of testing
  • And do a big, flawless implementation into your production environment over some weekend.

6 months later and you have your solution in prod, working like a dream.

Doing this the agile way might also take 6 months, maybe more, maybe less. You are just implementing this, feature by feature, into production until everyting is done.

Agile is not about speed!! It's about the fact that we rarely know what we want, let alone what our customers want. It's about the ability to change quickly.

So going agile allows us to move the end goal around. We do not have to know where we will end up. Let your customers guide you.

So when the client (or business) says "Hey, what about this ?" or "Can we please add feature x ?"  or  "Why did you not think of y?" in a waterfall project, if all went well, you say, "No problem, I did think of that, let me quickly enable that." (yeah right!), whereas in agile you say, "No problem let's quickly add it."

Project vs. Product

That's why it's also better to think of a product rather than a project. A project usually has a start time, end time, and a set of features. A product has versions and features and evolves over time. A product might never be done. That's OK. We are not building a house :)

Adaptive vs. Predictive

Another nice way to think about it is Adaptive vs. Predictive. With waterfall you have to predict into the future what needs to happen. You have to get this right, else you waste time (and we all know time is money).

That is why you plan. That is why you architect to cater for all sorts of possible changes. There are many books with all sorts of patterns to help you implement a system that can do more than what the client wants to try and cater for future changes. You have to get it spot on though, and that is close to impossible.

Don't get me wrong, I am not saying that implementing architectural patterns is wrong. It's just that sometimes we overengineer a system because we need to predict the future. We should rather become more adaptive to change, because change is the only constant.

Agile Principles

Lets look again at some of the agile principles, and make sure that we adhere to this rather than blindly following some rituals (Yes - you can be agile without stand-up meetings, sprints and post-it notes).

"Business people and developers must work
together daily throughout the project."

This is where the stand up meetings come from. The goal behind the stand-up meeting is to force business and developers to interact. You can also achieve this in another way, eg. make the project teams (business and developers) sit together.

"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."
"The best architectures, requirements, and designs
emerge from self-organizing teams"

Very important to give them the environment and freedom to get the job done. Enable your team. Decentralize control.

"Continuous attention to technical excellence
and good design enhances agility."
"Simplicity — the art of maximizing the amount
of work not done — is essential."

Do not do big up-front architecture. Evolutionary architecture and clean design principles are the way to go.

"Working software is the primary measure of progress."

Yep - not the number of Jira tickets closed!

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

We do not complain that business changed their mind again, in fact we encourage it. Change is OK!

"Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software."

We need to get working software in Production, no big bang implementation. (Remember Production does not necessarily mean Live).

See http://agilemanifesto.org/ for more.

Conclusion

Don't get caught up in the rituals.

Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming...

These are all great methodologies that all got together to create the agile methodology. It does not really matter what methodology you follow, just stick to the agile principles. Be pragmatic. So do not let your rituals, processes, and tools force you in a direction, let your agility use processes and tools to help implement the agile principles. If it does not work for you, let it go. Measure yourself against the delivery of working software. Continually improve.

Do not try and force agile onto a team, rather make sure that the natural operation of your team is agile. Enable them to become agile. Agile like a monkey.

agile scrum

Published at DZone with permission of Phillip Kruger. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Exploring Leading Software Development Methodologies
  • Adopting Agile Practices for Workforce Management: Benefits, Challenges, and Practices
  • Agile Frameworks in Action: Enhancing Flexibility in Service Delivery
  • At What Point Do Agile Teams Allocate Time for Innovation?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: