Understanding Agile Scrum and common terms

I've been in a few meetings this last week where people were mentioning Scrum terms but didn't know what they were. It's not their fault. The person introducing the terms into the project vocabulary should have provided an explanation before referencing them.

For those of you new to Agile Scrum, here are a few basics:

What is Agile Scrum? There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project.  Agile methods choose to do things in small increments with minimal planning, rather than long-term detailed planning.  There is a heavy emphasis on face-to-face communication over written communication.

Agile Scrum is not ideal for every project.  If the project has high criticality, is using junior developers, has clearly established requirements that do not change often, employs a large number of developers, you should think twice about using it as your method of choice.

I've seen it work very well with small (5-9 member) teams, where all the stakeholder knew they wanted "something" within a short period of time.  They did not know specifically what it was nor how to get from start to finish.  We used a lot of wireframes and prototypes to get us in the ballpark, until we could lock down clear functional and design requirements.

I think it's important for people to understand key terms in Agile Scrum as they relate to other project management methodologies.

Roles

Product Owner The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.  This owner could be a project manager, director...  Whatever their title, they must have the authority to make decisions on behalf of the project.

ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.  This is NOT a project manager.  This person is a facilitator.  They are merely there as a communications bridge and to offer motivation or remove impediments.

Team A cross-functional group of people responsible for managing itself to develop the product.  This is a small team (5-9) consisting of at least one person from each area (BA, QA, Risk, CM, Software Engineering...)  This team traditionally sits in the same room or area.

Scrum Team Product Owner, ScrumMaster and Team.  Everyone directly involved in the project, with the exception of users, stakeholders, and managers.

Artifacts

Sprint burn down chart Daily progress for a Sprint over the sprint's duration.  This chart can replace a Gantt chart in illustration of progress.

Product backlog A prioritized list of high level deliverables assigned to teams.  This list is similar to milestone deliveries you'd find in a Work Breakdown Structure.  These deliverables will still need to be decomposed (in the sprint backlog).

Sprint backlog A list of tasks to be completed during the sprint and assigned to individuals.  These are the actual decomposed items from the product backlog.  This list must be agreed to by the entire team prior to the sprint actually beginning.  If there is a change in the scope of the sprint backlog during a sprint, the sprint must be immediately stopped and scope redefined.

Other

Sprint A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.  Sprint time periods are established to provide enough time to deliver something, get feedback, and begin another iteration.

Product An output requested by the customer.  It is a completed document, process, web page, database...  Regardless of what it is, the customer believes that it has value.

Other terms to be listed in a later post: Sashimi, timebox, daily scrum, chickens, pigs, retrospective, user stories...

Kobayashi Maru for Projects

Without trying to appear to be too much of a geek, I sometimes code-name a project as Kobayashi Maru. For those out there who are not Star Trek geeks, Kobayashi Maru is a test in which command division cadets at Starfleet Academy are presented with a no-win scenario as a test of character. I use the term for a project in which management gets involved and I'm presented with a no-win scenario.  I doubt they are trying to test character. Rather, it's an example of their lack of understanding project management. I'm sure there are PMs out there who have had management redirect resources from your project to others, only to refuse to narrow scope or push out a delivery date. That is a Kobayashi Maru.  Just because I have a PMP®, don't expect me to pull a rabbit out of a hat.  On a previous program, I've looked management in the eye and reminded them that something will have to give.  Narrow scope, extend the deadline, lower quality expectation, or increase the budget.  Do something or this will be a no-win scenario.

Image from : drexfiles.wordpress.com

Using Agile does not mean a lack of defined process

Agile Scrum process

Sometimes I'm not surprised to hear one of our current contractor say they are now usingAgile.  This is their explanation for ad-hoc builds, lack of documentation, and lack of predictable process.  It can be frustrating to hear of development groups using it as a scapegoat.  Waterfall has been the decided process for our main program I'm working and it makes sense.  The requirements have been clearly identified, for several years.  The budget and schedule have been fixed, for several years. I'm not saying we can't use Agile in different areas of the program.  But, most important the current contract is not structured to support it. The contractor does not seem to understand the difference between cowboy coding and Agile.  Agile teams, do follow defined and often very disciplined and rigorous processes.  What is lacking, by this contractor, is any example of a defined process.

