Achieving Agility: Means to an End, or End in Itself

(c) 2010 Esther Derby

I recently spoke to a senior manager who wanted to know how “agile” his company was compared to other companies. When I asked what he’d gain from that information, he responded that then he’d know what practices the development teams needed to implement next. I’m not the only one receiving calls like this. Companies promising agility assessments are sprouting like dandelions.

How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that means), doesn’t matter.

What does matter is that your company is satisfying its customers, stakeholders, and employees.


Understanding your market and  customers (and potential customers) is the first step in building products that will sell. You need to know enough about both to create a product road map that guides product investments and lays out which features to deliver when.

If you aren’t sure what your customers think about your company’s current products, or don’t have a clear plan on how to create or evolve products, gather information. Investigating customer support requests, field studies and interviews can reveal how your customers currently use your product, which features need improvement, and give clues about unmet needs (which are candidates for future features and products).


Stakeholders include owners or shareholders, the board of directors, partners, suppliers, regulators and the communities in which you do business. Shareholders may focus on short-term profits; a board of directors or owner may have a interest in fiduciary responsibility and longevity of the company.

If your company isn’t delivering the financial returns necessary to remain in business, it’s time re-examine the factors that influence revenue. Most managers are familiar with traditional methods of assessing profitability. You may learn by looking at two other factors:

  • Value Creation, the process of turning a product idea into something you can sell
  • Missed Potential Profit, how much money and effort is dedicated to self-inflicted coordination overhead, rework, downtime, or support for difficult-to-use features.


In order to build great products and carry out the work of the organization, you need to attract and retain people who have the desire and ability to do the work. Great people want meaningful work, fair compensation, and work systems that support them to do their best. Great people flee workplaces that rob them of motivation and pride in work, throw up barriers or treat them with distrust.

Agile methods can help satisfy all three of these groups.

Agile encourages close collaboration with a product owner or customer (whether that’s an internal customer proxy, product owner or an end-user of the software). This helps teams understand the customer and his context, so they can make better decisions about feature design. Short iterations and frequent demonstrations of working features keeps development close to customer needs and wants.

Iteration planning and tracking story points helps teams and management understand capacity. Without this information, plans are merely wishes.

Agile methods encourage planning based on demonstrated capacity, using agile methods can help prevent cost overruns and help managers make decisions to continue funding feature development–or not. Managers have the opportunity to review progress and viability at the end of every iteration.

Working in short iterations to produce completed slices of feature can allow the company to realize revenue early; when teams finish small chunks of features each iteration, it’s no longer necessary to wait until all the features are completed to test and deploy. Every feature slice is tested and ready for customer acceptance at the end of the iteration. When the slices to add up to a marketable set, you can choose to release.

Agile engineering practices such as automated unit and customer tests, pair programming, and frequent integration find errors early which reduces the number of defects released to the customer. That results in lower support costs, find and fix costs and bad press generated by buggy products. Practices such as simple design, Test Driven Development and refactoring keep the design flexible and clean, avoiding design degradation and escalating costs for future changes.

Many teams who use agile methods are building strong cross-functional teams and report that their satisfaction with work-life and work/life balance is higher. Working at a sustainable pace and re-establishing pride in work bring intrinsic motivation. That makes it easier to attract and retain employees.

These are all things that matter in business.

Before you assess your “agility,” assess how well you are satisfying your customers, stakeholders and employees. If the data shows that your company needs better results to survive and thrive, prioritize and address first things first.

If you don’t know what customers think of your product or don’t know what product to build, start by obtaining feedback. Bring development teams and the folks who define products close together, so they can collaborate. If you are building the right products with the necessary quality, but not with the desired speed, investigate how cross-functional teams working in iteratively in time boxes can help and start there. If technical debt is costing money and slowing deployment, consider starting with disciplined agile engineering practices. If your employees feel unvalued and disengaged, examine your existing structures, policies and procedures. Dropping agile methods on top of procedures that communicate distrust and foster demotivation won’t bring the results you want.

Agile methods can contribute to improving results. Comparing your company’s agile adoption and imitating others may bring the results you want–if you are lucky and your context is nearly identical to the comparison companies.

Charting a course based on a clear understanding your current situation is most likely to succeed. Data that shows how your company is performing will garner more support for making changes than any pep talk, maturity rating, or agility assessment.

12 Replies to “Achieving Agility: Means to an End, or End in Itself”

  1. Great post!

    These caveats can be recognized using the multiple inspection and feedback points of the Scrum process. For me this post reiterates the importance of the Scrum Master role. An experienced Scrum Master can facilitate the projects towards surfacing and acting on the above issues.

    Being process focused gives the Scrum Master the opportunity to detect those issues. Reduce the Scrum Master to merely a coordinator would create a vacuum to be filled by a person who is knowledgeable and can influence change. IMHO:)


    • Hi, Sameh –

      Scrum can highlight issues in each of these areas. In many cases, they are big, systemic problems–much bigger than one individual can shift. System problems are management problems, and it takes a coalition of managers to change them.

  2. Great article and clearly articulates agile being a means to an end an end and having this goal in sight before you start your agile journey is crucial.
    Agile assessments can be useful to gain insights into specific areas e.g. a coaching focus, but if you don’t have the long term goal in sight then you are simply trying to get ‘an agile tick in the box’

  3. Agility is not a goal or something that is to be maximized. Agility is a continuum. There will be a point where there is sufficient agility to achieve your goals. So I agree with you that it doesn’t matter how Agile you are.

  4. Whilst I agree with what I understand the intent of this article is (that agility is not an end but a means to that end) I would say that in my experience you really only have to do one thing as a manager – keep your employees happy and tell them your top three priorities.

    Keeping customers happy follows naturally from the culture of seeing everyone as individuals and trying to fulfill their needs – which you need to do to keep your employees happy. One thing I dislike that I see in two many organisations is a separation of engineering (or an agile team) from the stakeholders. We should all have a common sense of identity and common goals. Losing this is I think one of the main causes of loss of efficiency when growing from start-up to large company. So I would again simply focus on keeping the employees happy and making sure they understand the top three priorities. Employees are smart, they’ll figure the rest out for themselves.

  5. […] Martin Proulx在名为“Yet Another Agile Maturity Model (AMM) – The 5 Levels of Maturity”的博文中提出了自己的看法,开篇两段话写得很中肯。他首先引用Esther Derby的观点,“How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that means), doesn’t matter. What does matter is that your company is satisfying its customers, stakeholders, and employees. (Achieving Agility: Means to an End, or End in Itself)”,而后则提出,“我们必须得面对一个事实,人们喜欢知道自己相比他人所处的位置。从很小的时候起,我们就被培养习惯要和他人进行比较,从而可以晋升至下一级——虽然压根不知道下一级是什么。” […]

Comments are closed.