4squareviews

In the third chapter called “Initiating Projects” of his book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck starts the discussion of the first process group called “Initiation” by making a quick comparison of this process group between traditional project management and agile project management.

Similarities between Initiation in Traditional vs. Agile Project Management

Before discussing the differences, John Stenbeck mentions the similarities.   First of all, he stresses the importance of project initiation for both traditional vs. agile project management.    Planning is about being efficient in reaching the goal of the project, initiating is about being effective in reaching the goal.    To put it another way, planning is about climbing the ladder to get to the top of the wall; initiating is about choosing the right wall to climb.

In terms of processes, stakeholder identification is a process common to both traditional and agile project management.    PMI has addressed the increasing importance of stakeholder engagement in the traditional PM framework by making stakeholder engagement a new knowledge area unto itself with the publishing of the 5th Edition PMBOK Guide at the end of 2012.

Differences between Initiation in Traditional vs. Agile Project Management

If you think of the three triple constraints of scope, time and cost, traditional project management focuses on scope, and then figures out in the planning stage how much time and cost it will take to achieve that scope.    In agile project management, on the other hand, it is time which is usually focuses on as the chief constraint, and then in the planning stage one figures out how much value can be added in any given stretch of time.

Given this different approach to the triple constraints right from the start, the details of the initiating process group start to diverge right from the start between traditional and agile project management.

Given the Agile Process Map that was described in the last post, the portion of that map that comes under the initiating process group will be discussed in the next post.   After that overall process is described, I will start to go into detail about the individual project management processes that make up that overall agile process.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, in the second chapter called “Introducing Agile Project Management”, he tries to strip down the essentials of what constitutes agile project management into something he calls the “Agile Process Map”.

The Agile Process Map

The agile process flows at a macro level from the first steady state to a transition state and then to a second steady state.

When I thought of this general process, I thought of a “Turing machine”, a mathematical model for an idealized computing device that consists of a paper tape which is divided into squares going through a read/write head.    When a square of the paper tape goes through the read/write head, it registers a “0” or “1”, and then the paper tape moves one step forward, with the next square being read by the machine.    The reading of the first square is like the “steady state” described in the graphic above, and then there is a transition state to the next square, which is read during the next “steady state” of the operation of the Turing machine.

Let’s go to the next level in abstraction and talk about what each of the states consist of that are referred to in the above diagram.

Steady State #1

Here are the elements that comprise Steady State #1, labeled whether they are people or documents (“artifacts” in the language of agile)

• Product Owner (person):   this person receives, analyzes, and prioritizes product features required for a successful solution to the requirements given by the customer
• Product Backlog (artifact):  this is where the product features are listed by the Product Owner
• Iteration Backlog (artifact):   this is where the product features are chosen out of the Product Backlog that the Team will work on during the iteration.
• Team (persons):   this is the group of people that will take the features listed in the Iteration Backlog and develop them during the next Iteration.

The reason why this is referred to as the Steady State #1 is because the list of product features in the Iteration Backlog does not change during the iteration.

Transition State

In the Transition State, there are two constants:

• the duration of the iteration
• the goal of the iteration, which is to take the features listed in the Iteration Backlog and develop them towards a potentially shippable product increment, which is a deliverable that adds value to the feature that is recognized by the customer.

Everything else in the Transition State is in a constant state of change.   Here’s how the team shapes its daily meetings to synchronize and plan the activities during the Transition State:

1.Each day when the team meets, each member briefly explains what they have done since the last meeting, what they will do before the next meeting, and what impediments are interfering with their ability to be productive.

2. The team uses the information in the above meeting to self-manage the team’s daily activities:

• each member makes reasonable progress towards the agreed-upon iteration goal; by having daily results that are measurable, external controls are unnecessary because each member holds other members accountable for achieving progress towards the goal
• each member synchronizes hand offs of work to other members as needed
• each member rallies to the support of other members who need assistance
• each member meets with the Product Owner as needed to clarify questions or concerns about features they are working on

Steady State #2

• The team has a review meeting to go over the work done on the Iteration Backlog to make sure it meets the definition of being complete.
• The team has a retrospective meeting  which focuses on the process and not the product to see how the process of creating value can be improved.

Then the Product Owner adjusts the Product Backlog, takes those features needed to be done in the next iteration and puts them on the Iteration Backlog, and you have new Steady State #1, after which the above cycle continues.

Now that is an overview of the agile process.    The rest of the book goes through the individual agile project management processes, of which there are 87, divided into 5 process groups and 7 knowledge areas.

This concludes the material in chapter 2, “Introducing Agile Project Management.”   In the rest of the chapters, the processes are introduced by process group as follows:

Chapter 3:  Initiating Projects

Chapters 4 through 6:   Planning Projects

Chapter 7:   Iterating Projects

Chapters 8 and 9:   Controlling Projects

Chapter 10:  Closing Projects

There is an eleventh chapter on how to pass the exam.

The next post will start on the material in chapter 3, “Initiating Projects.”

Filed under: Uncategorized | Leave a comment »

Yesterday our family had a funeral for my father, John P. Rowley, who had passed away earlier in the week.   We ended up having a wake for the immediate and extended family on Friday evening, and then for my father’s various colleagues, friends, acquaintances, we had a visitation on Saturday afternoon.

