Prakash 的个人资料Prakash's - Online Repos...照片日志列表 工具 帮助

日志


12月19日

Retrospectives - What is it and how to get started?

In his famous book "Project Retrospectives", Norman Kerth has defined retrospective as an opportunity for the participants to learn how to improve. The focus is on learning—not fault-finding.

Retrospective rituals are more than a review of the past.  They also provide a chance to look forward, to plot the next project, and to plan explicitly what will be approached differently next time

 

In their book "Agile Retrospectives, Making Good Teams great", Esther Derby and Diana Larsen has defined Retrospective as

"It's a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change, and generate action. Retrospectives go beyond checklist project audits or perfunctory project closeouts. And, in contrast to traditional postmortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so."

 

What a Retrospective isn't?

It is not a postmortem.

Why we call it as a retrospective and do not call it as a Post mortem? Post Mortem is something, which is done on something dead.  We are working on projects which are live. This has to be done at regular intervals.

It is not a Ceremony

Do not do it for the sake of doing it. Identify techniques which can make it fun, so that everyone participates and the team identifies areas of improvement. 

It is not a secret

Its not a meeting where you can point fingers/blame others. The purpose is to identify where the team is lacking and how we can improve as a team. The meeting can include all kinds of stakeholders (provided understands the purpose of the meeting)

It is not session to Whine.

It is definitely not a place to Crib. Emphasis is on being constructive.

It is not a place to blame others

Emphasis is on "I/We". Its not a meeting where you blast your customer side representative or the customer takes it as an opportunity to blast the team.

 

How to run/facilitate retrospectives?

 

Before the Meeting

Setup a Meeting with Team members and all the stakeholders. Its very important that the stakeholders also attend the meeting.  Have a meeting room setup for the discussion.

If your customers are in a different location, setup WebEx/LiveMeeting, Conference (Video Conferencing will be really great. Depends on the availability and Budget :))

 

Identify a template where you will capture the events and share it with all stakeholders (It will really help if your customers are in a different place).

 

In his book "Agile Project Management with Scrum", Ken Schwaber says the meeting should be time boxed to 3 hours. My interpretation to it is defined based on 30 Days iteration.

 

In my experience, for a 2 weeks sprint with a team size of 10, the retrospective could take anywhere between 1.5 to 2.5 hours.

 

Get some Snacks/Cookies for the team. Because my customers are in a different time zone, we will do it in our evening/their morning hours. If there is a need to stay late, cookies/snacks will help the team to be energized.

 

During the Meeting

Step 1: Start with Norm Kerth's Prime Directive for Retrospective. In our meetings, the whole team (here team includes the customer side architect and other stakeholders) reading the Prime Directive loudly once.

 

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time,  their skills and abilities, the resources available, and the situation at hand"

 

Step 2: Define the Ground Rules: Our Team ground rules are something like this

1. Do not finger point or blame others

2. We all are responsible for the success or failure of this

3. Try to attack the problem and not the person

4. At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgment used to embarrass.                

 

Step 3: Decide the facilitator.

 

Step 4: Appreciations: Team members to appreciate/recognize other team members who have helped them in 2 weeks. It helps in bonding. Make sure, the appreciations are captured and shared with stakeholders. Team members will definitely feel happy to see their name in that. May be it’s a collection of "Whale done" or good things everyone has noticed for 2 weeks.

 

Step 5: Once you are done with appreciations, move to the actual questions section.

 

Answer the 3 questions. Purpose is to inspect how things are and adapt ourselves accordingly.

 

1.    What worked well?

2.    What needs to be improved?

3.    What should we do differently?

 

You can change the format. We call it as "Mad (Crazy), Sad (Needs improvement) and Glad (Did Well)".

 

Step 6: Identify Lessons Learnt. We try to gather this from the GLAD, SAD and MAD sections.

 

