Professional ScrumMaster Class Offered in Austin Texas

November 3, 2011 — Bruce McGraw

I have written and spoken in the past about agile and the incremental approaches to building solutions.  I am learning more about SCRUM and how it can improve our ability to be successful in our projects.  Scrum provides a framework for software development that is incremental and iterative. Scrum is based on agile principles that involve planning and implementing software deliverables in short time cycles. As described by Ken Schwaber and Jeff Sutherland in “The Definitive Guide to Scrum: The Rules of the Game,” Scrum is simple to understand and “extremely difficult to master.”

As with other agile methods, Scrum works well in development efforts where requirements change frequently and objectives can be broken down into tasks that a team can accomplish in days rather than months (and most of us have experienced the constant requirements change problem). The role of a project manager in an agile development differs from the role served by managers operating under traditional waterfall methods, as discussed in Agile and project management – Advice from the warriors and now a formal certification in the PMI Agile Certified Practitioner (PMI-ACP).

A project using Scrum framework and methods is comprised of a product owner, the execution team and a “ScrumMaster”, who solves problems and facilitates execution. The Wikipedia write up on Scrum states, “The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks at hand.”

I am excited to announce that my organization, Cognitive Technologies, in partnership with Improving Enterprises, is offering the Professional Scrum Master (PSM) certification course in Austin Texas. I am planning on going, so that I can increase my knowledge and skills.

The next class is being held in Austin, TX on December 6-7, 2011. Taught by Don McGreal, the 2-day class is the first significant update of the Certified ScrumMaster (CSM) course that Ken Schwaber introduced and shared in 2002. As in the original, the framework, mechanics, and roles of Scrum are covered. The course then goes further by teaching students how to use Scrum to optimize value, productivity, and total cost of ownership of systems and products. Students will learn through instruction and team-based exercises, and will be challenged to think on their feet to better understand what to do when they return to their workplaces. If you or your organization is trying to use SCRUM then you need to send someone to a course like this.
Here are some details from the course information:

Structure of the Course

  • Scrum Basics – What is Scrum and how has it evolved?
  • Scrum Theory – Why does Scrum work and what are its core principles? How are the Scrum principles different from those of more traditional software development approaches, and what is the impact?
  • Scrum Framework and Meetings – How Scrum theory is implemented using time- boxes, roles, rules, and artifacts. How can these be used most effectively and how can they fall apart?
  • Scrum and Change – Scrum is different: what does this mean to my project and my organization? How do I best adopt Scrum given the change that is expected?
  • Scrum and Total Cost of Ownership – A system isn’t just developed, it is also sustained, maintained and enhanced. How is the Total Cost of Ownership (TCO) of our systems or products measured and optimized?
  • Scrum Teams – Scrum Teams are self-organizing and cross-functional; this is different from traditional development groups. How do we start with Scrum teams and how do we ensure their success?
  • Scrum Planning – Plan a project and estimate its cost and completion date.
  • Predictability, Risk Management, and Reporting – Scrum is empirical. How can predictions be made, risk be controlled, and progress be tracked using Scrum.
  • Scaling Scrum – Scrum works great with one team. It also works better than anything else for projects or product releases that involve hundreds or thousands of globally dispersed team members. How is scaling best accomplished using Scrum?

Audience
This training is primarily targeted at those responsible for the successful use and/or rollout of Scrum in a project or enterprise.

Prerequisites

  1. Have read one of the Scrum books.
  2. Have studied the Scrum Guide at www.scrum.org.
  3. Understand the basics of project management.
  4. Understand requirements and requirements decomposition.
  5. Have been on or closely involved with a project that builds or enhances a product.
  6. Want to know more about how Scrum works, how to use it, and how to implement it in an organization.

Cost

This class is normally $1,495 for the 2 day class, but Cognitive Technologies is offering a discount for early signup.To sign up for the course go to http://www.cognitive-technologies.com/products/training/scrum.aspx.

It is time for us to get serious about learning new methods for projects so I encourage you to look at all of the methodologies that are out there today. If you have more information about this type of training or Agile methods, feel free to leave a comment.