One of the regrets I have had is that I never wrote down my father’s stories from the various stages of his life from childhood, to when he was a soldier during the Korean War, and then afterwards as he started his career as a journalist and then ended up having two additional careers, one as a public relations manager for the United Way group of charities in Chicago, and in retirement as head of a charity called NAMI (National Alliance for the Mentally Ill).   As a family man, he ended up having five children, of whom I am the second in order.    The stories he would tell, especially those of his early life before I even existed, were the ones that I grew more and more interested in as time went on.

At the funeral however, the people that came in to pay their respects to my father and his family didn’t come in linear order based on what chapter of my father’s life it was when they met him and interacted with him.    There were people from all of his 89 years who came and went throughout the wake and then the visitation.

As I was thinking about the wonderful pageant of people who paraded through the funeral parlor this weekend, I realized it was probably easier to describe their interactions with my father not as a series of chapters, but as a series of concentric circles representing what part of my father’s life they had interaction with.   The above diagram is an adaptation of one I use when teaching about project management to represent the various levels of stakeholders of a project.    A stakeholder is one who can impact a project or one who can be impacted by the results of a project.    If you take my father’s life as a “project” In a loose way, then the stakeholders of the project known as my father’s life fall into several categories.    It’s in describing these that you end up getting a fuller, more dimensional picture of my father than the linear description of his life found in the funeral notice which I posted in the previous post.

1. My Father as Family Man

Of course, my father started life as the child of his own father, and the fact that he had an older sister and a younger brother shaped the course of his life.    His sister Mary and he were very intelligent and very good in school, and they both had a lifelong love of learning that never let them.    My father’s father died in my father’s childhood, and so in a way my father always had an awareness of the absence of his father, as if he had been, in his own way, abandoned by him.    This made him determined to stick around and be supportive of his own children.     Interesting enough, my mother had also been abandoned by one of her parents, in her case her mother, who left what we might call today an abusive relationship when the children were about junior high or high school age.    Again, like my father, this made her determined to stick around and be supportive of her own children, and my brothers, my sister and I were the beneficiaries of this determination.    My father’s mother ended up being embittered by the straitened circumstances that her husband’s death left them in, and here again, my father decided not to be like his parent, and ended up having a cheerful disposition which also remained with him to the end of his days.    Here, too, I can say we were the positive beneficiaries of this personality trait of my father’s.     When my older brother and I lost our jobs in 2010 in the midst of the economic recession that choked off the careers of many people here in the U.S. at that time, we were determined to get back into the work force, and we were both successful.    I know I can speak for my brother in saying that we credit this success to a large extent to that basic disposition of determination and positivity that we inherited from our father.

2. My Father as a Professional

My father had three careers, from 1948-1968 as a newspaper reporter, which he preferred to the more modern term of “journalist.”   He had a curiosity about the cultures, peoples, and countries of the world which never left him.   In the last year of his life, he discovered a program called “International Mysteries”, on one of the obscure international channels that came with our cable TV package, which showcased a new mystery story every Sunday evening from a different country in Europe.   It was his way of vicariously traveling, and he enjoyed the program tremendously.

As a reporter, he was very cynical about politicians, but very tenderhearted and compassionate towards ordinary people, as evidenced by his next two careers working with charities.    He left the Sun-Times newspaper in 1968 around the time that Rupert Murdoch bought the paper, because he saw the “handwriting on the wall” about what direction the paper was going to be taken, namely, sharply to the right.   However, he found a new career in public relations.   As he explained to me, “in a crisis, I know how to handle reporters because I was one once myself!”   After a brief stint in an educational publishing company called Science Research Associates, he joined the United Way of Chicago and worked there from 1972-1992.    He loved helping charities manage their resources and leverage the media to get the word out about the work they were doing to serve people in the city of Chicago and surrounding suburbs.

And finally, after he retired from United Way, he started exploring working with various charities as a volunteer, and finally ended up working for the South Suburbs of Chicago chapter of the National Alliance for the Mentally Ill, an advocacy group that supports those who have a mentally ill or family members who are caring for someone who has a mental illness.    He ended up being the President of the local chapter of that organization and retired from that position in 2007.

At the funeral, no one from his first career as a reporter was there at the funeral, but those who knew him in his second career as a public relations manager for United Way, and his third “career” as a public relations manager and then President of NAMI of Chicago South Suburbs, came to the funeral and it was gratifying to hear their stories and their gratitude for my Dad’s stewardship of those organizations.

3. My Father as a Citizen

In World War II, my father tried to enter the Army in 1944 when he turned 18, but was turned down by the medical board as “4F” because of the medical condition of having a perforated eardrum, which left my father more highly prone to infections.   He moved to Washington, D.C. and decided to help the war effort by working in the Department of the Navy.   Now in 1950, during the Korean War, he was called up but his ear condition but no longer an impediment to service in the army due to advances in handling infections through the use of sulfa drugs.   However, the fact that he knew German to a certain extent by having studied it in his last year in high school, meant that he was sent to Germany rather than to Korea.    His favorite line for serving his army service was “I fought Communism from the basement of a Bierstude in Berlin.”    Actually, he served as the public relations department of the army due to his two years of experience at the Sun Times newspaper in Chicago as a reporter.   He was always interested in books, TV programs, and films about World War II.   He felt proud of his service in the Army, but he felt a little abashed at the fact that he never played a large part in either World War II or the Korean War due to circumstances beyond his control.

