This article is the third in a series of articles on the subject of Agile theories

The power of Agile is that it leverages human behaviour as a means to achieve a goal. By understanding the theories behind the relevant human behaviour you can better utilise them and make the most of Agile. In this article I examine the various defined roles within Scrum, and look at the relevant Psychological, Business & Management theories. We will examine these under the headings of

Organisational Behavior

Senior management,

The Product Owner

The Scrum Master

The Team

It is important to note that Agile & Scrum are not simply a set of practices to be implemented according to a rigid set of guidelines or checklist. Successful Agile implementation is best described as a state of mind or mindset. The theories observed here are the manifestations of that mindset. You can use them to grow the desirable behaviours that springs forward from Agile.













Image source: Jack Moreh

Organisational Behaviour

"Understanding human needs is half the job of meeting them" - Adlai Stevenson

Regardless of our role within an organization, there are general Organisational Theories that relate to everyone and therefore must be understood, namely; Maslow’s Hierarchy of Needs, or ERG Theory, Taylors Principles of Scientific Management, Theory X and Y (Douglas McGregor) Organisational Structure and Job Characteristic Theory (Hackman & Oldham) that ‘proposed a model of five “core” job characteristics (i.e. skill variety, task identity, task significance, autonomy, and feedback) that affect five work-related outcomes (i.e. motivation, satisfaction, performance, and absenteeism and turnover) through three psychological states (i.e. experienced meaningfulness, experienced responsibility, and knowledge of results)’. You may note that this is a super-set of the Motivation Theory (Pink) discussed in a previous article. PERMA Theory (Seligman) also known as ‘Well-Being Theory’ has been gaining interest in the context of a work environment as it digs deeper into a persons measure of well-being.

Addressing these basic needs goes far in creating a high performance culture within an organisation.

Cross-cultural organisations benefit from broad rules of behaviours based upon Values, Expectations and Ad-Hoc Rules (SW-ICCM), as show by Xibao Zhang in his thesis. Hofstede’s Cultural Dimensions Theory lists the six dimensions upon which societal norms are woven into the fabric of our being & therefore effect culture within organisations.









Image source: gratisography.com

Senior Management

Senior management, sitting outside of Scrum teams need to set a clear strategic direction for the company, enabling employees to embrace the organisation through a clear set of company values. A HBR study sums it up well where they discuss the primary management practices—strategy, execution, culture, and structure. A Cummings & Worley study lays out how such change can be effected in six steps. Simon Sinek simplifies this in his Golden Circle Theory.

Within the context of Agile, traditional organizational cultures and structures would be required to reorganise if large scale Agile projects are adopted across the enterprise which are best suited to Agile Frameworks such as SAFe, Less or Dad. This would typically be the case in a business transformational project, or large scale projects with over 50 participants.

The frameworks listed above could be more readily adopted in the new generation of organisations that have Radical Management(SM), Holacracy, Cynefin, Management 3.0 or Teal Organistions at their core.









Image source: publicdomainarchive.com

The Product Owner

The Product Owner acts as an Agent (Agency Theory) on behalf of the project Stakeholders. They own, prepare and prioritise the Product Backlog, incrementally feeding User Stories to the Development Team based on the Sprint Vision. Together with the Development Team they jointly form the Scrum Team.

One of the key duties of the Product Owner is to protect the Development Team from outside influences, and then inspects, validates & Quality Assures their Sprint Output. Their other key duty is to deliver a Return on Investment (ROI) for the Project Sponsors & Stakeholders; customers and business units such as Marketing, IT, Customer Support, Business Strategy etc.

Unskilled Product Owners represent one of the biggest impediments to Agile

Given the diverse set of skills that the Product Owner must command, it is not surprising to note that unskilled Product Owners represent one of the biggest impediments to Agile adoption according to 49% of respondents to a Forrester survey. They need to keep an open mind, not fall prey to Confirmation Bias in their duties, and watch out for some of these specific pitfalls noted by agile.org.

Many college courses are devoted to Management & Leadership and so my purpose here is not to comprehensively cover this coursework in this article, but instead, I would like to point out the Management Theories and that most impact the Product Owner. I should first point out that the Product Owner is not a manager, in fact if a Product Owner were to issue autocratic diktats then we can certainly assume that the project is doomed. Instead the Product Owner needs to trust the Development Team to deliver upon their promises. This trust will be reciprocated as per the Swift Trust Theory (Meyerson).

Studious managers who fulfil the role of the Product Owner, may have noticed their focus shifting from literature on 'management' to 'leadership', this is due to the nature of the role of the Product Owner. This HBR article covers the transitional topic well.

The Product Owner needs to lead the Scrum team. As such, the Product Owner should understand their Leadership Style and should position themselves between a 5 – 7 on Tannenbaum-Schmidt Continuum depending on the project, to adequately lead the project.

