Agile Project Quotes

We practice mastering ourselves in the moment so that we can better open ourselves to being a servant leader and to harness our emotions and choose what to do with our reactions.

If you don’t collect any metrics, you’re flying blind. If you collect and focus on too many, they may be obstructing your field of view.

Over-seriousness is a warning sign for mediocrity and bureaucratic thinking. People who are seriously committed to mastery and high performance are secure enough to lighten up. —Michael J. Gelb

Adding manpower to a late project makes it later.

Building a project should be a single trivial operation.

The Agile Project Management principles and framework encourage learning and adapting as an integral part of delivering value to customers.

In fact, in an agile project, technical excellence is measured by both capacity to deliver customer value today and create an adaptable product for tomorrow.

In an agile project the team takes care of the tasks and the project leader takes care of the team.

when agile projects fail, it’s often because of cultural and philosophical differences between waterfall and agile methodologies.

Agile Project Management is an execution-biased model, not a planning-and-control-biased model.

Good agile project managers and teams don’t focus on mistakes — or on who did them, or on how many times they were done.

Agile Project Management -like its lean development counterparts- streamlines the development process, concentrating on value-adding activities and eliminating overhead and compliance activities.

Agile project leaders help their team balance at the edge of chaos—some structure, but not too much; adequate documentation, but not too much; some up-front architecture work, but not too much. Finding these balance points is the "art" of agile leadership.

If you can’t out-experiment and beat your competitors in time to market and agility, you are sunk. Features are always a gamble. If you’re lucky, ten percent will get the desired benefits. So the faster you can get those features to market and test them, the better off you’ll be. Incidentally, you also pay back the business faster for the use of capital, which means the business starts making money faster, too.

For an agile project, the ensemble includes core team members, customers, suppliers, executives, and other participants who interact with each other in various ways. It is these interactions, and the tacit and explicit information exchanges that occur within them, that project management practices need to facilitate.

Good business leaders create a vision, articulate the vision, passionately own the vision, and relentlessly drive it to completion.

Strong executive commitment is a success factor for implementing Scrum, and management can best demonstrate their support of the transformation through their actions.

If you have a problem and to solve it you need someone else to change, you don’t understand your problem yet

To be full of love and enthusiasm for your work is a prerequisite for collaboration, a professional obligation;

Potentially shippable is defined by a state of confidence or readiness, and shipping is a business decision.

Agile processes harness change for the customer's competitive advantage.

The problem is not that there are problems. The problem is expecting otherwise and thinking that having problems is a problem. —Theodore Rubin

Agility is the ability to balance flexibility and stability

In high-performance teams, "the leaders managed the principles, and the principles managed the team.

Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.

Agility is more attitude than process, more environment than methodology.

If we want to build great products, we need great people. If we want to attract and keep great people, we need great principles

A traditional project manager focuses on following the plan with minimal changes, whereas an agile leader focuses on adapting successfully to inevitable changes.

Agility is principally about mindset, not practices.

A team can employ agile practices, but it won't achieve the potential benefit of agile development without embracing agile values and principles.

The agile value "Delivering Value over Meeting Constraints" provides a focus for rethinking how we measure performance on projects.

The formula for success is simple: deliver today, adapt tomorrow.

Dialogue, discussion, and participatory decision making are all part of building self-discipline.

At the core of healthy team relationships is trust and respect.

If everyone is speaking the same language, then it becomes easier to create a team where everyone is of the same mind.

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

At any organizational level people are leaders not because of what they do, but because of who they are.

When project leaders focus on delivery, they add value to projects. When they focus on planning and control, they tend to add overhead.

If you want to innovate, you have to iterate!

Get the right people involved, and self-discipline comes more easily. Get the wrong people, and imposed discipline creeps in, destroying trust and respect.

The quality of results from any collaboration effort are driven by trust and respect

Thriving in today’s marketplace frequently depends on making a transformation to become more agile.

Stubbornness pays! We tend to think that it doesn’t, we might be hesitant to be stubborn – however only the stubborn succeed.

Iterative development, when accompanied with reasonable end-of-iteration reviews—product, technical, process, team—is also self-correcting.

If you want to be fast and agile, keep things simple. Speed isn't the result of simplicity, but simplicity enables speed.

Large portions of the productivity gains from agile methods come not from doing things better, but from not doing them at all.

The feature delivery approach helps define a workable interface between customers and product developers.

In my early years of iterative development, I thought timeboxes were actually about time. What I came to realize is that timeboxes are actually about forcing tough decisions.

Business agility is not just about raw speed. It’s about how good you are at detecting and responding to changes in the market and being able to take larger and more calculated risks.