Step 7: Identify Top 1 or 2 Actions items which the team is going to work in the next 2 weeks. Identify the Theme for the Area of improvement and the Action Superstars for the Theme.

 

After the Meeting

Share the Retrospective meeting notes with all the stakeholders.

Share the progress the team has made with the action items identified in the previous sprint with all the stakeholders.

Sharing the Retrospective notes could be in email, wiki, posters or any other format. Our team sends the report in email and keeps the copy in SVN.

The Scrum Master will follow up on the Action Items Identified.

 

Challenges

1.    Making the team participate.

2.    Everyone focusing on "I/We"

3.    Continuously identify area of improvements and working on them

4.    Creating a Learning Organization/Environment. Making it as a part of the organization culture.

 

Summary                                                                                        

The purpose is to create a learning environment, where everyone in the team and as a team learns and improves continuously. If retrospectives are conducted to its true spirit, the team will identify the recurring mistakes (patterns) and will work on improving. It helps in identifying the best practices and sharing the knowledge across the organization. It helps the team to prepare for the future.

Underlying theme: What can we do better next time?

 

References

Project Retrospectives: A Handbook for Team Reviews

Agile Retrospectives: Making Good Teams Great

Sustainable Software Development: An Agile Perspective

 

http://www.retrospectives.com

http://etutorials.org/Microsoft+Products/Agile+Project+Management+with+Scrum/Appendix+A+Rules/Sprint+Retrospective+Meeting/

http://pragmaticintegration.blogspot.com/2007/01/first-scrum-sprint-retrospective.html

http://www.cs.unca.edu/~manns/RetrospectivesPresentationatOOPSLA03.ppt

What's a Manager to Do? Manager's role in self-organizing teams

Moving toward self-organizing teams--whether driven by adopting agile methods or not--doesn't mean that all the managers are out the door. There's still plenty of management work to do; it's just different work. And, for many managers, it is also more satisfying work. 

 

In this article Esther Derby describes how self-organizing teams are different from manager-led teams and lay out how that changes the manager’s role.

 

Manager-led teams are often like ski teams. Each person is selected for her individual skills and abilities as a skier. Each excels as an individual. All the members of a ski team are working for a common goal--winning the competition. Each contributes to success by making it down the hill as fast as she can, while passing through all the gates on the course. The coach's job is to improve individual performance skills. A ski team trains together, but when the meet comes, each team member is on their own. They don’t win by working together; it's the sum of the individual scores that wins the meet. 

Self-organizing teams are more like soccer teams. Each player has a position on the team based on her skills; however, the team must work together in order to win the game. In addition, each team member constantly adjusts her position and actions to create the best opportunity to score (or to prevent the opposition from scoring). If the team doesn't constantly coordinate and adjust to the current circumstances, it doesn't stand much chance of winning, even with star players on the team. Once the team is on the field, the coach can only observe and diagnose problems. He directs the team during timeouts and adjusts strategies through substitutions. Most of his work comes before the game, building individual skills. But even more importantly, he teaches team members to work together to achieve their goal.
 

 

Original URL: http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea

12月16日

Program Management - What is it all about?

I was talking to a friend of mine (who is a project manager). He was asking me how my current role is different from a project manager's role. I discussed with him about the differences.

 

I have consolidated my notes from readings and my thoughts.

 

PMI's Standard for Program management defines it as

Program: "A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually".

Program Management: "It is the centralized management of a program to achieve the program's strategic benefits and objectives".

 

Enterprise Programme Management: Delivering Value defines it as

"We define enterprise program management as the capability to lead and manage resources, knowledge and skills in the effective deployment of multiple projects designed collectively to deliver enhanced value"

 

Program management provides assistance to:

1.    Ensure alignment of activities across multiple projects

2.    Optimize the use of resources

3.    Communicate with and involve people, both within and outside the program

4.    Drive the achievement of strategic objectives, and the delivery of benefits.

 

Program Management System