4. My Father’s Worldview

My father was a lifelong Democrat politically and his worldview was definitely of an liberal and international bent, something which all of his children have inherited.    In fact, when I became 18 he gave me a copy of Saul Alinsky’s Rules for Radicals, because he wanted to see my rebellious nature to be channeled into a constructive rather than destructive frame of mind.    The reason why he gave me that book was because he knew Prof. Alinsky at the University of Chicago where my father initiated but never completed Master’s level studies in Economics.    I know that if he hadn’t had so many children, he probably would have gone on to at least the Master’s level if not higher, because of his love of learning.   When I went on to get a Master’s Degree in Asian Studies from the University of Illinois in Urbana-Champaign in 1990, he made sure to be there at my graduation to tell me how proud he was that I had achieved what he had been unable to do in his own life.

The liberal and international views that he believed could be described as one which believed in the positive role of government to be the neutral arbiter of various groups in society, and on the world stage, where our country should lead by promoting international cooperation and diplomacy as tools that should be used first before the military option was tried.   He was increasingly cynical about politics towards the end of his life, although he remained optimistic about people’s ability to help others at the local level through organizations such as the charities he worked for during the last three decades of his life.

5. My Father’s Generation

Until the final week of his life, my father read a physical newspaper over breakfast and coffee, which shows that the habits of a lifetime were hard to break.   Although he did have a computer and used it for sending e-mails, looking up information, etc., he never liked reading books from a Kindle or getting his news from online blogs.   For him, a newspaper had a physical and mental weight to it that its digital version could never have in his eyes.   He was a “traditionalist” in that sense, if you want to give a label his generation that was born up until 1945.    However, unlike many his generation, he liked interacting with others in the next generations, and loved the fact that he was surrounded by neighbors who had kids.    He loved the “joyful noise” they made of playing or even sometimes fighting with each other or arguing with their parents, because it took him back to his life as a parent and his earlier life as a child.

CONCLUSION

In short, the various circles of stakeholders my father was a member of all made him a part of who he was.   He felt that it was the privilege of a lifetime to be who he was, when he was living, and where he was living, and this attitude of gratitude, that life is a gift, is something he took with him to the end.    And that is why I truly feel, from my perspective, that it was a privilege of a lifetime to be his son.

Filed under: Uncategorized | Leave a comment »

My father passed away this Sunday, Saturday 27th, and I wrote yesterday about the preparations that the family was making for the wake that was being held yesterday evening.    Today is the day of the visitation and funeral service itself, so I thought I would put in my blog a copy of the notice we sent out to the newspapers and through the funeral home about the life my father lived.     Here’s the funeral notice itself.

His love of the journalism profession stayed with him throughout his life; although he adapted well to the computer age, he still read a physical newspaper every morning with his breakfast and coffee for the rest of his life,.  Although he supplemented his diet of current events with the occasional new program, the print medium of journalism remained his passion.    He used those skills as a newspaper reporter to work in the field of public relations in his second career as Public Affairs and Marketing for the United Way of Chicago, where he worked for the next twenty years of his life.    Through his work, he realized that the world of advertising and marketing could be used not just to sell products to consumers, but to provide services to the needy through the charities supported by the United Way.

And when he retired in 1992, it wasn’t long before he made the transition to what I call his third career, that of working as Public Relations officer for the Chicago South Suburbs chapter of the National Alliance for the Mentally Ill after which he became the President from 1998 through 2007,, a span of almost a decade.    He would monitor the legislature for laws that would effect funding for treatment of those suffering from mental illness here in the state of Illinois, and would get the word out if funding cuts were being proposed.    Advocate groups including NAMI would sometimes rally and otherwise put pressure on politicians to reverse or at least reduce those cuts if possible.

One of the initiatives started under his tenure as President was a series of educational programs aimed at correctional facilities to give those who worked there practical guidance on how to deal with prisoners who exhibited symptoms of mental illness.    The thinking was that if would be the younger workers who would be more receptive to new information , but the reality of the program turned out to be that it was the “veterans” among the workers who were more receptive, because they had more experience with prisoners who exhibited symptoms of mental illness, and were therefore more grateful for any information that would help them defuse situations that could result in harm to themselves or other prisoners.

My Dad retired from his third career finally in 2008, and lived a comfortable retirement in Homewood, Illinois, together with youngest son James.    In 2013, I was in transition to a new career, and he asked me to come and stay with him temporarily as he underwent a risky heart valve operation.    After the initial exploratory operation, he suffered a mild stroke and I helped him as he went to a rehabilitation facility to recover his speech and motor skills.    His speech skills were the first to recover, because my Dad was a born storyteller and loved to engage in conversation.    His physical strength took a little longer, but when we took him home in the fall of 2013, I told him I had started to put roots down here in Chicago and decided to stay with him.    There were home health care aides who helped him from 9 AM to 8 PM, but I had the privilege of putting him to bed at night for the past two years.     The programs he enjoyed watching the most–besides the obligatory news programs–were International Mysteries that showed on MhZ channel and which showcased a mystery story from a different country in Europe each week.    He loved mysteries, detective novels, and spy stories throughout his life and these programs combined that interest of his with a bit of vicarious travel thrown in.   He also enjoyed science programs on Nova, the Discovery Channel and other learning channels.    Just the week before he had to go to the hospital with a gallbladder attack, he pointed out a program he wanted to watch on Nova about a new human species, Homo naledi, discovered by paleontologists in South Africa.    I ended up watching it with him and he sat in rapt attention as the program relayed the new discoveries being made.

