Tag Archives: Agile

Continuing Certification Requirements for Project Management Professional (PMP)

The years seem to have flown by, and it’s that time again to complete my Continuing Certification Requirements for my PMP cert.

I randomly searched the web for PMP courses, then found myself back at PMI.org “Searching Activities”.  Seems like the easiest way to lookup activities because they define the activities, and the correlated list of Professional Development Units, categorized by:

  • Technical
  • Leadership
  • Strategic & Business

Based on the activities I’ve already completed, my majority of work has been accomplished in the Technical category.  I need to focus on attaining Leadership and Strategic & Business categories.

PMP 2019 Continuing Certification Requirements
PMP 2019 Continuing Certification Requirements

Here are a few activities I thought were interesting.  Appreciate your feedback on these courses, or others relating to Leadership or Strategic & Business.

Agile Team Challenges

This online course is designed to help Agile practitioners decipher and solve the problems that arise regularly in their work. The course consists of 20 short case studies that test the student’s understanding of Agile practices and provide guidance for resolving common problems

Technical: 2.00 Leadership: 2.00

Integrating Agile and Waterfall Practices

This online course is designed to help Agile proponents recognize and resolve many of the common integration issues that emerge when these two methodologies are combined. The course consists of 20 short case studies that simulate the communication and interchanges that can occur as Agile and Waterfall practitioners work to resolve differences in the ways that they see and execute tasks.

Technical: 1.00 Leadership: 1.00  Strategic & Business: 1.00

Agile for Business Analysts – How a Business Analyst Survives in an Agile Business World

The agile philosophy in software development and in management is one of flexibility and responsiveness, increased communication and just in time decision making, and the removal of barriers of bureaucracy between the business problem and the solution. The agile approach appears to be in direct opposition to intermediaries and interpreters. Extended analytical processes are replaced by short delivery cycles. Business analysts, acting as intermediaries between those with the problem and those with the solution, providing analysis of the business processes and defining requirements that delineate the solution, may find their role evaporating in the agile sunlight. Is the role of business analyst being marginalized by agile development? What does the business analyst do in the new agile environment?

Technical: 5.50 Leadership: 4.50  Strategic & Business: 2.00

Assessing, Managing, and Mitigating Project Risk

Risk management is a key function in project management. Project managers should be able to apply a variety of risk-management tools in their work, including performing risk identification, quantification, response, monitoring, and control.

Technical: 3.00 Leadership: 3.00  Strategic & Business: 4.00

Managing Conflict on Project Teams

As a project leader you need to be able to distinguish between when conflict is healthy and when it’s damaging to relationships and productivity. In this course, authored by Cornell Instructor Robert Newman, you’ll learn to identify various causes and sources of conflict and learn to foster healthy disagreement within a project team.

Leadership: 5.00  Strategic & Business: 1.00

Agile Risk Management

Software componentization has made software more unpredictable because unforeseen conditions can cause components to interact in ways we hadn’t imagined. Greater complexity, increased user expectations, and our desire to use agile with ever increasing velocity require that we actively manage uncertainties and risks. Classic risk management identifies risks and prioritizes them to determine impact to the project, but how does that differ in an agile project? Agile is designed to handle uncertainty in requirements as new features are requested and priorities shift. What about the uncertainties outside of requirements changes? Understanding those risks even before the project gets started—and those that can possibly derail the project after delivery—is critical. Phil Lew and Moss Drake provide insight into the uncertainties and risks involved in agile software projects and supplements classic risk management approaches with how and when to apply within an agile process.

Technical: 3.25

Seven Interview Screening Questions for an Agile, Project Manager

It seems like only yesterday I was on the other side of the table, asking interview screening questions to perspective project manager candidates.  Here are seven interview screening questions I was asked earlier this week for an Agile, PM role, and my answers.

Background:

I’d consider myself an Agile Project Manager rather than a Scrum Master.  Differentiation?  I see the Scrum Master role as a coach / facilitator to help the team function using the Agile / Scrum methodologies.    The agile PM role, in my mind, does the coaching/facilitation as well as filling the traditional role as the PM.

Questions:

1.  What is the duration of the Sprint Cycle?

On scrum teams I’ve lead and been apart of in other capacities, its ranged from 1 to 2 weeks, but mostly two week sprints. In one instance, we had two week sprints, and then just after our major release to our client, we set the sprint to one week duration so we could incorporate client feedback ASAP.

