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

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

Building a project should be a single trivial operation.

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

Adding manpower to a late project makes it later.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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

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.

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

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

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

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

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

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

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

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

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

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

Agility is the ability to balance flexibility and stability

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

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

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!

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

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

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

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

The team was flowing. Work in progress was under control. Features were used by customers. It was like watching a unicorn drive a Tesla through a burndown chart.

No more “fake Agile.” No more box-checking.

Currently detecting 3% actual buy-in.

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

Let’s talk about Minimum Viable Product, or as I like to call it: the art of building just enough to find out you’re wrong.

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

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 feature delivery approach helps define a workable interface between customers and product developers.

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

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

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

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

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.

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.

Quix even built a kanban board that talked. It had an AI voice that said things like, “Your velocity is weak, and your story points are ashamed to be associated with you.” We named it KanbanChatterbox.

The room had all the trappings of corporate cosplay: walls lined with meaningless jargon posters (“Fail Fast,” “Think Lean,” “Sprint or Die!”), whiteboards no one had written on, and an “Agile Champion.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

However, interrupting technology workers is easy, because the consequences are invisible to almost everyone, even though the negative impact to productivity may be far greater than in manufacturing. For instance, an engineer assigned to multiple projects must switch between tasks, incurring all the costs of having to re-establish context, as well as cognitive rules and goals.

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.

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.

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?

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.

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.

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.

One of the biggest challenges implementing agile is the reward system. For example, individual salary scales and rewards can be decoupled from the function and substituted by group valuation rewards linked to the capacity of both the employee and/or the team. Or, it is possible to make a distinction between the fixed salary and flexible performance bonus, detached from the annual budget and not considered a personnel expense. The reward system is always the last to change, but it is crucial to include this subject in the initial conversations with the different stakeholders around agile projects.

There are bubbles of agile in a sea of Gantt charts with predetermined solutions, dates, and spending predicted at the point of knowing the least, an annual, bottom-up financial planning process that takes six months of the year to plan and re-plan and focuses on output over outcomes. There are “drop dead dates” and “deadlines” (in most cases it’s not life or death); RAG (red, amber, green) statuses and change control processes; a change lifecycle with twenty mandatory artifacts, most with their own stage-gate governance committee; a traditional waterfall Project Management Office; sixty-page Steering Committee decks; project plans with the word “sprint” ten times in the middle; a lack of psychological safety; a performance appraisal model that incentivizes mediocrity (underpromise to overdeliver) and uses a Think Big, Start Big, Learn Slow approach. The good news, with a charitable intent, is that the organization wants to improve.

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.

After considering what gets covered, you will need to turn your attention to who is involved in the performance management cycle. Traditional performance management models are typically formal and hierarchical—and often involve only the senior management or leadership team. When you're setting up performance management for the ecosystem economy, you need a less hierarchical, more project-oriented, more results-oriented model. You need to involve not just senior management, but also people from all levels within your agile model (e.g., tribes, chapters, and squads). Involving more of the team not only creates a more streamlined and efficient process, but also facilitates an unfiltered flow of information. Management gets an opportunity to hear an unfiltered report straight from the team members who will be best equipped to give it. And the team members get an opportunity to receive feedback and instruction straight from management, without anything getting lost in translation as the information passed through two or three levels of hierarchy and bureaucracy.

