How to Deal with the Monolith

Not all developers deal with big web sites or applications but many who do know this kind: The Monolith!

Some characteristics:

• Lots of code; probably hundreds of thousands of lines all together.
• Long history, relatively speaking.
• Project based development approach.
• No real describable architecture, chaotic organization.
• Hard to change, slow (and costly) to work with.
• Virtually irreplaceable.

Anatomy

Behold, the Monolith! No, it does not have to be one website; it can be many, but all interconnected tightly. There could be all kinds of examples, but here is one, and it will demonstrate the anatomy of this monster. In some sense, it is even hard to depict this thing because there is no clear cut way to make a sense of it in the first place.

Database

Databases, many of them, typically somehow interconnected. It could be database links, shared views, remote queries, stored procedures talking to other databases. The common denominator here is that at some point in history people felt that databases are a good place for application features and functionality. In fact, often it is very easy to integrate features and data across databases and then build stored procedure layer on top of it - all in the name of "databases must have a stored procedure layer", and that "code should be close to the data, and therefore a lot of it must live on top of the database engine". DB vendors have built all kinds of stuff people can use, so crafty developers (often DBAs) get ideas how to utilize them. 

Shared Data Access

Good developers try to layer their software so they create data-access layers. But since you need to build features based on all sorts of data, you can therefore connect to any database. This is acceptable to a developer who is under deadlines, and other pressures, or simply because he does not know better. We are also good citizens so we try to reuse software and depend on other such libraries to do our bidding.

Web Layer and Business Logic

Applications need to do some work, often referred as business logic. Typically, you'd create some kind of layer for this kind of behavior but the reality might be that no such thing really exists. More likely, this type of code is stuffed right in to web controls, page backing code, or anything comparable. Also, remember the good old database and stored procedures which seem to do a lot of this work, too. This code is all over the place, and so much so that you have really hard time understanding what is going on. Over time people just copy pasted bits and pieces of this functionality where ever it was needed because there are no rich models or anything resembling a layer that you could utilize.

In the end you have some kind of pancake for business logic and web layer all intertwined. There might be some attempt in Model View Controller (MVC) type of thing, or any alternative Model View View Model (MVVM) etc, but all of it is there mostly in name only. Say, you had to build a mobile view to support mobile browsers; well, good luck building it in the same web app.

How Did It Happen?

I already alluded to this but the classic Big Ball of Mud document is a pilgrimage destination for anyone who wants to know. The Monolith is really just a version of the shanty town architecture described in BBoM. 

So, it is more or less inevitable, and understandably so. Projects are a mainstay of work in any typical organization. Projects have boundaries based on some finite feature set that limits your design space. The focus of work jumps around between largely unrelated projects. People who do the work keep changing; people come in, people leave. There might be many teams, or there are really no consistent teams at all. These patterns keeps repeating year after year, project after project.

Not only that, but to the dismay of software developers, many stakeholders have no stake at all in creating good architecture, nor are they interested in paying for it. There might even be little chance that you can explain to them why they have to do it in the first place. In fact, they might even be sympathetic to your concerns but as the next project rolls in, it is clear to you that they still expect you to deal (almost exclusively) with stuff that matters to them.

How do I Survive?

Considering that you have a big web site (or any other big application) and you have this kind of problem, where do you even start? Your approaches are:

• Rewrite the entire thing
• Rewrite it piece by piece
• Surrender

The Big Rewrite

This approach often sounds attractive but unless you have solid support and business need from stakeholders and management, this is not going to happen. Usually if this approach is taken, the system is so bad that it threatens the business in some way. Or, in the happier case, the organization has ample resources and time, so the project is taken on because there is some related business opportunity, but rarely so.

Rewrites may take a long time, and are costly and risky projects. You will also have significant difficulties capturing business rules, and old functionality of a system that has been cemented in a messy and incoherent code base. Flipping a switch on an entire system is a difficult thing to do and requires a lot of strategizing and thought.

Rewrite Piece by Piece

This approach requires taking every opportunity to improve the system. You will spend significant amount of time in all your projects cleaning up things because projects are typically the only effective vehicle for this work. This will stretch all project time lines so you need management support for your work still, but you may have a better luck selling your plan because of the piece meal approach.

