The Pyramid and the Plum Tree

 Corporate culture is a funny thing to put your finger on, but it is arguably the most important aspect for professional happiness.  In "Orbiting the Giant Hairball" by Gordon MacKenzie, he describes 2 different corporate cultures:  the pyramid and the plum tree.  These depictions speak volumes and really resonate with me.  I highly recommend you pick up his book.  Throughout my career I have worked primarily for pyramid organizations, while at the same time I have attempted to create plum trees for organizations in my charge.  So let's talk about the differences and what it means to be a pyramid or a plum tree.

Pyramids are a top down organization where the leaders make all of the decisions and the people and individual contributors carry out those orders.  Growth is by decree.  Creativity and innovation often stagnate because mistakes and failures are punished.  No one is willing to go out on a limb for fear of failures.  Amazingly, the leaders often fail to hold themselves accountable to the same levels of rigor and instead blame those under them.  They truly believe that they are surrounded by a poorly performing organization and fail to see that they are often the reason.  In pyramid organizations employees are often a commodity.  

Several Quotes from the book further illustrate this:

Executives:  "We must grow or die!"

Leaders:  "We'll need to increase production!"  "We need to motivate the workers to produce more"  "You down there!  How can we (the leaders) motivate your?"

Workers: "Let us out from under this crushing mountain."

The workers are trapped under the bureaucracy.  They aren't given the freedom nor support needed to be more productive let alone innovative.  Demotivated is the norm and it only gets worse.  These companies are often "circling the drain".  They are desperately trying not to lose, but unwilling to make any meaningful changes.  This may prolong the status quo, but it eventually catches up.  These companies are at various points of death spiral and very few are able to come out of it.  Pyramids are tombs, which is a great analogy.  

Plum trees are the opposite.  The organization is fundamentally designed different.  Instead of the executes and leaders on top, the workers and product producers make up the top of the tree.  They have sunshine, they have air, and they can see from their vantage point.  They produce the fruit (cash crop).  Managers and Leaders make up the branches of the tree.  Their job is to support the producers at the top.  The trunk is the executives who are supporting the entire organization.  They work to ensure the managers and individual contributors have what they need to be productive but they also provide the support to how high the producers can go.  Resources flow from the roots through the trunk to the branches and leaves where they are used to promote growth.

    Workers:  "On a clear day we can see forever"  "We got what we need: sunshine and air"

    Managers & Executives:  "What do you need to motivate you?"

Unlike the pyramid, the plum tree model is a living organism.  It is flexible and can adjust with the times.  The plum tree can create opportunity through support of those that are closer to the solutions.  It breeds innovation and value by enabling change and creativity.  

Often in today's corporate environment the executives and leaders often dictate not only where they want the company to go, but how it is going to get there.  Often larger corporations fail to see the policies, procedures, decisions that may have made sense at a given point in time are now making a hairball that is inhibiting their ability to adapt, create, and innovate.  Leading to an inevitable and unenviable corporate normalcy.  

If you are a leader within your organization, I challenge you to look at the decision making process.  Do you find yourself pulled into even the most mundane topics so you can help make a decision?  Do you or your employees require permission to do what they need even while staying within the guidelines?  Are you unsure what you or your team is working toward or what the long plan is?  If you answered yes to any of these, there is a good chance you are working in a pyramid and you would be better off working on creating a more supportive plum tree environment. I also highly recommend that you pick up a copy of Gordon MacKenzie's book for inspiration.   

  

 

How is a Corporate Culture Defined?

Corporate Culture is a funny thing.  It is difficult to describe, yet it’s importance is undeniable.  Many believe that a culture is defined from the top and for the most part I do not disagree.  When the culture is set from the top it has the most chance of surviving.  However, unlike a lot of things in business, a culture cannot be defined by decree.  A CEO cannot just say what the culture of her organization will be, instead she and everyone under her must reinforce the culture through their actions.  For this reason, cultures usually develop over time.  This also means, that a culture can change but that the process often requires a concerted effort and will take significant time.  This is why it is extremely important for all levels of management to enforce and reinforce the culture that you want within the organization.

One question I hear a lot is “can a culture be defined from the bottom up?”.  I believe it can, but only to the point that the leadership allows it to and supports it.  Culture often needs to be enforced when different things influence our behaviors.  Let’s take a look at an example.

