Agility Software

Agile Training, Coaching, and Consulting

16 items tagged "Scrum"

Results 1 - 16 of 16

The Product Owner as Steward

Category: Blog
Created on Monday, 07 November 2016 20:08

The Product Owner as Steward

In the Professional Scrum Product Owner course, we teach that high performing Product Owners are entrepreneurial. They not only act with the business in mind, they have the authority to make important decisions. What should we do now versus later? What choices give us the best return on investment? What’s the ROI if we do this feature later instead of now?

The Product Owner as Steward

Category: Blog
Created on Monday, 07 November 2016 20:08

The Product Owner as Steward

In the Professional Scrum Product Owner course, we teach that high performing Product Owners are entrepreneurial. They not only act with the business in mind, they have the authority to make important decisions. What should we do now versus later? What choices give us the best return on investment? What’s the ROI if we do this feature later instead of now?

Use the Right Tool for the Job

Category: Blog
Created on Tuesday, 17 May 2016 10:42

When all you have is a hammer, everything looks like a nail!

Huh? I don’t know; it’s something my father always said.

I think he meant that if you don’t have the right tool for the job, you’ll use the tool you have. And if it’s the wrong tool, the job will suffer.

Use the Right Tool for the Job

Category: Blog
Created on Tuesday, 17 May 2016 10:42

When all you have is a hammer, everything looks like a nail!

Huh? I don’t know; it’s something my father always said.

I think he meant that if you don’t have the right tool for the job, you’ll use the tool you have. And if it’s the wrong tool, the job will suffer.

Scrum Glossary

Category: FAQs
Created on Monday, 18 August 2014 12:43

 

