Scrum pattern
![]() | It has been suggested that this article be merged into Scrum (software development). (Discuss) Proposed since May 2015. |
![]() | This article may require cleanup to meet Wikipedia's quality standards. The specific problem is: fundamental misunderstanding of scrum and patterns, promotional in places, overbroad claims. (May 2015) |
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 collecting fact and figures, such as the Project Management Institute, to provide empirical solutions gathered into good practices. 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, and regularly re-adjusts his viewpoint and propagates his knowledge through summits, articles, training, workshops or events.
Scrum patterns shares the goal of other patterns and/or Anti-pattern, which is to:
- 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 morale, 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 (more details on Scrum (development)).
There are two types of Scrum patterns:
- The "official" one that has been reduced to its minimum and 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 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 some free initiatives
- Scrum Patterns summary: https://sites.google.com/a/scrumorgpatterns.com/www/scrumpatternssummary
- ScrumPLoP is a major actor that provides many references and explanation:
- its mission: http://www.scrumplop.org/the-scrumplop-mission
- its Scrum patterns ScrumPlop.org
- Scrum Patterns: http://www.scrum-patterns.com – A community led reference site for Scrum Patterns, Anti-Patterns, Tips and Tactics.
- Organizational Patterns and Agility (by James O. Coplien and Nordija A/S) : http://jeffsutherland.com/20071029CoplienOrgPats.pdf with a summary here: http://scrum.jeffsutherland.com/2008/02/scrum-and-organizational-patterns.html
- Unlocking Potential: http://unlocking-potential.de/scrum (Translated from German's organization: http://www.openpm.info)
- agilepatterns.org: http://agilepatterns.org - patterns for agile transformation and enterprise scaling:
- its mission: https://sites.google.com/site/agilepatterns/home/about-agilepatterns-org
- perception of risk: https://sites.google.com/site/agilepatterns/home/is-agile-transformation-at-risk
- approach to agile scaling: https://sites.google.com/site/agilepatterns/home/startup-scale
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
- ^ 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).
- ^ Joseph, Gulla (February 2012). "Seven Reasons IT Projects Fail – Avoiding these pitfalls will help ensure success". IBM Systems Magazine. Retrieved 2013-12-09.
- ^ 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
(help)|publisher=
- ^ a b Elliott, Emily (18 September 2012). "Louisiana State University psychology professor". ITWorld. Louisiana State University. Retrieved 18 September 2012.
- ^ Robert Rogers; Stephen Monsell (1995). "The costs of a predictable switch between simple cognitive tasks". Journal of Experimental Psychology. pp. 124, 207–231.
- ^ 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) - ^ "How Employers Can Make Us Stop Multitasking". Harvard Business Review. Retrieved May 17, 2012.
- ^ "Multitasking Gets You There Later". infoQ. June 2010.
- ^ 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) - ^ RICHTEL, Matt (April 20, 2011). "Message to Executives: Stop Multitasking". The New York Times Blog.
- ^ Cherry, Kendra. "The Cognitive Costs of Multitasking". about.com : Cognitive Psychology.
- ^ "Multitasking kills productivity and that's bad for new business".
- ^ Derek Dean; Caroline Webb (January 2011). "Recovering from information overload". McKinsey Quarterly. McKinsey.
- ^ RICHTEL, Matt (14 June 2008). "Lost in E-Mail, Tech Firms Face Self-Made Beast". The New York Times. Retrieved June 14, 2008.
Further reading on software project management
- 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