Agile Scrum Quotes

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.

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.

Leonardo da Vinci said, “Simplicity is the ultimate sophistication.

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

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

Alignment is a force multiplier.

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

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

Team performance is directly proportional to team stability. Focus on building and maintaining a stable team. Stability reduces friction and increases credibility and confidence.

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.

One of the Scrum rules is that work cannot be pushed onto a team; the Product Owner offers items for the iteration, and the team pulls as many as they decide they can do at a sustainable pace with good quality.

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.

Agile Manifesto.” It declared the following values: people over processes; products that actually work over documenting what that product is supposed to do; collaborating with customers over negotiating with them; and responding to change over following a plan. Scrum is the framework I built to put those values into practice. There is no methodology.

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

Another way of looking at it might be to say that scrum doesn’t actually do anything; people do things.

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

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

A ScrumMaster’s role on the team is compared to a sheepdog. They guide the team toward the goal by enforcing boundaries, chasing off predators, and giving the occasional bark.

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

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

every Scrum team needs a ScrumMaster.

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

But for those that have not already attained mastery, structure and doctrine are needed because formlessness is useless to the beginner.

Un mal comienzo provoca un mal final” Eurípides

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

If you focus on the strength of the team, you will begin to find work as a positive challenge.

Frame your problem statements into actionable tasks and goals that lead to a solution. Problem statements incite procrastination and resistance whereas solution statements inspire hope and motivation.

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.

Summary of Scrum vs Kanban Similarities: - Both are Lean and Agile - Both use pull scheduling - Both limit WIP - Both use transperency to drive process improvement - Both focus on delivering releasable software and often - Both are based on self-organizing teams - Both require breaking the work into pieces. - In both, the release plan is continuously optimized based on empirical data (velocity/lead time)

Doing scrum” is as meaningless (and impossible) as creating an instance of an abstract class. Scrum is a framework for surfacing organizational dysfunction. It is not a process and it is not prescriptive.

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.

Large and small companies employed “agile” and “scrum” procedures that gave clueless managers a way to discipline and control engineers whose work they could neither reproduce independently nor competently evaluate.

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.

So, why do we do development work in these short cycles? To learn. Experience is the best teacher, and the scrum cycle is designed to provide you with multiple opportunities to receive feedback—from customers, from the team, from the market—and to learn from it.

Scrum is about whole people, not about skills. Scrum is not I, but We. It is about sharing, learning, continuous improvement, vibrant interaction, passionate collaboration, and personal growth. Scrum is about tribes, it is about building community. Each tribal member needs a sense of belonging, a personal quest.

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

One of the kindest services a scrum master can do for his or her team and for the organization as a whole is to create transparency—to radiate information. Transparency allows us to see flaws, and when we see the flaws we can make the choice to do something about them. We can stop being victims of process and start being warriors of change.

While it is not unheard of, most sane people would be embarrassed to take an introductory martial arts class and then develop their own “martial art” from it and teach it to unsuspecting students, exposing them to the danger of miscalculating their effectiveness at defending themselves in a critical situation. Yet agile practitioners do this every day ― some do not even feel any sense of shame for calling themselves “agile coaches” after a year of practical experience.

We’ve lost our way” is how another manifesto author, Andrew Hunt, put it in a 2015 essay titled “The Failure of Agile.” Hunt tells me the word agile has become “meaningless at best,” having been hijacked by “scads of vocal agile zealots” who had no idea what they were talking about. Agile has split into various camps and methodologies, with names like Large-Scale Scrum (LeSS) and Disciplined Agile Delivery (DAD). The worst flavor, Hunt tells me, is Scaled Agile Framework, or SAFe, which he and some other original manifesto authors jokingly call Shitty Agile for Enterprise. “It’s a disaster,” Hunt tells me. “I have a few consultant friends who are making big bucks cleaning up failed SAFe implementations.” SAFe is the hellspawn brainchild of a company called Scaled Agile Inc., a bunch of mad scientists whose approach consists of a nightmare world of rules and charts and configurations. SAFe itself comes in multiple configurations, which you can find on the Scaled Agile website. Each one is an abomination of corporate complexity and Rube Goldberg-esque interdependencies.

