Agile Software Development Quotes

Perhaps you thought that “getting it working” was the first order of business for a professional developer. I hope by now, however, that this book has disabused you of that idea. The functionality that you create today has a good chance of changing in the next release, but the readability of your code will have a profound effect on all the changes that will ever be made.

Suppose a developer has a conversation with a customer about details of a feature. The conversation should not be considered complete until it is expressed as a customer test.

Celebrate Successes, but Don't Declare Victory

It is a myth that we can get systems “right the first time.” Instead, we should implement only today’s stories, then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility. Test-driven development, refactoring, and the clean code they produce make this work at the code level.

Code formatting is about communication, and communication is the professional developer’s first order of business.

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test.” —Ray Ozzie, CTO, Microsoft Corporation

It may seem like writing tests slows down development; in fact, testing does not cost, it pays, both during development and over the system’s lifecycle.

To focus on the visible at the expense of the essential is irresponsible.

There is really no bad software development process. There is only how you are doing it today and better.

Agile is simple—it just isn’t easy.

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don’t have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code.

Code formatting is important. It is too important to ignore and it is too important to treat religiously. Code formatting is about communication, and communication is the professional developer’s first order of business.

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone. -Dave Thomas, founder of OTI, godfather of the Eclipse strategy

Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down.

agile development reflects a product lifecycle approach (continuous delivery of value), rather than a project approach (begin-end). While an individual release of a product can be managed as a project, an agile approach views a release as a single stage in a product’s ongoing evolution.

The majority of the cost of a software project is in long-term maintenance. In order to minimize the potential for defects as we introduce change, it’s critical for us to be able to understand what a system does. As systems become more complex, they take more and more time for a developer to understand, and there is an ever greater opportunity for a misunderstanding. Therefore, code should clearly express the intent of its author. The clearer the author can make the code, the less time others will have to spend understanding it. This will reduce defects and shrink the cost of maintenance.

Recommended Reading The Definitive Guide to Getting Your Budget Approved by Johannes Ritter and Frank Röttgers provides a systematic guide for creating a financial business case. The book includes examples as well as the methods for using Monte Carlo simulation and sensitivity analysis to create the business case. The methods described in the book can also be used for quantifying risks and project costs. Mary and Tom Poppendieck in their book Lean Software Development: describe the lean principles and the types of waste in software projects.

Countering the juggernaut of formalism is a minority worldview of equal historical standing, even though it does not share equal awareness or popularity. Variously known as hermeneutics, constructivism, interpretationalism, and most recently postmodernism, this tradition has consistently challenged almost everything advanced by the formalists. Iterative development practices, including XP, and object thinking are consistent with the hermeneutic worldview. Unfortunately, most object, XP, and agile practitioners are unaware of this tradition and its potential for providing philosophical support and justification for their approach to software development.

Improve performance through process improvements introduced with minimal resistance. Deliver with high quality. Deliver a predictable lead time by controlling the quantity of work-in-progress. Give team members a better life through an improved work/life balance. Provide slack in the system by balancing demand against throughput. Provide a simple prioritization mechanism that delays commitment and keeps options open. Provide a transparent scheme for seeing improvement opportunities, thereby enabling change to a more collaborative culture that encourages continuous improvement. Strive for a process that enables predictable results, business agility, good governance, and the development of what the Software Engineering Institute calls a high-maturity organization.

I would compare a project with a country, which is either properly regulated by the laws or enslaved by a dictator whom everybody is supposed to love. What modern management is doing in most companies is the latter scenario. They expect us to love the customer and work just because of that. There are no laws, no discipline, no regulations, and no principle, because, like every dictator, they simply are not competent enough in creating them. Dictators just capture the power and rule by the force: it's much easier than building a system of laws, which will work by itself. The management in software projects also can't create a proper management system, since they simply don't have enough knowledge for that. Instead, they expect our love. Isn't it obvious that rather soon that love turns into hate and we quit or the project collapses?