Many companies want to implement a “Fail Fast” culture.  In a fail fast culture, the goal is rapid learning, experimentation, and avoiding analysis paralysis.  Companies that want to adopt an fail fast culture want these benefits in order to innovate and hopefully grow a solution that meets a need in a creative new way.  Failing in this case is seen as simply part of the journey, so better to get through it and learn the lessons as quickly as possible so that they can move on the successes.  But there is more to failure than just the learning and exploration.  Failure has a lot of negatives associated with it too.  For one, failure can be extremely expensive.  I often see these negatives creep into the equation of culture because they can influence people’s behavior away from the culture.  This is why leadership is required to build a successful culture.  Leaders need to combat the negative influences to the culture they are trying to build.  This is one of the most important responsibilities of leadership in modern corporations.    

When only some leaders are supporting the culture and upper management doesn’t correct the situation, micro-cultures can form.  Micro-cultures within an organization form when there is an insulated group that can define and enforce their own culture with minimal outside influences.  This is why, it is very difficult to create a successful culture without the very top of the organization being on-board. Each layer of management needs to be supported by the layer above.  These micro-cultures can have devastating effects on the overall morale of the work force.  Micro-cultures can be a breeding ground of resentment.

Culture in all of its forms, macro and micro, is defined through the actions of the people that belong to it.  Culture cannot be declared and only survives by keeping the outside or negative influences at bay.  Leaders at all levels must help reinforce a culture or it will not take root.  The protection and cultivation of the "right" behaviors and the correction and redirection of "bad" behaviors falls squarely on the shoulders of management.  So while culture can be started from the bottom, without the support of management it has almost no chance to survive.  

Lessons for Management of a SaaS Application

Over the years I have been responsible for both Software-as-a-Service (SaaS) and On-Premises Applications.  Each has its pros and cons, but from a pure application development point of view it is difficult to beat a SaaS application model.  Retained ownership, speed of deployment and delivery to market, subscription based revenue models, etc. are some of the incredibly powerful benefits of SaaS applications.  However, it is not all roses and rainbows.  Below are a few of my top concerns that should be taken into consideration by all leaders of a SaaS application, regardless of their role.

Don't confuse usership with ownership.

The end user in a SaaS application is similar to a renter of an apartment. They have some rights to things, but they are far from having ownership rights.  Ultimately, they are not responsible, you are.  I like to think of SaaS applications as "They break it, you own it".  This means the Developers and DevOps engineers that build the application and maintain the infrastructure own it from soup to nuts.  They must be extremely defensive in nature and be willing to stop one actor from hurting the rest.  Because of this ownership it is extremely important to understand and clearly delineate between the different rights you versus your users have.

It is not uncommon for different groups to want to blur the line between usership and ownership.  Most common is the users themselves.  They want the control without the responsibility.  If you give up the control of who owns the application, environment, data center, etc. it generally comes with significant consquences.  Some of the consquences mean you have a SaaS application behaving more and more like an On-Premises application and losing some of the unique qualities that make SaaS so appealing in the first place like economies of scale, nimbleness, time to market, continuous deployment, among many others.  It is imperative to stand your ground and ensure the keys to the kingdom are kept squarely in your pocket.

What is good for the goose is good for the gander.

SaaS applications are shared applications.  The same code is used by many different clients or users.  This means that when you are building solutions, you want to make them solve problems for the widest market possible.  There has been a consistent pattern in my career of trying to solve problems for individual customers (usually the most vocal) and then unsuccessfully trying to apply them to the market as a whole.  This leads to a feature being used by a single user and worse an application that doesn't scale well and is incredibly difficult and expensive to support.  Eventually leading to feature fragmentation, feature duplication, feature consolidation and migration.  If you are not familiar with these concepts, they are all extremely time consuming, resource intensive, and expensive to deal with and should be avoided.

Consistency and Simplicity are the foundations of Trust.

Consistency is a key consideration of all applications.  This is especially true for Multi-Tenant SaaS applications as it creates a foundation that helps create an easy to use and intuitive solution.  Easy to use, intuitive design leads to a consistent user experience which is the primary ingredient to gaining your users trust.  If you gain users trust, you have a customer for life or at least until your lose their trust.  Using simple building blocks that work consistently to solve problems regardless of complexity is the hallmark of a successful SaaS Solution.  In general users of a SaaS application should be able to manage themselves and should need minimal to no intervention from you.  In order for that to be successful the application had better be intuitive in how it works.  

One platform to rule them all.

