Building a self organizing team of engineers!

 At its peak, a self organizing team is equivalent to a high performance team; A team of engineers that can deliver a quality product with maximum efficiency (minimum timespan!).

 You cannot put together a group of high performance individuals and expect the outcomes of a high performance team. The group of individuals will take their time to get to adapt to each other as well as the product and business domain. This can typically take one or two product release cycles.

 Lets start at the beginning. You are adopting agile product delivery and you want to setup a self organizing engineering team. Historically, engineers are used to management bringing in new processes or project tracking tools, and requesting the team for adoption, and the usual reaction at the beginning is passive resistance and minimal compliance to management requests for adopting the new process or tools. Your team is bound to look at your desire and goal to adopt agile in a similar manner.

 How about letting the engineering team decide for itself on how it will transition to agile product delivery? To make this possible you need one or more of your senior most technical leaders on the team to champion agile with the technical team. Your senior most technical leaders and you, thus have to go through rigorous agile trainings and have your own internal discussions and debates to arrive at how agile product delivery can benefit everyone in the context of your organization and what path and plan of adoption to get the team to transition to agile execution and product delivery.

 If you are setting up a project team of 7-9 engineers to deliver your first project release using agile, its critical that you choose a technical leader on the team who can champion self organization and steer and coach the team throughout the release. If you have multiple technical leaders who can play this role, that you can choose to round robin leaders into this role across releases. If you have no such technical leaders available, you are in trouble :). You may either hire such a leader, or temporarily ask someone from the management team or yourself play the role of the technical leader for the current project and use it as an opportunity to train one or two senior engineers on the team to take up the role in upcoming releases. This implies that you do not yet have a team that can self organize on its own, and you are using a temporary tactic of having a management person orchestrate the organization of work and decisions in the team.

 Having the right technical leader to champion the release is critical. As a next step the technical leader and you need to be clear about creating an empowering work culture and team. You are likely to have engineers with varying levels of experience and seniority on the team. Each such individual should be empowered to be able to own his work at this level, influence technical decision making in his areas of work as well across the team over time, and step up and take on more complex work.

 Initially the technical leader for the release will have to handle much of the self organization required within the team. Over time, he should be able to coach the team and decentralize the process of self organization and avoid being the bottleneck for decision making or self organization.

 What do we mean by a self organizing team? What should the team be able to do independently on its own? What do we mean by the team the team being able to own & deliver a product release from start to finish?

 A product or a product release solves a new customer problem.

 The team should be able to work closely with product owner on following aspects.

• Having a strong understanding of the customer problem in close interactions with product owner and customers.

• Propose solution alternatives and/or technology alternatives.

• Create early solution prototypes in working with product owner.

• Determine the functional release scope (product backlog) as well as non functional (system performance & scale & user responsiveness...) goals for release.

Once the general direction of the product solution is well established, the team should next be able to independently drive product release execution and solution validation engagements with customers.

Here are some critical situations where in the self organizing qualities of a team get really tested.

Situation 1: Coming up with overall sprint plan for release for complex features.

The team should be first able to come up with excellent incremental delivery plans for such complex features, (in terms of what should be accomplished first vs later), and then introduce the time and planning angle in terms of number of sprints and team members required to finish off such a feature. This is a situation where in the technical leader(s) of the team play a crucial part. If the team understood agile principles correctly, then this is the first part it should be able to get right; laying out the plan of attack for the product release. What does the team take up first? Technology evaluation or prototype of a functional solution of customer or both in parallel? If technology choices are well known or straight forward, which is the core functionality to be delivered and tested and validated with customers within the first sprint? And next...This is a situation, phase or part of the release where in the technical leader and the team build the mental map and vision for the rest of the release cycle.

Situation 2: Identifying work to be done in a sprint to meet committed product backlog items.

Does the team show rigour in quickly and comprehensively identifying the work involved in the product stack to be able to implement a set of product backlog items, during the sprint planning session? This becomes a very tricky situation while working on legacy products or components. Work can expand or contract significantly from what might have been originally anticipated, or if the team is new to the legacy components. The balance to be drawn here is over investigating or analysing the legacy code base or component vs jumping straight to execution. Senior technical members of the team again have to show their judgement at sensing when it is best to dig in a little deeper to understand the true nature and amount of work involved vs when to just get going and unearth the work along with the execution of the sprint.