When applying agile practices at the portfolio level, similar benefits accrue: • Demonstrable results—Every quarter or so products, or at least deployable pieces of products, are developed, implemented, tested, and accepted. Short projects deliver chunks of functionality incrementally. • Customer feedback—Each quarter product managers review results and provide feedback, and executives can view progress in terms of working products. • Better portfolio planning—Portfolio planning is more realistic because it is based on deployed whole or partial products. • Flexibility—Portfolios can be steered toward changing business goals and higher-value projects because changes are easy to incorporate at the end of each quarter. Because projects produce working products, partial value is captured rather than being lost completely as usually happens with serial projects that are terminated early. • Productivity—There is a hidden productivity improvement with agile methods from the work not done. Through constant negotiation, small projects are both eliminated and pared down.

Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. As productivity decreases, management does the only thing they can; they add more staff to the project to increase productivity. But that new staff is not versed in the design of the system. Furthermore, they, and everyone else on the team, are under horrific pressure to increase productivity. So they all make more and more messes, driving productivity further toward zero. Eventually the team rebels. They inform management that they cannot continue to develop in this odious code base. Management does not want to expend resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually, they bend to the demands of the developers and authorize the grand redesign in the sky. A new tiger team is selected. Everyone wants to be on this team because it’s a green-field project. They get to start over and create something wonderful. But only the best and brightest are chosen for the tiger team. Everyone else must continue to maintain the current system. Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Management will not replace the old system until the new system can do everything that the old system does. This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.

agile is the most disciplined and quality-driven set of development practices the industry has invented to date.

the user story as the primary artifact for identifying system behaviors that deliver value to the customer. We implied that engaging a user in a dialogue about how they use the system, and what benefit they derive, is a straightforward process.

The norm is that if you launch a big initiative and it fails (in any department, not just tech), it would certainly limit your career. In more agile cultures, failure isn’t punished. Instead, it’s a learning opportunity. The mindset of embracing risk and tolerating failure is a huge part of the software ethos. It’s also one of the biggest things that old companies avoid—even those with leaders who claim, as many do, that they want to become more like a startup.

It’s not just software itself—it’s the fundamental agility of software that drives Software People. It starts by listening to customers, rapidly building initial solutions to their problems, getting feedback, and then constantly iterating and improving. With this progression of computation, Software People can apply this software process to more and more of the world’s problems. I particularly enjoy seeing it arise in traditionally hardware-centric fields because when you see a Software Person running the playbook in the field of hardware, you can see the evolution play out physically in plastic, metal, and glass.

In their 2012 paper, “A Taxonomy of Dependencies in Agile Software Development,” Diane Strode and Sid Huff propose three different categories of dependency: knowledge, task, and resource dependencies.14 Such a taxonomy can help pinpoint dependencies between teams and the potential constraints to the flow of work ahead of time.

That’s why many Agile products start as feature poor. Chances are, features aren’t as important as getting an idea in front of customers quickly. So deadlines trump features, with quality as an underlying assumption.

That’s why many Agile products start as feature poor. Chances are, features aren’t as important as getting an idea in front of customers quickly. So deadlines trump features, with quality as an underlying assumption. Build less, but with confidence, is the path of many early product teams. If you’re right about the core, you can always iterate and build more features later.

Examples of slowification practices: using mock-ups, prototypes, simulations, scale model tests, offline problem-solving, land-based models, etc. §§ Examples of simplification practices: simple workflows, agile software development, modularization, just-in-time, pull systems, etc. ¶¶ Examples of amplification practices: stress tests, andon cords, smoke detectors, etc. to flag problems sooner rather than later.

Small batches create speed, flexibility and responsiveness for software projects.

In this tech-savvy world, the enhancement of globalization is changing our life very fast. However, you owe a small or large business; the use of the software is making our business simple yet. It helps us to manage our business effectively and reach great heights of success. Like many other software development companies around the world, Tech Dyno BD offers a software development service that helps your business or organization stay innovation-oriented, agile, and effective in managing company values best.