Plan-driven development works well if you are applying it to problems that are well defined, predictable, and unlikely to undergo any significant change. The problem is that most product development efforts are anything but predictable, especially at the beginning. So, while a plan-driven process gives the impression of an orderly, accountable, and measurable approach, that impression can lead to a false sense of security. After all, developing a product rarely goes as planned. For many, a plan-driven, sequential process just makes sense, understand it, design it, code it, test it, and deploy it, all according to a well-defined, prescribed plan. There is a belief that it should work. If applying a plan-driven approach doesn’t work, the prevailing attitude is that we must have done something wrong. Even if a plan-driven process repeatedly produces disappointing results, many organizations continue to apply the same approach, sure that if they just do it better, their results will improve. The problem, however, is not with the execution. It’s that plan-driven approaches are based on a set of beliefs that do not match the uncertainty inherent in most product development efforts.

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.

Saddam Tajammal is a seasoned scrum team leader and IT professional who is Agile Scrum Certifed.

If you think of a Scrum team as a military unit in battle (and you can), then you should think of the writer for that team as an embedded journalist.

Scrum Master The scrum master acts as a coach, guiding the team to ever-higher levels of cohesiveness, self-organization, and performance. While a team’s deliverable is the product, a scrum master’s deliverable is a high-performing, self-organizing team. The scrum master is the team’s good shepherd, its champion, guardian, facilitator, and scrum expert.  The scrum master helps the team learn and apply scrum and related agile practices to the team’s best advantage. The scrum master is constantly available to the team to help them remove any impediments or road-blocks that are keeping them from doing their work. The scrum master is not—we repeat, not—the team’s boss. This is a peer position on the team, set apart by knowledge and responsibilities not rank.

In Scrum, we make everything visible. We air our dirty laundry. We are honest about the state of our code because code is never perfect. We become more fully human, more worthy of the divine, and closer to that greatness in the details.

Don’t have written coding standards? This is a great reason to create them.

Jeff Bezos, founder of Amazon.com, uses a “two-pizza” rule for any team within the company. That is, the team should be able to be fed with no more than two pizzas.

less. All the work to create value happens within a sprint.

Therefore, when talking to top managers, addressing the ability to deliver reliably so they can keep their promises is paramount.

there is a lot of tension between top management and the middle layer in any organization.

humans are as much controlled by their emotions (system 1 thinking) as their logic (system 2 thinking) and the threat to their status and position will make fierce resistance often inevitable.

There are unfortunately too many coaches who once they have secured a high-paying year-long contract will not use that time to help the organization along, but suddenly develop a lot of understanding for the PMO, partially to have a more comfortable life (sometimes under the disguise of not being a Scrum Nazi)

the psychological structures and incentive systems that we are trying to help the client change affect us as well.

Brainstorming is to aim for alternatives.

Brainstorming is not about HOW; but How-To-Wow.

Tougher the project; Agiler the approach.

Agile; a little fragile; handle with care.

The Agile project manager plays a crucial role in ensuring the successful delivery of projects using Agile methodologies. They act as facilitators, coaches, and leaders, guiding the team through the iterative development process. Here are some key responsibilities of an Agile project manager: Orchestrating the project's lifecycle: This involves planning and breakdown of work into sprints, facilitating ceremonies like daily stand-ups, sprint planning, and retrospectives, and ensuring the project progresses smoothly towards its goals. Promoting collaboration and communication: Agile thrives on open communication and collaboration. The project manager fosters an environment where team members feel comfortable sharing ideas, concerns, and updates. They actively remove roadblocks and ensure everyone is aligned with the project vision and goals. Empowering the team: Agile teams are self-organizing and empowered to make decisions. The project manager provides guidance and support but avoids micromanaging. They trust the team's expertise and encourage them to take ownership of their work. Stakeholder management: The project manager acts as a bridge between the development team and stakeholders, including clients, sponsors, and other interested parties. They keep stakeholders informed of project progress, manage expectations, and address their concerns. Continuous improvement: Agile is an iterative process that emphasizes continuous improvement. The project manager actively seeks feedback from team members and stakeholders, analyzes project data, and identifies areas for improvement. They implement changes to the process and tools to enhance efficiency and effectiveness. Overall, the Agile project manager plays a vital role in driving successful project delivery through Agile methodologies. They wear multiple hats, acting as facilitators, coaches, leaders, and problem-solvers, ensuring the team has the resources, support, and environment they need to thrive.

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.