SaaS applications should appear as a single solution regardless of how they are built behind the scenes.  This means they need to scale, ideally both vertically and horizontally and both at the application/business logic tier and the database.  This also means understanding the multi-tenant nature of the application and being able to clearly identify and manage these tenants.  Building tools that are  able to address a single tenant, group of tenants, or all of them will go a long way toward being able to address the needs of your community of users.  Monitoring and maintenance is a long term concern for all SaaS applications.  The solution is owned by you, which requires you make and keep it available and performing at all times.  This becomes more difficult as your grow and scale.   

What is the spice of life?

For SaaS applications the "spice of life" is the ability to personalize and customize the solution.  Users have different patterns, styles, and needs.  Building different levels of customization and personalization into a SaaS application enables users to tailor the application to their needs.  This is incredibly important to building a strong positive user experience as it can't always be expected that the user conform to your approaches.  But customization and personalization is a double edged concept.  It must remain within the protected walls of the application.  Guardrails and limits should always accompany the ability to change the application to meet the needs of individual customers else you fall into the trap of building one-off solutions that cannot be supported in the application in a cost effective way.  This type customization can make changing or growing the application in the future more difficult too.  It is best to tread carefully in the area. 

A firm handshake makes a great first impression.

SaaS application should be able to be integrated with.  People are sharing with you one of the most valuable assets they have: Data.  Being able to get data into and out of your application is a must for all SaaS applications.  Being able to manipulate the data via the business solutions you provide another layer of integration that is often representative of a mature SaaS application.

Security is a key thread of the application tapestry.

As customers rely on your application to provide them with the services to meet their needs they also are entrusting you with their data.  The base expectations is that you are a good steward of their assets and you will keep them safe.  This means security must be a top level concern for all SaaS applications.

There are many concerns when building or managing software solutions regardless of how they are deployed and distributed.  SaaS applications have become the norm in a lot of ways and they come with their own unique concerns.  Maintaining the right mindset and understanding the problem space of SaaS applications is key to the success of the project.  If you are on this journey, good luck!  I hope some of my top concerns help guide your way.  

Empowerment and Decentralized Decision Making

In recent years there has been a significant shift in the development model from a centralized command and control structure with a strict hierarchy to a more fluid decentralized model.  This change has come in many different models and flavors: Scrum, Kanban, Lean, XP, Spotify-Model, to name a few.  However, the goal of all of these models is to empower teams to make decisions and rapidly respond to a changing environment.  This goal can be achieved by leveraging lots of different mechanisms: continuous deployment, a/b testing, continuous feedback loops, etc.

As more and more companies attempt to adopt these methodologies they are becoming mainstream.  However, the transformation process is not as simple or as straightforward as it looks and I have rarely seen a company do it successfully.  Yes, most can make the change to the process.  They can adopt the ceremonies or change the layout of the teams.  They even flatten the organization in some cases.  These are all steps in the right direction, however, all of these surface actions do not get to the spirit of the change and are more cosmetic in nature.  The whole movement is literally a paradigm shift that requires all levels to buy into it, from the individual contributor to the C-Suite.  This challenge is often a difficult one to overcome.

So why are the changes so difficult to make?  It requires a change to the core way most people think and even more importantly, it requires relinquishing control.  Giving up control and promoting a "servant leadership" mentality is often something that people are not interested or able to do.  Actively taking responsibility while delegating decisions to someone else is an extremely difficult proposition for most people, but this approach requires exactly that, relinquishing control and maintaining responsibility.  When this type of change is made, it sets the stage for empowering the team.

When teams are moving fast and are empowered to make decisions, they will also make mistakes. This is a good thing, but lessons must be gained.  This also means that adopting a culture of learning is extremely important.  When things go wrong, it cannot be about who did what.  If you are looking to place blame on someone, you haven't successfully made the mental shift.  The blame game is a top down model, empowerment and decentralizing decision making is a bottom up model.

When things do go wrong, and they should if you are doing things right.  The goal must be to first rapidly respond, if needed.  When the team has ownership, they will be able to do just that.  Secondly and most importantly, we need to understand "why" the problem occurred and learn from it.  This introspection and learning is imperative.  Without, the analysis and understanding we are very likely to repeat the mistakes again in the future.  When the same mistakes happen over and over again, a rut is formed.  It is never good to be in a rut.  Instead, a constant learning cycle is needed.  This learning cycle is what drives efficiency.  In fact, if you look at the Spotify-model, they talk about maintaining a balance between chaos and bureaucracy (View Here).  I love their idea of a "Minimal Viable Bureaucracy", which I interpret as:

The need for growth and the ability to deliver is difficult and can lead to problems. These problems are commonly corrected with increased process and additional controls.   Too much process and too many controls leads to an inability to deliver which is worse than the original problems.

By decentralizing the control and minimizing the process, you increase your ability to scale. Different teams are operating and learning independently enabling the organization to learn more lessons in less time.  Lessons lead to improved efficiency which is key for being able to grow organizations.

However, we are not out of the woods yet.  When you have a bunch of teams all operating independently things can quickly do awry.  Duplication of effort, lack of coordination, competing ideas, etc. are all real possibilities can lead to chaos and confusion.  This is when leadership is truly needed.  Netflix uses the term "Highly Aligned, Loosely Coupled".  The idea is quite simple and truly shows the role of leadership is to set the course for the teams and achieve a high level of alignment.  It is critical to ensure that the message is consistent and expectations are set clearly.  Once that is done, it is best to get out of the way of the teams and let them do what they need to do to achieve the goal.  Leadership will often need to be measuring throughout in order to gain insights to how the teams are working, both independently and together.  When needed course corrections and inputs can be changed in order to increase alignment between teams.

Empowering teams and decentralizing decision making is a powerful way to increase productivity and move faster.  Agile methodologies attempt to make the changes easier to manage, but without adopting the right frame of thinking and strong servant leadership at all levels, these concepts become more difficult or even impossible to implement successfully.



  

The Importance of Leadership - My Leadership Style

A lot of people have asked me why I decided to make the leap into management.  I was a fairly successful programmer having working my way up through the ranks from Junior Developer to Solutions Architect.  I prided myself on being a quick study and having an ability to contribute to a project almost immediately and continuing to be a go-to resource for years to come.  Unfortunately, I often saw that the leadership of the company lacking.  I felt the focus was often on the wrong things at the wrong times.  And the saying that people are promoted to incompetence had a ringing of truth to it.  There are lots of different types of leadership and they all have their place.  However, if the leaders don't do some of the basics, problems can quickly arise.

Here are some items that I consider extremely important for a leader:

1. Have a vision
2. Be future thinking.
3. Set the direction to meet the vision
4. Stay out of the weeds (50,000 foot view)
5. Balance the needs of customers with the needs of employees.
6. Recognize that change may be needed.
7. Keep Finger on the Pulse
8. Support the Team
9. Assess Self

Have a vision
Having a vision and effectively communicating it is one of the most important aspects of effective leadership.  It is arguably the single most important job of leaders.  Without it, the rest of the organization cannot execute effectively.  It is also important to note that Vision should remain relatively stable.  It takes time to execute on a vision, so if it is constantly changing/shifting it will lead to frustration and an inability to execute effectively on.

Be Future Thinking
It is easy to be focused on the here and now, but a good leader is also preparing for what comes next.  Products need to be developed, tested, deployed and to be successful you need to able to do that regularly.  By no means should a leader lose sight of the day-to-day activities required to execute.  However, true leaders should empower and trust the people under them to do the job they were hired to do.  It is important to spend the significant amount of time needed to prepare for the future so the organization can operate with a cadence that allows for a timely release to market.

Set the direction to meet the vision
Understanding what is comes next to execute on the vision is just as important as understanding the vision in the first place.  There are almost always multiple steps or milestones to meet in order to achieve the goals of the vision.  Effective leadership provides the focus for the teams to meet those goals by eliminating distractions and keeping the team moving forward.

Stay out of the weeds
The higher up the on the totem pole the leader is the more they should trust in the people beneath them to execute.  However, first line manager's also need to trust in the individual contributors that make up the team.  The goal should be to empower the team to effectively tackle whatever problems they are facing.

Balance the needs of customers with the needs of employees
These 2 groups are the most important for any leader to focus on.  However, often one side or the other can be neglected.  The goal is to provide customers with a compelling product or service and at the same time entrust the employees to build it.  When problems arise, it is important to balance the impact to these 2 groups.  Without customers you don't have a business and the same goes with employees.  If both groups are happy, life is much easier.

Recognize that change may be needed
In the book "The Lean Startup" by Eric Ries, he talks about the goal being to find engines of growth.  This is ultimately the goal of the company as it is responsible for driving revenue.  However, overtime the market changes and what once was driving growth may not longer be effective.  This is extremely important in the technology sector which seems to be changing all of the time.  These changes often must be adapted to.  It is an effective leader that can predict when to change and when to stay the course.