Bewilderingly, among some enterprises, there is a recent trend of anointing a special team that is separate from development and operations: the “DevOps” team. The whole point of DevOps is to create unity and collaboration among different specialties, not more silos. We even see job ads for “DevOps engineers,” who apparently are a special breed different from normal engineers and system admins. What happened? We believe this is the result of a buzzword-bingo approach to management. Rather than cultivating “individuals and interactions,” we have organizations hoping to avoid rethinking how to operate and instead get by with a reconfiguration of the software factory. And the surprising thing is that many have achieved that dubious goal.

Agile software teams solve the problems with waterfall by building their software incrementally, making only the decisions around the specific work packages they’ve chosen to complete in a sprint. They delay even the decisions about which work packages or user stories to implement, choosing them out of a backlog at the start of each sprint. They get immediate feedback, first from their own tests and then from the users at a Demo to validate their decisions.

Agile Software Development constructs that are not helpful when there are dependencies, long lead times, and resources from a variety of specific disciplines to manage with high cost-of-change. They don’t start over with a new plan every sprint or program increment.

the software team needs some way to validate their work before the responses from actual hardware are available. Simulators model behaviors from subsystems through the full system in virtual space — including user behavior. An emulator is a physical device that imitates the behavior of one subsystem, providing realistic inputs and outputs so that another subsystem can be developed independently.

These scrums provide opportunities for problems to surface and for a team member who’s overloaded to get help from another team member. Software teams benefit from meeting every day because their batches (user stories) are small enough to require daily coordination.

In software development, user stories can deliver direct user value independently

We are big fans of the agile software movement. In 2001, seventeen software developers met in Snowbird, Utah, and published the “Manifesto for Agile Software.” The four main values in the manifesto remind us how the best friction fixers think and act: (1) “individuals and interactions over processes and tools”; (2) “working software over comprehensive documentation”; (3) “customer collaboration over contract negotiation”; and (4) “responding to change over following a plan.” Agile software teams deliver their work in small increments rather than in one “big bang” launch. Rather than following a rigid plan, they constantly evaluate results and constraints and update the software, and how they work, along the way.

Agile development is an approach to software development that emerged in the late 1990’s from a collection of ideas about how to make software development more lightweight, flexible, and incremental; it was formally defined during a meeting of practitioners in 2001.

One of the most important elements of agile development is the notion that development should be incremental and iterative. In the agile approach, a software system is developed in a series of iterations, each of which adds and evaluates a few new features; each iteration includes design, test, and customer input.

It used to be that developers rarely wrote tests. If tests were written at all, they were written by a separate QA team. However, one of the tenets of agile development is that testing should be tightly integrated with development, and programmers should write tests for their own code. This practice has now become widespread.

Instead of security and compliance activities only being performed at the end of the project, controls are integrated into every stage of daily work in the software development life cycle, resulting in better quality, security, and compliance outcomes.

Meaningful work has social value. The software development that enables meaningful work is by extension meaningful work in and of itself.

I therefore believe that we will look back at the rise of the Agile brands being nothing more and nothing less than named collections of good practices as a crucial step in the evolution of software development.

with

We ignored the fact that many customers don’t know what they want. We ignored that fact that even when they know what they want, they can’t describe it. We ignored the fact that even when they can describe it, they often describe a proposed solution rather than the real need.

Instead of having a lengthy integration and qualification cycle, an agile process makes it part of the ongoing development process. This shift is accomplished through approaches like continuous integration/delivery, sprints with complete requirements, test-driven design, and automated testing. All this is put in place so that when customers think they have enough of the capabilities ready, the code is close to being ready to deploy.

business challenges started with a predicament of two-year long development cycles for delivering firmware, and of complex embedded software that had been slowly aging over many years and needed to be re-architected. Big-bang integrations were frequent. Before learning about agile, we had some early improvements and got to the point of 8-week development cycles, a daily build or two, and a nightly smoke test.