Situation 3: Communicating effectively on sprint commitments being or not being met.

The team has committed to 10 user features in the current sprint; When the current sprint completed, 7 out of the 10 features were completed.

Did the team announce that 3 of the 10 features would not be completed early enough? Or did it catch stakeholders by surprise on the last day in sprint review meeting?

i.e. Is the team able to keep an eye on the entire set of sprint goals, and is the team able to sense that it might have overcommitted, or understand that the work involved was more than anticipated, and communicate promptly and re-organize to complete maximum user features instead of 10? or is the team merely motoring along doing whatever they can, with no real commitment to the end outcome for the sprint?

An immature team can be two dimensional. Merely point to new work identified, call it a part and parcel of software development, speak of how this is acceptable in agile and pass on everything to the next sprint. A strong team of winners, will naturally think of a successful sprint, and think about what's possible, and what it can demonstrate as a sprint outcome which in turn acts as a sprint WIN for the team. This mental make up of the team is crucial. A team looking to win in every sprint vs a team mechanically going about identifying the work and laying it from sprint to sprint. Again the attitude and approach of the technical leader in team, majorly influences how the team conducts itself in this situation.

Situation 4: Setting the right standard on product quality.

The product build quality is not up to expectations; The team is generally on track to deliver on all sprint commitments, but there is a risk to quality of output.

Does the team set the right standard in such situations, and drive quality early and upfront? Even if it means implementing one less feature than what was committed in the sprint? In this case, is the team able to effectively work with the product owner and trade off on the sub feature in the interest of quality? Again, who keeps the pulse on the quality from the development team? An immature coding team might keep on coding, and generally, be aware of what functionality has been coded so far, and speak of progress, success and completion in terms of what's code complete. An experienced coding team looks for test results, drives and influences what is tested upfront, and looks for the most critical test results upfront, and then declares success on the basis of positive tests results and data points.

Situation 5: Overcoming technical impediments.

Developer X is struggling with a implementation of feature A, due to certain technology challenges. Feature A is core to the success of the sprint.

Does the team rally around this developer, and pull in skills and knowledge or take external help to get past this technical impediment, and in the worst case, even eliminate, reduce a non critical feature from sprint commitment in the interest of successfully implementing feature A? Understanding the critical themes and success factors for a release as well as a sprint, is a very crucial, and a mature team keeps this aspect in mind at all times, in its day to day organization and execution.

Situation 6: Handling product defects throughout the release cycle

It takes an experienced technical leader or team to determine defects that should be fixed immediately vs a little later, vs defects that are as per designed behaviour (and thus not defects!), vs defects that are outside of solution scope and hence would require change management to kick in to extend solution scope or the defects will move to next release. Defects can result in silent creep of project scope. An immature team will fix what it is told to, or what ever is open as a defect in the defect management system. An experienced team with a seasoned leader, is very effective at staying focused on the core, as well as the committed, and steer clear of busy work on defect management system, or clearly call out, what is out of solution scope, vs what is net new and unanticipated and has to be planned for, vs what can be deferred.

Situation 7: Handling non functional requirements.

The team has to work closely with product owner to ensure adequate attention to non functional requirements. Be it system performance or scale or user experience or user responsiveness or product security or legacy technical dept..

Can the team define the right goals and measures? In what sprint are these goals to be met? Work involving performance tuning and scale can take an unpredictable amount of time. How does the team proactively design for building the right system to meet required goals? If new architecture is being put in place or performance or responsiveness is a significant theme for the release, then such items, due to their complexity as well as relevance to the release have to be taken upfront in the release, as it constitutes a significant success factor or risk. Does the team adequately keep the non functional success factors in mind throughout the release?

Situation 8: Engaging cross functional stakeholders

The engineering team constitutes the majority of the overall team strength executing on the release, and need to have a sense of ownership, responsibility and drive on product release execution.