Project leaders need to focus on value in several ways: value determination (with product owners), value prioritization (backlog management), and value creation (iterative development).

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.

By adopting an agile mindset and providing improved engagement, collaboration, transparency, and adaptability via Scrum's values, roles, events, and artifacts, the results were excellent.

APM focuses on team management, from building self-organizing teams to developing a servant leadership style. It is both more difficult, and ultimately more rewarding than managing tasks.

Self-discipline is also built on competence, persistence, and the willingness to assume accountability for results. Competence is more than skill and ability; it's attitude and experience.

There are three particularly important issues involved in delivering customer value: focusing on innovation rather than efficiency and optimization, concentrating on execution, and lean thinking.

stress can be a real monster you have to vanquish from your team. And one of the main ways to do this is by ensuring that you plan your project in a very sustainable way, from the very beginning.

Traditional waterfall methods deliver value at the end of the project, often months or years after the project begins. Agile projects can deliver value quickly and incrementally during the life of the project. Capturing value early and often can significantly improve a project's return on investment, and utilizing iterative, feature-based delivery is the cornerstone practice in making that happen.

Situational leadership articulates that effective leaders are the ones able to change their behavior according to the situation at hand. It identifies leadership styles relevant to specific situations.

When uncertainty is low, adaptive approaches run the risk of higher costs. When uncertainty is high, optimizing approaches run the risk of settling too early on a particular solution and stifling innovation.

The MVP has just those features considered sufficient for it to be of value to customers and allow for it to be shipped or sold to early adopters. Customer feedback will inform future development of the product.

A maxim in the theater tells us this: On time is already late (Devin 2009). That is, if we arrive at work on time with our bodies only, having not groomed our minds to collaborate, we are simply late. Unprepared.

APM's core purpose of creating innovative new products and services means dealing with constant technological and competitive change, generating novel ideas, and continually reducing product development schedules.

What is the difference between project management and project leadership? Although there is an elusive line between them, the core difference is that management deals with complexity, whereas leadership deals with change.

Newtonian versus quantum, predictability versus flexibility, optimization versus adaptation, efficiency versus innovation—all these dichotomies reflect a fundamentally different way of making sense about the world and how to manage effectively within it.

Agile coach: The individual is an agile expert who provides guidance for new agile implementations as well as existing agile teams. The agile coach is experienced in employing agile techniques in different environments and has successfully run diverse agile projects. The individual builds and maintains relationships with everyone involved, coaches individuals, trains groups, and facilitates interactive workshops. The agile coach is typically from outside the organization, and the role may be temporary or permanent.

The function of leadership – the number-one responsibility of a leader – is to catalyze a clear and shared vision for the organization and to secure commitment to and vigorous pursuit of that vision.  This is a universal requirement of leadership.”[11] Jim Collins

Your goal is to build the kind of environment and work atmosphere that will make people actually want to work on their own, without feeling the threat of punishment if they have a bad day and without feeling constantly pressured by the stressed expressions of their bosses.

The term ‘female’ is derogatory not because it emphasises woman’s animality, but because it imprisons her in her sex; and if this sex seems to man to be contemptible and inimical even in harmless dumb animals, it is evidently because of the uneasy hostility stirred up in him by woman. Nevertheless he wishes to find in biology a justification for this sentiment. The word female brings up in his mind a saraband of imagery – a vast, round ovum engulfs and castrates the agile spermatozoan; the monstrous and swollen termite queen rules over the enslaved males; the female praying mantis and the spider, satiated with love, crush and devour their partners; the bitch in heat runs through the alleys, trailing behind her a wake of depraved odours; the she-monkey presents posterior immodestly and then steals away with hypocritical coquetry; and the most superb wild beasts – the tigress, the lioness, the panther – bed down slavishly under the imperial embrace of the male. Females sluggish, eager, artful, stupid, callous, lustful, ferocious, abased – man projects them all at once upon woman.

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.

Effective project leaders focus on people, product, and process—in that order. Without the right people, nothing gets built. Without a laser focus on product value, extraneous activities creep in. Without a minimum process framework, there can be inefficiency and possibly a little chaos.

A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary. A good manager manages the coefficients on these attributes rather than demanding that all those coefficients are 100%. It is this kind of management that Agile strives to enable.

Outcomes indicators include product vision, business objectives, and capabilities (high-level product functionality), not detail requirements. These outcome characteristics define a releasable product and quality objectives define a reliable and adaptable (works today, easy to enhance) product. These are the critical value traits, then teams need to strive to meet constraints—scope, schedule, and cost—but as secondary in importance to the value components. In many, if not most, agile projects schedule becomes the most critical constraint and is timeboxed (fixed) and scope varies.

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.