Keep finger on the pulse
Understanding the environment, whether customers, employees, or the market.  Often the information on when change or decisions are needed is available before the decision is critical.  By keeping your finger on the pulse and listening to feedback openly you will be able to head off problems before they become too disrupting.

Support the Team
You are the team's champion and there is a good chance that you will need to fight for them.  A leader represents the team and needs to be able to support them effectively.  Listening to the team and understanding their needs is a critical role.  Removing obstacles is an important part of the job for leaders.  Leaders are there to serve those under them while providing value to those above them.  Often these 2 roles can seem to be at odds with each other, but the reality if the team is executing on the things it needs to execute on, value will be provided up hill.

Assess One's Self
No one is perfect, at least I haven't met anyone that is.  It is important to constantly measure yourself and get feedback in order to improve.  This is often one of the most difficult parts of leadership.  Addressing your weaknesses is difficult, but without recognizing your short comings you cannot improve.  Leadership is a skill and needs to be honed through practice and effort.

The importance of addressing technical debt

Fixing Technical Debt has been a passion of mine for a very long time.  It is often the most impactful endeavor that software developers can do to affect the business in a positive manner.  But before we can correct technical debt, it is important to understand what "debt" is from a technical software perspective.

Ward Cunningham coined the debt metaphor a long time ago to explain the costs associated with software development and speeding the process up.  He compares it to borrowing money from a bank and how that allows you to do something beyond your current finances, such as buying a house.  The catch is that you have to pay back the loan plus interest.  You can see a video and transcript of Ward explaining the metaphor here.

http://agile.dzone.com/articles/understand-high-cost-technical

Like most things in the software business, a balance is required.  Balance between "borrowing" in order to increase feature availability and re-paying the debt incurred as we increase our knowledge and experience.

Over the course of my career, I have worked at all sorts of companies from the start-up with 6 people to the largest multi-national corporations.  What is interesting, is the lack of balance can be found at companies of all sizes.

What I have found is that the startup mentality is often to assume more debt in the hopes of becoming profitable through the acquisition of customers.  This is done by creating a product and adding features that are valuable to a customer base.  However, as the company and product matures, you reach a point where the income-to-debt ratio begins to take its toll.  Meaning that you reach a point where the company must start paying back on its debt or you will see a diminishing rate of return on the work you can complete.

This transition is often one of the hardest for a company make and the earlier that a product can make the change, the better off the company will continue to drive an engine of growth.  In fact, the technical debt metaphor explains that if the cost of the interest on the debt increases to an amount that is greater than revenue, the entire growth engine to stalls. This is obviously a disaster scenario for any company.

So how do we address technical debt?  This is not an easy question to answer, as each case can vary greatly.  However, there are some simple steps that can help drive the decisions to make the journey a successful one.

1. Consistent Vision

This is one of the single more important aspects of building a product.  You MUST know what the long term vision of the product/business is.  This is a 50,000ft view of things and I like to think of it as a compass point that point that direction that we need to head.  Everything that we do should be measured against this vision/direction.  One of the major generators of technical debt, especially in the early stages of a products lifecycle, is not understanding the needs of customers and frequent changes in direction.  By the time you are ready to address your technical debt, you should have a good foundation on what problems your product solves and how it solves them.  This should set the Vision.

A consistent vision is important for understanding and building new feature functionality as well as addressing technical debt.  More often than not, I have seen, the greedy shortsightedness of the business try to build a feature that is counter to the vision of the product because they are chasing a specific customer.  If you continually chasing business or attempting to be everything to everyone you will quickly find yourself under a mountain of technical debt.

2. Identify Milestones

Milestones provide 2 different pieces of information to the company that is trying to solve technical debt.  First, milestones help define problem areas within the business and secondly, they provide for a goal and timeline that aligns with the vision.  Milestones are the main driver of work and will detail the process and the acceptance criteria.

3. Disciplined Execution

The last item to address your technical debt is Disciplined Execution.  This is where the rubber meets the road, however it is important that the execution is well thought out and meets the milestone that it falls under otherwise you could be setting yourself up for adding debt instead of paying it off.  Disciplined execution means building off of simple concepts to grow a products functionality.  Do not attempt to predict how things will change or what will be needed in the future, instead build as simply as possible to meet the objectives of the Milestone.