To avoid some undue costs, you may limit yourself to working on fixes on the parts that are core to the system or are causing otherwise constant and significant costs to maintain. How do you know what is core? It is usually a part of the system that requires constant work to support the business. This focus may shift over time, as the business shifts focus, so it is not the same thing forever! 

Surrender

Some systems do not require changes often. It may not be worth the rewrite or any kind of fix campaign. You probably just want to stabilize the system to keep it going in this case. You may never get the management support that you need to do the work, either. These may be things that you do not like, but it is still a scenario that can happen.

Strategies

I will review a couple of strategies how to do a piece by piece rewrite. I think this is the most common workable scenario for big systems.

Transform from Inside Out

What I mean by this: 

• Establish modularization
• Utilize layering
• Use common infrastructure and frameworks
• Use proper Object Oriented Programming. (use Domain Driven Design etc.)

All this type of work would be done inside the Monolith application to slowly make it better from inside out, so that we eventually end up with a workable application.

This may be your first stab at the problem so this is an obvious choice. I certainly tried it. I would just say that this strategy has its limitations if your system is rather large. If you are looking at a scenario like in the anatomy picture, you are not likely to win with this strategy.

The Monolith actually has inherent gravity that does not allow you to escape into a green garden where you can maintain your newly hatched good software. You may rewrite parts of your system, but you almost never can remove the old code either because of the messy interconnected nature of The Monolith. You are also still being limited by the project nature of work which does not give you the room or freedom to roam in large swaths of software to detangle and replace things. In addition, you may attempt to aggressively create 'reusable' code and libraries but forget that reusable code creates tight dependencies, which is roughly the opposite of what you really want to achieve.

• Your new code and libraries simply add more weight. It's still a monolith but now even bigger!
• You can't isolate yourself from the bad parts very effectively to escape the gravity.

Break the Monolith

I would favor this strategy because it starts to deal with the actual problem. Break off your monolith into smaller applications, that then forms the system. No matter how messy your system is under the hood, on a conceptual level, your monolith still has groups of features (as seen by the user) that go together. These are the natural fault lines between the applications that you want to split off from the Monolith.

Your challenge is to detect the fault lines, take a scalpel, and cut. When doing so, you will copy code, even duplicate databases, and it is OK. You simply want to create an app that functions largely in isolation, from the database level up. The main rules is: share as little as possible, and copy over sharing.

There are many benefits to this approach:

• Much smaller and manageable application.
• You can change it in isolation without breaking something else.
• You can assign a team to work on it.
• You can do this gradually, piece by piece.
• You can choose any technology stack for the app.

The main challenge? Integration with other parts of the system. But note how this is the exact same challenge that the monolith sought to solve! The monolith approach was simply to share code or share databases etc. But, that is a bad way to integrate big systems because you can not operate, manage or change things that are too tightly integrated. Every system has bad code, so that is not even the main point here.

Also, now you can circle back, and "Transform from Inside Out" each of the small applications that you split off. So, first split, then transform. If you have the luxury to rewrite the split off app, then you can do that, too!

Anatomy of an App

So, what should these applications look like? None of this is a big secret, but let's go over it anyway. You break off your first app from the monolith, so what should happen? 

• Your app should run without the monolith; it does not care if the rest of the system runs or not, and it is happy to do whatever it needs to do without the rest.
• Your app has some data storage typically, a database if you will. The difference here is that it is not shared with any other app. This data is completely private to the app, and all the code that lives outside this app never touches this data.
• Your app integrates with the monolith or other apps by asynchronous messaging or by web level services. The integration is governed by contracts that are agreements about what goes on the wire and how to talk to the other side. Now, your app will own the contracts for the integration points that is chooses to advertise. There is no other way for another app to get access or visibility to the services.

The point of this approach is to protect the application from getting locked up in ways that prevent us from changing the innards. You do not want to sink back to the situation where you can't change your app because the way you chose to integrate things.

I would invite you to read Pat Helland's Data on the Outside vs. Data on the Inside to fully understand what needs to happen here to protect your app.

One final point is to not go overboard. Do not create too many micro applications, but choose bigger cohesive collection of features that go together. The size may vary, but when you start to look at a pile of code that is several thousand lines, there might be something worthy of a separate app there. Integration is not the easiest thing in the world to get right either, so do not create unnecessary work and complications by creating applications that can't really function on their own. There should not be that many integration needs if you get the size right, though that depends on the nature of the application just as well.