If your goal is to deliver a product that meets a known and unchanging specification, then try a repeatable process. However, if your goal is to deliver a valuable product to a customer within some targeted boundaries, when change and deadlines are significant factors, then reliable Agile processes work better.

I noticed a bumper sticker that said, simply, "gravity works." yes it does. Rock climbers know this and plan for it. So do agile coaches. I use this metaphor to illustrate that, in our physical environment, somethings are simply taken as a given. Constant. Always present. Undeniable. So, too, in our work environment.

Only experience can refine a leader's art. High-uncertainty projects are full of anxiety, change, and ambiguity that the team must deal with. It takes a different style of project management, a different pattern of team operation, and a different type of project leader. I've labeled this type of management leadership-collaboration.

Innovation delivers products that we can barely imagine. Efficiency and optimization are appropriate drivers for a production project, whereas innovation and creativity should drive an exploration-type project. A production mindset can restrict our vision to what appears doable. An exploration mindset helps us explore what seems impossible.

The ability to respond to change is good. The ability to create change for competitors is even better. When you create change you are on the competitive offensive. When you respond to competitors' changes you are on the defensive. When you can respond to change at any point in the development lifecycle, even late, then you have a distinct advantage.

In a self-organized team, individuals take accountability for managing their own workload, shift work among themselves based on need and best fit, and take responsibility for team effectiveness. Team members have considerable leeway in how they deliver results, they are self-disciplined in their accountability for those results, and they work within a flexible framework.

Executives, project leaders, and development teams must embrace a different view of the new product development world, one that not only recognizes change in the business world, but also understands the power of driving down iteration costs to enable experimentation and emergent processes. Understanding these differences and how they affect product development is key to understanding APM.

The capability of self-organizing teams lies in collaboration. When two engineers scratch out a design on a whiteboard, they are collaborating. When team members meet to brainstorm a design, they are collaborating. When team leaders meet to decide whether a product is ready to ship, they are collaborating. The result of any collaboration can be categorized as a tangible deliverable, a decision, or shared knowledge.

It is not loyalty or internal motivation that drives us programmers forward. We must write our code when the road to our personal success is absolutely clear for us and writing high quality code obviously helps us move forward on this road. To make this happen, the management has to define the rules of the game, also known as "process", and make sure they are strictly enforced, which is much more difficult than "being agile".

Driving exploration is critical, but knowing when to stop is also. Product development is exploring with a purpose, delivering value within a set of constraints. Frequent, timeboxed iterations compel the development and product teams and executives to make difficult tradeoff decisions early and often during the project. Feature delivery contributes to realistic evaluations because product managers can look at tangible, verifiable results.

The most important element of leadership effectiveness is authentically living the Vision of the company.  The values and ambitions of a company are not instilled entirely by what leaders say; they’re instilled primarily by what leaders do.  In a healthy company, there are no inconsistencies between what is said and what is believed deep down – the values come from within the leaders and imprint themselves on the organization through day-to-day activity.

a good set of questions to determine whether a project leader—or even an individual contributor—has an agile mindset might be, "In what specific ways and with what practices do you focus on value first and constraints last?" "In what specific ways and with what practices do you manage teams rather than tasks?" "In what specific ways and with what practices do you adapt to change rather than conform to plans?" Try these out in your organization to get a feel for your agile maturity.

This principle fits well with the concept of business and development working daily. Business needs to be intensely involved with the process, if for nothing more than identifying the 80% of the work that we really don’t have to do. Just think of the amount of money that could be saved every year by reducing project scope to only those features and functions that are actually used! Think of how quickly we could deliver functionality! Think of how many more “projects” we could complete!

The agile value "Delivering Value over Meeting Constraints" provides a focus for rethinking how we measure performance on projects. Although constraints such as cost and time are important, they should be secondary to creating value for customers. All too often, we focus on what is easily measurable and ignore really important characteristics that are harder to quantify. Agile development attempts to change that bias and focus on the most important things, and value is at the top of that list.

An adaptive development process has a different character from an optimizing one. Optimizing reflects a basic prescriptive Plan-Design-Build lifecycle. Adapting reflects an organic, evolutionary Envision-Explore-Adapt lifecycle. An adaptive approach begins not with a single solution, but with multiple potential solutions (experiments). It explores and selects the best by applying a series of fitness tests (actual product features or simulations subjected to acceptance tests) and then adapting to feedback.

We live in an age in which the volume of available information stupefies us. On any relatively interesting subject we can find thousands of Web pages, tens—if not hundreds—of books, and article after article. How do we filter all this information? How do we process all this information? Core values and principles provide one mechanism for processing and filtering information. They steer us in the direction of what is more, or less, important. They help us make product decisions and evaluate development practices.