ABOUT MATIYAS We are an enthusiastic and energetic establishment dedicated to bringing automation and transforming business processes digitally. We understand the value of technological advancements for increasing productivity and enhancing quality, and our in-house teams of dedicated professionals offer various services to achieve this objective effectively. Matiyas digital solutions help to streamline manufacturing business functions, increase profitability, automating efforts and increase the quality of production. Our Customized manufacturing digital solutions can assist you to address all the hurdles that occur during the manufacturing process. You can have complete control over the manufacturing process by handling inventory management and supply chain management effectively. At Matiyas, we are committed to bringing digital transformation in manufacturing through advanced solutions and excellent services Matiyas is providing industry 4.0 digital solutions to: • Oil & Gas • Cement Manufacturing • Electronics Manufacturing • Industrial Machinery and Equipment • Steel Manufacturing • Plastic Manufacturing • Packaging Manufacturing • Power Plants • Pharmaceutical • Fast Moving Consumer Goods (FMCG) • Medical Devices Industry • EPC Our digital solutions empower the manufacturers to closely supervise each and every stage of the manufacturing process and gives the absolute control over it, as a result you observe an ample reduction in wastage and material exchange possibilities which not only improves production quality but quantity too. We understand the major problems manufacturing businesses come across and we tailor best manufacturing digital solutions accordingly. HOW OUR MANUFACTURING DIGITAL SOLUTIONS CAN BENEFIT YOUR ORGANIZATION? Increased ROI Reduced Operational Costs & Optimize Operations Enhanced Resource Utilization & Reduced Overheads Deeper insights about your supply chains & production Improved Agility, Higher productivity Easier Collaboration Accountability and transparency And Many More .... Matiyas Digital Solutions: Inventory Management, Procurement Management, Selling Management, Production Management, Retail POS Management, Manufacturing Management, Project Management, Customer Relationship Management, Accounting & Finance Management, Human Capital Management, Assets Management, Quality Management, Ecommerce, Website, Hospital Management Information System HMIS, Education Management and many more… Matiyas Offices: India, Oman, Kuwait, Canada, UAE, Armenia, Africa, Egypt Interested to Automate and Collaborate Effectively Through Our Custom Digital Solutions?

Shifting from a project mindset to a continuous mindset is hard. We tend to take our six-month-long waterfall project, carve it up into a series of two-week sprints, and call it “Agile.” But this isn’t Agile.

Do the right thing at the right time.

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

When determining which types of high-tech communication tools to support, don’t choose tools that degrade direct and real-time conversation or introduce unnecessary complexity:

Elicitation is an art of extraction of information.

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.

Teams make decisions in Early Development that don’t get validated until later in the process. Then they have to go backwards to fix the problem, causing project delays, cost overruns and disappointing results.

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.

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.

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.

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.

If I have to motivate you, I’m spending too much leadership time and leadership energy on the raw materials. Each employee needs to bring the raw materials: the energy, the enthusiasm, the professionalism, the drive. The leader creates an environment where people can do great work in service of something bigger than themselves. This environment includes projects that are meaningful and valuable. The leader brings the work to the right people.

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

Many of the high-return projects are high risk, which is why I suggest you forget the idea of looking at risk at all. Manage the risk by using an incremental or, even better, agile approach to the project. Start with your organization's context of what moves the organization ahead instead of risk.

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.

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

APM is about people, their interactions, and creating an environment in which individual creativity and capability erupts to create great products. It's people, not processes, that build great products.

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

You need to know what you are going to adapt to. Kaput! Simple, you are going to adapt to the wishes of your customer.   But

People tend to continue working on a lost cause simply because they reason that it is worthwhile continuing something in which they have put in any kind of investment or effort.

When every team expedites their work, the net result is that every project ends up moving at the same slow crawl.

Our goal with a product-based funding model is to value the achievement of organizational and customer outcomes, such as revenue, customer lifetime value, or customer adoption rate, ideally with the minimum of output (e.g., amount of effort or time, lines of code). Contrast this to how projects are typically measured, such as whether it was completed within the promised budget, time, and scope.

Responsibility and accountability create self-organizing teams that work. The Declaration of Interdependence contains the principle, "We boost performance through group accountability for results and shared responsibility for team effectiveness." When an individual commits to delivering a particular feature during an iteration he accepts accountability for that delivery. When the team commits to a set of features by the end of the milestone, all members of the team accept that accountability. The product manager agrees to be accountable for providing requirements information to the team. The project leader agrees to be accountable for resolving impediments to team progress. When a team member commits to provide some information to another the next day, he has agreed to be accountable for that action. When team members commit to each other, when the team commits to the customer, when the project leader commits to provide the team with a particular resource, they are all agreeing to be held accountable.

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

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

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 QMO, worked closely with the PMO throughout the Kanban transformation, but we never tried to change them. Our stance was to help them understand what was different about how projects were governed with the new Agile practices so they could decide what to change.

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.