Monolith Conquered

Once you have taken this path, you may be looking at something like the picture below later. You have now split your big monolithic monster into manageable chunks that mostly just hum along on their own.

You will copy reference data via messaging, and integrate web features using typical web integration techniques. 

Messaging

Messaging is important for several reasons. It helps you to build loosely coupled apps, which is what we are looking for. Here you have the applications fire one-way events that other applications can subscribe to. I would not favor bidirectional request-response patterns here; we can use the web for that. 

For example, if you have an application that handles user profiles and login, you may fire events related to things that users do in that app. 

• Account Created
• Account Closed
• Account Edited
• User logged on
• User logged out

... just to give a few examples. Pat Helland's document gives an idea what the messages should look like on the wire. The main idea is not to leak details about the internals out in your messages that bind you to other applications too tightly again. So, do not use your internal models on the wire! This is what the contracts are for. The second important thing is to "tell" what your application is doing, rather than tell some other application to do something. This is sometimes called the Hollywood Principle or Inversion of Control.

If you then require reference data, or your application needs to react to something that another application is doing, you subscribe to the relevant events. Once you receive them, you act on the events, and do what your application chooses to do. You can store data in your internal database, or fire up processes to do work. Regardless, it is up to the app to decide how to react, and it may even send events of its own based on its internal processing.

This type of integration allows you to create loosely coupled applications, but also allows very rich interaction that often responds well to previously unseen needs.

Web Integration

Often, big web applications show information on the screen from various feature sets. Your front landing page may show some popular articles, forum threads, and other distilled user content. These views may then come from a number of applications that you have split off.

This creates an integration problem that you can solve on the web level.

• You may pull views on the server side.
• You can use Ajax to let the browser render the views.
• Or you can use some hybrid where you pull data from the server, but render on the browser.

There are different challenges to these approaches that you may have to solve, but generally, it is all doable with considerably little effort. I would favor integration in the browser if it is any way feasible because the browser has a sophisticated web page loading and caching model that avoids a lot of problems on the server side.

Try to keep all web artifacts including JavaScript and style sheets with the application that owns the web views you are serving. This way,  you can make integration very painless and clean.

Web Infrastructure

A couple of words about web infrastructure you can use to build your apps and integrate it all to a big application. You may ask how to deploy such an application in pieces? Two main approaches comes to mind:

1. Deploy to web container, such as Tomcat (Java) as a WAR (web archive), or IIS with .NET as virtual web apps, to build one web site.
2. Use a reverse proxy to build a site from a number of servers and web containers in them.
3. Combine the two so you can scale any app as you need, but let the user see just one web site.

Summary

It is possible to build reasonable size applications that mostly stand on their own, scale on their own, and you do not suffer from the monolith mess. You can assign teams to the apps, and you can fix the internals in separation from other applications. Your system stays changeable and you can respond to the needs of the business.

Note that you can do all of this without sharing code between your apps, and you can choose different technology stacks, programming languages, and solutions. All of it can be made to work together and managed with less headaches.

You can take this approach and apply it over time, little by little. You are not forced to do the big rewrite, or take on all problems on all at the same time. 

So, happy monolith slaying!

The Allure of Easy Answers

People are attracted to easy answers for difficult problems. We often refer these "easy answers" as fads once they gain popularity and some level of authority. The management fads are quite popular in our IT community for the simple reason that they attempt to answer the old problem of creating hyper productivity.

Many IT organizations are mired in problems creating results. If only those pesky developers would deliver what I want! Expectations turn into disappointments when the time lines are not what companies what, or  when companies can't fit their dreams into the budgets that they desire.

Agile! Yes, that will rocket our organization to unparalleled productivity. It's also very simple. I can see it fits on a pamphlet and it tells you what to do. Besides, they have Scrum Master courses, where within days you can now turn your organization into a well-oiled machine. All the experts say so, and we can hire Agile coaches who will come and rescue us if we get off the message.

Ok, so you are "doing" the Agile. You follow all the rules, and have your Scrums and Retrospectives, and Planning, and you tally up all the points and doodads. Cool, there is a graph that now tell exactly when we are going to be done! This is what management has been asking for all the time.

When the magic wears off then it does not look all that special. It sort of kind of works, but so did other things, sorta kinda. And, overall it probably is an improvement if you were stuck in Big Upfront Design. But, you can probably get the same just by having Medium Upfront Design, some work list, high level estimates that you keep updating, and some regular check point.