I can say these past two years have been some of the happiest of my life, being able to share them with my father whose relatively limited physical mobility did not affect his mental mobility at all.    When he recovered from the stroke, he felt that every day of his life was a gift, and his cheerful good nature shown through to all of those who knew him.    This week I was cleaning out his room in preparation for today’s funeral and I started feeling light-hearted and began to sing to myself, anything from snippets of Broadway tunes to the theme of “Star Trek:   The Next Generation.”    I caught myself and had to laugh out loud:   my Dad used to sing to himself when he on the computer in his bedroom or wheeling himself into the kitchen for a bite to eat.    I think unconsciously I was entering the “Dad zone” while in his bedroom and that’s why I was suddenly singing to myself, something I don’t normally do.    Only my father, I reflected, was capable of cheering me up even after he was gone from this world.

He lived a full life which was so full that it continues to spill over into mine and that of the rest of my brothers and sister, even as we gather together with his various relatives, friends and acquaintances to celebrate it.    At some point in my life, I think it was in college, I performed the mental experiment of asking myself, if I had not been his son, and had been his same age and say, met him in college, would I have been his friend?    I didn’t hesitate to answer an enthusiastic “yes”:   we’ve shared the same outlook on the world in our curiosity about the people from other cultures and countries, and while I have not inherited his same cynicism about politics that was borne out of being a journalist, I have inherited his attitude of gratitude towards life, which is perhaps his greatest legacy to me.

In the end, I will miss my conversations with him, but I don’t his presence as much because it is, to a certain extent, still with me.   As I mentioned in his funeral notice, it was a privilege of a lifetime to be his son.

Filed under: Uncategorized | 1 Comment »

This is an unusual post because I have been writing a series of posts introducing the concepts agile project management as part of a long-term project to create a series of notes for an agile study group for those studying for the PMI-ACP (Agile Certified Practitioner) exam.     However, an event occurred this week which has had me take a break from the world of agile project management–or so I thought at first.

1. The Funeral and the Project Plan

This week my father passed away on Sunday morning, and I have been, together with my brothers and sister, preparing for my father’s funeral this Saturday.    Nevertheless, something occurred during the preparations which has to do with agile project management, and I decided to share this experience which has been deeply personal and yet has been shaped by my professional experience with project management.

When I got the call from my sister on Sunday that my father passed away in the hospital, it was a shock to a certain extent, because he had been in the hospital with a gallbladder attack, and was preparing to have surgery the following day.    So we knew he was ill, but it was still a shock that he went so quickly before he even had a chance to have the surgery.    I went to the hospital right away and brought my notebook which serves as my own personal planning journal.    My sister said she and my brother were on their way to the hospital as well.    She called my older brother who lives in California, who started making arrangements to fly here to Chicago.

I got to the hospital first, and had a chance to say my own goodbye to my father who was lying there in the hospital bed looking as peaceful as if he was just taking a nap.    Since I was just waiting for my sister and brother to get there, my project management instincts kicked in and I got out my journal and wrote “The Goodbye Project” and started making entries for the various categories of activities that would have be done in order to get ready for the eventual funeral.

2.  Turning the Plan into an Agile Plan

When my sister and brother arrived, I put the journal away and we said our goodbyes to my father, comforted each other, and started turning to the various practicalities we needed to face, such as calling the funeral home.    Then we agreed to meet over at my Dad’s house.   When we arrived there, as my sister started making coffee, I got out my planning journal.   I thought when she saw it, I was afraid she might get angry and say something like “how could you be so left-brained at a time like this?”   But instead, she said, “oh, I’m so glad you’re doing this.   I was thinking about making a plan on the way back from the hospital, but I see you’ve already started.    Do you mind if I write on your plan?”    I said, ‘no, of course not,” and passed the journal to her.

She started filling in the plan, and then my brother contributed to it as well.    We formed it as a team, and in the next few days, we followed it as a team.    Sometimes we changed our project plan based on discussions with various relatives and friends of my father, like when we made the decision to split the funeral into two days based on various people’s schedules.   Some people would not be able to make it on Friday, and some people would not be able to make it on Saturday, but by having it on both days, we were able to accommodate everyone.

3. The Agile Funeral

Suddenly today while I was waking up from a nap and getting ready to do a post on my blog about agile project management, it occurred to me that I had been unwittingly planning an “agile funeral”, because my original idea of creating a plan for the funeral had taken on several aspects of agile project management:

• The traditional project plan, where I would have been the project manager, and my siblings would have been the team members, had been replaced by an agile plan, where my brother, sister and I were team members who were all contributing to it.
• The various team members doubled as SMEs in the areas of their expertise–my sister was in charge of cooking and preparing baked goods for the funeral, my brother (the artist in the family) was in charge of getting the pictures gathered and putting them on a flash drive we would take to show on a video monitor at the funeral, and I was in charge of communications, such as writing the obituary notice for the newspaper and the funeral home.    We all were equally adept at cleaning, so we split that chore between the three of us.
• As in most agile projects, our biggest constraint was not scope, but time–we needed to get the funeral arranged by the weekend because we are doing it for the convenience of the “stakeholders”, in the case the family and friends that knew my father the best.    Any clean-up project we thought of such as painting the porch on my father’s house that would take longer than a week was not put in the project plan.
• We communicated with the “stakeholders” (our relatives and Dad’s friends and acquaintances) on a regular basis and had to adapt our plan to their wishes, such as the fact that some couldn’t make it on one day and some couldn’t make it on the other, which caused us to compromise by doing the funeral on both days.
• Since the project was a week long, each day of this week has been zn increment referred to as a “sprint” (although some days it felt more like a marathon than a sprint).   Every morning after breakfast and coffee, we would gather around the kitchen table and look at our “burndown chart” from our plan and see what had been accomplished the previous day, what needed to be carried over from the previous day to the current day, as well as what fresh items needed to be accomplished on the current day.
• Agile projects try to conform to the normal rhythms of life such as a 8-hour work day.   Likewise, we planned out how much could get done each day in about 8 hours.   That would allow us to take one day at a time, focus on only that day and not get overwhelmed by how much there was to do by the time of the funeral.    This also allowed us to keep the evenings free so that after each day’s hard work, we could recover.by watching some comedy movie or television program to keep our spirits up, as well as having time to call up relatives and acquaintances of my father.

4. Agile is more than a methodology

Today is the day of the funeral, and I must say that my knowledge of project management, and agile in particular, really helped to take what was probably one of the most difficult projects I have undertaken in my life, planning for my own father’s funeral, and not only made it something manageable, but turned it into a way to bring my family closer together by working together to make the project happen.    I’m sure if my father could have seen us working together as a team this week, he would have been proud of us.    One of my mother’s favorite sayings was, “work is love made visible,” and our love for our father has been invested in the energy we have spent making preparations for today’s event.

In the end, if we are able to allow those who knew him to say their goodbyes to him, and to take home some positive memories along with the tears, the project will have been a success.    We owe him no less–it was a privilege of a lifetime to be one of his children.    It is yet another privilege of a lifetime to be one of a group of siblings that pull together in time of need and work together as a team, because teamwork, my dear readers, is ultimately the secret as to why agile works.    It’s not just a methodology–I can say from the bottom of my heart that for me it is now a way of life.

Filed under: Uncategorized | Leave a comment »

In the past series of blogs posts, I have gone over 9 agile project management frameworks, an alternative project management framework called Spiral (a variant of an “incremental” or “iterative” project management framework rather than an agile project management framework), and 2 agile project management tools.    What have I learned through going over this group.

1. The Agile Project Management Frameworks and Tools

First, let’s list the frameworks and tools I’ve reviewed: in previous posts

1. Scrum
2. Extreme Programming (XP)
3. Lean Software Development (LSD)
4. Feature Driven Development (FDD)
5. Agile Unified Process (AUP)
6. Crystal
7. Dynamic Systems Development Method (DSDM)
8. Essential Unified Process (EssUP)
9. Open Unified Process (OpenUP)
10. Spiral (not an agile, but an “incremental/iterative” framework)
11. Test Driven Development (TDD)–a tool, not a framework
12. Agile Modeling (AM)–a tool, not a framework

A couple of observations about the frameworks and tools on the list.    Although the tools can theoretically be used in conjunction with any framework, it is worthwhile to note that Test Driven Development was developed out of the Extreme Programming framework, and retains the feature of having programmers work in pairs to create and test code in tandem.

Three frameworks on the list, Agile Unified Process (AUP), Essential Unified Process (EssUP), and Open Unified Process (OpenUP) are all simplified versions of Rational Unified Process (RUP) developed by IBM.   Perhaps the reason why RUP has such a robust lineage is because of the influence that IBM has on the computer industry in general.    Why does Scrum top the list?   Perhaps because it is the most “lightweight” of the frameworks, meaning that the number of roles, artifacts, etc., is relatively small compared to more ornate frameworks like Extreme Programming (XP) or Lean Software Development (LSD).    Because it is a “lean” framework in terms of its moving parts, perhaps that is why it has gained market share, because it is more portable and therefore more easily adapted by applications areas outside of the software development field.

2.   Common Features of Agile Project Management Frameworks

At any rate, some of the common features of all of the frameworks are:

1. Communication with the key stakeholders–since the key stakeholders are the source of requirements, which must be fulfilled for the project to be a success, communication with stakeholders in terms of frequency and intensity is stressed in all frameworks.
2. Letting the solution evolve organically rather than be “pre-ordained” at the beginning of the project–traditional project management tries to specific the scope of the project to the greatest extent possible at the very beginning of the project.    This makes sense for creating solutions to ordinary problems, but it starts to fail as an approach when dealing with a project of great complexity (like those encountered in software development).  Remember the saying by Einstein that “problems cannot be solved with the same thinking we used when we created them?”   When you try at the beginning of the project to solve a complex problem, you fall into the trap of being at the same level of the problem and trying to come up with a solution.    Letting the solution evolve organically allows the collective intelligence of the group, which is more powerful than the intelligence of any one individual in the group, to bear on complex problems, and thus provide a level of thinking greater than those problems which allows for their solution.    This is why communication is done as much as possible in face-to-face mode, sometimes referred to as osmotic communication where people are absorbing information from other team members.
3. The constraints that are fixed are time and cost, whereas scope is flexible:  the exact inverse of traditional project management–the idea of some sort of time increment that fits together with the normal working life cycle of human beings, i.e., the week, is pretty standard throughout the frameworks.    Although the word “agile” is used to describe these frameworks, it is agile with respect to dealing with scope.    This agility is gained by having the other two major constraints, cost and especially time, more rigidly controlled than in traditional project management.   This allows the project to fit the life cycle of the human beings that work on the project, rather than the traditional PM practice of human beings trying to wrap their life cycle around the vicissitudes of the project schedule.
4. Documentation is reduced to the bare minimum required for people to work cohesively together towards the solution–some frameworks are more ornate than others when it comes to artifacts (agile speak for “project documentation”), but the artifacts are used to assist the active collaboration of team members towards a solution, rather than being an exercise in corporate-level box-checking that fits administrative requirements that are not germane to the requirements of the project itself.

These four features are the ones that appeared in the various guises of the frameworks I was reviewing.   Why do these common features keep showing up?    Probably because the frameworks all evolved facing similar types of problems.   The icthyosaur and the dolphin are not related in terms of evolutionary terms (one is a dinosaur and one is a mammal), but their shapes are similar because they both evolved in the same sea environment, which is an example of parallel evolution.   In a similar way, the frameworks that are not related directly in terms of lineage (i.e., all of the frameworks derived from the “Rational Unified Process” framework, have the common features mentioned above because they all evolved in response to problems in dealing with complex problems in the world of software development that shared similar features.

3.  The Future of Agile Project Management Frameworks

Although some of the frameworks have been created by the work of individuals (Crystal created by Alistair Cockburn, for example), those that will ultimately survive will be the ones that have evolved to meet the problems that project managers face.    The interesting prospect now is what the future holds for agile project management frameworks.  Although Scrum has the widest market share, John Stenbeck suggests that PMI might have a larger market share in the future.

At present (and I say this as a member of PMI) it is hard to see the outlines of this emerging because PMI lists a about a dozen textbooks as references for those who are studying for the PMI-ACP, and PMI is not known for having lightweight documentation as a strong suit (given the PMBOK Guide for Traditional Project Management), we will see if PMI can also adapt and create a framework which is as strong and as flexible as Scrum.

In fairness to PMI, of course, they did not develop all of the documentation just for the sake of producing documentation, but rather as a way to help companies solve problems that happen generically on projects, such as

• lack of clarity of the definition of the product of the project–remedied by a project charter and the project scope statement
• scope changes pushed by stakeholders–remedied by stakeholder register
• setbacks to the project created by external events–remedied by risk register

There are many examples I could give but the idea should be clear–the documentation must not meant to be a burden but rather as an aid to solving problems.

What would an successful agile framework be that is created by PMI?   In the end, those who are project managers or who are working on project teams are the customers, and PMI will have to deliver an agile framework that serves the needs of those customers    One mental model I have for such a framework si the geodesic dome created by Buckminster Fuller.    In and of itself, each strut of the geodesic dome is not structurally as strong as a girder or linking element of a traditional structure.  However, because each strut links to another one, the collective structure is strong enough to support itself even when facing hurricane strength winds.    In fact, he created the geodesic dome precisely in response to a request for structures to be created in the Antarctic for research stations that were faced with strong winds that would come from many possible directions.    In today’s project world, when stakeholders can affect the project from many different directions, it is important to have a structure that can withstand those changes.    Rather than strengthening the project manager per se, agile strengthens the entire team, and any framework that can assist in doing this will probably be the one that wins the market share for agile project management in the future.

Filed under: Uncategorized | Leave a comment »

In the second chapter of his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, John Stenbeck introduces agile project management, including the different frameworks that exist in the agile world and some tools which can be used independently in conjunction with any of these frameworks.    Yesterday’s post covered Test Driven Development (TDD), and today’s post covers the second example of an agile project management tool known as Agile Modeling (AM).

Like TDD, Agile Modeling (AM) can be used in conjunction with other agile frameworks.  Its most common usages are for software development projects.

Here are the basic principles behind Agile Modeling (AM).

1. Create multiple models in small increments–this is because any given model is bound to include some inaccuracies, and having multiple models will more likely produce code that ends up actually working
2. Create an abstract representation of the software–then prove or disprove its performance with code that either works or does not work
3. Use the right artifacts from each model–team improves its understanding of the approach to the solution
4. Follow a continuous forward match–iterating to the next model after one model is verified
5. Get active stakeholder participation in AM–project stakeholders know what the result of a successful model will be and can provide crucial feedback needed to improve between each model
6. Use applied simplicity–focus on the practice of only creating models for the current facet of the problem; this goes hand in hand with principle 1 above of creating multiple models in small increments, avoiding large, detailed models.   Do just enough modeling to understand the scope of the problem and the architecture of possible solutions.
7. Use open communication–display models on walls or Wiki’s, embrace collective ownership of artifacts, and use group-based model development.

These principles allow a team to do modeling in such a way that possible solutions are suggested, tested, and then improved upon in subsequent development iterations.

This concludes the two posts on agile project management tools.   Although they were developed for software development, it would be interesting to see if they can be applied to other application areas, in the same way as agile project management methodology is beginning to be applied on a wider basis.

The next post will be a wrap-up, where I give my I give my “agile beginner” impression of the various frameworks and tools, speculate on why they enjoy the market share that they do today, and what the future holds for them in the world of agile PM.

Filed under: Uncategorized | Leave a comment »

In the second chapter of his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, John Stenbeck introduces agile project management, including the different frameworks that exist in the agile world and some tools which can be used independently in conjunction with any of these frameworks.    The first example of an agile project management tool is Test Driven Development (TDD).

Although it can be used in conjunction with other agile frameworks, it originally grew out of concepts from the Extreme Programming (XP) framework (for more information, see my post outlining XP).   Its most common usages are

• automating an existing manual process that has a current testing process
• improving legacy code developed with older languages

TDD uses repetition of very short development cycles.   Here are the steps in each cycle:

1. Developer writes test preconditions, test controls, and test reporting based on predicted outcomes that define a desired improvement or new function.
2. Developer then writes code and uses automated testing software tools to monitor the execution of the code to test the actual outcomes against the predicted outcomes mentioned in step 1.
3. If as a result of step 2, the code fails the automated test case, the developer refines it until code is produced that passes.   Only then does the developer go on to step 4.
4. The developer refactors the code, processing the code with a tool that makes small changes that do not modify its functionality, but improve attributes like a) readability, b) complexity, c) maintainability, and d) compliance with architecture or object model standards for extensibility until the new code meets established standards.

