4squareviews

In Chapter 4 of the Agile Practice Guide, the three typical roles seen on an agile team are described.   Here are my notes from the description on p. 41

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 are these team roles structured in terms of relationships with each other?   That will be the subject of the next few posts.

Filed under: Uncategorized | Leave a comment »

In the discussion in chapter 4 of the Agile Practice Guide about setting up an agile environment, the discussion centered first on the role of the servant leader vs. the role of the traditional project manager.

Before going through the actual individual roles on an agile team (the material on and after p. 40), the Guide goes through some characteristics that the most effective agile teams have.

1. They tend to range in size from three to nine members in order to maximize collaboration between members.
2. They are co-located in the same space–again, to facilitate communication and interaction between members.
3. Team members are 100% dedicated to the teams, and are relieved from having to “multitask” during the day between multiple projects.   The team has all the necessary skills to deliver completed work.
4. Teams are self-managed, where team members themselves decide who will perform the work within the next period’s defined scope.
5. As mentioned in earlier posts, the leaders support the teams’ approach to their work, rather than directing it (the “servant leader” role).
6. They produce functional product increments frequently.
7. They have a limit on the WIP or work in progress, so its members can expedite work.
8. They do not take a waterfall approach, that is, addressing all of the requirements in a given period, THEN tackling the design, THEN doing the building, THEN the testing.   The reason is that some of the assumptions behind the requirements may have changed and then all of that work is wasted.   Rather, the team members collaborate on a small number of features across the board, and work on delivering smaller finished features.
9. Agile teams work to collaborate in various ways, and use feedback from retrospectives to alter their way of doing things if necessary, focusing on the result more than the process itself.
10. Agile teams bring a mixture of generalists and specialists, with the aim of producing “generalizing specialists” who have a focus specialty plus breadth of experience across multiple skills.

In the next post, I will go over the material starting on p. 40 of the Agile Alliance Guide that talks about three common roles in agile teams.

Filed under: Uncategorized | Leave a comment »

In the fourth chapter of the Agile Practice Guide, there is a discussion on implementing an agile environment.

After going through the material on the role of the servant leader (which may be called different things in different agile frameworks, such as a “scrum master” in Scrum), and contrasting that role with that of the traditional “project manager”, the Guide then talks about the agile team–its composition, interactions, and various identifiable roles.

This post will cover the composition of an agile team.   Agile optimizes the flow of value, and a team should be structured in such a way as to maximize this flow by rapidly delivering features to the customer.

If this flow is maximized, then the following good things happen:

• People are more likely to collaborate
• Teams finish valuable work faster
• Teams waste much less rime because they do not multitask.

An example of this flow maximization in an agile vs. a traditional project management environment comes from a story from the book The Culture Code by Daniel Coyle.   He describes how a task was given to a) a group of kindergartners and b) a group of MBA students.   The task had to do with creating a stable structure using nothing but a box that contained toothpicks and marshmallows.

It was the kindergartners who finished the task first.   Why?   The group of MBA students spent a lot of time defining the goal, and then deciding who would take on which role.  The kindergartners essentially dove right in to the task without worrying about who had what role.   In addition, they were highly interactive, giving congratulatory remarks on someone who was able to complete part of the structure, or comforting someone whose part of the structure collapsed and encouraging them to try again.   It was the increased collaboration and the ability to work faster that caused them to outperform a group of people with vastly more amounts of formal education.

I’m not saying that the lesson to take from this to go out and hire a bunch of kindergartners for your next agile project; however, you could learn something from the way they cooperate with each other and encourage each other while reaching a common goal.

The next post will cover in more detail the composition of agile teams and how the members of the team should interact with each other.

Filed under: Uncategorized | Leave a comment »