Glossary of Scrum terms derived from the Scrum Guide by Ken Schwaber and Jeff Sutherland.
Term Refers to Description
Acceptance Criteria Product Backlog attribute Clarifying description for Product Backlog items to help stakeholders, users, and the Development Team understand the correct functionality of each item.
Adapt Scrum attribute A fundamental empirical attribute. To adapt means to change based on what has been learned. See also Inspect, Transparent, and Empirical.
Adapts to Environment Development Team attribute The Development Team adapts to the environment. As a self-managed team, they are not authorized to do anything they want. The development team does decide "how" to accomplish Product Backlog items within the constraints of the organization.
Cross-Functional Development Team attribute The Development Team has all the skills necessary to achieve the Definition of Done every Sprint.
Daily Scrum Scrum event A daily meeting for the Development Team, timeboxed to 15 minutes. The purpose of the Daily Scrum is for the Development Team to update their Sprint Backlog to deliver as much "Done" incremental value as possible by the end of the current Sprint. Any impediments to delivering that value are identified and the Development Team and Scrum Master work to remove them.
Development Team Scrum role The Development Team is responsible for delivering software value every Sprint via a "done" increment. They are authorized and responsible for determining how they will deliver the most value possible every Sprint.
Definition of Done Scrum attribute Owned by the Development Team, the Definition of Done (often abbrieviated DoD) identifies the key practices that will be accomplished to develop Product Backlog items of value. Although the DoD is owned by the Development Team, the Product Owner "accepts" the work every Sprint.
Done Scrum attribute The term "done" in Scrum mean no work remains for a Product Backlog item to be Potentially Shippable.
Emprical Scrum attribute Also empiricism. Wiktionary: "Pertaining to or based on experience." The scientific method is an empirical process. Scrum is an empirical framework. An empirical approach requires transparency, inspection, and adaptation based on what has been learned.
Grooming Product Backlog process This term is no longer used. See Refinement
Increment Scrum artifact The most important artifact in Scrum. The Increment of software, developed by the Development Team, includes only Done value-added functionality as identified by the Product Owner jointly with the Development Team. Each Sprint's increment is built upon all previous increments so that the value is cumulative at the end of every Sprint.
Inspect Scrum attribute Literally: to look at. Inspection is required for Empirical approaches. Inspection in Scrum occurs throughout the framework and requires Transparency for learning through inspection.
Ordered Product Backlog attribute Items on the Product Backlog are Ordered. Items may be rank ordered or ordered by relative priority (for example, high, medium, low). The most basic ordering is "now" and "not now." The Product Owner is responsible for ordering items on the Product Backlog. The PO relies on stakeholders, users, customer, the Development Team, and their own experience to order the Product Backlog.
Points Product Backlog attribute (Often called Story Points.) The relative estimate of effort for each Product Backlog item. Points are estimated by the Development Team only.
Potentially Shippable Product Backlog attribute Each Increment of software completed at the end of every Sprint is "Potentially Shippable." That is, it may or may not be delivered to users at the Product Owner's discretion.
Process Manager Scrum Master attribute The Scrum Master is said to manage the process of the Scrum Framework. The SM is NOT a personnel manager.
Prioritized Product Backlog attribute See Ordered
Product Backlog Scrum artifact An ordered list of value-added items to be implemented in software by the Development Team(s). Each item describes the funtionality to be added and "acceptance criteria" describing how the Development Team will know they have implemented the functionality correctly. The relative effort for each item is estimated by the Development Team.
Product Burndown/Burnup Product Backlog attribute Optional. Usually in chart form. Depicts the amount of estimated effort (see Points) remaining (or completed in a Burnup chart) in a release or project. The sum total of all known remaining work is graphed at the end of each Sprint. Changes in known work may also be depicted. The chart helps the Product Owner, Development Team and stakeholders understand the likley timeframe for completing a desired set of functionality. The Burndown/Burnup charts are usually derived directly from the Product Backlog; the charts are owned by the Product Owner.
Product Owner Scrum role The Product Owner (PO) role is responsible for the return on investment in the software product or system. The Product Owner role is part of the bigger Product Management role and focuses on identifying and clarifying the valuable features and functionality needed by users, customers, stakeholders and the organization that owns the software asset. Specifically, the Product Owner is responsible for the items on the Product Backlog, refining them with stakeholders and the Development Team, ordering the items on the Backlog, ensuring the Development Team estimates the relative effort of the items, and delivering the most value possible for the investment the organization is making for the product/system.
"Ready" Product Backlog attribute Items on the Product Backlog are said to be Ready when they are well enough understood by the Development Team for them to plan the item into a Sprint. That implies they are small enough to be completed (Done) in one Sprint and that the Product Owner will get what they expected from the Development Team.
Refinement Product Backlog process A process whereby the Product Owner and the Development regularly review, refine, update, breakdown into smaller items, and estimate the relative effort of items on the Product Backlog. Refinement reviews items to be implemented in future Sprints (not currently planned items). No more than 10% of the Development Team's capacity should be spent in regular Product Backlog refinement.
Scrum Scrum role An empirical framework developed by Ken Schwaber and Jeff Sutherland in the 1990s. Scrum is an iterative, incremental approach to optimmize predictability and control risk. The basic framework identifies 3 roles, 3 artifacts, and 5 events and basic rules for the framework. The Scrum Guide is the definitive description of Scrum.
Sprint Backlog Scrum artifact Owned by the Development Team, the Sprint Backlog identifies the Product Backlog items to be implemented in a Sprint along with how the Development Team will implement them. There is a new Sprint Backlog for each Sprint.
Scrum Master Scrum role The Scrum Master (SM) role guides the Product Owner, the Development Team, and the rest of the organization into ever improving and optimizing use of the Scrum Framework. The Scrum Master ensures that the people in the roles understand the authority and responsibility and helps them improve their skills in fulfilling their roles. The SM also ensures the Scrum artifacts are created and maintained in the most optimum way possible according to the Scrum Framework. And the Scrum Master works with the Development Team to help them remove impediments to delivering the most value possible in Done increments of software every Sprint.
Scrum Team Scrum definition The Scrum Team consists of the Product Owner, the Development Team, and the Scrum Master.
Self-Managed Development Team attribute Development Teams are structured and empowered by the organization to manage their own work. They determine "how" the Product Backlog items will be implemented within the constraints of the environment in which they work. Impediments in the environment are identified by the Development Team and, together with the Scrum Master, are removed to optimize the Development Team's work.
Self-Organized Development Team attribute The Development Team alone has the authority and responsibility to organize their work and produce Done increments every Sprint. There are no titles and no "sub-teams" (like testing or business analyst) on the Development Team--no exceptions! Individuals on the Development Team will have special skills and abilities but the accountability remains with the Team as a whole.
Servant Leader Scrum Master attribute The Scrum Master is said to be a Servant Leader. The SM's purpose is to optimize the PO and Development Team roles, the Scrum artifacts, and the Scrum events. The Scrum Master also helps those outside the Scrum Team to understand which interactions with the Team are helpful and which are not. The SM helps everyone change those interactions to maximize the value delivered.
Sprint Scrum event Each Sprint is a fixed-length iteration during which the Scrum Team forecasts the work, executes the work and inspects and adapts the work. It is always one month or less and should be the same amount of time every Sprint to help the Team achieve a development cadence. The Sprint contains all other Scrum events and there are no time gaps between Sprints.
Sprint Burndown Sprint Backlog attribute An optional view of the work remaining during the Sprint. The Development Team may choose to use a Burndown chart to gain better insight into where they are in delivering the most value possible by the end of the current Sprint. The Sprint Burndown chart is usually derived directly from the Sprint Backlog and is owned and managed by the Development Team
Sprint Goal Scrum event The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog items. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal.
Sprint Planning Scrum event