2.  What are the various Agile ceremonies you conduct from day one to the last day of the sprint?

Project Kickoff – not necessarily limited to Agile, but is a project ceremony to get the team acquainted with roles and responsibilities, understanding scope at a high level, and the overall project duration expectations.

Initial Combing the Backlog with the Product Owner, and Tech lead(s) to identify priority backlog stories, and technical dependencies for the initial sprint(s), potentially looking ahead to 1+ sprints

Sprint Open #1 (all matrixed team members partake) In this meeting there are a number of activities that may occur:

  • Reviewing the Backlogwith the team in business priority sequence.  Fleshing out the user stories’ definitions, where required, enough to score each story
  • For each User Story in the Backlog prioritized for the current sprint, the team mayperform an efforting exercise to derive the ‘story points’. Playing Planning Poker is one way to derive story point estimates
  • Each of the story point estimates adds up to determine the potential velocity for the sprint, or team output potential
  • User stories assigned to the current Sprint are ‘Accepted’by the team for implementation in the first sprint, and are assigned to team members. e.g. for coding, doc, infra, or additional vetting, such as Architectural Spike stories.
  • Product Owner, Project + Technical Lead(s) decide beforehand how long sprints will take, and roughly thepotential velocity of the team based on all story points in the Sprint.
  • Sprint Open will commence, and any tool used, e.g. JIRA Agile, will enable the Agile PM / Scrum Master toinitiate the Sprint in the SCRUM / Kanban board.  All user stories are set to an initial state, e.g. “To Do”.

Agile Ceremonies Continued…

DSUs, Daily Standups, or Scrum sessions.  Traditionally, 15 minute sessions primarily to uncover BLOCKERS, and help each of the team members to remove their blockers.  Also, discussed, work from prior DSU, and current work until next DSU

(Optional) At the ending of each sprint, a day before Sprint Close, a Retrospective meeting is held, i.e. what did the team do well. what can they do better

Combing of the backlog for the next Sprint with the Product Owner, and Team Lead(s) e.g. re-evaluate priorities; e.g. 2 uncovered additional Stories / Tasks required for Sprint #2

Sprint Close #1 / Sprint Open #2 – Many times Sprint Close, and Sprint Open are combined, or may be separated depending upon the scope of the sprints.  I’ve sat through 4-5-hour Sprint Close sessions.  The Sprint Close may have each of the stories marked as status ‘Done’ reviewed by the team including the Business Product Owner.  A demonstration of the User Story, if applicable, may be performed, e.g. a new button function.  The team demo may occur by anyone on the project team.  The product owner may be required to move the status of the user story to ‘Accepted’ as a final status.  Additionally, burn down charts, and other visual aids may be provided to the team to uncover the team’s projected velocity on par with actual results, and lead to projected effort adjustments.

Sprint Open #2, similar activities to Sprint Open #1.  Team will see what stories they planned to complete, but did not.  Should the team push these stories to the next sprint, or to the backlog for future implementation.

Each sprint in the strictest sense, the content delivered should be ‘deployable’, a commitment to release work into target environments (e.g. Staging, Prod)

3.  When a project starts, how do you figure out the project scope?

Some projects with ‘external’ clients have a clear definition of project scope in the statement of work (SOW).  Other times a Product Owner may have a list of items solicited from product stakeholders.   These are two possible inputs to the ‘Product Backlog’ maintained in any Agile/Scrum facilitation tool, such as JIRA Agile, or Microsoft’s Team Foundation Server (TFS).

Combing the Backlog with the product owner, and tech leads may enable the team to add more details / definition to each of the User Stories in the Backlog.  In some cases, team leads may assign user stories to an Architect or Developer for the purpose of refining scope, and adding ‘sub-tasks’ to the user story.    In addition, some project scope needs to be defined and refined through ‘Architectural Spike Sessions’.

4.  If a Scrum Master is [managing] multiple projects, do they follow the same process for each project?

It helps if a consistent process is followed across scrum projects to eliminate confusion, and potential work across projects.  However, following a consistent process is not required, and there may be business or technical reasons to alter process.

5.  What kind of reports do you create in your Agile projects? Explain the reports.

Burn down chart – line chart representing work left to do vs. time.  Helps to understand if the team will achieve its projected work goals; shows the actual and estimated amount of work to be done