1.    Assists in the coordination of resources, timescales and scope across project teams

2.    Facilitates the effective deployment and sharing of skills and knowledge across the program

3.    Tracks and manages issues, risks, delivery of benefits and alignment to program objectives

4.    Provides executive management with a ‘dashboard’ on programme progress

5.    Provides programme management with the information and levers that they need to effectively manage program's.

 

The Handbook of Program management defines the Role of a Program Manager as

Program manager's role varies from managing multiple projects to managing multiple projects with operational responsibilities.

Typically, a program manager is subjected to all the complexities and stresses of a project manager, plus is required to manage ongoing operations while meeting business goal targets for the month, quarter, or year. The program manager often has to strike a balance between the amount of resources spent on operations and the amount of resources spent on development and new projects.

A program manager needs to have an ingrained sense of organizational mission, must lead and have the presence of a leader, must have a vision and strategy for long-term organizational improvement, must be a relationship builder, and must have the experience and ability to assess people and situations beyond their appearances.

 

Program manager is

·         Ultimately accountable for delivery of the business objectives.

·         Accountable for profit or cost targets linked to business strategy.

·         Accountable for policies that defines how the work is accomplished as it will have an impact on the business and cost targets.

·         Accountable for establishing a culture that allows his or her project managers to be successful. The program manager must create, manage, and continually improve the culture that enables successful projects.

·         Accountable for providing clarity and clearing chaos.

Program management decisions are both tactical and strategic in nature. The strategy aspects of these decisions must consider multidimensional impacts beyond the near-term delivery dates of the project.

 

Attributes of the Effective Program Manager

·         Being a program manager requires a greater skill set and more diverse background than being a project manager.

·         The most significant difference between project manager responsibility and program manager responsibility is the requirement for the program manager to establish a culture of success.

·         Self-regulation takes time to create, but it is the ultimate definition of presence. With self-regulation, the organization acts and performs just like the program manager would want it to even if he or she is not present.

·         Leadership is based on a relationship of trust, and program managers must consistently develop and use relationship capital.

·         The ability to accomplish objectives through others is directly correlated to the strength of the relationships or the relationship capital the program manager has developed.

·         Consistency in style, management techniques, and leadership traits are important anchors for any organization and contribute to a stable work environment.

·         Effective questioning starts with being perceptive and in touch with the organization—having a feel for the organization above and beyond what charts and graphs provide.

·         As program manager you want to establish a “self-regulating” culture where your team answers your questions before you ask them.

·         Decisions should be made quickly and at the appropriate level through the establishment of clear lines of accountability and escalation processes.

·         Long-term program success is dependent on the continued growth and development of program personnel.

 

Summary: A program manager is a Business Owner who owns the profit and loss of the group/program which he/she manages. It is more of a mindset transformation from a project manager's role. He / She is responsible for the overall accountability of the management of multiple projects, deliverables and budgets

 

As a Project manager, it is very important to solve people problems. Even as a Program manager it is very important, but the responsibilities are more than that. It is very important to empower the project managers in the program/group to handle such issues so that as a program manager one can handle the prime responsibilities of a program manager.

 

The success of a project manager is defined by how one executes the project and delivers the project within the triple constraints. The program manager also is judged on these three elements but at a level that is cumulative for all the projects and operations within the program. This aggregation of responsibilities for a variety of projects and operations means the program manager must make frequent trade-offs between business targets and project/operational performance.

 

As a Program manager, one will be responsible for the successful delivery of the Projects, creating a culture which enables project managers to deliver successfully, customer satisfaction, resource management (managing resources, recruitment, retaining employees, attrition, and employee satisfaction), risk management at a program/group level, responsible for the profit and loss, business development, meeting business and cost targets.

 

Books Referenced:

·         The Handbook of program management - How to facilitate project success with optimal program management

·         Enterprise Programme Management—Delivering Value

·         The Standard for Program Management