Agile certainly can work well if utilized by people who know what it is.  I've signed the Agile Manifesto. I know what Agile is.  Don't use a lowecase "agile" and think you're getting away with it.

What is missing from a Cost Performance Report

I recall a very positive meeting where we exposed several non project management team members to a Cost Performance Report (CPR) for the first time. A CPR addresses project performance through a defined period of time in relation to contractual requirements.  The CPR details budgeted work scheduled and performed, actual cost work performed, and the variance in both schedule and cost.  All of this is itemized per Work Breakdown Structure (WBS) element for both the current period and the cumulative to date.  The last values you see are the budgeted, estimated, and variance at completion of the contract. There were a lot of questions as to why one WBS element has a positive or negative cost variance and why it may have a positive or negative schedule variance.  Trying to explain this to those without a project management background can be a challenge.

I was having a sidebar conversation with one team member who could not understand how the element that pertained to him could be both ahead of schedule and below budgeted cost. The answer came from across the room in the form of a question.

"Is there any way this report captures quality?" The answer was no.

That my friends is called Triple Constraint.  We know the Scope, Time, and Cost within this report.  What we don't know is Quality, Risk, or Customer Satisfaction.  That's ok.  This is the CPR, not a Total Project Status (TPS) Report.

By not committing the scheduled time and budgeted dollars to complete the task to a level of quality that meets the customer's expectations, the contractor looks good only on paper.

Critical Path added to Technorati

In order to reach a broader audience, I have added Critical Path to Technorati, a blog search engine.  Feel free to view my Technorati Profile.

Free Lessons Learned Template

It is not important that you call it a Lessons Learned or a Postmortem. What is important is you learn from your mistakes. At the end of every iteration or project, you should identify everything that went wrong or could have gone better. Articulate them in a document. At the beginning of each new iteration or project, review the document and see not only what was learned but what has been implemented. Feel free to download my free Lessons Learned [Template]

Disappointing PMI Customer Service

Last month, I needed to get some information from PMI about OPM3 (Organizational Project Management Maturity Model). I wasn't satisfied with what was published on their website so I composed an email and sent it off. I received a confirmation email stating "Thank you for contacting the Project Management Institute. Thank you for contacting the PMI Global Operations Center in Newtown Square, Pennsylvania, USA. A Customer Care Associate will review your request and contact you within three (3) business days." I was even provided a ticket number. So, I waited 3 days. ...and waited. ...and waited.

Disgruntled and disappointed, I called them.  I was routed to "general" customer service.  After looking up my PMI membership number, the service representative couldn't answers my questions so she routed me to the desk of the person in charge of OPM3.  I left a voicemail about having questions about OPM3 and left my contact information multiple times.

And now I wait some more.

I'm coming up on 2 weeks and nobody has contacted me.  I feel like PMI is more interested in collecting membership dues and selling products then serving those who have obtained and maintain their PMP certifications.

Helping people looking for jobs

For those of you who were interested in the BA position that I posted 3 days ago, we've filled the position. I was recently asked what service I thought was the most beneficial for finding jobs.  Though I don't think any one service is perfect, a combination can get you qualified job leads in pretty short order.  When I was looking for a job, Careerbuilder referred a lot of people looking to hire anyone with a pulse.  I was sent solicitations ranging from selling insurance to stuffing envelopes.  Maybe they have the lowest prices for "employer" accounts?  I'd offer a pretty good rating to Monster.com.  I discovered reposting my resume on Monster every Sunday night resulted in a wave of qualified leads.  Another service that I found useful was The Ladders.  Ladders only lists jobs paying $100k or more.  Sure, it costs you money but it really helped weed out jobs I wasn't interested in.  To the contrary, I was really disappointed by jobs posted directly on corporate websites.  It was as though the HR departments or companies were saying they would like to hire people for positions but they didn't have any plan in place to actually interview and hire in a timely manner.

Hang in there people.  The jobs are out there.  You just need to know the right place to look.