There is hardly a topic thats more misunderstood than “Managers Role in Agile.” This is sometimes because various Agile frameworks like Scrum do not mention the word “Manager” and others like XP treat at as a purely optional role. All the emphasis is on a self functioning team - figuring out how best to do its work. However, we believe that even within the set up an XP or Scrum workplace, there is a place for the manager. Some of these responsibilities are clearly assigned while others are ones we have found useful.

Mapped Managerial Role Responsibilities :

• The best way to explore managerial role is to understand the dynamics of leadership required for an Agile Project. The three broad areas outlined are marketing leadership, process leadership and technical leadership.
• The marketing leadership is best represented and served by the product owner. The product owner is responsible to draft, defend, articulate and update the products specifications/ features/ requirements. She is the final word on what is to build and when. She should ideally have a deep understanding of what would the customers value. The product failure because it could not stand the test of the market or the customers did not like the product is a product owner’s failure. Product owner in essence controls the pivotal aspect of the product - what is being built, why is it being build and when is it being built. As discussed in the post on product owner, she may take the team’s input but thats only one aspect of the advice. She would listen to customers, conduct marketing surveys, stakeholders, research on product’s features and prepare cash flow plans.
• The process leadership is best represented and served by the Scrum Master or Process Coach. The Scrum Master would be responsible for the success of the Scrum Process. She would ensure things like whether a product backlog exists, whether sprint planning is being conducted, are sprint retrospectives surfacing problems and also conduct a daily stand up for the team. The roots of Scrum Master in servant leadership. The team is Scrum Master’s project and she has to ensure and do everything in her power to make the team successful in working together with Product Owner in developing a quality product.
• Self Organizing Team is responsible for delivering increment of functionality. The team would work with each other, divide tasks, commit to deliverables, ask any questions and pick up practices to do the work. The important aspects are for the team to identify, volunteer, commit to the various practices. The team is the one responsible for delivering the work - its either a 100% done or 100% not done.

Now that we have seen what are the main roles and responsibilities. Now let’s see what does a formal manager do in Agile. It is useful to take XP’s approach. The role of a manager although important but optional. Here are some of the approaches for transitioning a traditional manager  in an Agile environment:

• Become a product owner or scrum master
• Become a Manager 2.0 - we will touch on this in detail in our next post but for now lets just consider these points:
  • Managers continue in their existing role but do not do things that are not as per Agile values and beliefs. The easiest to identify in this case are things like task breakdown, task assignment, task tracking etc.
  • Managers add/ enhance some aspects which will help implementation of Agile. The easiest to identify in this case are things like providing feedback, amplifying learning, educating customers about Agile, functioning as technology or product or process Guru’s, working on next generation products, help Agile scale etc.
  • Managers edit some part of their responsibilities. For instance, customer interaction could mean that they work with customers to define their requirements better, work out business case, define the release schedule, work on competitive advantage of customers, become customer’s value partners. It is important to note that stuff like task management is not included here. Rather, manager can work as a customer proxy and managers then move towards a product owner profile. Similarly, feedback can be restructured on a weekly basis and help people define and attain their goals as well as help facilitate 360-degree feedback [probably keeping their feedback as advice] where the manager provides information as outlined by Esther Derby and other management gurus rather than assess people’s performance.

In our next post, we would discuss what managers typically do and how can they make the transition to become Manager 2.0

Popularity: 7%

Posted on April 26th, 2008 by admin
Filed under: Maturity | No Comments »

In our previous posts, we have emphasized the importance of a self organizing team. Self organization is a simple concept.

• A team is formed and a deadline is worked out.
• The team picks up what it can do in this deadline and off they go building what they committed and at the deadline, they demonstrate working software.
• During the time period between commitment and deadline, the team works together, finding out how they want to track progress, develop, collaborate, divide tasks and everything else that needs to be done to meet the deadline.

The key question is why would this work? It does because the commitment is team’s commitment. In traditional management styles, the management negotiates a deadline, commits the same, decides what all should be done in this time and then tells the team to go do it. This is a bit counter intuitive. The people who are doing the work should know the best on how to do it and how much time it will take to do it. Another reason why this works is because the team has a deadline to deliver quality working software. This means anything that does not contribute towards this end mission [any practice, any team configuration, any team member] is gradually taken out. This also works because the feedback loop is now directly between the team [responsible for building the right product] and the product owner [responsible for constructing the right product feature set].It is important to understand what does “Left Alone” mean here. The team is Left Alone in the sense that no one tells them what methodology to use to transform the requirements into functionality and there is no one but the team to blame if the team fails and also there is no one to bask in the glory other than the team if it succeeds. It is solely and utterly the team’s responsibility to figure out what to do, and to do it. However, there are some basic checks in place - they have to deliver what they commit or let the product owner know if they won’t be able to [and this should happen less and less as the project progresses] and they can ask the management for help in meeting their target [more people, training, removing obstacles etc.] Other than that the team collectively brainstorms and works to meet its commitment. The team self-organizes.

Now that we have discussed, what self organization is, it is important to note some Scrum and XP practices which help foster this self organization.

• Whole Team - The whole team is “whole team”. Everyone required to be involved in converting the features into functionality is a part of the team. If it means copywriters, designers, developers, testers and business analysts all have to be in one team - then that is it. The team also includes the Process Coach or Scrum Master. There may be a a manager as well who would be responsible for logistics, communication and coordinating activities. The idea of the Whole Team comes from eXtreme Programming. XP in fact goes a step forward and also includes the customer as a part of the Whole Team.
• Generalists - A team with Generalists [sharp, efficient, collaborative people] tends to better at self organizing. Why would this be so? This is because the team picks up work, identifies what is needed and sometimes something would be needed and on other times, something else. For instance, on some days, you might need more testers and on some days more analysts and on still others, more programmers. Specialists are unable to change gear while generalists [assuming your hiring practice is good], are able to change gear and collaborate to get things done. This is in keeping with the notion of creating a champion team rather than team of champions.
• Daily Stand Up - The daily stand up is opportunity for the whole team to collaborate and check the progress. They also identify where the most effort needs to be put in and if they are on the target to achieve their goals.
• Big Visible Charts - This is not something we have discussed so far. However, this is a powerful unifying tool. The team sees at all times, what is pending, what has been done and what is still pending to do. This allows them to plan their work better and also volunteer for more work and see who needs help. It is useful to note that if the team knows that either all of them fail or all of them succeed, big visible charts help the team see the tasks that are still to be done and plan for them.
• Flat Hierarchy - It is pretty obvious that if the team is left all to itself but one or two people are deciding what they should do and how they should do it, the team would fall into command and control again. Rather, the team has to be like a crack sports team which can organize itself beautifully depending on the current match situation.

Now that we have discussed about self organizing teams, it is important that we understand when is the team self organizing.  As per Wikipedia, self-organization is a process of attraction and repulsion in which the internal organization of a system, normally an open system, increases in complexity without being guided or managed by an outside source. Self-organizing systems typically (though not always) display emergent properties. A key characteristic that is generally overlooked is that “something is self-organizing if, left to itself, it tends to become more organized.” A team would not inherently become more organized if left “totally” on its own or without components that we talked about earlier. Without proper leadership or an organization structure that does not support self organizing teams, this would not be possible. Also, the move towards self organizing teams is an ever evolving theme and any equilibrium would be temporary. A single most important fact which management in Agile needs to learn is how to create such self organizing teams/ units. We will touch on this in our next post.

Popularity: 10%

Posted on April 21st, 2008 by admin
Filed under: Collaboration, Maturity, Practices | No Comments »