Blogging 2015 in review


The WordPress.com stats helper monkeys prepared a 2015 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 290,000 times in 2015. If it were an exhibit at the Louvre Museum, it would take about 12 days for that many people to see it.

Click here to see the complete report.

There were 17 pictures uploaded, taking up a total of 319 KB. That’s about a picture per month.

The busiest day of the year was November 3rd with 1,427 views. The most popular post that day was Time Management—Formulas relating to PERT analysis.

I am about 1/3 of the way through my project of going through the Agile PM Process Grid, which is the equivalent in size of the project I did in 2012 when I went through the entire Project Management Body of Knowledge, and again in 2013 when I did the same thing for the PMBOK 5th Edition.

I intend to go to WordPress Blogging University to see how I can improve my blog, both in appearance and in terms of content.   My goal is to reach 1,000,000 views and be of help to those who are trying to pass not only the Project Management Professional (PMP) certification exam, but the Agile Certified Practitioner (ACP) exam as well.

 

Advertisement

Agile PM Process Grid–Feature Breakdown Structures


John Stenbeck, in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates a grid of all 87 processes used in Agile project methodology.   They are divided into five process groups and 7 knowledge areas.

The past two posts have covered “3.8 Agile Estimating,”  that is, the eighth process in the third knowledge area of “Adaptive Planning”, which just happens to fall in the “Planning” process area.

This post covered a tool used in agile to accommodate                                         the short-term need for stability during the sprint and the long-term need for flexibility outside the sprint.    The tool is FBS, a Feature Breakdown Structure, analogous to the WBS or Work Breakdown Structure used in traditional PM.

The FBS is useful as a tool because it helps:

  1. The prioritizing of the customer/proxy’s business value
  2. Alignment of the customer/proxy and the project team by use of a common lexicon, expressed in the form of user stories and related tasks
  3. Analyze and identify variances between estimates and actuals.
  4. Participatory decision-making, because it helps extract important information in a workable form.
  5. Implementation of sustainable, effective solutions to complex problems that cannot be fully defined in advance.

The next post will cover process 3.9 Sizing, which helps define the relative development effort required to complete stories.

Agile PM Process Grid–3.8 Agile Estimating (2)


John Stenbeck, in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates a grid of all 87 processes used in Agile project methodology.   They are divided into five process groups and 7 knowledge areas.

Today I am continuing to cover process 3.7, that is, the seventh process in the third knowledge area of “Adaptive Planning”, which just happens to fall in the “Planning” process area.

In the last post, I talked about general principles behind agile estimating, and I continue that discussion here.   Specifically, I want to talk about the “cone of uncertainty.”    While customers interact with the team, their focus oscillates back and forth as they find the real boundaries of the problem and clarify the solution to it.    So stakeholders need to meaningfully engage with the team in order to move through the “cone of uncertainty” and find the optimal solution.

coneofuncertainty

How does this effect agile estimating?   As the amusing diagram shows above (taken from agilenutshell.com), it’s best not to make promises about how long it will take or how much it will cost to complete a project while the parameters of the solution are still being worked out (the “skull and crossbones” section of the graph).   Only when the solution starts to be relatively well defined can you be in a better position to make promises based on estimates (the “sunshine” section of the graph).

Understanding the cone of uncertainty requires that you understand two dynamic forces which seem to be opposing forces, for those who are new to agile frameworks.   These two forces are:

  1. Organizations need stability–in order to plan the marketing and other business functions that will be affected by the solution being developed.   So the definition of what is being developed needs to be stabilized.
  2. Agile teams need flexibility–in order to define how the solution is developed.

How are these supposedly opposing forces reconciled?

  1. Flexibility is provided with the roadmap (program level) and release plan (project level) timeboxes, as well as product backlog grooming; stability is provided with the iteration timebox (and committed iteration backlog).
  2. Customers need to be able to change their minds about requirements during the project.    Stability in the short term is provided during the sprint, when requirements are not allowed to change, and flexibility in the long term is provided outside the sprint.   The customer/proxy must then be committed to postponing changes until the end of any given iteration.