"When dealing with people, remember you are not dealing with creatures of logic, but with creatures of emotion" -Dale Carnegie

The Product Owner should understand their Base of Power (French and Raven) and be very aware of the legitimacy (or lack thereof) of your ‘power’. They should be aware of the traits of leaders & five practices of exemplary leadership, as the Implicit Leadership Theory (Lord) informs us that we already have preconceived notions of what a leader looks like. Most of all, however, they need to focus on building upon Emotional Intelligence (EQ Theory) (along with the 99 other Qs) and recognise their own strengths and limitations before they fall prey to the Peter Principle whereby they stop performing effectively, and "rise to the level of their incompetence".

In both the project that they are engaged in and the engaging product that they are creating, it is worthwhile for the Product Owner to be aware of the Peak End Rule (Fredrickson & Kahneman) to create memorable experiences by actively looking for the peak (enjoyment/engagement/interaction) and ensuring that the experience ends well.









Image Source: Rodion Katsaev

The Scrum Master

Embedded within the Development team, the Scrum Master not only facilitates meetings and unblocks impediments, but is also responsible for ensuring that Scrum itself is understood and enacted. As such, the Scrum Master would be well advised in knowing of the key Servant Leadership Theory (Greenleaf) and knowing that Contingency Theory claims that the way to organise the team is contingent (dependent) on the situation. Given this fact it would seem that a mixture of experience and Situational Leadership® Theory (Hersey & Blanchard) applies; an observation that has been expressed in literature involving the Evolution of Scrum Masters eventually leading to the Yoda Scrum Master meme.









Image source: publicdomainarchive.com

The Team

The Development Team are cross-functional, self-organising and self-managing (empowered).

When a group of individuals join together to solve as common problem as a team, they naturally progress through a four stage process as captured in Group Development Theory (Tuckman). These stages are Forming, Storming, Norming and Performing, where Performing equates to a strong velocity in terms of Agile. Adding an additional team member resets the stages and the team must go through the process again. Based on this theory, it is clear to see that adding a new team member will make the team temporarily less productive & therefore this should be avoided as much as possible. Of these stages, I’d like to single out Storming in order to highlight its importance. Motivation may be sapped during the Storming phase as ‘conflict and tension are resolved’ and a natural leader arises (This may not always be the Scrum Master!). Working styles, personality traits and undefined roles are all sources of conflict. While it is recommended that the Product Owner allow the team to self organise, it is possible that the team can become stuck in the Storming stage, in which case, the Product Owner may wish to adapt their leadership style [more detailed] to best suit the phase in order to assist the team.

It is only when the team are in the Performing stage can the team perform optimally. This usually happens after several Sprint Cycles (after several opportunities for learning) and is called hyper-velocity in Agile. Flow Theory (Csikszentmihalyi) equates to the expression of hyper-velocity when the Scrum team are fully immersed in their tasks and can be informally described as ‘in the zone’. Interrupting any of the team members during the Sprint while hyper-velocity is occurring can impact their current User Story by increasing its duration by anything between 20% to 50%. This is the process of Context Switching Theory (Weinberg) and it strengthens the necessity of the practice of not multi-tasking within the Sprint & observing the definition of Done / Done before moving onto another User Story. It highlights the fact that persons outside of the Development Team should only ask team members questions at the designated times (eg: Grooming / Refinement) or to a designated person such as the Product Owner or Scrum Master, in order to allow for hyper-velocity to occur.

We have already seen from the first article, that the team are about to engage in Kolb’s Experiential Learning Cycle (ELC) as part of the Scrum Cycle, but it should be noted that each team member will learn in a different way. The Honey & Mumford Learning Style Theory classifies people as either one of four types of learning styles; Activist, Theorist; Pragmatist and Reflector. ELC incorporates the Honey & Mumford four Learning Styles of;

· Activists are those people who learn by doing.

· Theorists learn by understanding the theory behind the actions.

· Pragmatists learn by putting that learning into practice in the real world.

· Reflectors learn by observing and thinking about what has happened

In summary, Scrum accommodates all learning styles and so everyone benefits. People sitting outside of the Scrum Team can also benefit in a process called diffusion chain, as stated in Observational Learning Theory. Coupled with the impact of the Intrinsic Motivation Theory it becomes clear that the Team have everything they need to determine their own success (Self Determination Theory (Deci & Ryan))





As this article in the Agile Theories series focused on people more than processes, it was always going to be the most complex and likely for omission of a relevant theory. However, I hope that it has informed you of new theories, reminded you of old ones or enlightened you to realise that actions that you undertake have a theory behind them and perhaps could be optimised.

In my final article in the series, I will focus on theories and processes surrounding the Product Backlog.