The Culture of Agile–Dismantling Silos


In the last three posts I described the three elements of the culture of agile as described in the fourth chapter of the Agile Practice Guide.   These are

  • self-organization
  • 100% dedication (i.e., team members’ time not split between other projects)
  • co-location (having access to a common workspace)

When I was the Director of the Executive Council at PMI Chicagoland, we talked about the creation of an agile culture and what threatened it within the organization.   One of the executives said, “well, you can create an agile culture on a team, but when you try to re-create that culture in the organization at large, watch out for the corporate antibodies that start to attack!”

What he was saying that the culture of the organization at large may be traditional, and creating a sub-culture within an agile team is all well and good, but the larger culture of the organizational may see this as a threat–in the analogy to the body’s immune system, the agile culture may be seen as a “foreign” or outside entity that the body needs to protect against.

In asking this executive what the main element of organizational culture is that perceives agile as a threat, he replied “organizational silos.”  I remembered that when this discussion came up on p. 47 of the Guide on “Overcoming Organizational Silos.”

How do you create an agile culture?   According to the Guide, “by building a foundational trust and a safe work environment to ensure that all team members have an equal voice and can be heard and considered.”   One of the names of this kind of organizational structure is a “heterarchy” where everybody is at the same level of power.   This is opposed to a “hierarchy” where certain members have more power than others, and this is often what you generally have in an organization that is divided into different silos or specialties.   On a traditional project that has a balanced matrix structure for example, you have the team members on a project who report on the one hand with regards to their project work to a project manager.   Their main work in the organization, however, comes from a particular department where they have a functional manager overseeing their everyday work for the company.   This often creates a tension within the team member of dual loyalties both to the project and to the larger operations of the company.

In agile, this is avoided by having the various functional managers who give team members to the agile project allow their members to join the project and dedicate all of their time to it for the duration of the project.   The loyalty now is not to a project manager, as in a traditional project, but to each other, the members of the cross-functional team.

Once the project is done, the organization at large can see how leveraging its people can optimize the project or product being built.   However, there is another advantage to the organization that is trying to adopt agile culture and that is to learn from the synergy of the team on that project and use it to try to dissolve the impediments that the organization puts out for cross-functional agile teams.

That is the way in which agile culture can affect the culture of the organization as large–not in the sense of destroying that overall culture, because that attitude is what causes the “corporate antibodies” to reject agile culture.   Rather, it should be seen in the light that agile culture “transcends and includes” the culture of the organization at large.  Yes, there are hierarchies that are unavoidable in many companies, but having the “heterarchies” of agile teams loose in the company may cause the silos to have greater communication with each other, and more empathy for what each of them needs.

In this way, agile culture can truly be transformative of the corporate culture as a whole, rather than being seen as a threat.

This was the last post on Chapter 4 on Creating an Agile Environment.  The next post will start with chapter 5: Delivering in an Agile Environment.  The first post will be on what a project charter, an essential document in traditional project management, looks like in an agile environment.

The Culture of Agile–Colocation


In the fourth chapter of the Agile Practice Guide which focuses on implementing an agile environment, after discussion on p. 40-42 of the various roles on an agile team, there is a discussion of the various values promoted by an agile culture.   In this context, you can take “culture” to mean the various qualities of the interactions between members of that group.   So what qualities does agile recommend in order to have a successful team?

These qualities are:

  • self-organizing (working out problems as a group rather than expecting a leader to assign people work)
  • dedicated team members (striving to have team members working exclusively on a single project rather than than dividing their time among a lot of projects)
  • colocating (having a common workspace where meetings can take place to monitor progress on the project and to discuss solutions to any impediments that may come up)

In the last post, I discussed the quality of dedicated focus as it applies to an agile team, meaning that is best when team members’ time is 100% dedicated to the project.  In this post, I will discuss how there should be a space that is 100% dedicated to the project.  This means that there is some common meeting place where all members meet to exchange information and work on solutions to problems.   To do this, the members have to work in the same general location, and this value is called co-location.

The ideal situation is to have a social area where members of the team can meet to have stand-ups, retrospectives, or any other type of meeting required.   It should have private areas where small groups of the team can split off and work out any problems that may arise in executing the tasks of the project.

However, this ideal is not always achievable.   Geographically distributed members need to manage their communications with the “home team” so that the team can learn to trust each other and work together as effectively as if they were physically present.  How can this be achieved?

Well, the Agile Alliance recommends two things:

  • Set-up video conferencing links between the various locations where the team is dispersed.   Start the link at the beginning of the day, and keep it open during the day so that the various members can communicate spontaneously with each other.
  • Set up remote pairing by using virtual conferencing tools to share screens, including voice and video links.   This may prove as effective as face-to-face pairing.

There are two common attributes to these links.   They a) include a video component because you can tell a lot more than communication through an e-mail or even through a telephone call; and b) always open so that they can be used spontaneously whenever problems arise.