The focus in TDD for the programmer is on passing the immediate test and only then considering how to handle exceptions, errors, and rare circumstances.    However, TDD not only provides validation of the correctness of code, but it can also drive program design.  The discipline developed in TDD of understanding how customers will use specific functionality will indicate how to create the test cases, and the focus on how the interface works before implementation occurs will create a better program.

TDD works best when working with programs with a more modular design, but can be difficult to apply with programs that integrate to databases, because in that case full functional tests may be required to determine success or failure of the code.   Another potential weakness of TDD is when the tests are created by the same developer who created the code.   This is one of the reasons why in XP, programming is usually done in pairs, with one programmer creating the code and the other programmer reviewing it.   The second programmer is probably the better one for creating the test conditions, etc., described in step 1 above, because he or she understands the code well enough from having reviewed it, but has another distance from the code writing process to create test conditions which will effective test the code without missing the developer’s “blind spots” regarding user specifications.

Management may object to using the Test Driven Development (TDD) tool because tests increase overhead, but TDD can be soon as a tool which simultaneously increases quality while reducing risk, so it can be seen as beneficial to the bottom line of a company in the long run.

The next post covers the other widely used tool in conjunction with various agile PM frameworks, namely Agile Modeling (AM).

Filed under: Uncategorized | Leave a comment »

This is the tenth and final post in a series of posts devoted to outlining the various alternative project management  frameworks, most of which exist in the world of agile project management, based on the book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, by John Stenbeck.

The first three posts covered those frameworks which are covered on the PMI-ACP exam, namely, Scrum, Extreme Programming (XP), and Lean Software Development (LSD).   The next three posts covered the relatively “minor players” in the marketplace, Feature Driven Development (FDD), Agile Unified Process (AUP), and Crystal, that are covered in John Stenbeck’s textbook.

The next series of three posts cover the very minor players that were considered to have too small a marketshare for John Stenbeck to even cover them in his textbook.    Nevertheless, out of curiosity and for completeness’ sake, I included them in this series of posts.   These included the Dynamic Systems Development Method (DSDM), Essential Unified Process (EssUP), and Open Unified Process (OpenUP).

Today’s post is on the Spiral process for software development projects; although it is not technically an agile project management framework, it is being included in this series because it is another alternative to traditional waterfall methodology.

The term Spiral is an alternative approach to

• traditional waterfall (aka “predictive”) methodology
• incremental (aka “iterative”) methodology
• agile (aka “adaptive”) methodology

It most closely fits into the second category of incremental or iterative methodologies.    The main idea behind the iterative approach is that the project activity goes back and repeats the same processes within the life cycle, but spiral motion combines two features, a) circular motion around the center and b) outward motion from the center, so each repeat of the process in the cycle is done at a higher level of development.    Another key concept in the spiral approach is that the next higher level of development is risk driven, meaning that it tries to lower the overall risk to the project.

Agile might be seen as the “extreme” version of these three categories, where the length of each increment of “sprint” (using language from Scrum) is fixed, and the focus is on adaptation between the requirements from the customer on the one hand and the development of the technical characteristics of the product on the other.

1.Spiral History

• 1986–Barry Boehm publishes a paper “A Spiral Model of Software Development and Enhancement”

The key point to remember here is that Spiral is one of the alternative approaches to project management which  actually predated the early formulations of agile.

2. 6 Invariants of Spiral model cycles