Does the team sit back and complain about the smallest of impediments across functions, or does the team demonstrate a winning attitude at driving the release forward, engage, collaborate and move thing forward, or effectively leverage the scrum master, product manager or even the leadership in doing so. An effective team and the right technical leaders, understands the significance of the product release to the business, and the part, relevant stakeholders are expected play in the release, and can hold stakeholders accountable to that expectation.

Situation 9: Engaging customers, executing customer validation & feedback

A good team expects the product owner to be the leader in such phases. A great team expects no one else to lead any aspect of the success of the release, that it is truly in the act of owning and delivering.

Again, a great team can easily define such customer engagements, and define the exact feedback it needs to gather to confirm success. And not merely execute a customer engagement event as a ceremonial phase of the product release cycle, to be completed as per process!

Your teams ability to self organized can be well understood from how well it can handle such situations. And in a positive environment, the team will learn and get better and better. The product owner, scrum master and the technical leader should form a critical leadership triad to work with the rest of the team during sprint retrospective meetings, to ensure that the team learns from its first mistakes, and continually gets better.

As a coder, I never wait on a tester to tell me what the quality of my code is, as per his own sequence of testing. That's putting my fate in his hands. I would always test what I should and can on my own, and then convince the tester about the right order in which critical tests results are to be measured, and the order in which I'm completing my code to make that critical sequence of test results possible. This sequence and the anticipated data points act as the mind map as well as the success criteria for a product or feature release. Well organized teams are simply good at working extremely cohesively in their coding and testing to hit the success parameters in testing in the shortest possible timespans!

What is working software or demo-able software or valuable software?

The Agile Manifesto refers to the concept of working software.
Working software over comprehensive documentation

The Principles behind Agile Manifesto refer to the concept of working software.
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Principle 4: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time-scale.
Principle 7:Working software is the primary measure of progress.



The concept of working or demo-able or valuable software appears quite obvious and commonsensical and like all such things, can escape even the best of engineers.
Firmly imbibing an understanding of working software in a consistent manner across the entire software engineering team is the most fundamental training required, at the onset of the transition to an agile delivery mode of execution. 

Here is the most common and obvious interpretation of agile of an engineering team newly transitioning to agile (in the context of coding and delivering working software)

In response to customer requirements or problem:

• Devise a new solution and technical design to be supported in the product release.
• Create a lean design and solution and get to the implementation stage as soon as possible. Avoid documentation of solution as it is time consuming (we would rather be coding), and continuously keeping such documentation updated in response to changes is cumbersome.
• Divide the implementation phase of the feature into N parts of X weeks each, each to be called as a sprint.
• Plan for a demo at the end of every sprint to demonstrate working software to stakeholders, and incorporate any feedback in subsequent sprints.
• Meet everyday to report on progress to the team and management, raise challenges or risks early, and resolve them early in the release stage.
• Repeat each day, week and sprint to defined script as per agile, and deliver the required functionality in N sprints.
• Repeat the above process for all features that constitute the minimal viable product release for the product.

The above definition is nothing but a leaner form of waterfall delivery model morphed as an agile model of delivery.

Back in the days of c programming, when engineering teams transitioned to c++, the programming language syntax remained the same, and most engineers, jammed in c functions into class member functions, and swiftly completed the transition. True thinking to objected oriented programming principles and consequent entity models and class implementations came in much later. The transition to agile software delivery requires a similar shift in paradigm in software delivery, build around the customer.

What do we mean by working software or demo-able software or valuable software?

Valuable software is software that solves a customer problem, and is ready to be deployed in production.

How do we go about building valuable software in multiple sprints?

Agile manifesto emphases on customer collaboration. The most critical phase of this collaboration, at the beginning of a product release, is at thoroughly understanding the customer problem. The second phase, is in validating the the solution devised in the product truly solves the customer problem.

Given a product release feature, how do we decide which part of the feature is to implemented in which sprint?

In traditional models, an engineering team would build the complex database or back-end systems to eliminate technology risks as early as possible and then build the layers upwards from bottom to the top, and add the UI layer (usually seen as the least complex or risky part of the release). In most software products, the UI layer is the only layer exposed to the customer. i.e. We built software products inside out(From technology to the customer). And then made them available to the customer for download and trials.