At the start of every Sprint, the Scrum Team plans the Sprint in two parts:

First, the Development Team estimates which Product Backlog items they can complete to be available in the Done increment at the end of the Sprint. The Sprint Goal is crafted as part one of Sprint Planning.

Second, the Development Team identifies how they will achieve the Done increment.

The guideline timebox for Sprint Planning is 2 hours for every week of Sprint (e.g., a 2 week Sprint should spend no more than 4 hours planning the Sprint).

Sprint Retrospective Scrum event After the Sprint Review, the Scrum Team reviews the processes by which they worked during the Sprint (inspecting themselves) with a goal of changing (adapting) those processes to make the next Sprint work better. The Sprint Retrospective reviews and modifies the State of the Process. The guideline timebox for Sprint Retrospective is 1 hour for every week of Sprint (e.g., a 2 week Sprint should spend no more than 2 hours in a retrospective).
Sprint Review Scrum event The Sprint Review occurs at the end of every Sprint. In addition to the Scrum Team, the Product Owner invites stakeholders and others that would benefit from understanding the current State of the Product. During the Review, the Product Owner will review the Product Backlog items completed by the Development Team in the Done increment and accept them (or not). The Development Team may demonstrate items that are Done this Sprint. Any items not completed during the Sprint are not demonstrated and are returned to the Product Backlog and ordered appropriately. Changes in the market and businss conditions which could affect the items or ordering on the Product Backlog are reviewed. The Product Owner reviews the budget and schedule for the investment in the product. And finally, the group collaborates on what is to be done next.
Stakeholders Extended role Anyone outside of the Scrum Team with a vested interest in the investment and delivered value of the product/system. Usually includes users, paying customers, organizational managers, and investors.
State of the Process Scrum attribute At the Sprint Retrospective, the State of the Process is reviewed and modified.
State of the Product Scrum attribute At the Sprint Review, the State of the Product is reviewed and decisions made based on the current state.
Timebox Scrum attribute The maximum amount of time that will be spent on a Scrum event. Timeboxes are established by the PO or Development Team or both in order to manage the overhead of the Scrum framework. The Scrum Master helps the Scrum Team maintain their timeboxes.
Transparent Scrum attribute Tranparency is an essential pillar of empirical processes. It means that everyone understands what is actually happening. Transparency is required for good decision making in empirical inspection and adaptation. The opposite of transparency (opacity), inhibits inspecting and adapting the product, processes, roles, artifacts, events, and operating rules of Scrum and will result in poor decision making.

 