Velocity chart – bar chart (per sprint) showing two grouped bars, one for commitment, and the second for completed.

6. If you have a team resistant to Agile, and are saying there are too many meetings and the process is micro managing the effort, how will you resolve this and convince them to use Agile?

Be on “their” side: “I agree, our daily standups should be all about blockers” How can we remove your blockers inhibiting your work.  “Sprint Open” is a vehicle to clarity on work to be done, and a quick turnaround time during “Sprint Close” are we delivering what the product owner is looking to achieve?  Keeps us focused on what is committed to by the team.

7.  How do you figure out the capacity of a project?

“Capacity of a project” is a ambiguous statement.  If you want to understand what can the team achieve within a given period of time, you establish (sometimes through trial and error) and verify the velocity of the team, how many points they can roughly achieve for a sprint.  Create buckets, or sprints from the backlog work, effort the user stories sprints, and an estimate is derived.  With each sprint, those estimates will be refined with a better understanding of scope and velocity.

Content from this post provided by Ian Roseman, PMP, CSM

The Art of Playing the Hand You’re Dealt

Being a Scrum Master, in some ways, is harder than being a Project Manager, because the people on the project do not report to you directly or through a matrix management organization. A Scrum Master is charged; however, with keeping the team on task, setting up and facilitating team meetings according to Scrum methodologies, producing reports, and overall to help facilitate the removal of blockers to help the team to close sprint product backlog items, and deliver releases.  It was challenging enough not having direct management responsibilities.  Now add a new process, and few tangible, people management incentives, and you would think deploying systems would get more challenging.  However, the Scrum methodology, an iterative process, an agile software development framework for managing software projects, once thoroughly adopted by team members, should make the deployment process more dependable, enables your consumers to see incremental progress of products, thus allowing for a course correction, while enabling your team to provide more refined estimates on releases.

A scrum team is formed from all sorts, software developers, release, or configuration management staff performing deployments, infrastructure staff managing hardware, representation from business constituency, and Quality Assurance traditional test or use case validation staff, which seem to be junior developers these days, and they all come together to deliver for each sprint.

As the Scrum Master, depending on the level of process required or desired from your organization, your role may be diminished to a glorified facilitator, if that’s what you believe is glorious. It may be a bit of fun, if you choose to make it, and if you have a great Scrum Master, and elements of a talented team.

NOTE:

A release is a set of sprints, and the duration of each sprint time is constant,e.g. there may be 6 sprints in a release, each sprint lasting two weeks.  The duration of the of sprints should be static, and the Scrum master may even setup the calendar date and time in advance for the whole release.

I’ve dissected agile, scrum methodology into six major components, as it has been used in practice on several teams of the teams I’ve been a part of, using this methodology:

1. Meetings

For small or large corporations the agile team works, even if you have a very small team trying to deliver new functionality, and constantly in bug/fix mode, or a large team with a vast amount of resources.  If you feel you are always having fire-drill meetings, put down the fire extinguisher, and listen up.  There are fewer meetings with this agile process, in fact, if there are too many meetings, we might want to call the meetings themselves out as ‘Blockers’, which we will get to in a moment.

I recommend three types of meetings with agile teams that will help you both deploy and support your product: a daily stand-up meeting, a retrospective meeting, and a sprint open/close meeting, and the final sprint meeting may serve as your release end review.

The daily stand-up meeting, or DSU, should be at most a 15 minute session, which each member of the team says, what they worked on yesterday, what they plan on working on today, and any Blockers they might have.  The scrum master facilitates these meetings, and if he or she hears a blocker announced, they try to crawl the group to get some assistance from the rest of the team members to remove the blockers.  What can we do to remove the blocker, should be the resounding question, and anything that prevents your progress on the tasks assigned to you for your product backlog items (PBI) is a blocker.  To back up one moment, a clarification PBIs are similar to change requests, or modification requests that you’ve worked with before, however, they may be written in an abstracted way, and then there are tangible tasks, which are ‘children’ objects are associated with the Product Backlog Item (PBI).

Next is the retrospective meeting, what can we do better next time, what did we do well this sprint, and so on.  There is typically one of these retrospective meetings per sprint, just before sprint close.  Finally, there is a Sprint Close and Sprint Open session combined that serves as a PBI demo for the completed items, and an assignment portion for the next set of PBIs to be worked on for the next sprint.  This meeting is the bulk of where the processes takes place.