When people look under the hood, we want them to be impressed with the neatness, consistency, and attention to detail that they perceive. We want them to be struck by the orderliness. We want their eyebrows to rise as they scroll through the modules. We want them to perceive that professionals have been at work. If instead they see a scrambled mass of code that looks like it was written by a bevy of drunken sailors, then they are likely to conclude that the same inattention to detail pervades every other aspect of the project.

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.

Recommended Reading Mike Cohn in his book User Stories Applied provides insights and details on user stories, including how to write them and their characteristics. His book Agile Estimating and Planning provides guidance on prioritizing user stories. Luke Hohmann in his book Innovation Games: Creating Breakthrough Products Through Collaborative Play describes 12 innovation games. The Definitive Guide to Getting Your Budget Approved by Johannes Ritter and Frank Röttgers provides a systematic guide for creating a quantifying the economic value for projects.

Authoritarian managers use power, often in the form of fear, to get people to do something their way. Leaders depend for the most part on influence rather than power, and influence derives from respect rather than fear. Respect, in turn, is based on qualities such as integrity, ability, fairness, truthfulness—in short, on character. Leaders are part of the team, and although they are given organizational authority, their real authority isn't delegated top-down but earned bottom-up. From the outside, a managed team and a led team can look the same, but from the inside they feel very different.

Creating new products and services differs from making minor enhancements to existing ones. The first must focus on innovation and adaptability, whereas the second usually focuses on efficiency and optimization. Efficiency delivers products and services that we can think of. Innovation delivers products that we can barely imagine. Efficiency and optimization are appropriate drivers for a production project, whereas innovation and creativity should drive an exploration-type project. A production mindset can restrict our vision to what appears doable. An exploration mindset helps us explore what seems impossible.

Shifting customer needs are common in today's marketplace. Businesses must be adaptive and responsive to change while delivering an exceptional customer experience to be competitive. Traditional development and delivery frameworks such as waterfall are often ineffective. In contrast, Scrum is a value-driven agile approach which incorporates adjustments based on regular and repeated customer and stakeholder feedback. And Scrum’s built-in rapid response to change leads to substantial benefits such as fast time-to-market, higher satisfaction, and continuous improvement—which supports innovation and drives competitive advantage.

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.

Ellen Braun, an accomplished agile manager, noticed that different behaviors emerge over time as telltale signs of a team’s emotional maturity, a key component in their ability to adjust as things happen to them and to get to the tipping point when “an individual’s self interest shifts to alignment with the behaviors that support team achievement” (Braun 2010). It is better to know some of the questions than all of the answers. —James Thurber Team Dynamics Survey Ellen created a list of survey questions she first used as personal reflection while she observed teams in action. Using these questions the same way, as a pathway to reflection, an agile coach can gain insight into potential team problems or areas for emotional growth. Using them with the team will be more insightful, perhaps as material for a retrospective where the team has the time and space to chew on the ideas that come up. While the team sprints, though, mull them over on your own, and notice what they tell you about team dynamics (Braun 2010). • How much does humor come into day-to-day interaction within the team? • What are the initial behaviors that the team shows in times of difficulty and stress? • How often are contradictory views raised by team members (including junior team members)? • When contradictory views are raised by team members, how often are they fully discussed? • Based on the norms of the team, how often do team members compromise in the course of usual team interactions (when not forced by circumstances)? • To what extent can any team member provide feedback to any other team member (think about negative and positive feedback)? • To what extent does any team member actually provide feedback to any other team member? • How likely would it be that a team member would discuss issues with your performance or behavior with another team member without giving feedback to you directly (triangulating)? • To what extent do you as an individual get support from your team on your personal career goals (such as learning a new skill from a team member)? • How likely would you be to ask team members for help if it required your admission that you were struggling with a work issue? • How likely would you be to share personal information with the team that made you feel vulnerable? • To what extent is the team likely to bring into team discussions an issue that may create conflict or disagreement within the team? • How likely or willing are you to bring into a team discussion an issue that is likely to have many different conflicting points of view? • If you bring an item into a team discussion that is likely to have many different conflicting points of view, how often does the team reach a consensus that takes into consideration all points of view and feels workable to you? • Can you identify an instance in the past two work days when you felt a sense of warmth or inclusion within the context of your team? • Can you identify an instance in the past two days when you felt a sense of disdain or exclusion within the context of your team? • How much does the team make you feel accountable for your work? Mulling over these questions solo or posing them to the team will likely generate a lot of raw material to consider. When you step back from the many answers, perhaps one or two themes jump out at you, signaling the “big things” to address.