Posted in General Project Management, Best Practice, Professional Development, Project Management. Tags: , , , , , . Leave a Comment »

How to cancel a failing project gracefully

September 8, 2011 — Bruce McGraw

 

A couple weeks ago (August 21, 2011 to be exact), I was watching a “60 Minutes” interview on TV about whistle blowing and a NSA employee’s possible trial for espionage. Interesting stuff, I guess. However, what caught my attention was that the charges revolved around a software development project. (Here’s the full story, if you are interested: U.S. v. Whistleblower Tom Drake.)

The gist of the story began when the NSA needed greater capability to sort through the terabytes of data it collected. Internally there was a tool, believed by the whistle blowers, to meet the NSA’s requirements. However, the Director decided to requisition develop of a new tool, called Trailblazer, that did everything they could imagine needing to be done. Millions of cost overrun dollars later, the project failed and the former head of NSA, Lt. Gen. Hayden told congress, “A lot of the failure in the Trailblazer Program was in the fact that we were trying to overachieve. And that a lot of the failure was that we were trying to do too much all at once.”

Been there. Done that. Got the project coffee mug!

Even when you are project manager for less grand goals than saving freedom and democracy, there comes a time in the life of many projects when the failure handwriting is on the wall. How can you tell when it is time and what is the best way to end a failing project?  Back in 2009, I wrote a post on Spotting a Failing project that was a short piece on the subject. In the current economic environment I have once again been asked to re-visit the subject by several of my clients.  I am not sure I have a nice precise answer to either of these questions, but I will share my thoughts on this often overlooked subject. 

Signs of a Project in Failure Mode

Recurrent cost and schedule over-runs may signal that a project is doomed to failure. Disruptive technologies or changes in the business case for a project can (and should) lead to project cancellation. In addition, customers can lose funding, especially in a recession or on government contracts subject to priority changes. All of these situations provide legitimate reasons to stop working on a software project.

I would like to add a few of my own observations – I have borrowed a couple, some tongue in cheek, from Code Squeeze’s “101 Ways to Know Your Software Project Is Doomed.”

Bruce’s top ten signs that your project may be a failure:

  1. The schedule changes every day
  2. No one has heard from nor can they find the project sponsor
  3. The weekly status report is always the same – it never changes
  4. Project resources (staff) are constantly changed out without notice
  5. No one can find the actual requirements document
  6. Every bug is prioritized as Critical and every feature is prioritized as Trivial
  7. Project cost estimates magically match the budget – all the time
  8. The phrase ‘It works on my machine’ is heard more than once a day
  9. All code reviews have been moved to a week before product launch
  10. None of the project team leads shows up for the status meetings; they send a proxy

For those of you working on Government projects who want some insightful information on why government software development contracts often fail, I highly recommend the Clutter IT Journal article, “How do the turkey projects get wings …” by Payson Hall. I also wrote a post about how bad estimating on government projects can lead to failures. The hard part is defining that your project is failing – sometimes you have to re-think what success would be.

How to Terminate a Failing Software Project with Grace

Grace means gaining concurrence from the project’s key stakeholders that stopping an irrecoverably failing project is the best action for all concerned. Or, to quote an old saying, “Don’t throw good money after bad.”

As a project manager, you created a risk management plan during initial project development that included trigger conditions to be monitored to indicate when the project’s success was threatened. I recommend contacting your PMO, portfolio manager or supervisor as soon as the trigger condition occurs. Tell them your plans to investigate the problem and give them a deadline to report results and recommendations. As part of your investigation, talk with your lead technologist in an effort to identify any products from the effort that can be salvaged as deliverables. Do not be offended if managers that are more senior suggest calling in a consultant to get a second opinion or to assist in generating options to project cancellation.

When alerting clients to a potential project failure, it is better to have a face-to-face meeting than to send a report or wait for the next scheduled review. I understand that no one likes to be the messenger bringing bad news. However, if you have done your due diligence in assessing the situation, the sooner you gain concurrence and understanding from customers, the sooner you can move on.