Greenfield DevOps projects are often pilots to demonstrate feasibility of public or private clouds, piloting deployment automation, and similar tools. An example of a greenfield DevOps project is the Hosted LabVIEW product in 2009 at National Instruments, a thirty-year-old organization with five thousand employees and $1 billion in annual revenue. To bring this product to market quickly, a new team was created and allowed to operate outside of the existing IT processes and explore the use of public clouds. The initial team included an applications architect, a systems architect, two developers, a system automation developer, an operations lead, and two offshore operations staff. By using DevOps practices, they were able to deliver Hosted LabVIEW to market in half the time of their normal product introductions.

You’ll notice in figure 8 that although the features are of varying lengths, the cumulative total time allotment is equal in each sprint (140 hours). Keeping

Creativity and innovation are the emergent results of well functioning agile teams.

Self-organizing teams form the core of APM. They blend freedom and responsibility, flexibility and structure. In the face of inconsistency and ambiguity, the teams strive to consistently deliver on the product vision within the project constraints. Accomplishing this requires teams with a self-organizing structure and self-disciplined individual team members. Building this kind of team is the core of an agile project leader's job.

The agile movement supports individuals and teams through dedication to the concepts of self-organization, self-discipline, egalitarianism, respect for individuals, and competency. "Agile" is a socio-technical movement driven by both the desire to create a particular work environment and the belief that an adaptive environment is critical to the goal of delivering innovative products to customers.

Adaptation can be considered a mindful response to change.

our most fragile artifacts support either our most important revenue-generating systems or our most critical projects. In

Another benefit of having Development and Operations using a shared tool is a unified backlog, where everyone prioritizes improvement projects from a global perspective, selecting

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.

Interestingly, Agile’s scrum-team approach has its own way of aggregating some execution risk. For example, in a traditional “single task owner” approach, the risk of execution is not aggregated at all, leaving that task owner to add a lot of task-level buffer to self-insure and deliver on his commitment. In contrast, a 5-person scrum team aggregates the risk that any single individual will make slow progress, as the other four team members can often make up the deficit. But why aggregate only up to the scrum-team level? Taking a lesson from the insurance industry, the more that risk can be aggregated, the easier it is to manage. Applied to projects, this will nearly always mean that it’s better to aggregate risk at the project level. As a result, an Agile project can improve speed by avoiding sprint-level commitments.

While both Agile and CCPM offer ways to aggregate risk, CCPM advocates elevating this risk to the project and portfolio levels whenever beneficial, and whenever acceptable to the customer. In contrast, Agile focuses its risk aggregation on the scrum team, ignoring the benefits of aggregating risk to the highest level feasible. There’s no reason Agile projects can’t also benefit by aggregating the risk beyond the scrum team, to the project level.

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!

Leaders usually need to be directive and supportive during the forming stage,

Ask team members to share a favorite travel photo, but not name the place. Team members ask questions and try to figure out where the photo was taken. Ask team members to share their favorite photo and

Try masks the intent and carries an element of implicit failure within the message. As Yoda said, you either do it or you don’t, there is no try.

Many times people use should instead of ‘I want’, this is the case with parents and children. The admonition of: “you should be nice” is actually saying: “I want you to be nice”.

Thomas Alva Edison, the great American inventor, once said: "I have not failed. I've just found 10,000 ways that won't work." Edison knew the power of failure in giving us a feedback, on what we are doing wrong, and how we can improve ourselves. Many people we know are afraid of taking the first step, taking a risk and moving away from their comfort zone. They are afraid of the difficulty that the first step poises. Of

