5 Reasons for Project Management Failure

Adapted from PM Network, October 2006

1. Organizations lack the resources, know-how and commitment to manage culture change.
2. Executives says they want good project management methologies, but their actions don't back up their words.
3. The methodology isn't scaled appropriately to the size of the project -- making project management seem cumbersome and unfocused.
4. Organizations fail to plan up front.
5. Senior managers think project management is a software tool.
   

It's take courage to initiate change. Managers need to be willing to take risks if they want projects to run better. SCRUM provides a framework for addressing these failures.

Changing the Mindset of an Organization

I have been working hard to convince people (i.e., management) within my organization that the benefits and values that Agile brings to organizations and projects far outweigh any possible side effects (I guess some warped people could see hyperproductivity and making everything visible as negative side effects).

We have a global agile process group and everyone on the team is in complete agreement that our current RUP process would benefit by adapting some Agile/Scrum techniques. Here's our current game plan:

1. How do we convince the organization of the benefits? How do we convince them that change is good?
   
2. Who do we get to sponsor the initiative at the executive level? We need someone with the courage to act differently, to find out if the environment will support us.
3. How do we incorporate Agile & Scrum best practices into our corporate culture and our projects sooner rather than later?

Any suggestions or experience with these questions would be greatly appreciated (both good and and comments welcome).

Scrum Core Values

I believe these should be posted somewhere for everyone on the team to see. It's very easy for them to lose sight of them otherwise.

Commitment

• Be willing to commit to a goal
• Support & encourage commitment
• The team has the authority to decide how to do the work it has selected

Focus

• Do your job
• Focus all of your efforts and skills on doing the work that you’ve committed to doing
• Don't worry about anything else
• Once you're focused, all of your time is spent looking for and trying solutions to bring order to the problems

Openness

• Keep everything about the project visible to everyone
• Scrum removes the ability to dissemble
• Responsibilities are clear, authority is allocated, and everything is visible
• Scrum counters interference; No one is allowed to add work to a Sprint once it is underway
• It’s better to produce something than it is to pursue many alternatives, please everyone, and produce nothing

Respect

• Individuals are shaped by their background and their experiences
• Respect the different people who comprise a team
• The team adjusts and adapts to meet its commitments for a Sprint:
  (1) Who does what is up to the team
  (2) The team commits as a whole and sinks or swims together
• Do your best, remember everyone else is doing his/her best, and help your teammates

Courage

• Have the courage to commit, to act, to be open, and to expect respect
  
• It requires courage to act differently; Courage to see find out that the environment will support these values; Courage to be willing to find out that relying on one’s own judgment is acceptable – even admirable
  
• Courage is having the guts, the determination, to do the best you can
  
• Courage is the stubbornness not to give up, but to figure out how to meet commitment

Eureka: The Daily Scrum

We have a team at the client site that is holding daily scrum meetings. I am onsite this week and was listening to the conversation (as a chicken from the other room). What I heard caught me off guard; it was a status meeting where they would actually go through and update each task in the Sprint Backlog.

I took the ScrumMaster to lunch and discussed with him the purpose and benefits of the 3 questions:

1. What did you do yesterday?
2. What will you do today?
3. What is preventing you from accomplishing your goal?

He was very receptive and acknowledged that he needed to make a change. We held a daily scrum this morning and went through the 3 questions with each team member.

The difference was remarkable. The meeting turned into a conversation rather than a status meeting. Team members were offering help to each other. They finally get it that they are a team and that they are measured as a team.

If anyone is running a project without the daily scrum, they are really missing out on significant opportunities.

Agility & Discipline Made Easy

I was turned on to the book "Agility and Discipline Made Easy" by a colleague of mine. This book is a good follow up to the book "The Rational Unified Process Made Easy." The primary focus of the book is to provide you with best practices for making projects more agile (with focus on the Unified Process).

The book outlines six fundamental principles (best practices) that characterize the most successful projects in the software development industry. Many of these principles are found to some degree in most iterative and agile processes:

1. Adapt the process
2. Balance stakeholder priorities
3. Collaborate across teams
4. Demonstrate value iteratively
5. Elevate the level of abstraction
6. Focus continuously on quality