When explaining the situation to customers, present the problem in non-technical language, offer your conclusions and recommendations. If you have a recovery plan, present the options along with their associated cost and schedule implications. If you identified salvageable elements from the project, describe how those can be polished and delivered.

Assuming that you are successful in convincing management, clients and sponsors that it is time to pull the plug, you should still push to perform some key tasks.  Before closing the project, create documentation and lessons learned for inclusion in the organization’s knowledge management system.  I am certain that the organization will not want to repeat the same mistakes again!

Please share your thoughts on how to spot and cancel a failing project.

Posted in General Project Management, Best Practice, management, Project Management. Tags: , , , , . 3 Comments »

Project Managers: The Trust Metric

September 1, 2011 — Bruce McGraw

Conventional “management” wisdom states that having trust among team members and between the team and management is critical to project success.  I just finished a project to implement a new tool suite for an organization and the need for trust was very apparent.  Trust however is neither simple to define or achieve. Trust is subjective. It involves a few key elements:

  • Predictability – a project manager expects a team member / employee to do what they agree to do in the way their manager expects them to do it. Likewise, employees trust managers who do what they say and what is expected of them.
  • Value Exchange – this element of trust means that you (and the organization) treat employees and staff fairly in exchange for satisfactorily completing the work they agree to do. This element has a touch of accountability in it.
  • Delayed Reciprocity – this element of trust is about giving payment or services with the expectation that sometime in the future your contribution will be recognized through receipt of goods or services of equal value. Kind of the “if I do good work it will be recognized/rewarded in the future” thought.
  • Honesty – this is a key element in trust.  It is very hard to measure, but easy to see when it does not exist. This element has the foundation of truth as its core.

Trust in the Real World of Management
If you only trust managers who place your interests ahead of their own, who always provide you with interesting assignments and give proper rewards and attention to your career, you will likely be disappointed. The Work Place Therapist offers these observations  about how managers make decisions:

  • They think of themselves and the impact a decision or assignment has on their lives and career (People will always look out for themselves, if possible).
  • They consider their reputation and want to be seen as go-to people who can get the job done.
  • In order of importance, they try to please their boss, the client and then you.

Understanding the priorities of senior executives and project managers helps you understand and predict how they will behave in a given situation. That being said, building trust on a team actually furthers the career goals of managers. Teams with high trust levels are more productive, more creative and enjoy the work and tasks more than teams where everyone feels they have to go it alone and watch their backs at all times. Teams without trust are dysfunctional and likely to fail.

How to Build Trust
Trust is built on a foundation of honesty. Project managers need to share information about project goals, resources and status and provide background or elaborate on the reasons for decisions. PMs need to show the team that they are professionals and value respect, honesty and accountability. The team may not like your answers; however, they will trust you as a conveyor of information.

If you make a promise to the team or individuals, you must follow through. If you fail to accomplish something you promised to do, you need to accept the responsibility, explain the failure – without pointing fingers up the management chain – and move on.

As a project manager, you build trust and the respect from your team through efforts to develop their skills and facilitating, to the extent possible, opportunities for them to display their accomplishments and be rewarded for their efforts. Taking credit for the work of others or denying them opportunities for advancement creates mistrust (vague doubts) and distrust (suspicion and complete lack of trust.) Working to ensure that team members are appropriately compensated, both monetarily and with perquisite considerations (Giving special perks), shows respect and helps develop the part of trust that relies on value exchange. Trust me when I say that the other team members will watch who you praise and reward to see if you are true to your words.

Delayed reciprocity may be the most challenging element of trust to build because it involves the most risk. From the perspective of a project manager, delayed reciprocity means you show trust in your team before you have evidence of their trustworthiness. You listen and accept their explanations of a task’s status. You expect them to solve problems and share accurate information with you and the team, without checking up on them. If an employee or staff member asks for exceptional consideration, such as time off or temporary changes in work hours because of a family problem, you trust them to be truthful and you make efforts to accommodate their situation.

Building team trust pays off in performance, creativity and employee retention. This is also how a culture of trust is built. Building trust is a key part of improving organizational and project culture. For those of you wanting to move beyond just building trust, Edgar Schein has many excellent articles and books about leadership and culture.