Scrum Glossary

Category: FAQs
Created on Monday, 18 August 2014 12:43

 

Glossary of Scrum terms derived from the Scrum Guide by Ken Schwaber and Jeff Sutherland.
Term Refers to Description
Acceptance Criteria Product Backlog attribute Clarifying description for Product Backlog items to help stakeholders, users, and the Development Team understand the correct functionality of each item.
Adapt Scrum attribute A fundamental empirical attribute. To adapt means to change based on what has been learned. See also Inspect, Transparent, and Empirical.
Adapts to Environment Development Team attribute The Development Team adapts to the environment. As a self-managed team, they are not authorized to do anything they want. The development team does decide "how" to accomplish Product Backlog items within the constraints of the organization.
Cross-Functional Development Team attribute The Development Team has all the skills necessary to achieve the Definition of Done every Sprint.
Daily Scrum Scrum event A daily meeting for the Development Team, timeboxed to 15 minutes. The purpose of the Daily Scrum is for the Development Team to update their Sprint Backlog to deliver as much "Done" incremental value as possible by the end of the current Sprint. Any impediments to delivering that value are identified and the Development Team and Scrum Master work to remove them.
Development Team Scrum role The Development Team is responsible for delivering software value every Sprint via a "done" increment. They are authorized and responsible for determining how they will deliver the most value possible every Sprint.
Definition of Done Scrum attribute Owned by the Development Team, the Definition of Done (often abbrieviated DoD) identifies the key practices that will be accomplished to develop Product Backlog items of value. Although the DoD is owned by the Development Team, the Product Owner "accepts" the work every Sprint.
Done Scrum attribute The term "done" in Scrum mean no work remains for a Product Backlog item to be Potentially Shippable.
Emprical Scrum attribute Also empiricism. Wiktionary: "Pertaining to or based on experience." The scientific method is an empirical process. Scrum is an empirical framework. An empirical approach requires transparency, inspection, and adaptation based on what has been learned.
Grooming Product Backlog process This term is no longer used. See Refinement
Increment Scrum artifact The most important artifact in Scrum. The Increment of software, developed by the Development Team, includes only Done value-added functionality as identified by the Product Owner jointly with the Development Team. Each Sprint's increment is built upon all previous increments so that the value is cumulative at the end of every Sprint.
Inspect Scrum attribute Literally: to look at. Inspection is required for Empirical approaches. Inspection in Scrum occurs throughout the framework and requires Transparency for learning through inspection.
Ordered Product Backlog attribute Items on the Product Backlog are Ordered. Items may be rank ordered or ordered by relative priority (for example, high, medium, low). The most basic ordering is "now" and "not now." The Product Owner is responsible for ordering items on the Product Backlog. The PO relies on stakeholders, users, customer, the Development Team, and their own experience to order the Product Backlog.
Points Product Backlog attribute (Often called Story Points.) The relative estimate of effort for each Product Backlog item. Points are estimated by the Development Team only.
Potentially Shippable Product Backlog attribute Each Increment of software completed at the end of every Sprint is "Potentially Shippable." That is, it may or may not be delivered to users at the Product Owner's discretion.
Process Manager Scrum Master attribute The Scrum Master is said to manage the process of the Scrum Framework. The SM is NOT a personnel manager.
Prioritized Product Backlog attribute See Ordered
Product Backlog Scrum artifact An ordered list of value-added items to be implemented in software by the Development Team(s). Each item describes the funtionality to be added and "acceptance criteria" describing how the Development Team will know they have implemented the functionality correctly. The relative effort for each item is estimated by the Development Team.
Product Burndown/Burnup Product Backlog attribute Optional. Usually in chart form. Depicts the amount of estimated effort (see Points) remaining (or completed in a Burnup chart) in a release or project. The sum total of all known remaining work is graphed at the end of each Sprint. Changes in known work may also be depicted. The chart helps the Product Owner, Development Team and stakeholders understand the likley timeframe for completing a desired set of functionality. The Burndown/Burnup charts are usually derived directly from the Product Backlog; the charts are owned by the Product Owner.
Product Owner Scrum role The Product Owner (PO) role is responsible for the return on investment in the software product or system. The Product Owner role is part of the bigger Product Management role and focuses on identifying and clarifying the valuable features and functionality needed by users, customers, stakeholders and the organization that owns the software asset. Specifically, the Product Owner is responsible for the items on the Product Backlog, refining them with stakeholders and the Development Team, ordering the items on the Backlog, ensuring the Development Team estimates the relative effort of the items, and delivering the most value possible for the investment the organization is making for the product/system.
"Ready" Product Backlog attribute Items on the Product Backlog are said to be Ready when they are well enough understood by the Development Team for them to plan the item into a Sprint. That implies they are small enough to be completed (Done) in one Sprint and that the Product Owner will get what they expected from the Development Team.
Refinement Product Backlog process A process whereby the Product Owner and the Development regularly review, refine, update, breakdown into smaller items, and estimate the relative effort of items on the Product Backlog. Refinement reviews items to be implemented in future Sprints (not currently planned items). No more than 10% of the Development Team's capacity should be spent in regular Product Backlog refinement.
Scrum Scrum role An empirical framework developed by Ken Schwaber and Jeff Sutherland in the 1990s. Scrum is an iterative, incremental approach to optimmize predictability and control risk. The basic framework identifies 3 roles, 3 artifacts, and 5 events and basic rules for the framework. The Scrum Guide is the definitive description of Scrum.
Sprint Backlog Scrum artifact Owned by the Development Team, the Sprint Backlog identifies the Product Backlog items to be implemented in a Sprint along with how the Development Team will implement them. There is a new Sprint Backlog for each Sprint.
Scrum Master Scrum role The Scrum Master (SM) role guides the Product Owner, the Development Team, and the rest of the organization into ever improving and optimizing use of the Scrum Framework. The Scrum Master ensures that the people in the roles understand the authority and responsibility and helps them improve their skills in fulfilling their roles. The SM also ensures the Scrum artifacts are created and maintained in the most optimum way possible according to the Scrum Framework. And the Scrum Master works with the Development Team to help them remove impediments to delivering the most value possible in Done increments of software every Sprint.
Scrum Team Scrum definition The Scrum Team consists of the Product Owner, the Development Team, and the Scrum Master.
Self-Managed Development Team attribute Development Teams are structured and empowered by the organization to manage their own work. They determine "how" the Product Backlog items will be implemented within the constraints of the environment in which they work. Impediments in the environment are identified by the Development Team and, together with the Scrum Master, are removed to optimize the Development Team's work.
Self-Organized Development Team attribute The Development Team alone has the authority and responsibility to organize their work and produce Done increments every Sprint. There are no titles and no "sub-teams" (like testing or business analyst) on the Development Team--no exceptions! Individuals on the Development Team will have special skills and abilities but the accountability remains with the Team as a whole.
Servant Leader Scrum Master attribute The Scrum Master is said to be a Servant Leader. The SM's purpose is to optimize the PO and Development Team roles, the Scrum artifacts, and the Scrum events. The Scrum Master also helps those outside the Scrum Team to understand which interactions with the Team are helpful and which are not. The SM helps everyone change those interactions to maximize the value delivered.
Sprint Scrum event Each Sprint is a fixed-length iteration during which the Scrum Team forecasts the work, executes the work and inspects and adapts the work. It is always one month or less and should be the same amount of time every Sprint to help the Team achieve a development cadence. The Sprint contains all other Scrum events and there are no time gaps between Sprints.
Sprint Burndown Sprint Backlog attribute An optional view of the work remaining during the Sprint. The Development Team may choose to use a Burndown chart to gain better insight into where they are in delivering the most value possible by the end of the current Sprint. The Sprint Burndown chart is usually derived directly from the Sprint Backlog and is owned and managed by the Development Team
Sprint Goal Scrum event The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog items. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal.
Sprint Planning Scrum event