2. Product Backlog Items

In the initial Sprint Open meeting, you review all of the product backlog items, which may or may not have an associated business priority at the time.  Some teams use 1 to 1000, where 1 is the highest priority, up to the 100th priority may get ‘Committed to’ for the current sprint, and anything over 100, may get deferred to the next sprint, e.g. 200+.  Sometimes, if the team knows they won’t put a product backlog item in the current release, they set the business priority of the PBI to 1000, where it sits in the backlog to be reviewed for a future release.

During the sprint open, the business representative, with input from all of their sources, e.g. marketing, sales, assigns the highest priority to the PBIs they would like to go into the first sprint, second sprint,… and the entire release.  This process may actually happen before the Sprint Open meeting with the development leads, who may understand the dependencies of the PBIs to help guide the business people.  In attendance is also the scrum master, which is in most meetings to keep discussions limited on any particular item, for example.  If the Scrum Master during any of the meetings finds the conversation drifting into a long, and drawn architecture discussion, the team may decide to make a separate PBI for the discussion worth typically 1 point.

3. Points

The Scrum master will sort the order of the Product Backlog of Items by business Priority, 1 being the highest, and that’s the order in which the team goes through PBIs.  After each product backlog item (PBI) is assigned a business priority, the development team leads, in the Sprint Open, ‘commits’ to achieving them within the agreed sprint time. During the Sprint Open, the people on the Sprint Open (all team members) may add a bit of color to the description of the PBI, then it’s “Poker Time”.

4. Planning Poker

There are many free web sites, or utilities out there that help you facilitate planning poker. e.g., http://planningpoker.com/ or some teams just cut construction paper, and put a number on each page.  We will use the web site in our example.  EVERY team member logs onto the site, and sees a set of cards with numerical values 1/2, 1, to 100.  Different teams do poker in alternate ways, but what you are supposed to do is correlate the entire effort you think it will take to deliver a particular PBI, regardless of your role or intimate knowledge of the PBI.  You may ask questions to get an understanding of the request, but the idea is to vote on it, especially / even if you are not doing the work on the item.  This process is more physiological in nature, and should alleviate any deflation, inflation, or wild guestimates over time (e.g. multiple sprints, or releases).  There are natural habitual things people do when they provide estimates.  The person may want to impress their boss, and provide a deflated, or aggressive estimate.  The boss may in fact try to skew the inflation to the business representative(s) to put the product out ‘sooner than humanly possible’, or a person on the project may inflate their estimate to get more time than required on the project for whatever hedonistic reason.  All players put in their score of effort, e.g. 1 = 1 person day, for example, and each card is facing down until all team members enter their cards, then the scrum master presses the button to flip the cards, and the negotiation process begins.  The scrum master bargains with the highest and lowest scorers, “Can you come down from a 5 to a 3?” and “Would you be willing to go from a 1 to a 3?” to drive a consensus.  The team members talk about why they scored a particular item a certain way, and eventually some consensus is reached without using the heaving hand, or the boss persuading the vote.  This process helps over time give more predictable estimates from the team, and you may discover the average output of the team, with a few variable factors, such as blockers.  In the Sprint Close, the Scrum master may actually show a graph, here are all the PBIs we committed to in this sprint, here is their point value, and here is what we earned, and here is what we tried to earn.

5. Demonstration and Deployment

If you say all sprints are two weeks, rain or shine, you have the sprint close meeting, demonstrate the PBIs that were achieved, and theoretically, each sprint can and may be deploy-able to every environment, including production, if required.  Typically, you would wait till the final sprint close before deploying to production, but it doesn’t always happen that way, especially if we have a support bug/fix along the way.  That’s why each PBI is discrete and deploy-able on each Sprint Close, so when you assign the item after the points are agreed to, and close the PBI, it must be thoroughly tested (by whomever), and ready for production, that’s why you may associate several tasks to a PBI, such as unit, module, and system integration test case creation and execution.  If PBIs that are assigned to staff do not get updated with a status from Assigned to Closed, then those items during Sprint Close get reviewed during the second half of the meeting, in the Sprint Open, and the team decides if they want to move them forward to the next sprint, release, or to the backlog for a future release.

6. Incentives and Detractors

