4squareviews

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.

Filed under: Uncategorized | Leave a comment »

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…

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

From the last post, here are the three common roles found on an agile team:

1. Cross-functional team member–in keeping with the non-hierarchical structure of the agile team, the cross-functional team member is mentioned first, and NOT the product owner or team facilitator.   They are professionals who deliver potentially releasable product on a regular basis.   They need to deliver work in the shortest possible time, with higher quality, without external dependencies.
2. The product owner interacts with the customer and stakeholders as well as the team, and they pay attention to the highest value for the customer. They typically have a business background and have deep subject matter expertise.   They create the backlog for and with the team, in a way that delivers the highest value without creating waste.
3. This role can be called various names, such as a project manager, scrum master, as well as a team lead, couch, or facilitator.  The servant leader, no matter what he or she is called, needs to focus on facilitation of the work done by the team, impediment removal, and coaching.   If the servant leader feels their internal coaching capability is not yet fully developed, then they may invite external agile coaches.

How do they interact with each other, with the customers for whom the project is being done, and the organization which is doing the project?

Well, bear with me on this, but an analogy came to me yesterday while I was taking a shower–it’s like how soap works to get things clean.   A soap molecule must combine water and the substance that is being cleaned, including if it is covered in something oily like grease, and essentially have the water molecules carry away the dirt off the surface being cleaned.

One problem with this is that water and oil do not normally mix.   The soap molecule has a special structure which is that at one end, it attracts water (it is hydrophilic to use the technical term).   The other end repels water but is compatible with oil because it is itself composed of fatty acids.   The soap molecule, by combining these two properties in the same molecule, can therefore make water and oil mix, causing the oily dirt to be carried away when the water is washed away.

The product owner faces the customers and communicates their requirements to the cross-functional team members.   The cross-functional team members are the ones who are trying to create a solution, so they are, like water molecules, trying to break apart the problems being handed to them by the product owner, who gets them from the customers.  The customers and the cross-functional team members are like the “oil” and “water” that have to work together to get the solution done.

And what causes them to be able to work together, when their roles are so different?   That is the team facilitator (who may also be called a project manager, scrum master, or other designation)–he or she holds the team together by facilitating, coaching if necessary, and removing impediments that would prevent them from working cohesively.

So the team facilitator has to face both the team AND the product owner in order to make sure that the solutions that the team come up with are communicated to the customer so that the customer is pleased with the product.

What types of specializations work best with these three roles?   That is the subject of the following post.

Filed under: Uncategorized | Leave a comment »