Another tool related to agile estimating is the Feature Breakdown Structure (FBS), the analogy of the Work Breakdown Structure in traditional PM.   This is discussed in the next post.

Agile PM Process Grid–3.8 Agile Estimating


John Stenbeck, in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates a grid of all 87 processes used in Agile project methodology.   They are divided into five process groups and 7 knowledge areas.

Today I am covering process 3.7, that is, the seventh process in the third knowledge area of “Adaptive Planning”, which just happens to fall in the “Planning” process area.

This post will cover some general principles related to agile estimating.   One important point that John Stenbeck makes is that estimates are, by definition, inaccurate.    Why?   Because they are usually made based on assumptions, which may change.    However, management needs to know the value of the constraints of time and cost, i.e., “when will the project be done?” and “how much will the project cost?”   There is a fundamental tension between the desire to have accurate estimates and the difficulty in achieving them, which only increases as the complexity of the project increases.  Because there is a general trend nowadays towards projects with higher and higher complexity, that means that the difficulty of achieving accurate estimates is also on the increase.

Besides this fundamental tension mentioned above, there is an additional factors which compounds the problem.   There are two risks involved with, say, a time estimate for any given activity:  the risk that that the duration be under-estimated and the risk that the duration be over-estimated.   However, these risks are usually not equal.   In general, the risk of the time estimate for an activity to be under-estimated is higher than the risk of it being over-estimated.    Maybe this is because estimates are done with a desire to be optimistic and to please management by achieving the project within the shortest duration possible.    (The same risk, of course, occurs with the cost estimate.)

Now, the next point to understand is that estimation involves figuring out how many resources, either of time or cost, are to be devoted to an activity, but the estimating process itself requires the spending of resources.    In agile estimating, the idea is that you should spend resources on estimating in direct proportion to the accuracy they provide, which is a measure of how much value the estimate has for those planning the project.

So if the probable accuracy of an estimate is low, then one should minimize the resources spent on that.   On the other hand, if the probable accuracy of an estimate is higher, then one can invest more resources in producing that estimate.

In the next post, I will discuss the cone of uncertainty, another important principle behind agile estimating.

 

 

Interfaith Symposium 2015


I was invited to the Interfaith Symposium 2015, a parallel event at the 14th Annual MAS ICNA Convention held at this time every year.    The convention draws over 15,000 of the Muslim faith, and this year was the first time the convention reached out and created an Interfaith Symposium.    Leaders 0f the interfaith movement from various faith communities around the Chicagoland area were invited to be speakers, and I was invited as a Board member of the UUCC Park Forest Church.

At the luncheon, Dr. Tariq Ramadan, Professor of Contemporary Islamic Studies at Oxford University, who teaches at the Oxford Faculty of Theology, spoke on the importance of the interfaith movement.

Then, in the main hall, 9 members of the interfaith religious movement in the Chicagoland area were given the platform to talk about what importance they placed in the interfaith movement.   These speakers were:

  1. Imam Abdul Malik Mujahid–President of Sound Vision and Radio Islam, selected 5 times as one of the 500 most influential Muslims in the world.    He is the board chair of the Parliament of the World’s Religions.   Imam Mujahid also chairs the Burma Task Force USA to stop the genocide of Rohingyas.
  2. The Very Reverend Thomas Baima–Vicar for Ecumenical and Interreligious Affairs of the Archdiocese of Chicago.   He served as editorial advisor for the journal Chicago Studies which published the Spring 2008 issue:  “Catholic-Muslim Dialogue:  Reflections and Perspectives.”
  3. Rabbi Michael Davis–Founding member of the Jewish Voice for Peace Rabbinical Council.
  4. Rev. Dr. Stanley Davis, Jr.–Co-Executive Director of the Council of Religious Leaders of Metropolitan Chicago (CRLMC), as well as Executive Director Emeritus of the Chicago and Northern Illinois region of the National Conference for Community and Justice.
  5. Dr. Robert Henderson–serves on the National Spiritual Assembly of the Baha’is of the United States.   His initiation and direction of the study “Models of Unity” resulted in a landmark analysis of intergroup unity in the Chicago metropolitan area.
  6. Jasvir Kaur–Board member of Sikh Outreach Services, which serves local Sikh youth and seniors and coordinates efforts to feed the needy.   She is co-founder of the Sikh Healing Collective and she volunteers globally and locally in disaster relief efforts and on medical missions with various organizations.
  7. Rev. Jay Moses–Pastor at Hope Presbyterian Church in Wheaton, IL.  Serves the committee for Interfaith relations and as the Muslim Relations Coordinator for Chicagoland at the Presbytery of Chicago.
  8. Dr. Marcenia Richard–Pastor at Life Center Ministries.  Formally the Executive Director of the Peace Coalition against Violence at St. Sabina, Marcenia is also the founder of Fierce Women of Faith, an interfaith coalition of women advocating for peace.
  9. Rev. Dr. Mark Swanson–The Harold S. Vogelaar Professor of Christian-Muslim Studies and Interfaith Relations and Associate Director of Center of Christian-Muslim Engagement for Peace and Justice.  He is an ordained pastor of the Evangelical Lutheran Church in America.