At the start of every Sprint, the Scrum Team plans the Sprint in two parts:

First, the Development Team estimates which Product Backlog items they can complete to be available in the Done increment at the end of the Sprint. The Sprint Goal is crafted as part one of Sprint Planning.

Second, the Development Team identifies how they will achieve the Done increment.

The guideline timebox for Sprint Planning is 2 hours for every week of Sprint (e.g., a 2 week Sprint should spend no more than 4 hours planning the Sprint).

Sprint Retrospective Scrum event After the Sprint Review, the Scrum Team reviews the processes by which they worked during the Sprint (inspecting themselves) with a goal of changing (adapting) those processes to make the next Sprint work better. The Sprint Retrospective reviews and modifies the State of the Process. The guideline timebox for Sprint Retrospective is 1 hour for every week of Sprint (e.g., a 2 week Sprint should spend no more than 2 hours in a retrospective).
Sprint Review Scrum event The Sprint Review occurs at the end of every Sprint. In addition to the Scrum Team, the Product Owner invites stakeholders and others that would benefit from understanding the current State of the Product. During the Review, the Product Owner will review the Product Backlog items completed by the Development Team in the Done increment and accept them (or not). The Development Team may demonstrate items that are Done this Sprint. Any items not completed during the Sprint are not demonstrated and are returned to the Product Backlog and ordered appropriately. Changes in the market and businss conditions which could affect the items or ordering on the Product Backlog are reviewed. The Product Owner reviews the budget and schedule for the investment in the product. And finally, the group collaborates on what is to be done next.
Stakeholders Extended role Anyone outside of the Scrum Team with a vested interest in the investment and delivered value of the product/system. Usually includes users, paying customers, organizational managers, and investors.
State of the Process Scrum attribute At the Sprint Retrospective, the State of the Process is reviewed and modified.
State of the Product Scrum attribute At the Sprint Review, the State of the Product is reviewed and decisions made based on the current state.
Timebox Scrum attribute The maximum amount of time that will be spent on a Scrum event. Timeboxes are established by the PO or Development Team or both in order to manage the overhead of the Scrum framework. The Scrum Master helps the Scrum Team maintain their timeboxes.
Transparent Scrum attribute Tranparency is an essential pillar of empirical processes. It means that everyone understands what is actually happening. Transparency is required for good decision making in empirical inspection and adaptation. The opposite of transparency (opacity), inhibits inspecting and adapting the product, processes, roles, artifacts, events, and operating rules of Scrum and will result in poor decision making.

 