I remember tracking work on a spread sheet that would calculate the delivery date based on the task estimates ten years ago. This was the early days of Agile awareness for the greater public. However, any developer worth some gravy would already know the tools to be successful - hence the spread sheet. It's just that when you suddenly throw in a layer of bureaucracy and a Project Management Office in the mix when things usually take a nose dive. Welcome loss of sanity.

Suddenly some publicized Agile stuff starts to sound very good because it is marketable. You can sell that to a manager in a nice package, and you can give your graphs and velocity numbers to them, and boast about great progress. Yay! That's the antidote against PMO and layers of confusion!

But, I must admit that I am tired of the masquerade. I completely understand the Agile principle because that's what competent developers do on a daily basis, and have done so for a long time. It is just that when all those things that developers do to make things successful is marginalized, externalized and parcel wrapped into a "management fad" that the basic ideas of building software systems get lost somewhere. It's like a regression more than advancement when you start reciting Scrum commandments as the only gospel.

The problem is that fads provide easy and attractive answers. Unfortunately, you can only deliver successful stuff with great people. It's not the amount of people, but the kind of people you have. You still have to do the hard work, put the hours in, and be good at great many things. People are inconsistent, and they do not follow rules. Even if they follow rules, they follow them differently each time, with variable results. If something gets on the way, people stop doing it.

Because people are the way they are, you need adaptability, some light weight process, and interaction with feedback. That paired with good people will give you results. That same thing with wrong people hardly ever will. In fact, the process probably does not matter much. You can succeed with waterfall consistently if you have the right people.

Puzzling Hiring Problems

Developer Categories

So, you can't find a decent software developer to join your team? It should not be a surprise. Good developers are rare birds; very intelligent, introverts, detail minded, problem solvers, independent. I don't want to put people in a slot, but this is how developers often are. There just aren't that many sufficiently "brain damaged" people around who like to torture themselves with menial and time consuming problems that take deep concentration. You know, the kind of book worm stuff that people hate when they go to school etc.

You often see a a category of applicants who claim to know programming, but they don't. They usually fail even rudimentary tests that you put in front of them. They  are just fishing around, thinking that they can just grab a job and do a bit of good ole hacking on the side. These people don't really want to be software developers on the long run, even for the money. This group of people are a waste of time for anyone who wants to hire a software developer. They won't get much done, and what they get done, sucks.

We have software developers who tend to be careerists. They go to work and write software to get a pay check. They might be introverts and have some of the characteristics of good software developers, but they are only marginally committed. Nothing bad there. Most people you hire are probably like this. They get things done, but it's just not going to be anything more than average. They also mostly expect the work to be handed to them with full requirements and instructions what to develop.

And then there is the group, who is above the average. They care what they do, and they want to write software. They want to learn and they are motivated. These people are good hires, because they also get things done, and over time, they can do things that careerists just won't ever do.

The problem with the last group is that the ones that really have honed their skills are just not out in the open for the grabs, unless you are lucky. You simply rarely see them.

Engineer vs. Designer

Perhaps you have then hired someone suitable enough. They might be talented, and eager to do the job. They produce results and get things done, at times. But something just does not really jive. This seems to be true too; some developers enjoy the theoretical aspects of the profession, and some just like to slap things together quickly.

Either extreme does not work well. You don't want the architecture astronauts, or the cut and paste hackers, but you do want something in the middle range. This is because theory matters when it is put to good practical use.

You sometimes see people get stuck designing all kinds of lofty ideas that are not really relevant to the problem anymore from the practical perspective. It can be fun to think about, but it's a disaster waiting to happen in real life. It can take different forms; mindless use of tools that do not solve the practical and real problem (because in theory it could work), stuffing layers to software that only add to complexity (because it's what the best practices are). This is the designer trap that people sometimes get into.

Opposite can happen. Software is getting done fast, and quickly, but it is all in the name of getting it out the door in what ever way. It's bad software, hacky, copy pasted, sloppy, not well thought out, without any decent structure. Sure, it can work but only in small scale. Bigger software, critical software, and long term maintenance of software are those key areas where this kind of "getting it done" approach will create a disaster. It's perhaps what happens more often than over-architecting because things are being done and there is the feel of great progress. Managers especially love these kinds of people who turn around on a dime and "get things done".

