Jump to content

Scrum pattern

Add links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Vthavo (talk | contribs) at 20:47, 8 March 2014. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

A scrum pattern defines a specific problem an IT team development may encounter throughout the life-cycle of an application. Each pattern is created based on the Root cause analysis of project's failure or success:

  • across multiple IT projects,
  • ranging from small to large projects,

which guaranties the relevance of a pattern.

For instance, since 1985 the Standish Group [1] gathers a large amount of data on real-life IT failures (Standish Group is at the origin of the CHAOS report based on a database of 80000 real IT projects [1] and states that 76% of requirements change after a project has started) and provides an ability to profile current IT projects against those cases, within their offering of IT investment planning research and services.[1] Separately, IBM has established the top 7 factors of project failures.[2]

Also based on extended analysis, companies and individuals are regularly gathering under umbrella of the Project Management Institute to provide empirical solutions.[citation needed] This is the case of Jeff Sutherland, the co-creator of Scrum (development), who travels around the world to collect information whether on IT projects or on manufacturing industry. Then, he re-adjusts his viewpoint and propagates his knowledge through summits, articles, training, workshops or free events.[citation needed]

Scrum patterns are useful to:[citation needed]

  • help identify and define recurring problems within an IT product team,
  • suggest solutions that were proven to work for other teams, and provide a larger view on the scope of the solutions,
  • refer to related patterns an IT product team may face.

By formalizing a problem and providing a solution that has been tested across multiple organizations, a team could significantly increase/optimize its performance, self-esteem and moral, both individually, and as a team. Note: the Team is self-organized, with no micromanagement nor team leader, but rather a ScrumMaster serving as a Servant leadership with no people management responsibilities.[citation needed]

There are two types of Scrum patterns:[citation needed]

  • the core ones that has been grouped into a Scrum Guide[3] that is made available as Open Source, but still owned by their 2 co-creators (Ken Schwaber and Jeff Sutherland). Since this guide is meant to be small (16 pages as per today), to understand a specific pattern's usage and context, it is advised to rely on the literature maintained by the agile software development community,
  • Additional patterns, maintained by the agile software development community. Their names may vary from one initiative to another, but the problem they address remains the same.

History

Patterns of IT project failures has been identified before the creation of Scrum. By formalizing empirical experiences into best practices to form the Scrum framework, this movement has been accelerated, particularly after October 2011 when Ken Schwaber and Jeff Sutherland released "The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game".[3] It is a simplified version of the previous guides, so that only the core Scrum is present. Since this version, Scrum was made open source the community (but the owners remains Jeff and Ken). As a result, additional advices, improvements and initiatives was launched, and various communities have further developed scrum patterns.

"Scrum pattern" refers to both Scrum (development) that is an agile software development and also to software design pattern. Similarly to Software design pattern, we could find Scrum anti-pattern, which gathers a list of all bad practices that guaranties either the failure of a projects or the generation of many frustrations.

Usage

When you want to move toward agility either on a new project or on an existing one, a scrum pattern helps identify and communicate the changes needed to the development team and the management. Ideally, the entire core Scrum should be implemented, then instead of picking-up randomly any Scrum artifact and implement it, the usage of Lean software development, specifically the Kaizen (i.e. in Japanese "philosophy of improvement"), one could quickly increase a team's velocity in a structured manner with low efforts but high Return on investment. With this one single improvement wisely identified would solve the majority of your problems. This is also known as the 20/80 ratio or Pareto principle largely used in manufacturing industry and statistics. In our case, 20% of the effort spent on the improvements would solve 80% of our problems, which could be enough to consider spending our remaining 80% of energy in building a valuable product for the customer.

Example of Scrum patterns and usage

List of Scrum Patterns (non exhaustive)

Here are list of free initiatives

Problem to solve: Multitasking that reduces productivity, introduces errors and frustrations

Problem: Many studies,[4][5][6][7][8] literature,[9] articles[10][11][12] and worldwide consulting firms,[13] including recent ones from Louisiana State University psychology Professor Emily Elliott[4] stresses the fact that multitasking of any kind reduces the productivity and/or increases rate of errors, thus generates unnecessary frustrations.

It has been estimated that $650 billion[14] a year is wasted in US businesses due to multitasking.

