retrospective Archive

8

Project Management Theater

After hearing public outcry over all of the “junk” grabbing going on at Transportation Security Agency (TSA) checkpoints, I heard the resurfacing of the term “Security Theater”.  I’m not certain if TSA “gets it”.  If you are going to take true action to help fix issues, you need to treat the cause and not a symptom.  Have a shoe bomber?  Make everyone take off their shoes.  Have someone wearing baggy clothes wear a bomb onto a plane, spend millions of dollars to see beyond the baggy clothes.  Without telling you what I did, I bypassed both the new full-body scanners and the TSA pat down in two major airports within the last few weeks.  Certainly, I didn’t want to deal with either so I was happy.  The problem I have, as a stakeholder, is a lot of money has been spent and the issue still exists.

Imagine if that happened on your project?

I see Lessons Learned meetings or a Retrospectives as opportunities to help you refine your processes.  You see what works and doesn’t work.  You find out the root causes and then you make changes.  You refine.

Today I witnessed what I call Project Management Theater.  The vendor loves to use Gantt charts.    On a program level, both the customer and vendor follow a more traditional waterfall process.  At last count (5 minutes ago) the “integrated” schedule had 5,954 lines.  (Internally, I use a backlog and Kanban) Within seconds of reviewing this monster schedule, I could point out improper work decomposition, improper work package mapping, description inconsistencies, improper use of preprocessors or successors and the list goes on.  If your customer prefers the use of Gantt charts over Burndown charts, I’m not going to argue with them.  Whatever the culture will demand, you have to work with it.  But, the problem here is these are just charts.  They are only as good as the data driving them.  When the customer asked me today what I thought of the split view the vendor provided (WBS/Gantt chart), I was blunt.  I hate it. I added, everything that needed to be reviewed at the meeting could have been presented either as a milestone report or backlog.  Instead, we spent most of our time trying to locate activities and get statuses on each.  On top of that, the schedule provided had not been updated in two weeks.  Therefore, we had to ask over and over again if certain activities had been completed.

If you’re going to commit time and money for a support activity, please make sure the resulting “thing” has some value.  At the next meeting, I expect the Gantt chart to go the way of the dinosaur.  I’m advising the customer to request a milestone report from the vendor (instead of the WBS/Gantt Chart).  In the end, I want to ensure the vendor is reaching agreed upon milestones.  Currently, the customer is so distracted by all of the inaccurate details of the schedule, they forget to ask the hard questions about the milestones.

Eliminating the Gantt chart is not going to solve the problem.  Next week, I’m going to show the executive team a Kanban of the milestones.  Let’s see if they find more value in that.

Like the image? Find it at Pictofigo

Popularity: 1%

0

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

Popularity: 1%