To a significant degree these two kinds problems emerge from lack of experience. People are just good enough to produce results but the wisdom, intuition or true skill is not there to reign in the bad behaviors. Experienced people are simply far more balanced and know how to manage the outcomes.

Introverts and Extroverts

Some people are more social than others. Some people are more detail oriented than others. Some can solve problems better than others, and different kinds of problems. Some people are glib, some are not. What do you really want to emphasize in a developer?

There is the argument that now that we are doing all this Agile stuff that developers need to be really social and engaging, eagerly embracing the business, while at the same time you want them to produce brilliant, well thought out software that comes out like clock work, and never misses a deadline. Well, easier said than done.

I mentioned that most good software developers are really introverts. It's still true, in my opinion. It does not mean they are not social enough, but they are not the ones with the gift of the gab and "social engineers". They mostly focus on solving "non-people" problems that are eternally boring to the vast majority of people. These people stay focused on the technical aspects of getting things done, formulating complex things and making it real in terms of good software. It requires lots of concentration, free from unnecessary interruptions.This regardless of all the buzz about agile pairing etc. I don't think it always works; have never seen it work for real, in fact.

I think you want some kind of mix here as well, slanted towards the introvert types. If you want a good reliable software developer, you need that quieter type who gets things done with good workable design skills, who can still interact successfully with business and product owners when required. The onus for successful interaction is often put on the developer, but I think this is wrong - why not require equal attention and skills from business/product people when interacting with developers, to be able to understand enough what the developer is saying. IT functions are now so central to businesses that having business people who do not understand their IT operations is really a bad thing.

There are places for extroverts as well, in the agile realm of things. A good Scrum Master is often someone who's an extrovert, but they necessarily do not or should not lead software development from the trenches. Their focus tends to drift away from what is required to produce good software in practical terms. These kinds of people tend to jump around from one thing to another, relishing the opportunities to get things done quickly and moving on. Software development might interest them, but not in the sense that is required to become good at it.

The bottom line - don't expect developers to be socially gifted, while at the same time being great at building good software. It just does not work that way. We do not elect, nor often see politicians who are introverts, so why put unrealistic expectations on software developers? Brain, and the way it works matters when it comes to different kinds of jobs.

The Estimation Game

Recently, there has been various articles and blog posts about project or work estimation and whether it is worth doing.

What are the reasons for doing estimation?

• Know the size of work.
• Know the cost of work.
• Know the staffing.
• Know when you are done.

What can you estimate?

• Known requirements/features.

Challenges?

• Changing/unclear/missing Requirements.
• Knowledge of the Domain.
• Skill of staff.
• Changing Staff.
• Feedback/communication.

The reason for doing anything is to get reasonable value in return. The value that you expect typically is predictability. No cost overruns, work completed on time, and completed with the features as expected in working condition.

This sounds simple enough but it really depends. The problem really comes in with the size of the work.

Bigger projects have so much variability and unknowns that even the best attempts to estimate work up front will likely fail. It is hard to know what in fact will happen and the outcomes depend on the flexibility of the overall plan and the attitude of the team and the stake holders. The real problem here is that estimates become an unchangeable plan, and then they also become time commitments. When you fix these two things you have nowhere to go when surprises occur and new work is invariably discovered. On the other hand, if you are flexible, large swaths of the project plan might change on the way and budgets and time lines might actually have less relevance in the overall process. Also, the human component is so dominant in long running projects that it is very hard to guess what the output of the team is, especially if the team keeps changing along the way.

Smaller and often unrelated work items can be estimated quite easily and there are far fewer surprises. However, this kind of workflow often has so much flexibility that the work plans keep changing from week to week. Many of the items that are estimated will never be worked on and new items are inserted to the work flow. It might be that there is a lot of churn and time spent on estimates but at the same time it is quite well known how soon work is completed when it is started anyway. If you put a work item on top of the priority queue you can expect it to be done within the iteration, as will many other items reasonably close to the top of the list. Further down in the list the item is, less you really care about it, and the stake holders might never really care about it at all after couple of iterations.

So, where is the value? I think the only real value is the ability use living estimates as a decision making tool.