These three elements I mentioned at the top of the post–self-organizing, dedication, and colocation–are essential for the creation of an agile culture.   However, if the organization itself is more of a traditional mindset, there will be resistance that comes from the organization.   As an executive put it once from the Executive Council of the PMI Chicagoland chapter, “the corporate antibodies will attack any foreign body that tries to spread any contrary message.”   The antibodies in this case take the form of organizational silos.   These impede the formation of cross-functional agile teams.   How to overcome this corporate resistance will be the subject of the next post.

 

The Culture of Agile–Dedicated Team Members


In the fourth chapter of the Agile Practice Guide which focuses on implementing an agile environment, after discussion on p. 40-42 of the various roles on an agile team, there is a discussion of the various values promoted by an agile culture.   In this context, you can take “culture” to mean the various qualities of the interactions between members of that group.   So what qualities does agile recommend in order to have a successful team?

These qualities are:

  • self-organizing (working out problems as a group rather than expecting a leader to assign people work)
  • dedicated team members (striving to have team members working exclusively on a single project rather than than dividing their time among a lot of projects)
  • colocating (having a common workspace where meetings can take place to monitor progress on the project and to discuss solutions to any impediments that may come up)

In the last post, I discussed the quality of self-organizing as it applies to an agile team.  In this post, I will discuss the quality of being dedicated to a project.   Here I mean that the team members’ time is dedicated 100% to the project.   This goes against the trend of multitasking, where a person switches from project to project in the course of a day.

Why is multitasking discouraged in agile teams?   For the simple reason that it lowers productivity.   Many people do not realize by how much it reduces their productivity.  Here are some facts I found on the website Productivity Theory

 

  • Even short periods of mental blocks caused by alternating tasks costs between 20 to 40 percent of one’s productivity, according to a study at the University of Michigan’s Brian Cognition and Action Laboratory.
  • If you’re immersed in a task, such as writing a report, and an email notification distracts you, know that it can take you up to 25 minutes to become deeply absorbed again in the task, advises Dr. Julia Irwin, a senior lecturer of psychology at Macquarie University.
  • Other studies report evidence against multitasking as a desired skill. The University of London found that those who multitask during cognitive activities had an IQ drop similar to if they’d pulled an all-nighter or smoked marijuana, averaging ten points. Men who multitasked saw drop of 15 points, communicating with the average mental faculties of an eight-year-old.