What is Scrum?

Category: FAQs
Created on Saturday, 19 October 2013 18:16

Scrum is an agile development framework originally developed in the 1990's by Ken Schwaber and Jeff Sutherland.

It is a way for teams to work together to develop a products in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed.

More specifically, Scrum is a simple framework for effective team collaboration on complex projects. It provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge. Scrum leverages the innate traits and characteristics in people to allow them to do great things together.

How does Scrum Work? Building complex products for customers is an inherently difficult task. The fundamental process is incredibly simple and is organized into 3 primary roles:

  • Product Owners determine what needs to be built in the next 30 days or less.
  • Development Teams build what is needed in 30 days (or less), and then demonstrate what they have built. Based on this demonstration, the Product Owner determines what to build next.
  • Scrum Masters ensure this process happens as smoothly as possible, and continually help improve the process, the team and the product being created.

While this is an incredibly simplified view of how Scrum works, it captures the essence of this highly productive approach for team collaboration and product development.

The Scrum Guide, written by Ken Schwaber and Jeff Sutherland, outlines the essential elements of Scrum. You can find the latest version here in many languages.

What is Scrum?

Category: FAQs
Created on Saturday, 19 October 2013 18:16

Scrum is an agile development framework originally developed in the 1990's by Ken Schwaber and Jeff Sutherland.