As you can tell by the bios of the speakers, they combine ferocious learning with a passion for reaching out to others of different faiths, including those of the Muslim faith.

There were several themes that came up in Dr. Ramadan’s talk at lunch and the interfaith speaker panel afterwards.

  1. Getting involved in interfaith work first requires knowledge.   If you say you tolerate those of a difference faith, that means you are passively (or perhaps passive-aggressively) disengaging yourself from them.    Positive acceptance  comes from approaching those of another faith not in the spirit of proselytizing, but of wanting to learn more about the other’s faith.
  2. Getting involved in interfaith work requires a vision, a plan and resources.   The vision comes from the faith of each individual, but a plan requires that the group come up with pragmatic goals that can be achieved.    And the resources need to be sought locally, in the community, first before trying to get resources from outside the community.
  3. Interfaith work means effective communication, which in this day and age means social media.   The traditional media are loathe to change the “traditional wisdom” with regards to any given topic, which sometimes means ignoring stories that don’t fit the established narrative, but they are often forced to cover topics that have created a stir on social media.

I was pleased to have been invited as an attendee, due to my position as Board member of UUCC Park Forest.   I hope the stimulating conversation and connections made at this event will bear fruit in 2016 to have the different faith communities work together for social justice.

Agile PM Process Grid–3.7 Definition of Done


The last post covered process 3.6 Iteration Backlog, where negotiating is done between the customer-proxy and the team as to what user stories the team is committed to completing by the end of the iteration.

Part of that negotiating exactly contains the process that is the subject of this post, 3.7 Definition of Done,

Okay, let’s say that the team completes all of the user stories to its satisfaction by the end of the iteration.   All’s well, right?   Well, not if the customer looks at the work and declares that it isn’t done to the customer’s satisfaction.   That’s where the Definition of Done comes in.

It lists all of the specific activities to be finished and all the tests to be done so that a specific user story can be said to be complete.   It’s important to list this out in an explicit and concrete manner so that they can be misunderstanding at the end of the iteration between the team and the customer/proxy.

Sometimes creating an appropriate definition of what “done” means can be a lot of work, but cannot be avoided or done sloppily, because it will create the potential for results that are disappointing and frustrating for both parties.   This means that there will have to be rework done, which wastes time and personnel resources, but it also damages the relationship of trust between the parties, and that is the real “currency” that the project rests upon.

After a brief break tomorrow for a post on another topic, I will return two days from now with a series of posts on processes 3.8 and 3.9 Estimation and Sizing.  These processes are at the heart of agile estimating and I look forward to tackling them, which may take several days worth of posts.

 

12 UU Gifts to the Christmas Tradition


Unitarians and Universalists combined in 1961 to form Unitarian-Universalism, a liberal Christian religion that holds several principles in common, among those being social justice, and an appreciation of the diversity of religious practices of other religions.

