The People View looks at the “soft-practices” involved in communication techniques, team building, decision making, leadership and team forming.
Based in psychology, the People View explicitly focuses on social practices because the business of software development is normally a team activity. For many organizations software development is a team-of-teams activity.
The People View incorporates Holistic Communication, a psychology and linguistics approach to effective communication in a business context.
People are important, not roles
Roles are not very important in HSD because real people don’t conform to a set of bullet points created by a process engineer. In line with the HSD principles, we do not wish to put people in a box that describes their characteristics. Instead, we acknowledge that individuals have many different skills and that team and organizational strength comes from diversity. Differences of opinions and approaches are not just a natural consequence of dealing with people but a source of significant value.
We “Value individuals and interactions, encouraging collaboration, reducing layers of communication over processes, tools and hierarchy” (from our manifesto). There is some value in processes, tools and (maybe) hierarchy but, there is far more value in individuals freely collaborating directly, and not through layers of organization or management. To this end, we incorporate psychology based professional mindfulness and conflict resolution amongst other techniques.
HSD only identifies the following roles:
A Business Leader is a person or group in the business who performs cultural, visionary and executive leadership. Leaders make decisions and perform a number of governance functions for the organization such as Strategic Direction and Continuous Investment Review.
A Business Leader might be a Business Owner, Director, senior Individual or skilled Individual – Business Leadership does not have to be a role performed by an individual although that is currently the most prevalent model.
Business Customers are stakeholders who the business provides value for. Business Customers can be either internal or external and are ultimately the owners of the cost/benefit case for a Product or Product Family.
Product Customers are stakeholders who require value from a specific product or product family. They are typically business domain experts and are capable of making decisions on the detail and relative priority of product requirements. Product Customers perform User Acceptance functions and are ideally real users of a Product.
Other roles are implicit and are best sourced from an intentional organizational design. Common roles are various flavors of Manager (e.g. Project/Product Manager), Architect, Analyst, Developer, Integrator, Support Engineer etc.. However, excessive explicit definition of these roles can lead to dysfunctional behavior such as:
- Abdication of collaborative responsibility for business value caused by role delineation as each role can consider some activities “not my job”
- “Empire building” of certain roles, especially if externally commercially sourced
- An inability to retain skilled technical staff as they are forced into management roles to progress their careers
Large organizations typically have both generalists and specialists. It is unrealistic to think that everyone can perform every necessary function as different individuals will have different skills. Roles are useful in this regard, but not if they drive the dysfunctional behaviors mentioned above. Creation of business value is everyone’s responsibility.
Many teams find they need leadership and that often falls to a person with the right character to communicate for the team, and deal with (sometimes robust) stakeholders. In these cases a Project Manager is also common.
Project/Product Managers act as leaders for teams performing critical communication roles, dealing with stakeholders, coordinating with other teams, mitigating local risks, driving continuous improvement etc. Not all teams need Product/Project Managers as some teams perform these functions as a group.
We recommend intentional organizational design and maintenance of a healthy workforce based on:
- Identifying skills required to deliver the Strategic Direction
- Recruiting and retaining skilled staff and contractors (see Workforce Shaping)
- Engagement with suppliers and partners if necessary
- Use of the Bubble Up practice to promote honest transparent communication and cross-organization engagement
- Strong cultural leadership (open, honest and transparent)
- Promotion of individual motivation
Personal motivation is the foundation of effective working in individuals and essential for meaningful Business Change.
The Royal Society for the encouragement of Arts, Manufacturers and Commerce (RSA) have published an excellent animated video on motivation based on some of Dan Pink’s work available on Youtube. To summarize, money and bonuses have been shown by various studies to be terrible motivators for complicated and complex work. People need to be paid enough so they’re not worried about mortgages, paying for food and living their perception of a reasonable lifestyle. Once these basic needs are met financial rewards for knowledge work actually detract from motivation.
Happy, motivated people are productive people. Motivation is based on Autonomy, Mastery and Purpose.
Autonomy is a key ingredient in motivation.
Organizations often talk about empowerment rather than autonomy; however, they are not the same thing. Simply, empowerment is given whereas autonomy is taken. This distinction has an effect on moral responsibility in terms of decision making.
Because an empowered individual or team is given its mandate for action from a higher power (i.e. management), the moral responsibility for its actions is, at best, derived from the high power but normally resides with the higher power. Empowered teams will often go and check with their senior management. Over time that degrades to only doing what they’re told.
An autonomous individual or team, however, assumes their own moral responsibility. An autonomous team has the right to do what it wants (within ethical constraints) without asking permission, without external limitation to the scope of that right. This is in contrast to an empowered team who are empowered to “do something” and therefore by implication anything that falls outside of that defined “something” is contentious.
Some organizations struggle with implementing this idea because there isn’t full trust between teams and the Business Leaders. However, if teams are truly trusted to act in the best interests of a transparent Strategic Direction they can be autonomous in selecting their working practices.
Autonomy doesn’t preclude fitting in with stakeholder’s requirements, only choosing the tactical details without constraint.
For a software team this means that the autonomous team can decide to take whatever action necessary to achieve its goals (as aligned to Strategic Direction and therefore Requiremements) only when the customer is part of the team making those decisions.
Individual Mastery refers to the continuous growth of a person’s skills as well as the mechanisms useful in increasing and rewarding mastery.
As we learn more in a field of knowledge such as Software Development, Business Management or any of the various specialisms that those terms overlap with, we are on a journey from novice to mastery. As we learn more, we need to learn new things to keep our skills fresh. We need to learn from a variety of sources, some outside of our specialist field that inform our understanding at a deeper level.
Mastery = (knowledge + talent + practice) * experience
Decision Making Models
Evidence Based Decision Making involved ensuring that facts are used to make decisions to avoid change or leadership by assertion. Evidence Based Decision Making explores the different ways decisions can be made ranging from autocratic to democratic and intentionally chooses a method based on the decision type.
People operate with and across organizational structures. As described in Conway’s Law, the structures an organization chooses have a significant effect on the People in that organization.
As businesses grow beyond single isolated teams they tend to seek ways to structure themselves in an attempt to make work and people more “manageable”. This is based on the mistaken belief that structure is organization, whereas structure is only one part of organization. Structure can be useful when it reflects desired cultural models and isolates truly separate concerns (e.g. ethical divides in different parts of a business such as tax advice vs. audit assurance) or completely separate brands/business lines. However, by its nature, structure can be divisive.
Every team boundary, or other structural boundary, typically causes a team inbox, backlog or other form of work queue adding to the total Lead Time for work unnecessarily. As a result, structure increases the impedance in the organization to doing a piece of work.
Hybrid Dynamic Model
The Hybrid Dynamic Model is a modern approach to structuring an organisations portfolio that allows for multiple ways of working to co-exist from innovation to utility work and for that work to change which processes, cultures and practices it uses over time.
An “Operating Model” describes how an organisation does its business in terms of both its structure and its behaviour – it is the business architecture. An “Operating Model” exists in every organisation, whether it is explicitly written down or simply a collection of processes and practices. The Operating Model includes how strategy flows through planning and delivery, how money is spent and controlled, how governance works, how people are organised and how quality is assured. If the Operating Model is inefficient or unable to react well to change, everything else suffers.
Many organisations evolve an Operating Model that fits their stable way of working, allowing for a focus on efficiency and improvement, driving out variation. This approach can work well in periods of stability but makes organisations brittle and unable to react well to change because the only way the organisation knows how to deal with events is to apply its tried and tested approaches. When the environment is less stable, or the variety of work types increases a Hybrid Dynamic Model is more appropriate.
Forming Effective Teams
Team Forming is a technique used to identify a team’s purpose, ways of working and interfaces.
The Business of Software Engineering is a social one. People, working together achieve business value. Processes, plans and organization charts don’t.
Much of the conflict we’ve observed in organizations is inherent in the internal team structures and inter-team relationships caused by either dysfunctional or emergent organizational design. Holistic Software Development focuses on tried and tested mechanisms for effective team forming. This practice looks at effective Team Forming.
We recommend that teams hold regular retrospectives to aid their internal communication and cohesiveness.
Retrospectives are periodic team based reviews focusing on what went well and what went wrong so that lessons can be learned and processes improved.
Stakeholder management refers to establishing an understanding of stakeholders, relationships, expectations and objectives. Stakeholders are people or organizations who are affected by the outcome of an project, programme or other business activity.
Communication is the transfer of messages from one person to another person. Holism refers to treating the whole of a system not just its constituent parts. Therefore holistic communication is applying systems thinking to inter-personal communication. Since communication is so critical to team working, which is the foundation of Software Engineering businesses, we consider communication techniques in some detail.
Using psychology and linguistic based communication techniques and change practices we improve decision making, intra- and inter-team communication, conflict prevention (and resolution) and Business Change.