It is a way for teams to work together to develop a products in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed.

More specifically, Scrum is a simple framework for effective team collaboration on complex projects. It provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge. Scrum leverages the innate traits and characteristics in people to allow them to do great things together.

How does Scrum Work? Building complex products for customers is an inherently difficult task. The fundamental process is incredibly simple and is organized into 3 primary roles:

  • Product Owners determine what needs to be built in the next 30 days or less.
  • Development Teams build what is needed in 30 days (or less), and then demonstrate what they have built. Based on this demonstration, the Product Owner determines what to build next.
  • Scrum Masters ensure this process happens as smoothly as possible, and continually help improve the process, the team and the product being created.

While this is an incredibly simplified view of how Scrum works, it captures the essence of this highly productive approach for team collaboration and product development.

The Scrum Guide, written by Ken Schwaber and Jeff Sutherland, outlines the essential elements of Scrum. You can find the latest version here in many languages.

Using Agile to Become More Agile

Category: Blog
Created on Saturday, 19 October 2013 14:53

As development teams adopt Scrum and other agile development techniques, the rest of the organization often struggles to deal with frequent, incremental releases. How can they get the full advantage that agile development offers?

Using Agile to Become More Agile

Category: Blog
Created on Saturday, 19 October 2013 14:53

As development teams adopt Scrum and other agile development techniques, the rest of the organization often struggles to deal with frequent, incremental releases. How can they get the full advantage that agile development offers?

Agility Jump-Start Program

Category: Agility Jump-Start
Created on Tuesday, 03 September 2013 19:32

One of the top reasons people say their agile projects fail is that they don't have enough experience with agile! Training is important—developers need to learn agile skills—but it's not enough.

If you're adopting agile practices, you'll need training and you'll need experienced help.

Agility Software offers the cost-effective Agility Jump-Start Program. For the price of just training all your agile team members, you also get expert in-person help from Agility Software experts. And the program is scalable from one project team to a whole product line or multiple departments. (To achieve enterprise-wide agility, see our Agility Path™ Program.)

The Agility Jump-Start Program consists of four elements:

1. We'll train the developers, Product Owners, and Scrum Masters for your agile team. They'll get the latest generation of training from Scrum.org by licensed Professional Scrum Trainers. This is not abbreviated training; they'll get the entire course for every participant including the opportunity to achieve Scrum.org certification for Professional Scrum Master or Professional Product Owner.* If you need Kanban to manage complicated processes, we'll train you in that too!

2. We'll coach you through your project startup including identifying key Scrum roles and holding workshops to develop your initial Product Backlog. For Kanban, we'll help you with Value Stream Mapping and setting up your initial Kanban board.

3. We'll coach you through Product Backlog estimation, release planning (if needed), and your first Sprint Planning. During your first Sprint, we're available to help you work through the initial learning experience of actually doing Scrum!

4. Finally, we'll coach you through your first Sprint Review and Sprint Retrospective. We'll show you the best ways to review your product and to evaluate your processes to be on your path to continuous improvement and agile adoption.

For the cost of just training a typical Scrum team, you can get the Agility Jump-Start Program for the same price! Yes, for just the price to train your people, you get professional expertise, guiding you through every step of the way. And the Agility Jump-Start Program is offered for multiple teams, departments and organizations as well.

Contact us today for more information. We'll answer your questions and help you adopt agile practices right away.

 

* Professional Scrum Developer training and certification are also available as an Agility Jump-Start Program add-on.

Agility Jump-Start Program

Category: Agility Jump-Start
Created on Tuesday, 03 September 2013 19:32

One of the top reasons people say their agile projects fail is that they don't have enough experience with agile! Training is important—developers need to learn agile skills—but it's not enough.

If you're adopting agile practices, you'll need training and you'll need experienced help.

Agility Software offers the cost-effective Agility Jump-Start Program. For the price of just training all your agile team members, you also get expert in-person help from Agility Software experts. And the program is scalable from one project team to a whole product line or multiple departments. (To achieve enterprise-wide agility, see our Agility Path™ Program.)