Following this simple approach to tackling your technical debt can pay huge dividends to the products that you build and also to meeting and exceeding customer expectations.  Assuming debt is often a necessary part of building software, but that also means that paying off that debt is also necessary.  Without a plan to address debt, it will continue to grow with defaulting being the final outcome.  Good luck!  I would love to hear your thoughts & feelings on technical debt.

Waterfall Leadership in the Age of Agile

The agile movement has been sweeping the software development world for years and it is clear why. The agile method is a more natural way to develop software and produces results.  These results are also delivered sooner and with better visibility than the older more traditional methodologies, like waterfall SDLC. However, agile is not perfect and everyone's implementation seems to be different.  While this is normal and even encouraged, it leads to the question 'why?'.

One major difference that leads to an inconsistent implementation of agile (specifically Scrum) is the makeup of the leadership team.  In Scrum, there is one tenant that is stressed more than any other: The Team.  Everything is designed around making the team as efficient as possible.  Decisions are made at the team level, empowerment of the team to make decisions, communication within the team is paramount, succeed/fail as a team, etc. However, when the leadership or business is not also aligned to the Scrum methodology problems occur.

The development team is meant to be self sufficient.  In order to achieve this, roles must come together: development, QA (Manual/Automation), UI/UX, Business (PO/BA), DevOps, etc.  The team can achieve whatever is asked of it because they have the right skills and experience across all of the disciplines.  However, often the leadership is not aligned with this and each role within the team has a different manager chain that they report up through.  So while we ask our teams to work as a single unit, the management of the individuals make that increasingly difficult by not having a unified voice.

Compounding this is the fact that the business is often stuck in the waterfall way of thinking.  They are planning functional releases and working with sales to get that new functionality to the end users.  They are working with focus groups and trying to build a thorough road map and longer term plan based on what they learn.  But a detailed long term plan is barely worth the paper it is printed on.  The reality is that the software world is often too fluid to formulate a detailed plan that covers anything greater than a few months that remains accurate and on point.  Don't confuse the plan with vision, which is necessary for all parties to stay on task.  From my experience, most business partners have failed to make the switch to the agile movement and breaking away from the outdated waterfall school of thought.  This is often the cause of friction and confusion between the agile and non-agile groups and usually ends with the feeling of teams of operating in "agile within waterfall".

So how do you overcome this scenario?  Well, like agile there is no hard and fast solutions.  You need to ask yourself if you are truly committed to being an Agile organization.  If you are, then there are several changes that can be made.


Single functional leadership (close to the team)

A single functional leader that spans the different roles within an organization but owns the product or functional area is necessary to ensure a consistent and single voice.  You may still have resource managers for the different roles within the team, but the work the team is responsible for requires that everyone is one the same page and is not getting mixed signals from their management streams.  There are no "side project" or my manager is asking me to do something for him, etc.  It is controlled environment where there is a single focus, the Team.  

  

Set priorities, measure, and re-evaluate

One of the major concepts behind agile is to work on smaller unit and to deliver benefit earlier.  This often means that functionality is delivered and then refined over time.  This is especially true in SAAS products.  The business needs to set the course and provide information as needed.  When the solution is delivered, we need to measure to see if the changes are achieving the goals.  If we get positive results than the process should be to iterate and increment.  This constant cycle ensure we are moving toward the long term goals.  

Sell what you have, not what is coming

This idea seems to be very difficult for people to implement as it is human nature to talk about the exciting upcoming features.  The problem is the agile way is to deliver incremental functionality and to re-evaluate based on measurement.  Unfortunately, that means that what is important today may not be that important tomorrow.  So if you are selling based on a promise that we will deliver some functionality in a certain amount of time you are setting yourself and your customers for disappointment.  The customers will almost definitely see this as over-promising and under-delivering. 

Deliver smaller and iterate

The agile team itself needs to deliver smaller units of work.  The idea is that by doing this all time time, it becomes easier to measure and re-evaluate.  The process of shipping a new or modified piece of functionality becomes easier due to the frequency and practice.  The functionality can be refined over time and the product can grow based on the priorities of today, not the priorities that were based on assumptions from the past.

The Agile methodology is not limited to the functional teams that make up the organization.  To fully see the benefit of the Agile methodology all parts of the company need to embrace it.  Working within a waterfall environment while conducting the agile ceremonies will not provide the value that these methodologies can.