A daily stand-up can get frustrating — it can seem like nothing’s moving. Teams usually do better with a Status Event two or three times per week instead of a daily scrum.

David Varonin, a Certified Scrum Product Owner, thrives on fostering cultures of creativity and innovation. With a knack for problem-solving, he guides development teams in Agile practices, ensuring projects stay on track.

What we are describing is a mindset change from “doing my job” to “doing the job.” It is also a change in focus from “what we are doing” (work) to what is getting done (results).

stories. It is unimportant, disregard

It has been said that we have been given two ears and only one mouth, so we should listen twice as much as we talk. Listening is an art form, and asking questions is a tool to active listening. Yet, asking

Leadership – inborn or learnt? The case for situational leadership

Of course, there is one obvious thing we could do to try to improve velocity: work longer hours. Working a lot of consecutive overtime might initially cause velocity to increase (see “Overtime” in Figure 7.14). Figure 7.14. The effect of overtime on velocity (based on a figure from Cook 2008) That increase will almost certainly be followed by an aggressive decline in velocity along with a simultaneous decline in quality. Even after the overtime period ends, the team will need some amount of time to recover before returning to its reasonable baseline velocity. I have seen examples of where the trough (decreased velocity area) during the recovery period is larger than the crest (increased velocity area) during the overtime period. The end result is that lots of overtime may provide some short-term benefits, but these are frequently far outweighed by the long-term consequences.

We need to uncover better ways to improve and retrospectives can provide the solution.

With agile retrospectives the team drives their own actions!

Rituals bring people together, allowing them to focus on what is important and to acknowledge significant events or accomplishments.

Without a good facilitator, a retrospective most likely will be a disaster.

Before starting a retrospective, you need to think about which exercises would be most suitable.

Getting feasible actions out of a retrospective and getting them done helps teams to learn and improve.

The goal of retrospectives is help teams to continuously improve their way of working.

Agile retrospectives give the power to the team, where it belongs!

It seems to me that Scrum and other agile techniques are being used as substitutes for careful modeling, where a product backlog is thrust at developers as if it serves as a set of designs. Most agile practitioners will leave their daily stand-up without giving a second thought to how their backlog tasks will affect the underlying model of the business. Although I assume this is needless to say, I must assert that Scrum, for example, was never meant to stand in place of design. No matter how many project and product managers would like to keep you marching on a relentless path of continuous delivery, Scrum was not meant only as a means to keep Gantt chart enthusiasts happy. Yet, it has become that in so many cases.

It seems to me that Scrum and other agile techniques are being used as substitutes for careful modeling, where a product backlog is thrust at developers as if it serves as a set of designs. Most agile practitioners will leave their daily stand-up without giving a second thought to how their backlog tasks will affect the underlying model of the business. Although I assume this is needless to say, I must assert that Scrum, for example, was never meant to stand in place of design. No matter how many project and product managers would like to keep you marching on a relentless path of continuous delivery, Scrum was not meant only as a means to keep Gantt chart enthusiasts happy. Yet, it has become that in so many cases.

Leaders facilitating team responsibilities must link accountability to motivation in order to be highly effective.

There is only one move that really counts: the next one” (Gilb 1988, 97).

What tasks I’ve completed since the last daily scrum. What tasks I expect to complete by the next daily scrum. What obstacles are slowing me down.

accurately setting and managing expectations.

Слово scrum («схватка») взято из регби и обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели.

Шартрский собор строился пятьдесят семь лет. Готов поспорить, что перед началом строительства каменщики, глядя в глаза епископу, утверждали: «Двадцать лет — самое долгое. Может, и за пятнадцать справимся».

Восемьдесят процентов успеха и ценности любой программы заложены в двадцати процентах ее функциональных возможностей.

But if you want to produce multiple informal butt loads then this process can damage agile performance.

Scrum дает нужную гибкость, чтобы быстро реагировать на меняющиеся условия рынка и давление со стороны конкурентов или внедрять новые идеи наших команд.

que diecisiete líderes de desarrollo de software escribimos lo que hoy se conoce como el Agile Manifesto. En ese documento proclamamos estos valores: personas antes que procesos, productos que funcionen antes que documentar lo que se supone que deben hacer, colaborar

