Awesome Scrum Intro Video

As I was reading tweets over the weekend, I discovered an awesome video by Hamid Shojaee, Founder and CEO of Axosoft. It's an 8 minute introduction video on Scrum.  With background music sounding a bit like Block Rockin' Beats by The Chemical Brothers, this video is to the point and completely awesome.

I think this type of video is necessary to show to stakeholders, who have not had an introduction to Agile or Scrum.  In this ADD world we live in, I think we need to deliver some information in the same way we would deliver features in a Sprint.  Go for the items of highest value and deliver them in a short period of time.  Additionally, deliver the information is a way that it can stand on its own.

I remember getting 50 government people in a room with an experienced Scrum Trainer, to introduce them to Scrum.  After several hours, some still didn't grasp the basics.  If they were forced to watch this video in the first 8 minutes of the training, I bet the day would have gone a lot differently.

Snow Removal From an Agile PM Perspective

This weekend, our house at the lake received about 30 inches of snow.  It was pretty overwhelming.  Our HOA at Lake Linganore did a very good job and I'm going to tell you why.  Two significant snowfalls ago, we waited 2 days before we saw the first snowplow.  We didn't hear anything out of the HOA.  Days later, the residents got an email from the HOA saying threatening telephone calls and emails  didn't help and to please refrain from doing it in the future.  They believed they did the best they could with the resources they had. I thought they could have done better.  I sent a very pleasant email to the HOA thanking them for their efforts.  A few days later, I sent a followup email with a proposal:  At the next snow storm, I recommended the HOA send out emails, informing the residents of the progress being made.  Whenever I don't like how a product or service was provided to me, I try to offer constructive feedback.  The next storm came, and this time, so did the emails.  There were only a few but they were very clear.  They outlined the priorities of the snow removal.  Main arteries were of highest priority.  The side streets would be tended to when they could.  This time, some residents got stuck before making it to their homes.  They abandoned their vehicles, and unfortunately, a group of vehicles got hit by a snowplow.

Though it took a few days, the HOA came and plowed us out.  Other than those who had damaged vehicles, the tone in the neighborhood was very much improved.  We understood the priorities and respected them.  The communications is what we valued the most.

This weekend, we had an even bigger storm then the last.  This time, the HOA revised their process.  We got emails a day before the snow arrived.  They advised us to get off the roads by a certain time and identified where to park to avoid getting hit by a plow.  We were also provided a list of the highest priorities in order of importance and grouped by need to have and want to have.  Lastly, we received regular emails notifying us of progress or impediments and who could expect to be plowed out next.

Here are a few successes

• They listened to customer feedback
• The process was refined, based on user feedback
• A list of objectives was made and circulated, identifying items of greatest value
• Regular communications

We received a status report this evening.  In it, we were advised another storm is on its way.  Though the community will be completely plowed by the time it arrives, we were assured the HOA will keep us informed. They added, snow removal operations will be reviewed to see what went right and what when wrong this time around and apply those lessons learned to the next storm.

Did your snow removal go as smoothly this time around?

I would love to hear your comments or stories.

Regards,

Derek

Seeing Value From The Customer Perspective

I recently sat in a meeting between a vendor and client, where the client was attempting to communicate their need to route new work deliverables to an existing Change Control Board (CCB). The contractor came back and said they believed the CCB in this case would not provide value and perhaps it should be bypassed.

Note to all vendors: Just because a process does not appear valuable to you, it does not mean the process does not provide value. The use of the CCB provides a (formal) control point helping to prevent unauthorized work and cost overruns. This goes further then just having a client billed for unauthorized work. Any work done without prior authorization has a risk of negatively impacting project schedule, cost, or quality. The mere act of doing unauthorized work impacts the scope.

I don't care if you're using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.

If you think you need to deviate from a documented or understood process, rewrite your process to account for the deviations. If you are unwilling to change your documented process, the deviation is unworthy of being done.

I created the Visio diagram (above) a few months back to help both the customer and vendor visualize what we were trying to accomplish.  The challenge was implementing Scrum in a very formal and controlled environment.

I certainly recognize many don't have such a formal process.  Instead of CCBs, you may call them Product Backlog Review Meetings.  Counter to this, you may have a very fluid and simple software development life cycle (SDLC).  If so, you still need to understand your process and you still need to communicate with your customer.  Understand what their highest priorities are and deliver.

My Merge of GTD and Kanban

I'm not going sit here an boast of being some kind of expert on Kanban or guru of personal productivity.  I'm just a Project Manager/Leader who is always keeping his eyes and ears open for newer or better ways to manage time or work.  I believe you should always try to eliminate non-value-added processes, resulting in a positive impact of customer satisfaction, while reducing support costs.  How do you do that?  You get it done as effectively and efficiently as possible. I recently completed Getting Things Done by David Allen.  It was an interesting book.  Though I use paperless processes to "get things done", David offered one bit of advice that resonated with me.  To advance a task or activity to more of an actionable conclusion, he said to ask "What's the next action?"

This parallels what I do with my Kanban (task) board.  I currently have 4 columns:  Backlog, Work In Progress (WIP), Blocked, Done.  When a prioritized task can not be worked, I put the task card (user story) in the "blocked" column.  I then ask myself the question.  What's the next action? Without asking yourself that simple question, your task may be blocked longer than necessary.  You have to understand there may be 3 or 4 steps you need to complete before you can unblock your task and get it back to WIP.  So, ask the question.

As to not ignore the obvious, I recommend you write your tasks in a standard user story format.As a [perspective], I want to [activity], so I can [desired outcome]

It doesn't matter if you use a physical or virtual Kanban (task) board.  I recommend following 3 simple rules:

1. Keep your tasks visible

2. Keep your tasks limited

3. Keep your tasks actionable

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...