Each principle is then broken down into sets of practices for:

• Supporting Iterative Development
• Improving Your Ability to Manage Requirements
• Improving Your Ability to Do Architecture, Design, and Implementation
• Improving Your Ability to Do Testing

I highly recommend this book for those of you that are experienced with RUP and want to make your processes more agile.

Set the Foundation in the Inception Phase

Jon Kern has written an excellent overview of what you need to accomplish in the Inception phase of a project in order to set the proper foundation for all future work.

Here is a high-level summary of his article.

To set the proper foundation, you need to have the following defined:

• Prioritized list of features for Release 1 (at a minimum)
• Domain model
• Technical architecture
• Automated build process
• Coding guidelines
• Version control system
• Issue tracking system
• Requirements management system
• Collaborative workspace (e.g., blogs, wiki)

Jon properly notes that there are two critical pieces to the Inception process: the domain workshop and the technical workshop.


The requirements-gathering process takes place in the Domain Workshop. The Technical Workshop is used to ensure the architecture and development techniques are defined. At the end of this process, we will have the necessary ingredients to form a Release Plan and can start the iterative development in earnest.

In the Domain Workshop, the artifacts we should typically end up with include:

• Business definition
  - Problem statement
  - Vision document
  - Simple cost/benefit check
  
• Feature set
  - Basic description
  - Roughly prioritized
  
• Domain model (initial cut)
  
• "Non-functional" requirements

In the Technical Workshop, the artifacts we should typically end up with include:

• Architecture vision
  
• Things we chose not to do (and why)
  
• Object models
  
• Sequence diagrams
  
• Deployment diagram
  

If all of these goals are accomplished, the team will be able to move forward quickly with a list of features in hand, the technical architecture determined, a set of coding guidelines, a set of automated build scripts and a domain model from which to start coding.

This is certainly a recipe for success!!!

Agile & Blended Shore Projects

My whitepaper is finally published. It's titled "Adapting the Agile Unified Process to Blended Shore Projects." You can read it here.

I have put nearly all of my recommendations into practice and they are working. Our next step is to collect more metrics to help us plan the project.

New Metrics

• Use Function Point Analysis to create estimates by feature
• Review & update FPA estimates after each iteration
• Record the number of function points per feature in the Product Backlog
• Record the actual effort for each feature after it is implemented
• Team Productivity = Total # of function points implemented in an iteration
• Track actual effort per function point
• Track team productivity over time; the trend should be that the team's productivity increases as they become more familiar with the domain and technology

What's Working

• Product Backlog as the master feature set
• Iteration (Sprint) Backlog for each team
• Daily Scrum
• Iteration Assessments (Sprint Review Meetings)
• Iteration Planning Sessions (Sprint Planning Sessions)
• Early and frequent delivery to QC within an iteration
• Storyboards
• Modeling
  

Challenges

• No automated test tools are available for Avalon/WinFX
• Technical reviews of requirements are not conducted soon enough; we plan to bring more technical resources onshore to close the communication gap
• Tracking rework and changes; we have revised our change control process so we have a record of the changes requested and the effort to implement each

This is fun and it's working well!!!

My next assignment

Since I am the only certified ScrumMaster in our company, I have been tasked with creating a "plan" for how I would run an agile/scrum project with our blended-shore model. Things I need to consider:

1. How will this affect/be different than our existing RUP process?
2. Would applying this "plan" to a project jeapordize our CCMi Level 5 certification, if at all?
3. What training would people on the project need?
4. What communication mechanisms should the team use?
5. Do I need to have the "best" people place on this project? What skills sets will I need?
   
6. Team size
7. Offshore team location (India, Vietnam, or both)

Fortunately for me, there has been much research done already in this area and I have plenty of materials to help me get started.

Maybe I'll post my plan here along the way to get some feedback (assuming anyone actually reads this blog).

Welcome to The SCRUM Blog!

I am a recently Certified ScrumMaster (CSM) and I have been implementing SCRUM (and Agile) practices and techniques on my projects for the past year. I created this blog in the hopes that it will serve as a discussion area for those of us wanting to implement Agile and SCRUM. I welcome your comments.