The Agility Jump-Start Program consists of four elements:

1. We'll train the developers, Product Owners, and Scrum Masters for your agile team. They'll get the latest generation of training from Scrum.org by licensed Professional Scrum Trainers. This is not abbreviated training; they'll get the entire course for every participant including the opportunity to achieve Scrum.org certification for Professional Scrum Master or Professional Product Owner.* If you need Kanban to manage complicated processes, we'll train you in that too!

2. We'll coach you through your project startup including identifying key Scrum roles and holding workshops to develop your initial Product Backlog. For Kanban, we'll help you with Value Stream Mapping and setting up your initial Kanban board.

3. We'll coach you through Product Backlog estimation, release planning (if needed), and your first Sprint Planning. During your first Sprint, we're available to help you work through the initial learning experience of actually doing Scrum!

4. Finally, we'll coach you through your first Sprint Review and Sprint Retrospective. We'll show you the best ways to review your product and to evaluate your processes to be on your path to continuous improvement and agile adoption.

For the cost of just training a typical Scrum team, you can get the Agility Jump-Start Program for the same price! Yes, for just the price to train your people, you get professional expertise, guiding you through every step of the way. And the Agility Jump-Start Program is offered for multiple teams, departments and organizations as well.

Contact us today for more information. We'll answer your questions and help you adopt agile practices right away.

 

* Professional Scrum Developer training and certification are also available as an Agility Jump-Start Program add-on.

Scrum for the Enterprise: Scrum.org's Agility Path

Category: Blog
Created on Sunday, 18 August 2013 10:39

What could be more appropriate than using Agile practices to spread "agile" throughout your organization? Scrum.org recently released the Agility PathTM; like Scrum, a freely available framework for using agile to become more agile.

Scrum for the Enterprise: Scrum.org's Agility Path

Category: Blog
Created on Sunday, 18 August 2013 10:39

What could be more appropriate than using Agile practices to spread "agile" throughout your organization? Scrum.org recently released the Agility PathTM; like Scrum, a freely available framework for using agile to become more agile.

About Us

Category: About Us
Created on Wednesday, 18 July 2012 19:05

 

Agility Software was founded by Mark Noneman. He has been a Scrum and Lean practitioner since 2002 applying, adapting, teaching and coaching agile and lean development in a wide variety of software and non-software projects. The most rewarding part? Helping teams succeed at becoming self-organizing and delivering higher quality more quickly than they have ever experienced before!
 
Mark specializes in teaching, coaching and consulting for the adoption of Scrum, Kanban, the Scaled Agile Framework (SAFe), Nexis, and other agile and lean techniques. He has worked with a wide variety of industries including “shrink-wrap” software, IT organizations, and contract development in many industries, particularly electronic design automation, enterprise software, e-commerce, and defense.
 
Contact Mark now to start taking advantage of agile today!
 
Professional Scrum Expert
Professional Scrum Trainer
 
 Certified SAFe® Program Consultant
 
 

About Us

Category: About Us
Created on Wednesday, 18 July 2012 19:05

 

Agility Software was founded by Mark Noneman. He has been a Scrum and Lean practitioner since 2002 applying, adapting, teaching and coaching agile and lean development in a wide variety of software and non-software projects. The most rewarding part? Helping teams succeed at becoming self-organizing and delivering higher quality more quickly than they have ever experienced before!
 
Mark specializes in teaching, coaching and consulting for the adoption of Scrum, Kanban, the Scaled Agile Framework (SAFe), Nexis, and other agile and lean techniques. He has worked with a wide variety of industries including “shrink-wrap” software, IT organizations, and contract development in many industries, particularly electronic design automation, enterprise software, e-commerce, and defense.
 
Contact Mark now to start taking advantage of agile today!
 
Professional Scrum Expert
Professional Scrum Trainer
 
 Certified SAFe® Program Consultant
 
 
FacebookLinkedIn