Have you been challenged to give or receive trust? What methods have you found successful? In your experience, what manager behaviors kill trust?

Posted in General Project Management, Best Practice, pm, management, Project Management. Tags: , , , , , . 2 Comments »

The Importance of Project Planning – PMBOK Chapter 3

August 11, 2011 — Bruce McGraw

OK, it has been a while since I talked about the PMBOK and I wanted to continue a series of posts on PMI PMBOK areas (started with “What is the PMBOK all about”.  This week we look at one of the critical areas that many PMs shortchange in managing projects – planning

“No battle plan survives contact with the enemy” is a bit of wisdom about the world alternately attributed to Helmuth von Moltke the Elder, Erwin Rommel, Carl von Clausewitz, Colin Powell and Murphy’s Laws of War. Yet, military leaders continue to develop plans for every imaginable contingency. If plans are destined to fail in the real world, why should we as project managers bother with planning?

Plans rarely fail entirely. Rather, details of a plan require changes as factors outside the control of the PM require responses that deviate from the original plan. However, a project plan provides a roadmap of key destinations (milestones) and a timeline to reach those locations, even when detours become necessary.

Of course, the PMBOK addresses project planning in detail beginning in Section 3.4. It suggests that a project plan encompass:

  • Scope
  • Activities
  • Resources
  • Schedule
  • Quality assurance
  • Risk analysis

In the discussion, PMBOK acknowledges that, “as more information is gathered and understood – which is their way of saying contact with the enemy — additional planning may be required.”

Types of Plans
Creating a project plan is not a trivial exercise. The project manager needs to spend time gathering requirements from a variety of stakeholders and working closely with key technical staff to identify strategies and risks. For large or complex projects, creating even the initial plan may take several weeks. However, not all projects are “created equal” and some may not justify this amount of effort. Sometimes a project plan can be created on the back of an envelope (and, of course, captured in more detail during documentation – MS Excel is probably the most popular way many of you do this.)

  • Exploratory Plans: these often begin with a conversation and some, “what ifs.” A creative developer has an idea for a potentially useful software tool or an alternate approach to solving a vexing problem. What makes these thought exercises a project that requires planning is the need for resources. It is one thing to have an idea. However to try it out and test its utility, someone has to approve the objective and the allocation of hardware and human resources. Even exploratory projects need a statement of the problem, a sequence of steps, a schedule and a method to evaluate outcomes.
  • Agile Development Plans: I discussed Agile Development methodology in “Project Management and the Agility Factor” as a style of project development that focuses on short iterations of feature development. Kent McDonald, writing for ProjectConnections, suggests that a Project Plan for Agile Development would only cover a period of two to four weeks. “During those iterations, all of the necessary work to take features from an idea to a working product is completed …” Each iteration begins with a feature-based plan that includes detailed tasks, schedule and deliverables.
  • Traditional Waterfall Plans: When waterfall development method is used on a project, the project management plan covers the life cycle of the project in discrete steps beginning with requirements analysis followed by design, implementation, test and maintenance. Because plans developed for waterfall method projects may cover months or even years of activity, these plans are more likely to require re-planning driven by external events.

Characteristics of a Good Project Management Plan
Here are a few tips to help you make a better project plan:

  • Cover all the bases listed in PMBOK
  • Clearly defines the scope of the project
  • Show dependencies between tasks as part of risk management
  • Comprehend resource loading and realistic levels of effort
  • Reflect awareness of project risks and allow time to understand and mitigate them
  • Accompany the plan with a communication plan that explains goals, tasks, schedule and performance information with key stakeholders
  • Include qualitative measurement of deliverables tied to project requirements (Focused on outcomes and not just widgets)
  • Help developers, team leaders and users understand the project and their role in its success
  • Make sure the plan is sized appropriate to the scope and size of the project (“Not too big, not too small but just right”)
Posted in General Project Management, Best Practice, PMBoK, Planning. Tags: , , , , , . 4 Comments »
« Older posts
Newer posts »
Follow

Get every new post delivered to your Inbox.

Join 354 other followers