1. The requirements are known in advance of implementation.
2. The requirements have no unresolved, high-risk implications, such as risks due to cost, schedule, performance, safety, security, user interfaces, organizational impacts, etc.
3. The nature of the requirements will not change very much during development or evolution.
4. The requirements are compatible with all the key system stakeholders’ expectations, including users, customer, developers, maintainers, and investors.
5. The right architecture for implementing the requirements is well understood.
6. There is enough calendar time to proceed sequentially.

3. 4 Activities performed in every Spiral model ycle

1. Consider the win conditions of all success-critical stakeholders.
2. Identify and evaluate alternative approaches for satisfying the win conditions.
3. Identify and resolve risks that stem from the selected approach(es).
4. Obtain approval from all success-critical stakeholders, plus commitment to pursue the next cycle.

4. Risk Determines …

1. Level of effort–project team must decide how much effort is enough, with decisions being made by minimizing overall risk
2. Degree of detail–project team must decide for any project artifact how much detail is enough, with decisions again being made by minimizing overall risk.

5. 3 Anchor Point Milestones used in Spiral Model

1. Life Cycle Objectives–Is there a sufficient definition of a technical and management approach to satisfying everyone’s win conditions?
2. Life Cycle Architecture–Is there a sufficient definition of the preferred approach to satisfying everyone’s win conditions, and are all significant risks eliminated or mitigated?
3. Initial Operational Capability–Is there sufficient preparation of the software, site, users, operators, and maintainers to satisfy everyone’s win conditions by launching the system?

These three anchor point milestones are similar to those in the Rational Unified Process (RUP)

1. Spiral Life Cycle Objective (LCO) ==>  RUP Boundary between Inception and Elaboration Phases
2. Spiral Life Cycle Architecture (LCA) ==> RUP Boundary between Elaboration and Construction Phases
3. Initial Operational Capability (IOC) ==> RUP Boundary between Construction and Transition Phases

With these ten posts on alternative project management frameworks completed, I will now discuss two agile project management tools, which can be used in conjunction with an agile project management framework, namely

• Test Driven Development (TDD)
• Agile Modeling (AM)

Filed under: Uncategorized | Leave a comment »

This is the ninth in a series of posts devoted to outlining the various agile frameworks that exist in the world of agile project management, based on the book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, by John Stenbeck.

The first three posts covered those frameworks which are covered on the PMI-ACP exam, namely, Scrum, Extreme Programming (XP), and Lean Software Development (LSD).   The next three posts covered the relatively “minor players” in the marketplace, Feature Driven Development (FDD), Agile Unified Process (AUP), and Crystal, that are covered in John Stenbeck’s textbook.

The next series of three posts cover the very minor players that were considered to have too small a marketshare for John Stenbeck to even cover them in his textbook.    Nevertheless, out of curiosity and for completeness’ sake, I will include them in this series of posts.   Yesterday’s post was about the Essential Unifired Process (EssUP).   Today’s post covers the Open Unified Process or OpenUP framework, another methodology that, like Agile Unified Process (which was covered in an earlier post), was derived from the Rational Unified Process (RUP) methodology.

The Open Unified Process (OpenUP) is a part of the Eclipse Process Framework which is managed by the Eclipse Foundation, a consortium of software industry vendors.    OpenUP targets small and collocated teams constituting 3 to 6 people and involving 3 to 6 months of development effort.

1.  OpenUp History

• 2000–Scott Ambler and Larry Constantine write a collection of books that became the foundation of Unified Process (UP), which later developed into Rational Unified Process
• 2000-2003–IBM subsidiary Rational Software corporations develops UP into Rational Unified Process
• 2005–Open source content was added to RUP to create Basic Unified Process (BUP) and transitioned to the Eclipse Foundation
• 2006–BUP renamed OpenUP

2. 4 Features OpenUp has in common with its parent RUP

1. Iterative development
2. Use Cases and scenarios during development
3. Risk Management
4. Architecture-centric approach

Most optional parts of RUP have been excluded, with many of the remaining parts merged.

3. The 3 Layers of Organization in OpenUp

1. Project Lifecycle–divided into 4 phases:  Inception, Elaboration, Construction, and Transition, each of which provides stakeholders and team members with opportunities for collaboration and decision points (“go or no-go decisions”) at the end of each phase; results in a released application
2. Iterations–time-boxed intervals typically measured in weeks, focusing on delivering incremental value to stakeholders which progresses towards delivering results for each phase mentioned above in paragraph 1
3. Micro-increments–short units of work (measured in a few hours to a few days) that produce a steady measurable pace of project progress by a committed, self-organized team; results in iteration objectives mentioned in paragraph 2

In the description of the organization of OpenUp given by the Eclipse Foundation in

http://epf.eclipse.org/wikis/openup/

the image is that of a series of interlocking gears for the different layers of organization of the project.

4. The 4 Principles of OpenUp

1. Balance competing priorities to maximize stakeholder value
2. Collaborate to align interests and share understanding
3. Focus on the architecture early on to minimize risks and organize development
4. Evolve to continuous obtain feedback and improve

Like other Unified Process frameworks, there are quite a few defined roles related to development, deployment, and the organizational environment.

The Dutch University of Groningen and the Swedish Linneaus University both heavily use OpenUp, as does the Dutch HU University of Applied Sciences in Utrecht.

The next post, the tenth and last post in this series, covers the Spiral Framework.

Filed under: Uncategorized | Leave a comment »