In the long running projects, you only care what the estimate is NOW. It could be different from what it was a month ago, and it will be different in a month from now. You will gain experience what the team can do over time. That will give projections for cost and completion times. With good enough management of priorities and the value of the feature set it is possible to approach something attainable. Also, there must be openness to react and change the plan. Staffing changes will provide additional challenges but on the long run it is possible to gauge how the project is doing over how the team is doing in the project.

There might not be so much value at all doing estimates for variable short term work where experience will quickly tell what the 'event horizon' is because you only really care about the immediate results anyway.

This is still somewhat simplistic analysis because it does not fully appricient the complexities of understanding work, producing right results, dealing with feedback and inspection. Building the right thing is still the most important goal and measuring that is very esoteric and based on things that are hard to measure. Many teams can call things done and can appear to make progress but what exactly are they producing and how? Sometimes you see those high profile failures that leaves you puzzled - obviously it was considered done, and all the rest, but it just did not work. Obviously the estimates were wrong, even when budget goals or time lines were met.

What is Product Design?

As a programmer, how do you answer that question? What is Product Design? Not oddly enough, people have a wide variety of opinions what really is product design. Ask a product manager and they think they are designing, ask UI designers and they think they are designing, ask a programmer and you get the same answer.

I came across these two posts about the topic:

• Web Design is Product Design
• Programming is Product Design

One is asserting that web designers that draw pretty pictures are really not doing the full round trip in web design. The other, which is a response, argues that programmers who do not do CSS and graphical design are not designing the whole thing either.

Both would be right, but the argument is just pointing to a dysfunction in typical design roles. There are so many aspects to design that people can't often do them all. However, if you are looking for some kind of ultimate solution, you want a virtuoso who can do it all. At the same time, it is probably not too much to ask  that people actually cross different disciplines. Often, that is better than mastery of programming alone, for example.

It is fine if a web designer draws images. It's a bit like making a rough sketch before the actual work starts, just get some idea about the web site. However, I would argue that there is still a big gap between that and actual design that is sufficient. Mastery of HTML and CSS should be required from web designers. And more than that, a real understanding of functionality and usability. This is the kind of middle ground that is very important but it is left in the no mans land, and that's a big gap in deed.

Programmers should know about HTML and CSS. Programmers can be a great asset in organizing and helping design here. Programmers are usually very particular about the aesthetics of organization, rules, practices. Programmers should know about usability, and how software translates to user experience. This is not important only because it makes user's life easier but it also affects how software is designed, and therefore it makes programmer's life easier.

There is a nice symbiotic relationship that can be created here where web designers, functional designers, and programmers can cross disciplines and interact in a positive way. It is easier said than done, of course. I have long argued that web designers should be integrated to the programming teams as full fledged members. In agile terminology, it is all matter of definition of "done". How can you really separate web design from programming, when all of that is in the cross roads that makes software great, or not?

Agile Golden Hammer

Now that the Agile movement is well past the early adoption phase, in mainstream, people have started to complain that Agile does not work and the research seems to show that Agile adoption often fails on many facets. While it is true that Agile is not always the solution, it is also a fact that people do not GET Agile.

Just get some basics right. It is not rocket science.

• Agile practices work when we are in creative work environments, often requiring individual skill , knowledge and creativity. There are no repeatable and simple steps to complete work.
• Create space and autonomy for people who are doing this demanding creative work. This kind of work requires a lot of concentration, and time. Avoid interruptions.
• Focus on learning. What ever makes learning faster, getting feedback faster, getting to the next level faster - do it. Usually this means small increments of work, learning from it, improving, and doing it again. Experiment, get to the solution, and then do it right. Hack when you start, but finish solid.
• Get the teams right. Cross functional does not mean a group of developers. It means designers, testers, developers, business people, sales, all in one package, in one unit. If you can't get most (if not all) of your work done from end to end with the people in your team, you are limiting yourself. Not always possible, but strive for it.

What not to do:

• Start with Scrum, and do Scrum one year after. Scrum is a starting point, not what you should end up with. Dogma kills.
• Expect Scrum etc. to solve your problems. People solve problems, people improve. Scrum remains the same, no matter how hard you try . If Scrum does not seem to work - don't use it. Instead, find what does work.
• Expect people to just jump in and get it. Sorry, I don't believe this is even possible, unless you are in a very coherent and cocooned environment with like-minded people.  Most people don't care about Agile, Scrum or any gold plated buzz word. Just go and do something - don't try to sell Agile.