One incentive mechanism for the team is awarding team bucks.  This can be a great way to award team members.  Each person on the team gets imaginary team dollars, and they are to award monthly their allotment of team dollars to co-team members, and the team member should state some reason, however abstract, why they are awarding their allotment of money to this individual.  So for example, the Scrum Master at the end of each sprint, month, or some frequency which makes sense for the release(s) will say to the team staff, it’s the closing of the sprint/month, and you should allocate your, let’s say five dollars, to your co-team members.  Team members may divide their abstract money across a few of the team members.  At the end of the release, the senior staff, it would be a business sponsor, who is funding the project, would do some conversion, and allocate a monetary value correlation.  If it’s a large organization, there may be an internal store that sells company logo labeled supplies, so you might get a company mug, or tee shirt.  I have used this technique in at least one place, and it is mildly effective.  Depending upon team morale, they can be enthusiastic about it, or feign enthusiasm.  Either way, win, win.

One infamous detractor to coming late to meetings or swearing during meetings is “The Penalty Jar”.  I’ve used this technique, and heard about it in quite a few places.  It’s a basic premise, your late to a meeting, put a dollar in the jar, change, or whatever.  A collective donation, which is then used to perhaps buy pizza on the night of releases.  Jokingly some managers might off hand swear lightly and put a fiver in the jar, just to uplift morale.  It is a physiological counterweight effect, that depending upon the team attitude and company policy, some may say enforce swearing, but it’s light handed, and the fiver is meant to imply the manager is ‘paying forward’ to encourage the team toward the end goal, the release.

Conclusion:

I hope this was an easy read.  Many teams are using these methodologies today, but surprisingly, some have yet to adopt this process.  At times, this process may be challenging when interacting with on and offshore teams that have great differences in time zones because teams prefer to have the DSU in the morning or midday the latest, while the blockers are fresh in their minds, and able to help others get un-blocked after the call.  I’ve seen it work well with a 9 AM <->12 PM timezone delta although it could be done with a middle person playing the role as the off shore liaison.  However,  even if there are no language differences, the lack of full team interaction may inhibit team members to unblock someone for some cases, which require direct peer to peer team staff interaction.  Alternately, staff sometimes work off-shift to solve some blockers.

Google Plus…Beta in Progress

Last night I was driving my daughter and her guy friend home from an after school program, and I really like this kid, he’s a little tech geek like me.  I spoke to this computer savvy twelve year old kid, and was asking him all these questions from a kid’s perspective about all these new technologies.  He was articulating and rattling off thought provoking and meaningful information.  It was like I was talking to an industry analyst, bright fun, good kid.  He and I talked non-stop, and after we dropped him off, and I realized we monopolized the conversation, and my daughter might have wanted to get in a word, so I apologized.  Forgot what it was like to be teen, a girl no less.

Anyway, in the mist of our discussion the kid said he uses a gmail account instead of his default ISP.  I asked him about what he thought of Google Plus.  He said he did some exploring of it. “Yeah, Google + was created to compete with Facebook, but it’s not really that great.”   I asked him if he knew about a few features I thought were cool, and his response was “No, not really, Instagram,” he said “was ‘killin it’ though.” We went onto more market analysis of the space.  I was amazed.  Kids.

It was then I realized why the kid didn’t get past the first page.  Appeal and usability.  These are concepts in User Interface design and are essential in attracting users. These types of features are usually added later on.  The standard technology mantra, is “Make it work, then make it work [faster, refine UI, etc].  If I was trying to really be unbiased, Google Plus is tantamount to a Beta product.  As an example, the “Your Circle” buttons truncate the Circle name, are square shaped, and don’t have an appeal.  In fact, many of the user interface features feel canned.  The user interface is not the focus initially when putting out a product, especially when you are in a rapid mode of delivering, and are certain your product may change drastically, i.e. based on your road map, user feedback, and so on.  Although I really like the baseline platform, and am trying not to be, I am a bit biased in favor of Google.  Google Plus looks like they are using the Agile methodology with Scrum Sprints and constant releases. To be clear, I am using their own, Google’s latest browser Chrome, on Windows 7 with a powerful computer.

So, what does this teach us?  Well, in Project Management, sometimes you can add all the resources in the world to a project, but at some point you get diminishing returns, and there is a limit to delivery capability even using Agile and Scrum methodologies, especially if Social Networking is high on Google’s agenda.  Agile requires user feedback, hence the release, and user response cyclical feedback loop.