Today it is Christmas, and I wanted to share with readers the 12 gifts that Unitarians or Universalists have given to the Christmas tradition, at least as it is practiced in the United States.    These gifts reflect the principles I mentioned above.    These historical footnotes were taken from a sermon given by Rev. Denise Tracy, who was the celebrant for our Christmas Eve service last year.

  1. In the American colonies in the 1700s, while the Pilgrims were against the celebration of Christmas, Unitarians began celebrating Christmas by serving others on that day, particular the poor and less fortunate.   A narrative description of this can be found in the beginning of the story “Little Women” written by Unitarian Louisa May Alcott.
  2. In 1798, a British Unitarian, Samuel Coleridge, wrote in an article for the Christian Register, a British Unitarian newspaper, about the German tradition of giving gifts on Christmas.    As a result, the idea of gift giving began in Unitarian homes in England and then spread across the ocean to the USA shortly afterwards.
  3. In 1821, a baby girl named Clara Barton was born in the early hours of Christmas day.   She became known as the “Other Christmas Baby.”  She grew up as a Universalist, became a nurse during the Civil War and later founded the Red Cross.   (This is more of a gift from Christmas to the Unitarian-Universalist tradition.)
  4. In 1823, Clement Clark Moore, a Unitarian, wrote a poem called “A Visit from St. Nicholas.”   By that time, Christmas was a religious celebration, but he wanted to have Christmas as a holiday to be enjoyed by children as well.    The poem became well-known as “The Night Before Christmas.”
  5. In 1825, a Unitarian scholar named John Bowering, wrote the Christmas song “Watchman, Tell us of the Night,” which advocates the values of peace and truth.
  6. In 1833, a Unitarian Minister named Charles Follen placed a Christmas tree in a public building for the first time in America, at the Unitarian Church in Lexington, MA.
  7. In 1843, the British Unitarian Charles Dickens wrote the Christmas Carol, in which Ebenezer Scrooge is visited by three spirits that try to make him repent for his selfishness and hard-heartedness.   In the end of the story, Tiny Tim proclaims the Universalist sentiment “God bless us every one!”
  8. In 1847, a Catholic named Placide Cappeau was commissioned to write a poem entitled “Cantique Noel.”   He asked his colleague, Adolph Charles Adams, to write the music.   When it was discovered that the music was written by a Jew, the music was forbidden to be performed in the Catholic Church.   In the USA in 1855, an ardent Unitarian abolitionist named John Sullivan Dwight, translated Cantique Noel into English, and we know it now by the title “O Holy Night.”
  9. In 1857, an abolitionist named James Pierpont, who was a Unitarian minister in the Savannah Unitarian Church in Georgia, was missing his home in Massachusetts in the wintertime when he wrote the song “Jingle Bells.”
  10. In 1849, Europe was embroiled in war and the USA invaded Mexico.  Unitarian W. P. Hunt wanted a hymn with a vision of Peace for the World, and since he didn’t find any that he liked, he wrote “It Came Upon A Midnight Clear.”
  11. In 1863, Henry Wadsworth Longfellow’s only son was severely wounded in the Civil War.    His wife was in the midst of melting sealing wax, when she accidentally set fire to her own gauzy clothing and was enveloped in flames.   She died the next day.   On Christmas morning, Longfellow heard the bells from the church and wrote the song “I Heard the Bells On Christmas Day”, as a way of saying that despite his personal tragedy, he would not lose faith.
  12. In 1962 at the height of the Cuban Missile Crisis, a Unitarian Universalist couple from Connecticut, Gloria Shayne and Noel Regny, wrote the words and music to “Do You Hear What I Hear?”.  They wrote it as a prayer for peace on behalf of the world’s children.

So no matter what spiritual tradition you belong to, I wanted to present you with this post showing the gifts that Unitarians and Universalists have given to the celebration of Christmas here in the United States.

Agile PM Process Grid–3.6 Iteration Backlog


In this series of posts, I’m discussing those processes that are related to the “Adaptive Planning” knowledge area.   The last process was 3.5 User Stories and today’s post is 3.6 Iteration Backlog.

