Agile Project Management 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

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

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

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

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.

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.

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.

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

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

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

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

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

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

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.

The iterative piece of agile can be defined by four key terms: iterative, feature-based, timeboxed, and incremental.

Project leaders must be champions of technical excellence; they must support and advocate technical excellence while maintaining a watchful eye on other project objectives.

Johannes Ritter and Frank Röttgers’s book The Definitive Guide to Getting Your Budget Approved

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

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new system.  For the initiator has the enmity of all who would profit by the preservation of the old institutions and merely lukewarm defenders in those who would gain by the new ones.” Nicholi Machiavelli in The Prince 1513 A.D.

Figure 4: Illustration of the T-shaped

Only by repeatedly accepting failure and subsequently purging its causes from the system you can steadily grow a software project and allow it to perform successfully.

AC + OC > V, that is, actual cost + opportunity cost > value

This mind-set of motivating people to do evolutionary process improvement is the basis of both Agile and Lean.

Agile project management approaches are characterized by change expectancy, iterative development, phased deployments, collaboration, people focus, customer focus, timeboxing, detailed near-term schedules, frequent feedback loops, and constant risk management. DevOps and DevSecOps practices are an extension of agile approaches, include a new set of tools, technologies, and approaches, rely on a culture of collaboration, and are characterized by integrating the infrastructure operations and/or security quality into the entire systems development life cycle.

The only people relatively happy with the status quo were the project managers and their group manager, who were working in accordance with their professional credential, the Project Management Professional (or PMP), granted to them for passing an exam from the PMI. They didn’t take responsibility for project failure, nor were they ever held accountable. Their role was to crank the handle on the bureaucracy and point the finger of blame at the department managers when expectations were not met. If there was going to be resistance, we would expect it to come from the project managers. Everyone else was eager for change.

Agile project management revolves around empirical control.

Agile teams are required to make sure that all of the customer’s expectations are met.

Declaration of Interdependence for Modern Management (2005)

The Standish Group is an Information Technology organization that assesses risk, cost, return, and value of software projects. Since 1994, they have published the Chaos report that studies software failures and successes. The latest Chaos report recommends agile processes as one of the ten project success factors. (The Standish Group International Inc. 2012)

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

Customers Have the Highest Priority

In August 2012, Jurgen Appelo published a list of (Top 100 Agile Books (Edition 2012)) by using a qualitative and quantitative rating system. His list reflects the most and best rated during the time span that the books earned the ratings.

(Lindvall , et al. 2002, 197) Waterfall and spiral methodologies are plan-driven methods (also referred to as traditional methodologies.)