In today's highly connected world and commoditized connectivity costs, we now have an opportunity to build and deliver software outside in. From customer, the customer problem, back to technology.

As product engineers, we have to ask ourselves the following questions.

• What is the quickest path to getting the product out to customers and users for early validation? (wait no later than you need to to confirm success)
• What input information or data do I need from customers upfront in product release cycle to test with real data inputs early in the engineering cycle as possible? (avoid simulating or guessing data or inputs when you can actually use real data to accurately test and confirm success.)

This in turn influences the team to take a top down (end to end) approach to building features in the complete product component stack, as well as in visualizing the end outcome upfront and then reverse engineering the sprint plan to get to the end outcome in the earliest possible time span.

At times, this might mean that, the architecture required to meet the performance and scale for every customer or all customers, is not yet in place in the first software increment delivered to customers.

Internally, multiple sprints might be required within a product release, to get to a stage where in valuable software is ready to be delivered to customers. Each such sprint has to produce a working software increment that is demo-able (early sprints) to customers or ready to be deployed for actual hands on use and trials by customers and users. When the team reviews a sprint plan and targeted outcomes from the customer perspective (what can I demonstrate and share with a customer at the end of each sprint to get customer feedback and to convey the progress we are making on the product release), it keeps the team honest to agile principles. Regular demo's and update to customers and internal stakeholders in-turn builds tremendous confidence amongst customers, product owner and the leadership team. Working software thus becomes the best and only measure of success.

This write-up about working software sounds pretty obvious; however you are bound to face challenges if the following is true for your team

• An untrained (in agile) team can easily get lost in technology or theoretical or paper solutions or use simulated data or worst, use limited and hand-crafted test data and deliver working code or working components as working software. 
• If the business domain for the product is complex, and the engineering team does not have the right level of maturity in the domain, they are far more likely to stick to doing what they know best (design, evaluate technology and code), as opposed to taking on the customer problem and customer solution validation phases, head on, EARLY into the product release cycle. 
• If your organization is structured by different teams owning different parts of the product stack, members of such teams are bound to only look at what work they have to do, and not worry about the overall picture. At worst, the team might expect the testers to figure out and tell them whether the solution works end to end in the product stack.
• If team members are geo-distributed they are bound to pick up the work that requires minimal interactions across teams, first, and then plan integration phases late in the game.

This is where the engineering leadership team has to set the right standard, and really review and confirm that the team indeed has put the customer, and customer problem above everything else, and has a great agile plan in place to get the product release out of the door . Great delivery strategies, that focus on early validation of understanding of customer problem and early and continuous confirmation of solution (and its completeness) with customers, is the only way to ensure successful releases. And an engineering feature or product has to delivered accordingly to such a strategy built at the beginning of the release.

Agile delivery philosophy requires engineers to put the customer problem and customer collaboration for solving the customer problem, ahead of coding and technology, and that is never intuitive to most die hard engineers passionate about technology and eager to write code and learn new technologies all the time. With agile, engineers now have to 'run their own business'; Be engaged & engage customers and product owners, and own product feature releases from start to finish of a product release.

Agile manifesto and principles

The text for this post is taken from the reference links. No book or blog on agile software delivery is complete without a mention of the manifesto and principles. The principles behind the agile manifesto unfortunately do not provide any in-depth insights over what is already conveyed in the manifesto. Most of the principles are applicable to any product or team, irrespective of the methodology or philosophy for execution, and this probably is the motivation and cause behind the hundreds of books and blogs that attempt to convey how the manifesto and principles have to be adopted in practice, to achieve desired outcomes.


