Andrew T. Pham

Even if you have learned that there is no project manager on a Scrum project, that does not mean that there is no management, or especially, leadership on a Scrum project. This misconception was corrected in a discussion by Scrum Alliance‘s board member Mike Cohn posted Aug 25, 2009 on InformIT.
Unlike the traditional command and control environment, management responsibility is now split among the three different components of the Scrum team: ScrumMaster, development team and product owner. Although the ScrumMaster and the product owner do not directly manage the team, they are responsible for project reporting to the management of the business. This is true, according to Ken Schwaber in Agile Project Management with Scrum, even if we no longer report by tasks on a Scrum project but only by requirements.
Anyone can be considered a leader on a Scrum project as long as that person has some influence over the team. To the surprise of some purists and our delight, in his blog, Mike Cohn mentioned product owner, ScrumMaster, and even functional manager, as examples of leaders who can influence the direction and success of a Scrum project. But to paraphrase what Mike Cohn wrote on his blog, there is more to leading a self-organizing team than buying food or letting the team do what they want. Leaders on a Scrum project should influence teams in an indirect way. Welcome to Andrew Pham and Phuong-Van Pham, that wrote Scrum in Action: Agile Software Project Management and Development in 2011.
Even though their discussion that follows is somewhat different from the CDE (Container, Difference, Exchange) discussion on how to lead a self-organizing team in Mike Cohn’s excellent book, Succeeding with Agile Using Scrum it does share a common premise in that the Scrum project team requires quite a bit of management and leadership to work, contrary to popular beliefs. A well-known technique for coaching, one of the preferred techniques used by servant-leaders to enhance a team member’s performance, is known as the GROW model (which stands for Goal, Reality, Options, and Will).
In order to be a good leader or a true manager, the authors think you should be:
- Honest: Honest means that you should say what you do and do what you say. Because no one is perfect, people will not hold a grudge against if you sincerely admit your mistakes; on the contrary, they will respect you more for your honesty. And if people respect you, they will be more likely to follow you than someone they do not respect.
- Open: One of the most important character traits of a leader is to be open to people’s ideas and opinions. Do not shut down any suggestion coming from the team or from people around you without first reviewing its merits.
- Authentic: This means that you should not try to behave in a way that is not true to your values and beliefs. In other words, you do not try to play games by pretending to be someone you are not.
- Available: We are all busy in corporate environments, but as a leader people expect you to be available to give them advice, listen to their concerns, and to give them feedback or clarification about something they do not understand well.
- Caring about others: In a society where success and promotion are key words, it may be hard to ask you to care about others. But when you think about it, it is ultimately your success that you are taking care of when you help your team members succeed at what they do.

Pham & Phuong-van Pham discuss the important role of product owneras well. The seven qualities of a great product owner are:
1. Know how to successfully manage the stakeholders’ expectations and sometimes conflicting priorities.
2. Have a clear vision and knowledge of the product.
3. Know how to gather requirements to turn the product vision into a good product backlog.
4. Be fully available to actively engage with the team, not only during the sprint, but also during the release and sprint planning.
5. Be a good organizer who can juggle multiple activities, while keeping things in perspective and maintaining her composure.
6. Know how to communicate the product vision; not only to the team, but also with the business, so their trust in the team remains intact throughout the life of the project.
7. Be a good leader, able to guide, coach, and support the team as needed while making sure that the business gets the value they expect out of IT.
Closest to home for a project manager is the role of the product owner, as you may agree with me.

The authors have more to bring to the table. Finance speak to get buy-in from management. A visual gathering of requirements. To verify that the requirements (user stories or PBIs) are properly written and ready for development, the product owner and the team can use the CUTFIT rules. These rules require that the story point be consistent, unambiguous, testable, feasible, independent, and traceable.
As a consequence of Scrum success, more and more companies are contemplating rolling out Scrum to their entire IT department. One of the impediments to this is the fact that the story point value is unfortunately not comparable between teams.

The authors offer a new technique based on an objective criteria-based estimating process in the form of a series of relatively straightforward tables to guide the team in their effort to estimate the different stories or PBIs. As simple as it is, this method allows us to make objective comparisons among teams as well as among different members of the same Scrum team.
As software professionals, many of us are accustomed to doing a lot of architectural design using all kinds of tools. Then along came eXtreme Programming, which dictated that we should only design as we go. The success of Scrum seems to have amplified this phenomenon.
But as lessons start to emerge from Scrum projects, it has become clear that without an architecture vision, the chunk of user stories the teams get from the product owner will look like a stack of cards, without any clear idea of what the final product will look like. With a clear architecture vision laid down at the beginning, one observes that team velocity does not fluctuate much, but instead increases over time. To arrive at this architecture vision, we must first identify user stories that share common business data and consider building them together. By splitting the user stories along common business data elements, the team will be able to organize their work and develop in parallel. This is something many software managers have dreamt of because they see the potential benefit it can be to team performance.
Working with common business data also allows the team to lay down some sort of stable data architecture, a key ingredient to good data reporting and analytics. Another benefit of this is to allow the product owner to change the project’s sequencing without negatively affecting the team’s velocity.
The authors share their wisdom on other topics as well, such as adapting Scrum, when to have a Scrum Master, automated testing, teamwork and the question whether you can have an abnormal end of a sprint. Scrum in action is a must have on your journey beyond the Scrum bootcamp.… (more)