The goal of iteration planning is to take the group of user stories in the product backlog and choose a subset that the team can complete by the end of the iteration.

Who makes the decision about what’s going to go into the iteration?  That’s the result of negotiation between the team and the customer/proxy.   The customer/proxy will be arguing for the largest number of user stories to be put in the iteration, whereas the team will more conservative in their estimation of the number of user stories for the obvious reason that they will be doing the work.

Once the result of the negotiation is complete, however, a reciprocal commitment is made:   the team commits to completing the user stories specified in the iteration backlog, and the customer/proxy commits to not adding new stories or changing the priority of the stories in the current iteration.

For the user stories to be complete, the customer/proxy and the team have to agree upon what the “definition of done” is so that they is no room for ambiguity.   That is the subject of the next post.

Agile PM Process Grid–3.5 User Stories


The process of using user stories is the first process in the Planning Process Group and the Adaptive Planning knowledge area in John Stenbeck’s “Agile PM Process Grid”.   The “3” in the “3.5” refers to the fact that it is a process in the third knowledge area of Adaptive Planning.   The “5” refers to the fact that, of the processes in that third knowledge area, it is the 5th process to be done in Agile PM.   The first four were done in the Initiating Process Group.

With that orientation of where we are in the agile process grid, let’s now discuss why user stories is the first process in agile planning.    A user story is a tool or technique used to capture an important piece of functionality that the customer feels is valuable.   The word story denotes that it describes something that the customer wants to do, enabled by the functionality that the team will be creating.

The customer/proxy is primarily responsible for writing user stories on cards that include important details like the acceptance criteria, tests for that functionality, and a definition of what it will look like when it’s done.

On the card you can leave an empty space in the upper corners to designate the relative “priority” of the user story and the “size” of the user story (how long it will take to develop).

The top half will contain something along the lines of:

  • As a (role), I want (something; function) so that (goal, benefit).

The second part is the acceptance criteria, the format of which is usually something like:

  • Given (a condition) when (a trigger) occurs then (an outcome) is produced.

As mentioned above, the user stories are put on sticky notes or index cards, and then they can be arranged in order or priority and or size.  This facilitates discussion and planning focused on the end user’s view of the feature.

There are two advantages of user stories.

  1. They emphasize face-to-face communication, which reduces the time and cost of idea transfer.
  2. They contribute to the continuous replanning of the product backlog, as adjustments may need to be made if the priority or size of a user story changes.

User stories are action oriented and so is the participatory decision-making process which utilizes them.

The next post covers the nest process 3.6 Iteration Backlog.

Agile PM Process Grid–2.6 and 2.7 Decomposition and Progressive Elaboration


John Stenbeck, in his book “PMI-ACP and Certified Scrum Pr0fessional Exam Prep and Desk Reference” has set forth an Agile Project Management Processes Grid.

Today I’m doing a post on the process 2.6 Decomposition, which breaks down features into small items called user stories.   Process 2.7 Progressive Elaboration is a process which users story maps to arrange the user stories in a way that aligns with the goals of a market and development plan, and simultaneously organizes the user stories accordingly to their complexity.

The first purpose of a story map is to identify the highest priority features for development.   Stories are arranged vertically according to their importance, and so the stories at the top of each column are the ones that are destined for release first.

So the user stories that make up the first release are then grouped together, followed by the ones that make up the second release, and so on.   They are divided by natural fracture lines, which occur where a potentially shippable product becomes an actual shippable product, or release.

The second purpose of a story map is to help determine how fast the solution development can be expected to progress and to set a baseline schedule.   Stories are arranged horizontally according to the size of the user story, from smallest to the largest.

Once the user stories are grouped together by natural fracture lines into those that belong to release #1, release #2, and so forth, then the total number of user stories in each release can be summed up.   Then, with an estimate of the team velocity (the amount of user stories that can be reliably completed in an iteration), the number of iterations required for each release can be calculated.

The next process is in the Adaptive Planning knowledge area, and it is the tool of 3.5 User Stories.