Manifesto for agile software development (Reference: http://agilemanifesto.org/)

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more.

12 Principles behind agile manifesto (Reference:http://agilemanifesto.org/principles.html)

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

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

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time-scale.

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

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Transitioning Product teams to agile – Key considerations

How do we enable the product team for agile product development and delivery?

 Let us first understand the links between a engineers and customers

Coder -Product Manager-Tester-IT Infrastructure-Project Manager-(execs)-Marketing-Sales-Sales Engineers-Account Managers-Product Technical Support- Customers

To enable continuous and incremental software delivery we have to navigate the above chain with maximum efficiency. (i.e. quickly and easily)

In this post I will focus on the product team (product managers and engineers). Given below are the key considerations for maximizing efficiency in delivering continuous product releases.


Engineering Team
Product delivery methodologies and tools do not deliver products; Software engineers do. The technical team needs to have the the correct composition of technical leadership, technology skills and maturity to deliver successful product releases to customer requirements and system (performance & scale) requirements, in effectively crafted product increments.
Lack of technical leadership will result in complete failure of product or releases, irrespective of the product delivery methodology of the organization.
If majority of members in the engineering team have never previously worked on software products with the level of complexity (user experience or architecture or performance & scale) expected in the product to be worked upon, it points to lack of experience and maturity in the engineering team. The engineering team might also lack experience or awareness to lean and agile engineering or collaboration practices or tools. This can result in delayed product releases through over engineering of solutions or initial optimistic commitments in a product release or inefficient collaboration and decision making during release execution.
The ability of an Organization's leadership team to effectively set-up the right engineering team is the most critical factor for the success or failure of product delivery.


Product architecture
Product architectures needs to be adequately modular to enable automated software updates to production deployments. The goal is to ensure the highest uptime for the product and a hassle free product update and maintenance experience for customers.
In the case of pure SAAS products, the organization owns and maintains product deployment in its own data centres or through PAAS providers like Amazon Web services, Rackspace or Microsoft Azure. This fact makes it relatively easier to update product production deployments with no intervention from customers.
In the case of products that either exclusively deploy in customer environments or partly deploy component in customer environments, the components deploying in customer environments have to have the architecture and capability to be able to download and deploy product updates with minimal down time and ensure minimal intervention from customers i.e. Minimize or avoid expensive product resets or restarts and consequent change management process workflows in customer environments.


Customer engagement
Engineering team have to be in a position to engage customers to get direct customer feedback on functionality being built in the product at regular intervals.

• The product team has to select a right sized and representative customer sample set to get maximum validation of product functionality being built, before the newer functionality in the product is available to all customers.
• Customers have to be able to use the product functionality being built and give concrete feedback based on their experience, at the earliest possible point in the product release cycle.
• The product has to capture the right amount of information to effectively understanding customer behaviour patterns from the customers use of the product.
• Product components deployed in customer environments and interacting with the customer environments are in a position to gather valuable information on customer environments to enable software engineers to effectively understand IT environment characteristics across customers.

Continuous Integration (CI) engineering systems
Product engineering teams have to have continuous integration engineering systems in place for continuous development, testing and delivery;

Code review tools, continuous build integration, unit testing & integration testing, software security testing, test automation, test environments, staging (production replica) environments.

The goal is to minimize the time cycle between the point at which new code is added to the point at which the new code is published to be deployed in production environments to deliver net new value to customers. As an important consideration, automation in engineering systems has to ensure that, on a day to day basis, engineers spend maximum time in writing or debugging code (creating value), and minimal time on all other activities like building, packaging, test deployments, regression tests etc.

Process & collaboration mechanisms
Information, actions and decisions have to flow effectively between every department or function involved in the value chain between the coder and customers.
Within the product team (Product Owner, and Engineering team), effective collaboration could involve daily stand-up meetings, tools for capturing arising issues (impediments), technical decisions, risks, unanticipated work items, as well as sequence diagrams,whiteboard diagrams, test results etc. that precisely convey the right state of the feature/product as implemented in an iteration on a daily basis.


Project management tools
Agile tools for tracking project scope (product backlog), iterations (sprints), regular progress on features & sub features (user stories), work that could not complete in an iteration (spillovers), in a manner highly visible and transparent to project stakeholders.


Its very typical for Organizations adopting agile to first adopt agile collaboration practices, or project management tools in isolation, to claim success at adopting agile product delivery. As a first step such an Organization would first request development managers, testing managers or project managers to undergo agile or scrum master trainings, define a new process around agile collaboration mechanisms, perhaps invite an agile coach as a consultant, and quickly get to adopting agile in the next release. This is a classic top down or management driven approach that adds tremendous burden on engineers. They have to continue with existing engineering practices, or product architectures or customer engagement practices, and now have to additionally take on additional complexity of a new process, take responsibility to be self organizing and share updates on their progress through the newer tools etc.


Agile speaks of the need for the engineering team to be self organizing. This very principle requires the organization to, as a first step, empower the engineers and technical leaders and involve them and ideally have them decide the best path to moving to an agile product delivery model. This might in-turn require bringing in upfront training to engineers on agile product delivery model to have them understand the benefits and implications of agile. This is the true agile and empowered approach to adopting agile in an engineering organization.

What is agile software development?

The literal meaning of the word  Agile - Ability to move quickly and easily.

Agile software development is a philosophy for delivering software to customers in a continuous and incremental manner.

What does continuous amount to, in practice?

It could be any interval from 1 day ( defect fix ) to one week (an enhancement) to a month (new feature) to 3 months (multiple features) or anything in between or more in extreme cases.
What do we mean by incremental? A software increment of value to customers. (Minimal viable product, a new feature or a new enhancement or a defect fix).

Agile software development can be adopted for all forms of software products. Be it a mobile application or e-commerce website or an enterprise software as a service (SAAS) product or a product that only deploys in enterprise customer IT environments.

There is no such thing as an agile software development team in isolation. True agile software development and delivery requires engineers and everyone in between engineers and customers to adopt an agile approach in serving customers. i.e. The entire organization has to adopt the agile philosophy.

To transition to agile, the organization has to absolutely clear on this simple and critical outcome of agile: Continuous and incremental delivery. The team has to then work backwards, and determine the systems, teams & business processes that need to be put in place to complete the transition.

Agile methodology can itself be adopted in an agile manner.

Agile methodology is most effectively adopted using a top down approach; from leaderdship to every ground level team member in every function; engineering, product management, marketing or sales.

Agile methodology is most effectively adopted from right to left in the value chain from engineer to customer; From customer facing functions back to the internal functions or departments and engineering teams.

Traditional businesses have been using the agile philosophy for setting up and running businesses for ages. Lets consider an example

You are an expert at baking cakes and have decided to build a business around it.You could initially start by testing your concepts with your family & friends, then identify a restaurant that is willing to add your cakes to their dessert menu. If your cakes are well received, you could then decide to extend your production capabilities to scale to a few more restaurants. At some point you might decide to setup your own outlet... and so on.

With the advancement, growth and commoditization of technology and connectivity, the software industry now has the same opportunity.

Here is an example of an continuous iterative technology product delivery to customers.
Lets consider businesses like MagicBricks.com or Housing,com which host websites to enable customers to rent or purchase apartments.

Once the business idea is validated, the first product deliverable can be the minimal capability required for owners to register and publish apartments available on rent, and seekers to register and express interest in taking up an apartment on rent, and exchange contact information with apartment owners to engage and go through with the transaction.

With this minimal product capability in place, the product can be launched in an agile and iterative manner across geographic areas, one city at a time. This approach can enable the business to focus on getting the product right in one city, and also ensure that the product (website) is not overloaded with traffic that it is not yet capable of handling. Once the product team has validated the product for a single location, it can then choose to build the right scale in the product to enable it to take on higher traffic and handle larger data sets in the backend systems. It is now in a position to rapidly iterate and expand across geographic locations.

As a second iteration, the product team can then go on build product capabilities for enabling customers to purchase new apartments and work with builders to register new projects and enable customers to discover apartments that match their needs.

At every stage of continuous engagement with customers (builders as well apartment seekers), the product team can use the opportunity to listen and take feedack from customers to continuously refine the product experience for the customer to get it to be as intutive as possible.

The product team can continue to add more capabilities to the product that continually add value to customers, and help the product and business in staying ahead of the competition.

This is too obvious an example and you dont have to be a software engineering professional to understand it. Agile software development is all about the art of making technology & software development transparent to the business or customers or shareholders. The organization should only have to focus on what value it has to deliver to customers, and software delivery systems, processes and teams should enable effective delivery of required capabilities in an continuous and incremental manner.

The transition of a traditional technology company or a technology enabled company from traditional product delivery mechanisms to agile product delivery can be challenging, but  tremendously rewarding for customers, organization and engineers.