aim is to make the delivery of software from the hands of developers into production a reliable, predictable, visible, and largely automated process with well-understood, quantifiable risks. Using the approach that we describe in this book, it is possible to go from having an idea to delivering working code that implements it into production in a matter of minutes or hours, while at the same time improving the quality of the software thus delivered. The vast majority of the cost associated with delivering successful software is incurred after the first release. This is the cost of support, maintenance, adding new features, and fixing defects. This is especially true of software delivered via iterative processes, where the first release contains the minimum amount of functionality providing value to the customer. Hence the title of this book, Continuous Delivery, which is taken from the first principle of the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Software architecture plays a pivotal role in the delivery of successful software yet it’s frustratingly neglected by many teams.

Non-functional requirements” not sounding cool isn’t a reason to neglect them.

organisations often tend to see software architecture as a rank rather than a role too

As a noun then, architecture can be summarised as being about structure. It’s about the decomposition of a product into a collection of components/modules and interactions.

As a verb, architecture (i.e. the process, architecting) is about understanding what you need to build, creating a vision for building it and making the appropriate design decisions. All of this needs to be based upon requirements because requirements drive architecture.

a software architect who codes is a more effective and happier architect

You don’t need to be the best coder on the team

developers are likely to ignore your coding experience if you’re not programming on the project

Unlike the medieval building industry though, the software development industry lacks an explicit way for people to progress from being junior developers through to software architects. We don’t have a common apprenticeship model.

No one has yet figured out how to manage people effectively into battle; they must be led,” wrote John Kotter

accurately setting and managing expectations.

Arguing on the Internet is a complete and utter waste of time and energy. It is futile and illogical. Yet, despite being a category of people who rely on their keen sense of logic, software developers often argue on the Internet.

Agile is a response to the need for more continuous software repair. Its central strategy is to reduce the size and increase the frequency of the design-develop-test lifecycle. Over time, Agile has discovered and incorporated several powerful techniques to remove noise from the iterative lifecycle. These

Contrast this to the more traditional model where Development and Test teams are assigned to a “project” and then reassigned to another project as soon as the project is completed and funding runs out. This leads to all sorts of undesired outcomes, including developers being unable to see the long-term consequences of decisions they make (a form of feedback) and a funding model that only values and pays for the earliest stages of the software life cycle—which, tragically, is also the least expensive part for successful products or services. ††

We’re all doing the same thing — getting stuff done. We work together to make it happen, and we jump back and forth between all the normal development activities as the situation dictates.

In the previous two decades, as NUMMI’s success had become better known, executives in other industries had started adapting the Toyota Production System philosophy to other industries. In 2001, a group of computer programmers had gathered at a ski lodge in Utah to write a set of principles, called the “Manifesto for Agile Software Development,” that adapted Toyota’s methods and lean manufacturing to how software was created.

In recent years, Eric Ries famously adapted Lean to solve the wicked problem of software startups: what if we build something nobody wants?[ 41] He advocates use of a minimum viable product (“ MVP”) as the hub of a Build-Measure-Learn loop that allows for the least expensive experiment. By selling an early version of a product or feature, we can get feedback from customers, not just about how it’s designed, but about what the market actually wants. Lean helps us find the goal. Figure 1-7. The Lean Model. Agile is a similar mindset that arose in response to frustration with the waterfall model in software development. Agilistas argue that while Big Design Up Front may be required in the contexts of manufacturing and construction where it’s costly if not impossible to make changes during or after execution, it makes no sense for software. Since requirements often change and code can be edited, the Agile Manifesto endorses flexibility. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