The word ‘why’ carries guilt and finger-pointing into our team communications. It is better that we leave it out of our messages as it doesn’t have any positive impact on what we are saying. Rather, it is clearer to state what we want to achieve or alternatively ask information gathering questions using the word ‘how’. For example Ashley might ask: “Tina, can you please explain how these figures impact the transfer to operations?” Notice that while ‘why’ structures a closed ended question, ‘how’ questions are open-ended and investigate as to the process that led to a certain consequence.

Describe the behavior you would like to see, rather than the behavior you don’t want to see.

The cone of uncertainty shows that during the feasibility phase of a project a schedule estimate is typically as far off as 60% to 160%. That is, a project expected to take 20 weeks could take anywhere from 12 to 32 weeks. After the requirements are written, the estimate might still be off +/- 15% in either direction. So an estimate of 20 weeks means work that takes 17 to 23 weeks. Figure 1.1. The cone of uncertainty narrows as the project progresses.

three mortal leadership sins (i.e. not walking the talk, leading from power and not authority and assuming agreement) that can derail even the most adept and agile of leaders. 

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.

A central tenet of Agile Project Management is that knowledge about the context of the problem and the variables of its solution are discovered and created as an integral part of the development process. Agile Project Management solutions are created, built, or developed in stages so that as the customer uncovers specific real needs (remember IKIWISI?) the team can design and write code accordingly. 

The first agile principle in this example is that the team must have the necessary skills to complete the project.  Agile is not a silver bullet!  If a team does not have the required skills, even agile cannot help it successfully complete projects.  The second agile principle here is that the team must be self-organized, highly-trusted, and accountable.

Anyone who practices ad hoc development under the guise of agile methods is an imposter.

The Scrum idea of a separated Scrum Master is good for Scrum, but not appropriate for most projects. Good development requires not just talkers but doers.

We judge ourselves by what we feel capable of doing, while others judge us by what we have already done. —Henry Wadsworth Longfellow, American poet

A positive environment can’t happen if team members are negative toward one another. It’s the team leader’s place to put an end to this as soon as it starts.

A positive environment can’t happen if team members are negative toward one another.

Indeed, most of us realize that the requirements are the most volatile elements in the project.

True compassion is not just an emotional response but a firm commitment founded on reason. Because of this firm foundation, a truly compassionate attitude toward others does not change even if they behave negatively. Genuine compassion is based not on our own projections and expectations, but rather on the needs of the other: irrespective of whether another person is a close friend or an enemy, as long as that person wishes for peace and happiness and wishes to overcome suffering, then on that basis we develop genuine concern for their problem. This is genuine compassion (The Dalai Lama 2003).

global virtual high performance teams revolve around four concepts: (1) relationships, (2) accountability, (3) networking, and (4) leadership.

Relationships are of keen interest to successful team managers

Through collaborative problem-solving approaches, human capital is turned into an individual sense of ownership.

leaders are also representatives of company policies, processes, and procedures.

Recommended Reading Mike Cohn Agile Estimating and Planning provides guidance on iteration planning, including estimating the effort for user stories. David J. Anderson Kanban: Successful Evolutionary Change for Your Technology Business provides the guidance, definitions, and metric calculations necessary to establish an efficient software development flow, including establishing WIP limits.

Shu-Ha-Ri is the levels of learning from Aikido. Shu-Ha-Ri means learn-detach-transcend.

Succeeding with Agile Mike Cohn (2010)

we want to improve testing to reduce bugs in the system to reduce the duration to deliver new software releases” to financial business cases “with a 80% probability we will achieve benefits between 12.14 and 13.86 million Euro.” (Ritter and Marburger, 2012)

Ownership means that team members acknowledge responsibility for work and its results as a facilitator or strategist joined in collaboration.

We are uncovering better ways of developing software by doing it and helping others do it.

Agile project management revolves around empirical control.

to be able to achieve flexibility, all people involved in the project must perform continuous inspections and evaluations.

the team working using the Waterfall finishes each phase before moving to the next one.