(See the website at https://productivitytheory.com/multitasking-lower-iq/ for more information.)

This is why the agile ideal culture is where everyone the team is 100% allocated to one project.

Based on this information, we know now that the team needs to be focused in time to be at maximum efficiency on the project, but they also need to be focused in space.   That is the subject of the next post, on the third value mentioned at the top of this blog post, namely colocation.

 

The Culture of Agile–Self-Organizing Teams


This is a discussion of the main qualities of the culture on an agile team, based on the discussion in chapter 4 of the Agile Practice Guide.

Reviewing from the previous post, the main elements of agile culture are:

  • self-organizing (working out problems as a group rather than expecting a leader to assign people work)
  • dedicated team members (striving to have team members working exclusively on a single project rather than than dividing their time among a lot of projects)
  • colocating (having a common workspace where meetings can take place to monitor progress on the project and to discuss solutions to any impediments that may come up)

Let’s talk about the first element, that of self-organizing teams.

If you have worked on a project as a project manager using traditional methodologies, the biggest culture shock you experience when starting to work on a project using agile methodologies is the command structure.   Rather than waiting for assignments from the project manager, the team members not only do the work, but they divide the work up among themselves, based on their own experience and their affinity towards the various parts of the work that need to be done.

My first experience of a self-organizing team was not at work, but at home during a family crisis.   My father was getting ready to go in for surgery on his gall-bladder after a severe attack.   It was a Friday when he went in to the hospital.   I saw him on Saturday and, other than the pain he was experiencing, he was in good spirits.   I told him I would come in and see him again on Sunday after I got out of church.

I was just about to step into the car on my way to the hospital when my sister called me to say that, 15 minutes ago, our father had suddenly died.   The nurse was actually in the room tending to the other patient when she heard my dad cry out and when she opened the partition between the beds she saw him, trying to sit up as he clutched his chest and calling out my mother’s name–then he collapsed, and … he was gone.

I was on my way to the hospital anyway, so I told my sister I would meet her there.   I went to the hospital and said my goodbyes to him, and then sat in the chair waiting for them to give me some paperwork to sign.   I always have my planning notebook with me so I took it out and started sketching what my siblings and I would have to do to prepare for the funeral.

When my sister came in, and we hugged and cried together a bit, she went to visit with him one last time, and as she came over and sat down beside me, she noticed I was writing in my journal.   She asked me what I was doing, and I said I was starting to put together a list of all the things we would have to do to get ready.   She looked it over and said, “do you mind if I add to the list?”  That was her polite way of saying, “hey, you missed a spot.”   Well, that occupied her while I went over to talk to the nurse to get ready to call the funeral director.

In the meanwhile, my younger brother came in, and he ended up adding to the list.  Now that we were gathered together, we called my older brother who was in living in California to relay the bad news to him.    Eventually, after dealing with the emotional impact of what had just happened to us, I mentioned the “funeral project” to-do list we had been working on, and my older brother asked us to send it to him so he could contribute as well.

After he sent it back to us with his additions, we had a conference call and divided up the work.   As you might guess, those items which people cared about the most and added to the plan were the ones most often that they chose to take care of.

I thought about how our “funeral project” felt different than other projects where I was a project manager.   Well, first of all, I wasn’t in charge–we all were sort of in charge, at least of our portion of what had to be done.   I laughed when I thought about what my siblings would have said if I had asked to be the project manager–they never obligingly took my orders for them to do things when I was a kid, and there was very little chance they would start doing so now that we are all adults.

But the other difference was, the fact that we all chose the work we wanted to do, while still being willing to help the others out if they needed it, meant that we worked cohesively as a team.   The work actually brought us together and, of course, brought us together with all the friends and extended family whom we invited to the funeral.

So I experienced the culture shock of being on an agile team under circumstances that were emotionally very trying, but for me the cohesiveness of our little team blunted a lot of the emotional trauma that I might have experienced if I had been facing it alone.

I thought that if my father’s consciousness did survive death, he would have been proud to see us working together, like the many times he and my mother would stand poised outside the living room watching us having fun together playing a board game.  My father was now gone and, my mother having passed about a dozen years ago, we were now truly on our own.   But we still remained a family nonetheless, and that’s what I remember of my first experience being on an agile team.

The next post will cover the second element of agile culture:  dedicated team members.

The Culture of Agile


In the fourth chapter of the Agile Practice Guide which focuses on implementing an agile environment, after discussion on p. 40-42 of the various roles on an agile team, there is a discussion of the various values promoted by an agile culture.   In this context, you can take “culture” to mean the various qualities of the interactions between members of that group.   So what qualities does agile recommend in order to have a successful team?

These qualities are:

  • self-organizing (working out problems as a group rather than expecting a leader to assign people work)
  • dedicated team members (striving to have team members working exclusively on a single project rather than than dividing their time among a lot of projects)
  • colocating (having a common workspace where meetings can take place to monitor progress on the project and to discuss solutions to any impediments that may come up)

Of course, these are the ideals, but not every organization can live up to them 100%.   The Agile Alliance recognizes this, and tries to suggest alternatives for organizations that cannot achieve these ideals in their purest form.

I will take up each three of these qualities suggested by the Agile Practice Guide in the next few posts–both the ideals and the suggestions for working alternatives…

A Generalist vs. A Specialist: Which is Better in Agile?


This is a discussion contained in a sidebar on p. 42 of Chapter 4:  Implementing Agile in the Agile Practice Guide.

The letter “I” is long, but not wide, and so a “I-shaped” person, metaphorically speaking, is someone who has depth within a certain domain of knowledge, but not contribute that much outside the domain.

The letter “T” is wide at the top, and so a “T-shaped” person, metaphorically speaking, is someone who has expertise in one area, but adds to that with less-developed skills in associated areas, and most importantly, good collaboration skills.   This allows them to help other people when and where necessary.

My guess would be that a “T-shaped” person is more suited to the role as a team facilitator, and that an “I-shaped” person is more suited to the role of being a team member.   A product owner would be somewhere in between because that person has to have enough skills in the domain that the product entails, but also has to have enough expertise in business so that they can take the technical work and prioritize it according to how much business value it adds to the customer.

In the next post, I will cover the next topic which is the recommendation by the Agile Alliance regarding how the team members do their work.

Agile Team Role Capabilities


In the last post, I went over the three main agile team roles;  cross-functional team members, product owner, and team facilitator.    These are mentioned in Chapter 4 on Implementing Agile, as part of the The Agile Practice Guide put out by the Agile Alliance.

In this post I am listing what the capabilities are of the people who should fulfill these roles.

  1.  Cross-functional team members–they should have the professional experience to deliver potentially releasable product on a regular basis.  On a software development project, for example, there should be designers, developers, and testers.   They should have a focus specialty plus a breadth of experience across multiple skills.   This is why the Agile Practice Guide consists “generalizing specialists” to be best suited to this role as a team member.
  2. Product owner–this person should have business background so that they can focus on prioritizing the work according to how much business value it brings to the customer.   The result is the product backlog, which the product owner manages to help the teams deliver that business value.
  3. Team facilitator–rather than focusing on the features of the product (the results), the team facilitator focuses on the process itself, and helps serve the team by facilitating, coaching, and removing impediments.   To do the latter, they need to have strong relationships in their organization.

The product owner and team facilitator have complementary roles that face the team and the customer, respectively.

The phrase “generalizing specialists” may seem to be a contradiction in terms, but it is explained more fully in a sidebar on p. 42 in the discussion of “I-shaped” versus “T-shaped” people.  That is the subject of the next post.