Organizational pattern
Organizational patterns are used to solve problems by adding a structure to a system of people, such as companies , political parties , the military and other organizations .
history
While organizational patterns have existed for a very long time, the concept of the pattern goes back to the architect Christopher Alexander . Alexander's ideas were adopted in software development in the early 1990s and later expanded to include organizations.
Organizational forms
Organization design pattern
Project management pattern
Community of trust
The personal relationships between employees have a significant influence on the effectiveness of a team. It is therefore important a community of trust (English: community of trust ) to build. Without trust between employees, communication is restricted and work processes have to be managed independently, which leads to multiple costs.
To strengthen the community, it is important to show trust in others yourself. Restrictions on access to information or bureaucratic hurdles in work processes can impair trust, which is why it is important to give employees control over their own work processes. In addition, employees need to feel that they have an influence on decisions, as they tend to trust the decisions of a decision maker. The employees also feel more obliged to take responsibility for the assigned tasks. This is important because another person cannot be given responsibility (they can only be accountable for their actions ), but the person concerned must take responsibility himself.
authorization
With the authorization (English: empowerment ) control over subordinate employees is deliberately waived. In contrast to the community of trust, which is based on an (implicit) bilateral agreement, authorization is unidirectional from a superordinate body. The aim of the authorization is, on the one hand, to expand the community of trust and, on the other hand, to relieve the higher-level bodies by reducing bureaucracy .
Assessment of the schedule
An assessment of the schedule (English: size the schedule ) is carried out when the product to be created is understood and the project size can be estimated.
Both too narrow and too large-scale schedules are to be assessed negatively. Too tight schedules lead to overworking of employees and to non-adherence to agreed deadlines or the delivery of an inferior product. This also affects subsequent organizational units and the customer. Too large a schedule increases costs for the customer by wasting time on incidental matters. Both lead to missed market opportunities.
An acceleration of work processes through an increase in the number of employees is often offset by Brooks' law and Amdahl's law .
The employees who work on the project should help estimate the project time - especially for their own workload. Good assessments can be rewarded with financial incentives or additional free time ( see also: Compensate Success ). In addition, two time estimates should be made. An internal schedule that is created in consultation with the employees, as well as an external one, which is agreed with the customer. The external schedule should be one to two weeks or two to three months above the internal schedule for a medium-sized project in order to be able to compensate for any overruns.
Comparable work
Comparable work is a pattern which Ward Cunningham defined as follows:
“Every project must commit to delivery on a few hard times and fast dates. This is actually fortunate because it is about the only way to get out of work that is going poorly. "
“Every project has to commit to delivery on several fixed dates in quick succession. This is beneficial because it is the only way to get rid of work that is going badly. "
See also: Scrum .
Get on with it
With get on with it or partial evaluation , the project is already started, although not all requirements are clear yet . Also, dependencies are often not predictable in detail and often only arise towards the end of a project. As soon as the direction of the project development can be estimated, one should therefore start with the things for which there is a high degree of confidence . In this phase, an informal work plan can already be used and prototypes can be developed. The prototypes also give an insight into what the structure of the finished product can look like and enable stable bases to be named . Often projects started early are carried out in the form of Skunk works . These are best executed in parallel with other business processes and use underutilized resources.
This pattern accelerates the completion of the product. However, because work has to be discarded in part due to changing requirements, this pattern should not be used if the resources required for the task are a bottleneck on which other processes also depend. Good communication is also required with subsequent units by means of responsibilities engage and hallway chatter .
See also: Build prototypes .
Named stable bases
Named stable bases are defined interfaces between project parts. These are named when the project plan has been drawn up and development of the product has started. Through the defined interfaces, the individual teams gain a common understanding of the product to be developed and can build on a defined basic behavior. The set of defined and named interfaces should be expanded regularly (e.g. weekly).
The development of prototypes is a way of defining a basic set of interfaces.
See also: Build prototypes , Programming episodes .
Incremental integration
In the incremental integration ( English: incremental integration ), the parts are put together a regular product to be developed. This avoids major integration problems in the late stage of product development. The development status is recorded and a new stable base on which the further development of the product is built.
Private world
As a private world ( private world ) is called a work environment has on an individual employee alone and all the necessary tools to provide needed for the activities of the employee.
Private worlds are often found in software development, in which a programmer has, in addition to the integrated development environment and the compiler , a local snapshot of the software to be developed (i.e. a named stable base ) and the required program libraries in order to be able to create and test the software at any time .
Build prototypes
Build Prototypes ( build prototype ) is a principle of the construction of a prototype of the recommended product to be produced. The concept of the product becomes apparent on the prototype and possible problems of the product can be recognized at an early stage and taken into account in further product development in the form of requirements to be tested .
The prototype means that change requests for the product come early, which avoids expensive undesirable developments. It is advisable to involve the customer in the development and to obtain feedback on the prototype.
See also: engange customers .
Take no small slips
Take no small slips (about: do not make little slip ) should be used when a project is behind schedule. If the planned completion date is repeatedly postponed by a few days, confidence in the project plan decreases. Therefore, the completion date should be postponed by a larger area, possibly with planned security.
The project status should be checked about once a week and the expected completion date should be re-estimated based on statistical data.
Division of labor
Division of labor (English: work split ) a method is to focus on the important activities by the team is divided and less important activities is shifted into subgroups. The important activities should not occupy more than half of the team, while unimportant activities can be omitted.
Division of labor should be used when important goals are behind schedule because the team is busy achieving less important goals.
Completion headroom
When calculated for each group in a project the expected completion date, the difference between the expected completion date and the planned completion date as is completion headroom (literally Completion headroom ), respectively.
This difference should be recalculated at least once a week so that management can take appropriate countermeasures should the difference increase too much. Among other things, a new prioritization and subsequent division of activities and, if necessary, postponing the planned completion date are suitable here.
Implicit requirements
Implicit requirements ( implied requirements ) are requirements that the customer has to be explicitly listed without them. Implicit requirements arise when the individual functions of the product to be developed are divided up and named.
Especially in software development, implicit requirements can include security, performance, logging, backup strategies, error handling, maintainability, adaptability to changed business processes, etc.
Queue
A queue (English: workqueue ) is a prioritized list implied requirements , thus still to be working. The order of the activities changes when the requirements change.
A queue corresponds to the backlog in Scrum .
A queue is much easier to handle and clearer than a traditional network plan made up of Gantt charts , which is more difficult to create, overwhelms the people involved with details and also has to be largely discarded if the requirements change.
Recommitment meeting
A recommitment meeting is a meeting of the project management and leading developers of a project when implicit requirements cannot be met within the planned schedule. It is important to clarify how a required functionality can be implemented with the least possible effort. The schedule is then updated using a work queue report.
Informal laboratory plan
An Informal Labor Plan is a public indicative schedule . Individuals or small groups create their own short-term schedules in order to divide the work so that the schedule set by management can be adhered to as best as possible. The project manager only monitors the schedule with a rough resolution, while the employees take care of the details independently and commit themselves to sticking to their schedule.
Development episode
In a development episode , all employees on a team deal with the same problem. This combines the different strengths of the individual people in order to achieve the best possible solution. As a side effect, knowledge is transferred from specialists to the other employees, whereby the reputation of the specialists within the group increases.
Developer Controls Process
Developer Controls Process is an information structure within a company in which the developers of a product can communicate bidirectionally with all stakeholders involved. The flow of information includes ideas, requirements elicitation, testing, delivery and marketing of the respective products.
However, it is important here not to overload developers with tasks. This can be done by filtering the flow of information, distributing tasks within the development team, and delegating.
Work flows inward
Work flows inward is an information structure in which work from outside the company flows directly to the appropriate role. To make this possible, clearly defined roles and established processes are required.
It is characteristic here that management is only marginally involved in the flow of information and does not generate any additional work. It is also important to ensure that the flow of information from a customer to the respective employee is informal and not indicative.
Programming episodes
A programming episode is when those program sections are coded by software for which there is a clear decision on the desired behavior. Program sections for which no clear decision is possible will be made at a later point in time after a review of the existing code base and implemented in a subsequent programming episode.
Someone Always Makes Progress
Someone always makes progress is a management principle in which one part of the team takes care of the core task of achieving a certain goal, while another part of the team takes care of tasks that distract from the core task.
More project management patterns
- team per task
- sacrifice one person
- mercenary analyst
- interrupts unjam blocking
- don't interrupt an interrupt
- day care
- surrogate customer
Gradual growth pattern
Size the organization
In size the organization is about to be able to assess the company as the sum of all teams, the required size of a team for a project, or the size needed. For large projects (with Software> 25 k SLOC ) it is rare that the project will be completed within the planned time and costs. There are various reasons for this:
- If the project team is too big, the costs are usually so high that the investment is not worthwhile.
- If the project team is too large, the common overview of the product is lost.
- Teams that are too large are less adaptable to small changes and take longer to react.
- If the team is too small, the time cannot be kept.
- If the project team is too small, the critical mass and therefore the moment to realize the project is missing.
- If the project team is enlarged late in the project, Brooks' law applies .
In software projects with a well-selected and supported project team of 10 people, projects of the following size can be managed:
- 60 kSLOC in 8 months
- 200 kSLOC in 15 months
- 1500 kSLOC in 31 months
Each role in the team can communicate with 3 to 7 other roles, which also ensures communication within different departments in large companies.
The best team size will vary with the project, but should be no less than 3 people and no more than 12 people. Larger teams should be split up, but the split can also lead to a reduction in productivity due to a change in work processes.
Surrogate customer
A surrogate customer ( replacement customer ) is used when the customer is required for feedback on the product but the customer is not available.
The problem that the customer is not available can arise for various reasons. About if
- the product the customer should first create
- the customer is too busy
- the contact with the customer is inappropriate at any given time
- a faulty company policy separates the developer of the product from the customer
To replace the customer, someone should be chosen who is not involved (i.e. not biased) in the development of the product. However, it should be noted that a replacement customer cannot completely replace the actual customer and is only a temporary solution.
More growth patterns
- phasing it in
- apprenticeship
- solo virtuoso
- engange customers
- scenarios define problem
- firewalls
- gatekeeper
- self-selecting team
- unity of purpose
- team pride
- patron role
- various groups
- public character
- matron role
- holistic diversity
- legend role
- wise fool
- domain expertise in roles
- subsystem by skill
- moderate truck number
- compensate success
- failed project wake
- don't interrupt an interrupt
- developing in pairs
- engage quality assurance
- application design is bounded by test design
- merchendary analyst
- group validation
- Community of trust
- Skunk works
Organizational construction pattern
Organizational style pattern
- few roles
- producer roles
- producers in the middle
- stable roles
- organization follows location
- organization follows market
- face to face before working remotely
- shaping circulation realms
- distribute work evenly
- responsibilities engage
- hallway chatter
- decouple stages
- hub, spoke, and rim
- move responsibilities
- upside-down matrix management
- the watercooler
- three to seven helpers per role
- coupling decreases latency
- standards linking locations
More organizational style patterns
People and product samples
- architect controls product
- architecture team
- lock'em up together
- smoke-filled room
- stand-up meeting
- deploy along the grain
- subsystem by skill
- architect also implements
- generics and specifics
- standards linking locations
- code ownership
- feature assignment
- variation behind interface
- private versioning
- loose interfaces
- subclass per team
- hierarchy of factories
- parser builder
- gradual engagement
Further person and product samples
Further organizational patterns
- Arranging the furniture
- Ad hoc corrections
- All at once
- Architecture definition team
- Balanced team
- Business process model
- Clear the fog
- Creator Reviewer
- Demo prep
- Designers are our friends
- Early and regular delivery
- Establish the business objectives
- Get involved early
- Gradual stiffening
- Guru does all
- Market walkthrough
- Master Journeyman
- Microcosm
- Owner per deliverable
- Participating audience
- Peacemaker
- Product initiative
- Prototpyes
- Query objects
- Shared clear vision
- Shearing layers
- Small writing team
- Skill mix
- Work allocation
- Work group
- Distribution of towns
- Subculture boundary
- Identifiable neighborhood
Standards
- BS 15000
- IT Infrastructure Library
- ISO / IEC 20000
- Microsoft Operations Framework (MOF)
- COBIT
- Enhanced Telecom Operations Map
people
literature
- James O. Coplien, Heil B. Harrison: Organizational Patterns of Agile Software Development . Pearson , Prentice Hall , Upper Saddle River 2004, ISBN 978-0-13-146740-8 , pp. 432 .
- Linda Rising: The Patterns Almanac 2000 . Addison-Wesley , Amsterdam 2000, ISBN 978-0-201-61567-8 , pp. 448 .
- Steve Berczuk, Brad Appleton: Software Configuration Management Patterns: Effective Teamwork and Practical Integration . Addison-Wesley, 2002, ISBN 978-0-201-74117-9 , pp. 208 .
Web links
- Ward Cunningham : Portland Pattern Repository's Wiki. Cunningham & Cunningham, Inc., accessed March 10, 2013 .
- Brian Foote : Pattern Labyrinth. Retrieved March 10, 2013 .
Individual evidence
- ↑ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq ar as at au av aw ax ay az ba bb bc bd be bf bg bh bi bj bk bl bm bn bo bp bq br bs bt bu bv bw bx by bz ca cb cc cd ce cf cg ch ci cj ck cl cm cn co cp cq cr cs James O Coplien, Heil B. Harrison: Organizational Patterns of Agile Software Development . Pearson , Prentice Hall, Upper Saddle River 2004, ISBN 978-0-13-146740-8 , pp. 432 .
- ^ A b c d Christopher Alexander: A Pattern Language: Towns, Buildings, Construction . Oxford University Press, New York 1977, ISBN 978-0-19-501919-3 , pp. 1171 .
- ↑ Christopher Alexander: The Timeless Way of Building . Oxford University Press, 1979, ISBN 978-0-19-502402-9 , pp. 568 .
- ^ A b John Vlissides , Norman Kerth , James Coplien : Pattern Languages of Program Design (= Pattern Languages of Program Design . Band 2 ). 1st edition. Addison-Wesley, 1996, ISBN 978-0-201-89527-8 , Demo Prep: A Pattern Language for the Preparation of Software Demonstrations, pp. 624 (English, c2.com [accessed March 7, 2013]).
- ↑ a b Stephen Berczuk, Brad Appleton: Software Configuration Management Patterns: Effective Teamwork, Practical Integration . Addison-Wesley, Amsterdam 2002, ISBN 978-0-201-74117-9 .
- ^ Ian Graham: Specification in Expert Systems and Conventional IT Projects . In: Computing and Control Engineering Journal 2 . tape 2 , 1991, p. 82-89 .
- ^ Frederick Brooks : The Mythical Man-Month: Essays on Software Engineering . Addison-Wesley, 1995, ISBN 978-0-201-83595-3 , pp. 272 .
- ↑ a b c d Ward Cunningham , John Vlissides , Norman Kerth , James Coplien : Pattern Languages of Program Design (= Pattern Languages of Program Design . Volume 2 ). Addison-Wesley, Amsterdam 1996, ISBN 978-0-201-89527-8 , Episodes: A Pattern Language of Competive Development.
- ↑ Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherlan: Scrum: A Pattern Language for Hyperproductive Software Development. (PDF; 118 kB) Retrieved on March 28, 2013 (English).
- ↑ Linda Rising: The Patterns Almanac 2000 . Addison-Wesley, Amsterdam 2000, ISBN 978-0-201-61567-8 , pp. 448 .
- ↑ Luke Wroblewski: Gradual Engagement Boosts Twitter Sign-Ups by 29%. June 16, 2010, accessed April 8, 2013 .
- ^ Alistair Cockburn: Surviving Object-Oriented Projects: A Manager's Guide . Addison-Wesley, Amsterdam 1998, ISBN 978-0-201-49834-9 , pp. 272 .
- ↑ Bruce G. Whitenack: Pattern Languages of Program Design (= Pattern Languages of Program Design . Band 2 ). Addison-Wesley, 1995, ISBN 978-0-201-89527-8 , RAPPeL: A Requirements Analysis Process Pattern Language for Object-Oriented Development, pp. 259-291 .