PM 2 Vorlesung 7 Teil 1

Based on combined experiences of developing software, the signatories value

Individuals and interactions over process and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

• Unlike waterfall approaches, agile projects have fixed timeframes and resources, while the scope is variable.

• But even though the project scope may change, agile development teams commit to fixed iterations

Openness

Courage

Respect

Focus

Commitment

• Continuous gathering of customer/user feedback.

• Iterative planning and execution cycles.

• Regular presentation of interim results (e.g., prototypes / minimum viable products)

Scrum is an agile process model to reduce complexity from a process perspective

Most modern development projects are too complex to be planned consistently. Solution through empirical, incremental and iterative approach.

Transparency

Review

Adjustment

The progress and obstacles of a project are recorded daily and are visible to all

Product functionalities are delivered and evaluated at regular intervals.

The product requirements are not defined once but are reassessed after each delivery and adjusted if necessary.

Product Owner

Developer team

Scrum Master

Responsible for product and return on investment

• Defines the product vision

• Represents stakeholders

• Formulates requirements in theproduct backlog

• Prioritizes tasks/stories bybusiness value

Works self-organized and delivers the product

• Optimal size 7 +/- 2 members

• Fully dedicated and self-organized

• Cross functional with T-shaped skillsets

• Responsible for delivery of committed results

Brings agility into the team

• Assures that processes and rules are understood and kept

• Moderates scrum events

• Solves/removes impediments

• Supports the self-organization

• Responsible for an efficient workflow

In the Sprint Planning and Daily Scrum, the team establishes the sprint goals and the daily plan.

Sprint Planning usually consists of two phases

Who takes part: Full team (product owner, scrum master, dev. team)

Time frame: 2 hours per week in a sprint

• Presentation of Product Backlog by the Product Owner

• Team chooses as many requirements as it deems to be able to realize

• Establishing sprint goal

• Planning in detail

• Sprint backlog is broken down into tasks

Building transparency and planning the day

The development team meets every day to plan the day and ensure transparency

Who takes part: Development team (others optional)

Time frame: 15 min

Every team member answers these questions:

• What did I achieve since yesterday?

• What will I achieve until tomorrow?

• Which problems are holding me back?

During the Sprint Review and Sprint Retrospective the team discusses results and identifies opportunities for improvement

Product optimization

The team and the stakeholders discuss the results of the sprint and the next steps

Who takes part: Full team and key stakeholders

Time frame: 1 hour per week in a sprint

• Development team presents the results of the sprint

• Focus on the sprint goal

• Product Owner accepts the increment and possibly modifies the Product Backlog

Who takes part: Full team

Time frame: 45 min per week in a Sprint

Optimizing the way of work

The team analyzes their methods and procedures to identify opportunities for improvement

Scrum Master supports finding Good Practices and defining improvement measures

• What went well? What went badly?

• How can we improve?

Product Backlog

Sprint Backlog

Increment

• List of all known requirements

• Prioritized by Product Owner based on business value

• Changes over the course of the project

• Plan of tasks for the Sprint

• Illustrated on a task board

• Task sizes about 0,5 – 2 days

• All tasks are prioritized and estimated

• Sum of finalized Backlog Entries in one sprint

• Potentially ready for delivery

• Meets the Definition of Done

Valuable

Usable

Feasible

Delightful

People choose to use or buy it

People can figure out how to use it

We can build and deliver it

We can “wow” ou users

No agile methods

• Problem and solution are known and can be solved with a high degree of certainty and predictability

• Agile methods are superfluous and create more effort than necessary

Organize Work with Kanban, Waterfall

• Characterized by a high number of variables that follow a linear causality

• Needs time and possibly experts to do extensive analysis and develop plans

• Kanban or the waterfall approach can help organize work and workflow

Scrum, OKR

• Make assumptions, learn through constant trial and error, and identify patterns

• OKR synchronizes the work of individual teams with business goals, and Scrum helps organize the work of one or more teams

Design Thinking

• Dependent on fast action, many experiments, and direct feedback

• With increasing uncertainty, the importance of building and testing simple prototypes quickly in a design thinking process with very short iteration cycles increases

Focus on customer

Project autonomy and improvisation

Iterative nature

• Agile projects in a portfolio must reconcile tensions between customer needs and organizational strategy

• Increases number of interactions at portfolio level

• Greater coordination is needed between dynamic projects to ensure the emergent portfolio remains aligned to the intended portfolio

• Traditional top-down portfolio management approach difficult

Need for adaptiveness at the portfolio level due to regular changes in agile projects

• Agile practices positively relate to project success through TWQ

• Traditional PPM practices such as business case existence, strategic clarity, and operational control constrain this relationship

• Teams can enhance their teamwork when they use agile methods.

• In strongly controlled portfolios, agile practices might be less valuable.

• Well-established routines, for example, business cases, should be adopted where appropriate by using other approaches that are designed for agile projects (e.g., planning poker)

• Results support the beneficial influence of agile capabilities on emerging strategy recognition. Agile capabilities seem to mainly affect performance through their indirect effect via emerging strategy recognition.

• Positive relationship between entrepreneurial orientation and agile capabilities

• Voice behavior is also positively related to agile capabilities and portfolio success

• Emerging structures arising from the exchange can be beneficial in terms of emerging strategy recognition as one essential part of the strategy development process

• Managers should promote an autonomous mindset of employees

Culture

Autonomy

Cross-functional capabilties

Customer Integration

Iterative Work Method

Flat Hierarchies

Describes a set of values and norms that organization members share and that define appropriate attitudes and behaviors

Refers to a “self-directed behavior with general limits set by managerial control” which, if granted, ensures required resources’ allocation and encourages employees’ trial-and-error experimentations

Describes a team composition principle in which employees with different functional backgrounds should fulfill a common organizational objective

Describes a very pronounced company-customer relationship in which the customer is highly involved in interfirm activities, resulting in additional value creation for both parties

Describes the development process’s division into short and incremental sequences, repeated until a final product evolves

Refer to fewer managerial layers in the company’s chain of command