We will actively manage this technical debt by ensuring that we invest at least 20% of all Development and Operations cycles on refactoring, investing in automation work and architecture and non-functional requirements (NFRs, sometimes referred to as the “ilities”), such as maintainability, manageability, scalability, reliability, testability, deployability, and security. Figure 11: Invest 20% of cycles on those that create positive, user-invisible value (Source: “Machine Learning and Technical Debt with D. Sculley,” Software Engineering Daily podcast, November 17, 2015,

Myth—DevOps Means Eliminating IT Operations, or “NoOps”: Many misinterpret DevOps as the complete elimination of the IT Operations function. However, this is rarely the case. While the nature of IT Operations work may change, it remains as important as ever. IT Operations collaborates far earlier in the software life cycle with Development, who continues to work with IT Operations long after the code has been deployed into production. Instead of IT Operations doing manual work that comes from work tickets, it enables developer productivity through APIs and self-serviced platforms that create environments, test and deploy code, monitor and display production telemetry, and so forth. By doing this, IT Operations become more like Development (as do QA and Infosec), engaged in product development, where the product is the platform that developers use to safely, quickly, and securely test, deploy, and run their IT services in production.

As an Agile software development team, we’d been following the hallowed eXtreme Programming tenets, including YAGNI. That is, You Aren’t Gonna Need It: a caution to not write unnecessary code —

It is much more important to develop people with the expertise to make wise decisions than it is to develop decision-making processes that purportedly think for people. We are also convinced that it is quite possible to develop many people who are able to make wise intuitive decisions.

There are few endeavors in which it is more important to keep options open than in software development. In Chapter 3, “Decide as Late as Possible

A Standish Group study found that 45 percent of features in a typical system are never used and 19 percent are rarely used.

Set-based development means that you communicate constraints, not solutions.

resist the temptation to jump to a solution;

keep the constraints of the problem visible

it is easier to change a decision that hasn’t been made.

Software rarely comes with a warranty.

Software rarely comes with a warranty. Let’s

premature design commitment is a design failure mode

Frameworks should be extracted from a collection of successful implementations, not built on speculation.

If the vision of perceived integrity isn’t refreshed regularly, the engineers have a tendency to get lost in the technical details and forget the customer values.

However, if damaging behavior can be limited through the relationship rather than the contract, all manner of benefits in terms of speed, flexibility, cost, and information exchange can result. Unfortunately, these benefits are counterintuitive

In a three-year period, we had 78 projects, and 77 of them were delivered on time, on budget, and in scope. Then I surveyed the customers and found out that none of them was happy!

Thus, fixed-price contracts tend to select the vendor most likely to get in trouble.

The simple mathematical fact working here is that variation is always amplified as it moves down a chain of connected events. A little variation in step one introduces a huge variation five steps later.

When you try to measure performance, particularly the performance of knowledge workers, you’re positively courting dysfunction.

Resistance indicates a perceived threat to a largely unconscious belief system, one that has no doubt successfully guided the organization in the past.

because the belief system has no doubt led to success in the past, so it will fight back with many varieties of self-fulfilling prophecies.

empowerment: moving decisions to the lowest possible level in an organization while developing the capacity of those people to make decisions wisely.

A mature organization focuses on learning effectively and empowers the people who do the work to make decisions.

He notes that the policies established to solve a problem will often exacerbate the problem, creating a downward spiral: As a problem gets worse, managers apply even more aggressively the very policies that are causing the problem.

Focusing exclusively on local measurements has a tendency to inhibit collaboration beyond the area being measured, because there is no reward for it.

and so we persist in using suboptimized measurements out of superstition and habit.

Can’t we do better with Applicant Tracking System (ATS) software?

It is important to remember that although it is relatively easy to write code, it is very difficult to create a sustainable platform.

One of the most important roles for management is ensuring architectural integrity and sustainability when developing code. One

Process is only a second-order effect. The unique people, their feelings and qualities, are more influential

Always trust that engineers are doing the best they know how or can in the situation. People want to do a good job;

Despite using the latest agile software development methods, the team had created the biggest waste of all: building a product no one wanted.