Estoy seguro de que has oído las mismas historias de horror que yo: el remozamiento de la cocina que supuestamente llevaría dos semanas y terminó tardando seis, obligando así a la familia a consumir comida rápida durante más de un mes; la reparación eléctrica que se prolongó tres veces más de lo previsto; la minucia que acabó resultando interminable. Pues bien, hace un par de años mi amigo Eelco Rustenburg, también adepto a Agile, me contó en una cena que había decidido remodelar su casa de cabo a rabo. Acometería todas las habitaciones, haciendo una nueva instalación eléctrica, incorporando nuevos aparatos y dando a todo una nueva capa de pintura. Planeaba tardar únicamente seis semanas. Todos reímos y empezamos a obsequiar a Eelco nuestras trágicas historias de remodelación.

Telling your truth with compassion instead of delivering “constructive” criticism

It has been said that because we have been given two ears and only one mouth, we should listen twice as much as we talk. Listening is an art form, and asking questions is a tool to active listening.

The practices and artifacts of Scrum –backlogs, sprints, stand ups, increments, burn charts –reflect an understanding of the need to strike a balance between planning and improvisation, and the value of engaging the entire team in both. As we’ll see later, Agile and Lean ideas can be useful beyond their original ecosystems, but translation must be done mindfully. The history of planning from Taylor to Agile reflects a shift in the zeitgeist –the spirit of the age –from manufacturing to software that affects all aspects of work and life. In business strategy, attention has shifted from formal strategic planning to more collaborative, agile methods. In part, this is due to the clear weakness of static plans as noted by Henry Mintzberg. Plans by their very nature are designed to promote inflexibility. They are meant to establish clear direction, to impose stability on an organization… planning is built around the categories that already exist in the organization.[ 43] But the resistance to plans is also fueled by fashion. In many organizations, the aversion to anything old is palpable. Project managers have burned their Gantt charts. Everything happens emergently in Trello and Slack. And this is not all good. As the pendulum swings out of control, chaos inevitably strikes. In organizations of all shapes and sizes, the failure to fit process to context hurts people and bottom lines. It’s time to realize we can’t not plan, and there is no one best way. Defining and embracing a process is planning, and it’s vital to find your fit. That’s why I believe in planning by design. As a professional practice, design exists across contexts. People design all sorts of objects, systems, services, and experiences. While each type of design has unique tools and methods, the creative process is inspired by commonalities. Designers make ideas tangible so we can see what we think. And as Steve Jobs noted, “It’s not just what it looks like and feels like.

Managers must be true servant leaders (and the scrum framework calls this out in the position of scrum master as servant leader) for their people. The front line workers are not there to serve their managers. It is up to management to create an environment that allows workers to do their work.            

It is often a devastating question to ask oneself, but it is sometimes important to ask it—‘In saying what I have in mind will I really improve on the silence?’” (

the enablers of situational leadership are empathy, active listening and a propensity to understand complex human and team interactions. The challenge in leadership is all about applying the proper situational behavior. We have to analyze the situation and shift from our incumbent approach towards a situation, to the style which the situation warrants and which leads to the optimal outcome. By integrating and implementing ideas of situational leadership in our work place we can become better leaders.

According to the findings, the most effective team building practices in creation of virtual networks of practice are: ‘(1) recruitment and selection; (2) training and development; (3) rewards and recognition; (4) supervisory support; (5) rules regarding knowledge disclosure; (6) time pressure; and (7) collaborative programs and projects (Jolinka and Dankbaar

The clearer and more simply the vision is stated, the easier it is for team members to buy into it.

Exhibiting vulnerabilities requires being confident in yourself and being able to laugh at your own mistakes. People who have to appear perfect often feel that way because they lack self-confidence. Yet, being willing to open up and be vulnerable can do more to make a team come together than standing aloof.

has been said that we have been given two ears and only one mouth, so we should listen twice as much as we talk.

High power high interest stakeholders – manage closely; High power low interest stakeholders – keep satisfied; Low power high interest stakeholders – keep informed; Low power low interest stakeholders – monitor with minimal effort.

Los planes son solo buenas intenciones a no ser que se conviertan en trabajo duro” Peter Drucker