Pharmaceutical business seems an unlikely place for Scrum. Strict regulation and long development cycles make it difficult to embrace Agile. This report outlines our learnings with Scrum in regulated environments.
1. INTRODUCTION
Roche Pharma Finland (Roche Oy), founded in 1982, is the Finnish subsidiary of Roche Group. Based in Espoo the company covers all health care districts in Finland with its services. Roche Oy is specialised in innovative cancer treatments, and the company also has an extensive product portfolio for the treatment of neurological disorders, lung diseases, disorders of the immune system and infectious diseases. The business in Finland focuses on hospital medicines.
Healthcare sector is tightly regulated. Roche Oy has to operate under strict medical and ethical control. Risk taking and experimentation are not natural in their business. However, Roche Oy managed to implement Scrum successfully and break some barriers that earlier limited their thinking and operational model.
Reaktor Innovations is a Finnish consultant company. Reaktor delivers digital future to its customers and creates digital services in retail, aviation, defsec, gaming, life science and entertainment sectors, to name a few. Reaktor has a coaching and training business unit that provides customers with Agile coaching.
Roche and Reaktor cooperated in 2020 to reinvent Roche and roll in a new Agile mode of operation. This report describes the journey of Roche and experience of Reaktor coaches, Sami and Jarkko. We are seasoned Agile coaches, putting together more than 30 years of experience. However, our background is mostly in software development and in businesses creating products. Marita from Roche provides her insight from the client’s point-of-view through this report.
2. Motivation
Why did a medical company decide to try Agile and Scrum? In 2018, there was a global decision at Roche inspired by Agile in other non-software companies (for example ING). Pharma International headquarters decided that all Affiliates should try Scrum. Finland was one of the first affiliates to jump onboard.
Marita explains the need for external coaching: “Our first thought was that nobody does this in Finland, so we went to get training in the Netherlands and the first Scrum Masters started working with teams. After a while we noticed teams were doing Scrum very differently; we wanted to understand what needs to be harmonised across teams and what can be decided by teams. We had also learned that there are companies with agile knowledge and experience in Finland and we knew that Reaktor has a very high profile in being one of the Agile pioneers here. So I decided to contact Reaktor in late 2019.”
Roche transformation was a very attractive opportunity to us. First and foremost, the company has a good purpose. They work to improve the lives of patients, many of them being terminally ill, and bring high-quality extra months to their lives. Secondly, the company is not in the software business so their intention to use Scrum was very unique. Thirdly, the company had already started their transformation and the goals for the change were both ambitious and well-articulated. Additionally, the size of the company (about 85 people when we started) was small enough as we saw high potential for a significant change in a short time period.
We have some experience with non-software teams, but most of our coaching experience was in IT or software development, so this was a new environment for us. That created some anxiety if we were able to provide anything of value in such a different context.
What really sparked our curiosity as coaches was a perceived mismatch between reality and the selected approach: How can a company in a regulated business do Scrum? What would be “a potentially shippable product increment” in their context?
3. Background
Roche’s transformation had started well before they contacted Reaktor. The transformation was not just “doing Scrum” but thoroughly refreshing their structure and practices. In a sense we were jumping onto a moving train since a lot of thinking was already done and many things were decided and implemented.
Marita recalls the start of the journey: “Before teams started using Scrum, there was a planning period and people from different departments got together to think how we can best meet the needs of healthcare professionals and our other partners. We wanted to maximise employee involvement and deliberately did not have anyone from our leadership in the design team.” .
This design team introduced a set of goals to the organisation:
- Customers are at the centre of everything—satisfied employees as the key to success
- Testing an unfinished product in order to see if the direction is right
- Decisions are made where the impact and influence is
- Promoting openness with inclusive, clear and straightforward communication
- Supervisors are coaches who remove obstacles, help with the big picture and prioritising
Besides new thinking, the change also required new structures. In the new model, the number of supervisors decreased from 22 to 7 and people joined in self-regulated autonomous teams.
Figure 1: Roche organogram with Community “beehives” and Disease Area teams
After starting our work we observed the following. Disease Areas (DA), for example “Breast cancer” or “Hematological diseases”, are the core of the organisation. Each DA team is cross-functional, for example both Medical and Commercial skills are available in the team. Disease Area lead is a Product Owner for the DA in question. Organisational flexibility was built-in by designing volatile DA teams: teams can be added, modified and removed based on business needs. However, during one year we did not see this volatility happen and the only changes were minor personnel changes (new recruits / people leaving).
Communities were stable structures that provided a homebase for people with similar skills, for example “Commercial” or “Science”. Community Leads were line managers (supervisors) for employees.
It quickly became clear for us that the ambition level in organisation was very high. Besides Scrum they were aiming to become Teal [Laloux]. The organisation was putting a lot of emphasis on working towards their North Star—providing better care for more patients faster. The North Star was a self-crafted shared ambition for all teams.
The transformation strategy was to involve people, start with new thinking and only then bring in Scrum. An alternative would be “Scrum your way into the new thinking”: do Scrum and build new thinking while doing it. That approach would bring visible benefits sooner (e.g. Scrum events would be in place earlier), but Roche approach taught us the importance of shifting mindset when launching a major change. New thinking paved the way for new working practices, e.g. Scrum, and created a strong pull for coaching.
4. Being Humble Makes a Great Start
Based on our previous experience, we knew that understanding the current state is a key to a successful change. Jarkko’s thoughts: “When I started as a consultant after years in a product business I felt a strong need to have an impact early on and assert myself as a big expert. Nowadays I know better, and my natural instinct is to first learn and listen to people in different roles at the company.”
We received a lot of information from Roche before we started, but we still insisted on spending two-weeks on an assessment about the current state of the organization. We interviewed 14 people and summarised our findings into a presentation. The structure of interviews was very simple:
- How does the work work? If needed, draw the flow of work on paper
- How do you know you are successful in your work?
- Top-3 things that work well at Roche?
- Top-3 things that do not work at Roche?
- If you would get a magic wand, what would you change?
Simple open-ended questions allowed us to hear different opinions and made it possible to test our own thinking: we were not trying to fit answers into a model but rather understand what is happening at Roche.
It turned out the “magic wand” question was very powerful. It made people think outside their daily tasks and imagine what would be really good for them and for the company. It’s a very open question and came in a good spot in the interview, when a lot of the basic stuff was already covered. Sami was actually a bit worried about asking this question from e.g. CEO, but this was probably the question that gave us the most insight.
During his interview, the CEO explained to us the thinking behind transformation. These ideas were very different from the usual “more value” or “better quality” or “happier employees”:
- Become more customer-driven instead of being product-centric.
- Transform the organisation from a pyramid to communities.
- Switch the leadership mindset from being in control to knowing what is going on.
In our opinion, these were the key levers for improving business performance and employee satisfaction. They hit the sweet spot between new thinking and new practises. They were easy to communicate and explained well the intentions behind transformation.
The CEO was also an active proponent of Scrum. He offered support and even pushed people to become more Agile. This happened in e.g. form of speeches in different company wide events. This is very helpful, as then everybody is clear that this is something allowed and encouraged. It’s not usual to have such a high level enthusiastic advocate for agile in transformations we have faced, so we were delighted.
However, it became clear to us that the agile transformation had been born as a top-down idea. As a result, we observed uncertainty in teams about what is mandatory and what is voluntary; what can be adjusted by the teams and what needs to be done in the same way through organization. This revelation helped us to find the right tone in our further discussions.
We presented assessment findings to Roche leadership and the CEO summarised the key points in an email to everyone in the organisation. At the same time, we were invited to a Friday coffee break at the main cafeteria of company headquarters in Espoo and we introduced ourselves to everyone in the office.
In that event we wanted to give an impression that we are not forcing anything on anybody. So instead of e.g. describing what we will do and what kind of agile practices we are advocating for, Jarkko gave a speech that summarized three pitfalls of helping:
- Help is forced on us without us wanting it
- Being asked to help without knowing what we should help with and how
- Help is not available when needed
Then we asked people to have a small group discussion about where they need help and we heard their comments.
We believe this started the assignment on the right foot; people realized that we were there to listen and to help, not to blindly push our own agenda. This is a decision we are still very happy about, and we also got concrete appreciation about it later when we were concluding our assignment.
5. Being Agile Requires Structure
We introduced the term “Enabling structures” in the assessment and that resonated well for both leadership and team members. Enabling structures means clear and simple rules that enable everyone to self-organize. In other words, we defined what is common for all teams and what is left for teams to decide by themselves.
We took enabling structures from Cynefin model. Cynefin uses a term enabling constraint and it is defined as “..context sensitive rules that creates alignment for agents in system” [Brougham]. Cynefin recommends creating enabling constraints when the work falls into the complex domain. As enabling constraints are context-sensitive, they can not be copy-pasted from other environments. The process of creating enabling constraints is more useful than applying rules. This is why copying for example “Spotify Model” does not provide desired results in other contexts.
Sometimes self-organisation turns into an “anti-structure” movement. Any attempt to bring structure is considered harmful for team autonomy. The concept of enabling structures provided teams with a concrete way to take ownership of their work and it created energy to shape suitable working practices for each team. We see that enabling structures is a useful way to frame the need for structures in self-organizing teams.
6. Enforcing Some New Practices Helps People Learn
Our first contacts with the teams were Scrum events. All teams were doing one month Sprints with Sprint Planning, weekly team meetings and Sprint Closing. Incoming work was organised into Product Backlog.
6.1 Tailored Scrum was not a good idea
Teams were tweaking Scrum and it turned out to be a root cause for some of the problems we observed.
Sprint Review was replaced by Sprint Closing which was a team internal event, no stakeholders were invited. Stakeholders were invited to Stakeholder Reviews, but those reviews were infrequent.
Daily Scrum was replaced with a weekly meeting, the main reason being that people spent most of their time in customer meetings. We also saw another reason—the lack of common goals in the team. During Sprint Planning meetings we observed that work was allocated to individuals and there was very little swarming.
6.2 Back on track
We contacted Scrum Masters and team leads and started to talk about how coaches could help the teams in practice. We offered our ideas based on what we knew already, and offered to facilitate new practices for the teams. This was very well received and no-one declined our offer to help with scrum events.
One of the first steps was to re-introduce a proper Sprint Review and remove Sprint Closing and the occasional Stakeholder Review from calendars. One concern in teams was: How to get busy people to the review meeting every month? We addressed this and proposed that each Review would have max 4 guests from other teams. Another rule was that the primary invitee from another team was not Product Owner as they were the most busy people in the organisation.
A lesson learned here is that people need a little bit of pushing, and it’s good that we took initiative – actually more and more initiative as time went on.
6.3 Results
We learned that the elements of Scrum are in place for a purpose. Tweaking Scrum may make things worse, even when tweaking is done with good intentions.
Regarding Daily vs Weekly we learned that not-doing something is also an intervention. There were sound reasons for not having Daily meetings: work required a lot of traveling to customers, people worked on individual tasks with no need to share progress on a daily basis. We succumbed to these reasons and—by doing nothing about it—we quietly supported the organisation with this decision.
However, if a coach decides not to make intervention early, it will be more difficult to change things later. This may be dangerous, especially if the decision not to intervene is accidental. What we now afterwards wonder is how easily we let this one go. Maybe we were already blind to some things ourselves?
Improving on Sprint Review brought the best results. We introduced a template script that made the event more fluent and useful for participants. Another improvement was happening in Sprint Planning: since a Review was happening relatively soon, teams were forced to think about “what can we present in Review regarding this topic”, which helped teams to have better focus in the Sprint.
Jarkko reflects: “I’m really happy about the decision to create a script for Review. Distributing the script wasn’t planned, it just happened as I had anyway made a script for my own use and running proper sprint reviews seemed to hit a spot. We could have used this approach—create a script and share it to teams—for other stuff, too, and probably will in the future assignments.”
7. Focus Brings Clarity
All teams used a Product Backlog for upcoming work. But the backlog was not like any backlog we had seen: it was more like a road map or collection of themes that teams should focus on in the coming 6-12 months. It definitely wasn’t a prioritized list of work-items in any of the teams.
Teams also had another source for incoming work: Pivotal Challenges. These were longer-living issues that teams had to consider when planning their work, for example “Cooperation with Patient Advocacy Groups”.
7.1 Flooding with work
In the Sprint Planning sessions we realised quickly that teams had several problems related to work management:
- There was no real Product Backlog where teams can pull work for the next Sprint. Product Backlog was a collection of ideas and not prioritised.
- Teams had multiple channels for incoming work: Product Backlog and Pivotal Challenges. New work was introduced also during Sprint Planning.
- As a consequence, teams did not have a single goal for a Sprint. Flood of incoming work forced them to take bits and pieces from everywhere. Many items were unfinished at the end of Sprint and they spilled over to the next Sprint for finalisation.
- As a further consequence, people were overloaded with work and they were multitasking heavily.
At this point we shifted our focus from Scrum events to backlog management in order to get rid of overload. We realised that significant progress won’t happen before people have time to plan, complete and review their work.
7.2 Experimenting until we know what works
The first experiment was to change Product Backlog from “a roadmap” to “a real backlog”. We did backlog refinement sessions with teams and split large items to Sprint-size chunks. Unfortunately this experiment did not spread to teams: their idea of Product Backlog as a road map was deeply rooted in thinking and the idea of refining and prioritising backlog died quickly.
Another idea was to estimate the size of Sprint Backlog items. Also this experiment turned out to be not useful. We learned that “size” of work is not relevant when much of the work is dealing with external stakeholders (healthcare professionals in hospitals). Work was a lot about waiting or trying to get access. Also this experiment was abandoned after about two Sprints, because it did not help with overload.
One successful experiment was to limit work-in-progress by reducing the number of Sprint Goals. Previously teams had vague goals or many goals (or no goal at all, just tasks). We encouraged teams in Planning meetings to focus on only a few goals. While this was painful in the beginning (“everything is important, we must take it in the Sprint”) it was later considered as the best tool to reduce workload and get things done.
To our experience it paid back to be pretty assertive and require teams to cut the work-in-progress. Limiting WIP under pressure would not have been possible without us pushing teams to do it.
7.3 Results
Unfortunately, busyness and overload remained in the organisation but focused Sprint Goals helped teams to improve in this area. Sprint Goals also made Sprint Reviews more useful as the team had a “coherent story” to share with stakeholders, not just bits and pieces. Sprint Goal also helps to decide which stakeholders should be present in Sprint Review.
At this point we did a lot of experiments that did not stick. Besides backlog-related experiments we also tried to create visualisation of current work in each team and also agree what will remain team specific and not visualised. We organised two workshops but never reached a conclusion. It was frustrating, but we understood that much of our work is to experiment with options and choose those that are the best fit. Experiments, even the “failed ones” were useful to understand the real problem. As soon as we know what does not work we get a better understanding of the problem.
8. Remote Work Works, Too
One of our strategy to find contacts was to hang around in the office in between meetings. That made us available for ad-hoc conversations that in our experience yield opportunities for coaching, facilitation, getting to learn the organization and so on. We didn’t realise how significant this strategy was until it was taken away.
Covid-induced remote work flushed that strategy down the drain. At first we felt that this was probably the end of the work. Marita said that also Roche was unsure how to continue with coaching. After the initial shock we pulled ourselves together and adopted a different approach: we decided to contact teams explicitly and, as we learned later, with a very concrete agenda. It is easier to propose for example a facilitated event (e.g. sprint planning), than to offer vague team coaching.
We divided the teams between us coaches so that each team (and Scrum Master and PO) got a dedicated contact. Especially in remote working setup, it pays off to remove all the possible barriers from getting to speak with people, when there is no opportunity for random meetings in the corridors or at the water cooler.
Initially we hesitated to split teams between us. We thought that it’s better to act as a two-person resource pool to provide availability and skills of both coaches. In practice though, that was more difficult for teams. It seemed that they didn’t contact us at all since there was no clear, dedicated single point of contact.
Digitalisation of backlogs and boards had been a discussion topic already before Covid-19, and like in the world in general, forceful switch to remote work gave it a huge push. It wasn’t anymore about whether we do stuff in electrical format or not, instead the new question was how do we do it. That created an opportunity to improve workflows of the teams also in other ways. For example, remote work was a great excuse for us to promote good Trello-related working practices to all teams and hence improve the flow of work. Communicating only through video calls also seemed to spark conflicts in teams more easily, so we got an opportunity to bring teamwork topics into our coaching.
With all the trouble that the Covid-19 pandemic brought, it also provided the needed tension, a driver and an opportunity for change. Learning here is what Winston Churchill once famously said: “Never let a good crisis go to waste.”
9. Becoming a Team Requires Work
Roche was strongly advocating Teal thinking and pushed teams to be self-organised and autonomous. Despite the push for Teal and autonomy in teams, we observed that teams at Roche were more workgroups than teams. Teams had goals, but team goals those were very high-level and did not guide team members in decision making or prioritisation. People in teams were primarily working on their individual tasks.
9.1 Misunderstandings about teamwork
While people understood the importance of teams, there was a visible lack of skills regarding working as a team. Sami recalls an example from one team. The overall atmosphere was good and a recent Review had been a success. Even so, there was an outburst in a Retrospective when some team members clearly disagreed how something should have been during the Sprint. To my observation the team lacked skills to handle the conflict. The reaction was avoidance rather than working through the situation.
I discussed this with Country Lead and she expressed concern that “we are losing our team spirit”. At that moment I realised that expectations towards working as a team were not reasonable. For example, having and handling conflicts is part of the work and good teams have the capability to overcome conflict—great teams do not avoid conflict. I also noticed that the team did not have structure and practices for decision-making.
9.2 Investing in team skills
I decided to take the topic up in the next team meeting and I asked everyone to describe their feelings about it. This released some of the pressure, team members were able to discuss the topic and agreed that team dynamics needs attention.
The next offsite planning day was luckily a face-to-face meeting, right before summer holidays. In our previous coaching assignment, we had used “My User Manual” exercise [Kailanto] to build vulnerability-based trust and we decided to give it a go also at Roche. The exercise is a quick and fun way to introduce oneself for other team members and it was well received also in Roche teams. That started the teamification process and opened people to talk about “softer” topics in their team, such as personal style for asking help. Another topic was decision making in the team: for example how work is divided, who decides project priority etc.
We continued the process in the following team off-site after a few weeks. This time the topic was team stages per Tuckman model [Tuckman] and vulnerability-based trust [Lencioni]. I also ran an exercise where the team created guiding principles for their work using “Team user manual”, a chartering canvas created by Reaktor.
9.3 Results
After one “teamification” workshop, also other teams wanted to have similar sessions. Turned out that the company goal for self-organising teams required that people understand teamwork better, otherwise Teal teams do not happen. Teams would remain as mere working groups. By the end of the assignment, I did seven workshops for disease area teams and communities.
Teamwork is the most important element in successful organisations. We learned that in order to succeed, the teams need to have skills to work as a team and the structure in the organisation needs to support teamwork. Furthermore, leadership needs to promote teamwork-related mindset actively. If any of these conditions is missing, teams do not happen. Without a compelling goal about teamwork, teamwork feels fake. And without the needed skills, Teal remains wishful thinking.
Teamwork requires attention and a conscious decision from everyone to work as a team. In the workshops we gave teams tools so that the company-wide desire for autonomous, self-organising teams really happens.
10. Heading for Exits
At the later parts of our assignment, our goal was to make teams and the organization capable of continuing improving their own agile practices by themselves.
We finalised Scrum baseline and reviewed it with Country Leads. We felt that it worked very well that we had quite a big say here, although the standard coaching approach would be to get the teams to write the baseline by themselves.
We also prepared scripts for Scrum events. We did the first rounds of facilitation, but then we gave scripts to Scrum Masters and asked them to facilitate, following the steps we did the last time. This worked great—it removed a lot of uncertainty from what is supposed to happen in sprint review and gave confidence to start facilitating by themselves instead of depending on coaches.
11. What We Learned
Being Agile needs structure and Scrum provides it. However, one needs to be very careful when doing Scrum. Tailoring may feel attractive, but dropping or changing elements of Scrum can result in unwanted consequences. At Roche, such an example was replacing Sprint Review with Sprint closing: the goal was to reduce meetings and optimise team’s time but actually it removed an important feedback loop and increased work when a separate Stakeholder Review was introduced.
Enforcing some new practices helps people learn. At Roche, coaching was welcomed, and managers were expected to be more coaches than supervisors. But mere coaching, asking questions and letting people figure out a solution, may not solve the problem if people lack capability or knowledge how to go forward. A stronger intervention, for example suggesting a solution, is faster and allows the team to focus on more important topics. Scrum Baseline and script for Sprint Review were such interventions: we suggested a structure for work so that team members can focus on the substance.
Focus brings clarity. Overload needs to be addressed right away. If teams are overloaded, they will not have time or motivation to stop and think how to improve. Overload is a systemic problem and it can not be solved locally. Such attempts (such as “everyone should manage their own workload”) are doomed unless some system conditions are changed. At Roche, such system condition was the number of Sprint Goals. By limiting number of Sprint goals, we reduced the amount of work in Sprints and disallowed people outside the team to push their needs into the team.
Becoming a team requires work. Strong, autonomous teams require three things: (i) No dependencies between teams, (ii) compelling goal regarding teamwork and (iii) skill to work as a team. Roche designed teams so that there were no dependencies between teams and they invested a lot to Teal culture. For the skills part Roche needed support: the desire to be Teal was strong but teams felt that they were left alone and without sufficient skills to build strong teams.
Being humble is important. We consciously decided to help people and teams rather than enforce Scrum. In the feedback sessions when we were leaving Roche, a couple of positive things came up constantly. One was our humbleness and eagerness to listen to them, their knowledge about their business area and their concerns about agile methods, despite the fact that we clearly knew a lot about Scrum practices and working agile. Quote from one of the team members: “I really appreciated that you respected why we do things in certain ways and also adapted your own approach, instead of just trying to force us to do Scrum by the book.”
Roche puts effort in scaling up good practices and sharing experiences. One great learning for us was “Scrum Walk”. It is a quarterly get-together where teams exhibit their working practices. Scrum Walk was literally a walk when people were at the office and visited other teams’ work spaces. After switching to remote work, Scrum Walks continue as an online event. I (Sami) have already used this concept with other large organisations to improve the flow of information between teams.
What about our initial curiosity: how a company in a regulated environment can do Scrum? What is their potentially shippable product?
We witnessed that Scrum works in a non-software company and in a regulated environment. Scrum brings structure to work, encourages collaboration and makes teams and the organisation faster by pushing decision making from top of pyramid to teams. This was noted by Roche personnel in their company-wide Retrospective, as they mentioned Scrum and autonomous teams being the #1 reason for being capable of adapting quickly to Covid-19 restrictions.
Contrary to our belief about heavily regulated industries like pharma, regulation and compliance was not an issue, at least what comes to agile transformation and using Scrum. Regulation and compliance do exist, but they were taken as part of life, as a given to the organisation. This turned out to be a great mindset in transformation: if something is beyond the sphere of influence then it does not help to complain about it.
Regarding Potentially Shippable Product, Roche teams did not have a clearly defined Product that they work on. Product is a key element in Scrum: Product Owner, Product Backlog and Product Increment all require that team(s) have a Product that they develop. Since Roche used Scrum for organising work rather than delivering a project, they had to work around “potentially shippable product”. In practise teams agreed Definition of Done for all work in Sprint. DoD described the outcome that the team is aiming to achieve in a Sprint, it answered the question “how far we go in this Sprint?” DoD also defined how to present the outcome in the review. This is a concept we plan to use in our future coaching as it helps team to focus also when Product is not applicable.
What do we think went well in this assignment? Listening and caring for people worked. It also paid back to be a bit enforcing at certain times. We tried out different things and quickly dropped what was not working. It was good that we started to contact people more directly. We’re really happy that our idea was always to make Roche people capable of facilitating and improving the practices by themselves, instead of becoming reliant on us being there.
What do we think we could have done better? Being more explicit about trying certain working practices like WIP limits. Having more courage to directly contact people and suggest different activities. We also now have a better understanding about how to balance between structure and liberty through the enabling structures, so we will be even better equipped to use that same approach next time.
12. Acknowledgements
Thank you so much Marita for writing this together with us and trusting us with the assignment in the first place. Thank you Scrum Masters, POs and everybody at Roche for working with us and being eager to improve. Thank you Maturin Tchoumi for your insightful and thoughtful sponsorship of the agile mindset at Roche. Thank you Nathalie Hammering for pushing us to make this report as good as possible and for all the comments and effort you put into it.
REFERENCES
[LaLoux] Laloux, F.. “Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness”, Nelson Parker, 2014.
[Brougham] Brougham, G. The Cynefin Mini-Book, lulu.com, 2015.
[Kailanto] Kailanto, J. https://coachjarkko.com/2018/04/17/personal-user-manual-tells-others-how-to-work-with-you/
[Tuckman] Tuckman, B. W. “Developmental Sequence in Small Groups”, Psychological Bulletin, Volume 63, Number 6, Pages 384-99.
[Lencioni] Lencioni, P. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass, 2002.