Solution: ScrumPlop addresses this issue using the "first-things-first" Scrum pattern, when the context of the problem is summarized, and references and studies that justifies the solution are given.

References

  1. ^ a b c "The Standish Group – About". Retrieved 2013-12-09. Cite error: The named reference "StandishGroup" was defined multiple times with different content (see the help page).
  2. ^ Joseph, Gulla (February 2012). "Seven Reasons IT Projects Fail – Avoiding these pitfalls will help ensure success". IBM Systems Magazine. Retrieved 2013-12-09.
  3. ^ a b "The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game" (PDF). http://www.scrum.org. Retrieved October 2011. {{cite web}}: Check date values in: |accessdate= (help); External link in |publisher= (help)
  4. ^ a b Elliott, Emily (18 September 2012). "Louisiana State University psychology professor". ITWorld. Louisiana State University. Retrieved 18 September 2012.
  5. ^ Robert Rogers; Stephen Monsell (1995). "The costs of a predictable switch between simple cognitive tasks". Journal of Experimental Psychology. pp. 124, 207–231.
  6. ^ Rubinstein, Joshua S.; Meyer, David E.; Evans, Jeffrey E. (2001). Executive Control of Cognitive Processes in Task Switching. Human Perception and Performance. Journal of Experimental Psychology.{{cite book}}: CS1 maint: multiple names: authors list (link)
  7. ^ "How Employers Can Make Us Stop Multitasking". Harvard Business Review. Retrieved May 17, 2012.
  8. ^ "Multitasking Gets You There Later". infoQ. June 2010.
  9. ^ Crenshaw, Dave (2008). The myth of multitasking : how doing it all gets nothing done (1st ed. ed.). San Francisco: Jossey-Bass. p. 144. ISBN 978-0470372258. {{cite book}}: |edition= has extra text (help)
  10. ^ RICHTEL, Matt (APRIL 20, 2011). The New York Times Blog http://bits.blogs.nytimes.com/2011/04/20/message-to-executives-stop-multitasking/. {{cite news}}: Check date values in: |date= (help); Missing or empty |title= (help)
  11. ^ Cherry, Kendra. "The Cognitive Costs of Multitasking". about.com : Cognitive Psychology.
  12. ^ "Multitasking kills productivity and that's bad for new business".
  13. ^ Derek Dean; Caroline Webb (January 2011). "Recovering from information overload". McKinsey Quarterly. McKinsey.
  14. ^ RICHTEL, Matt (14 June 2008). The New York Times http://www.nytimes.com/2008/06/14/technology/14email.html. Retrieved June 14, 2008. {{cite journal}}: Missing or empty |title= (help)

Further reading

Soft skills to go beyond scrum patterns and further increase in team's efficiency

Scrum patterns, by design, are based on empirical facts and measures. To really understand what is behind the scene, soft skills have to be developed and a great help will come from the knowledge of complementary and powerful disciplines such as (and not limited to):

Many of the scrum artifacts are empirical answers some bias, and when knowing the most important ones, it is easier to put in place artifacts such as the scrum ones to move toward the success of an IT project.[citation needed]

For instance "Timeboxing" is an answer to the optimism bias, that is one of the reason why the Mantra of agile software development and Lean software development is "Think big, act small, fail fast; learn rapidly" . However, some bias could be sometimes beneficial, because a bias is a very basic instinctive but wrong answer to complex situation, but could lead by chance to good outcome.[citation needed]

When error in decision making could make your project fail

Over 70% of project fails (*) (**) (***), due to a numerous number of factors. The biases mentioned above contributes in taking a bad decisions; they are listed here: "List of biases in judgment and decision making".

(*) Why 70% of Government IT Projects Fail ? http://www.espsolutionsgroup.com/espweb/assets/files/ESP_QPM_ORG_revised.pdf

(**) Dec 2008 Zdnet Study, http://www.zdnet.com/blog/projectfailures/study-68-percent-of-it-projects-fail/1175

(***) University of Missouri-St. Louis http://www.umsl.edu/~sauterv/analysis/6840_f03_papers/frese

Other Scrum topics

Videos

Retrieved from "https://en.wikipedia.org/w/index.php?title=Scrum_pattern&oldid=598743435"