In Memoriam: John P. Rowley

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.
John P Rowley

“John Perry Rowley, of Homewood, IL, died on September 27th at the age of 89, at Advocate Christ Hospital in Oak Lawn. John is survived by his children John Lawrence Rowley, Jerome Francis Rowley, Ralph William Rowley and Nora Elizabeth Rowley. He is predeceased by his wife Dorothy Winifred Rowley (née Stift) and his youngest son James Patrick Rowley. He graduated from Subiaco Academy in 1944 as the Salutatorian, and he was then drafted into the US Army in 1950, where he served for two years in Germany in the Army’s Public Affairs group. After leaving the Army, he attended Loyola University where he studied Political Science. He met his future wife Dorothy in English class taught by Father Jerome, who ended up performing their wedding ceremony in 1953. He was a reporter for the Sun Times from 1948-1967, Information Manager for the educational publisher Science Research Associates from 1967-72, and was the Director of Public Affairs and Marketing for the United Way of Chicago from 1972-1992. After he retired, he was on the board of the AIDS Ministries of Chicago, and was President of the South Suburban chapter for NAMI (National Alliance for the Mentally Ill). He was a great storyteller and loved helping others. “

The picture we chose was of my father when he was a newspaper reporter for the Sun-Times back in 1948.    He started as a copy boy, and worked at the paper for almost 20 years.    He had three careers in his life, the first as a newspaper reporter, but then when Rupert Murdoch bought the Sun-Times my father saw the handwriting on the wall and decided to leave the paper while it was still the relatively liberal paper in the Chicago area.

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.

The Agile Goodbye

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

Agile Project Management Frameworks and Tools–A Summary

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.

Agile Project Management Tools–Agile Modeling (AM)

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.

Agile Project Management Tools–Test Driven Development (TDD)

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

Alternative Project Management Frameworks–Spiral

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)

Agile Project Management Frameworks–Open Unified Process (Open UP)

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

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.

Agile Project Management Frameworks–Essential Unified Process

This is the eighth 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 will cover the very minor players that were considered to have too small a marketshare for John Stenbeck to even cover them in the textbook.    Nevertheless, out of curiosity and for completeness’ sake, I will include them in this series of posts.   Yesterday’s post was about the Dynamic Systems Development Method (DSDM).    Today’s post covers the Essential Unified Process, another methodology that, like Agile Unified Process (which was covered in an earlier post), was derived from the Rational Unified Process (RUP) methodology.

The Essential Unified Process for software development, or EssUP, was invented by Ivar Jacobson as an improvement on the Rational Unified Process (which is also the “parent” of Agile Unified Process or AUP.   It identifies practices which are borrowed from Rational Unified Process and agile development in general.    The idea is to pick those practices that are applicable to a particular solution and to combine them into a project management process.    RUP, on the other hand, has practices which are intertwined and cannot be taken a la carte, so to speak.

1. 5 Essential Practices (taken from

  1. Architecture Essentials–allows you to ensure that the architecture selected for the project is fit for purpose.
  2. Iterative Essentials–allows you to adopt an iterative, timeboxed approach to managing and monitoring the project.
  3. Use-Case Essentials–enables you to capture requirements in an agile fashion and to use them to drive the development and testing of the solution.
  4. Component Essentials–allows you to develop software in a simple, scalable, test-driven fashion
  5. Product Essentials—captures the essence of product management to enable you to get closer to your customers and identify your major releases.

2. 4 Cross-Cutting Practices

  1. Process Essentials–ensures continuous process improvement
  2. Team Essentials–captures the essence of collaborative team working
  3. Modeling Essentials–describes an agile approach to modeling
  4. Unified Process Lifecycle Essentials–provides a set of phases and milestones to help plan and track iterative projects.

The practices have all been built on real-world experience and each practice is presented as a set of process cards that contain the elements of the process including

  • competency definitions
  • activity definitions
  • artifact definitions, and
  • process patterns.

It is meant to be agile, iterative, and most important, lightweight in the sense that it is modular and can be adapted to the needs of any given project.

The next post presents yet another agile framework that was derived from the Rational Unified Process framework, namely, the Open Unified Process or OpenUP framework.

Agile Project Management Frameworks–Dynamic Systems Development Method (DSDM)

This is the seventh 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 will cover the very minor players that were considered to have too small a marketshare for John Stenbeck to even cover them in the textbook.    Nevertheless, out of curiosity and for completeness’ sake, I will include them in this series of posts.   Today’s post is about Dynamic Systems Development Method (DSDM).

DSDM is primarily a software development method, and is an agile project management framework.

1.DSDM History

  • 1994–First release of DSDM, which was an attempt to provide discipline to the Rapid Application Development (RAD) Method.
  • 2007–DSDM becomes a generic approach to project management that is capable of being applied out of the original application area of IT, branded as “DSDM Atern”
  • 2014–DSDM Atern drops “Atern” and is referred to as simply “DSDM”; attempts to integrate with PMBOK, PRINCE2 traditional PM frameworks, as well as various agile approaches

2. 8 Principles of DSDM

    1. Focus on the business need–focus on business priorities, particularly critical functionalities
    2. Deliver on time–always meet deadlines by timeboxing the work
    3. Collaborate–users and developers share a workplace so that decisions can be made collaboratively
    4. Never compromise quality–quality level must be set at outset and not allowed to vary, by building in quality and testing early and continuously
    5. Build incrementally from firm foundations–strive for early delivery of business benefit where possible, and formally reassess priorities and ongoing project viability with each delivered increment
    6. Develop iteratively–it is better to deliver something “good enough” rather than “perfect”
    7. Communicate continuously and clearly–foster cooperation among all project stakeholders
    8. Demonstrate control–use appropriate level of formality for tracking/reporting, and manage proactively

3.  4 Stages of Project Life Cycle

  1. Stage 1A–Feasbility Study:  feasibility of project for use with DSDM is examined and Stage 1B–Business Study:  stakeholders come together to discuss proposed system, and develop a set of requirements
  2. Stage 2–Functional Model Iteration:  creation of a functional prototype and models
  3. Stage 3–System Design and Build Iteration:  integrates functional components from Stage 2 into a single system that satisfies users needs
  4. Stage 4–Implementation:  tested system is delivered to the users with documentation

4. 7 Core Techniques used in DSDM

  1. Timeboxing–split up the project in portions each with a fixed budget and delivery date; each portion is assigned a number of prioritized rquirements
  2. MoSCoW–priotizes requirements according to whether you MUST have, SHOULD have, COULD have, or WON’T have them in the project
  3. Prototyping–creation of prototypes of the system under development at an early stage of the project
  4. Testing–realize a solution of good quality by testing throughout each iteration using the test management approach of the team’s choosing
  5. Workshop–brings the different stakeholders of the project together to discuss requirements, functionalities and mutual understanding
  6. Modeling–used to visualize the diagrammatic representation of a specific aspect of the system or business area that is being developed
  7. Configuration management–the products and the various versions of their design must be controlled strictly as they achieve completion, so that everyone is working on the current version

5. 13 Roles used in DSDM

  1. Executive Sponsor–the “Project Champion” who has the authority to commit appropriate funds and resources. 
  2. Visionary–has responsibility to initialize project by ensuring essential requirements are decided upon early on. Visionary has the most accurate perception of the business objectives of the system and the project. Another task is to supervise and keep the development process in the right track.
  3. Ambassador User–brings the knowledge of user community into the project; ensures that the developers receive enough amount of user’s feedback during the development process.
  4. Advisor User–any user that represents an important viewpoint and brings the daily knowledge of the project.\
  5. Project Manager–anyone from user community or IT staff who manages the project in general.
  6. Technical Co-ordinator–responsible for designing the system architecture and controlling the technical quality in the project
  7. Team Leader–leads team and ensures that the team works effectively as a whole
  8. Solution Developer–interprets the system requirements and models it, including developing the deliverable codes and building the prototypes.
  9. Solution Tester–checks the correctness in a technical extents by performing some testing, detecting defects where necessary and retesting once defects are fixed. 
  10. Scribe–responsible to gather and record the requirements, agreements, and decisions made in every workshop.
  11. Facilitator–responsible for managing the progress of workshops.
  12. Specialist Roles Business Architect, Quality Manager, System Integrator, etc.

Unlike XP and RUP development methods, DSDM is a framework that allows members of the team to use tools and techniques of their choosing (such as the test development method).   Like other development methods, the scope is allowed to evolve, whereas the other two of the triple constraints, time and budget, are relatively fixed.   Also like other methods, there is a strong focus on communication between stakeholders in the system and involvement of those stakeholders in the process of translating requirements into technical characteristics of the product.

The next post covers the Essential Unified Process, another methodology that, like Agile Unified Process (which was covered in an earlier post), was derived from the Rational Unified Process (RUP) methodology.

Agile Project Management Frameworks–Crystal

This is the sixth of 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 cover the relatively “minor players” in the marketplace, Feature Driven Development (FDD), Agile Unified Process (AUP), and Crystal.    This post covers Crystal, the only framework that is actually a family of frameworks.

1.Crystal History

  • 2004–Alistair Cockburn published “Crystal Clear:  A Human-Powered Methodology for Small Teams”

2. Crystal Determining Factors

In Crystal, the two factors determining the specific framework within the family of frameworks called Crystal are:

  1. Size–determined by the number of people involve in a project
  2. Criticality–determined by the potential damage the system can cause if it does not perform as designed

3. Crystal Family Colors

There are five “colors” which represent the five families of Crystal methodogies, whiich are to be adopted based on the size of the project (i.e., the number of people involved on a project

  1. Clear–up to 6 people
  2. Yellow–up to 20 people
  3. Orange–up to 40 people
  4. Red–up to 80 people
  5. Maroon–up to 200 people

If you are in a project that has a Crystal Clear framework, and you increase the people in your project to greater than 6, than Alistair Cockburn recommends the project the next higher framework level (Crystal Yellow), rather than trying to expand the prior Crystal Clear practices.

As you go up in levels, the project is expected to be harder.

4.  4 Levels of Criticality in Crystal

Besides having a “size” factor which determines the framework, the other factor mentioned above which effects the framework is that of “criticality”, which is the level of potential damage the system can cause if it does not perform as designed

  1. Comfort (C)
  2. Discretionary Money (D)
  3. Essential Money (E)
  4. Life (L)

One of the key issues in the Obamacare initiative when it comes to automating record systems is that the companies who are implementing these solutions need to understand the criticality of the systems they are creating.   If there is a mistake made by the automated system, it could mean a patient’s life could be at stake.   Crystal is the only agile methodology which explicitly recognizes this level of criticality in the choice of methodology.

5. 7 Key Principles of Crystal

  1. Frequent Delivery (FD)–stakeholders and customers received deliverables every couple of months at a minimum.
  2. Continual Feedback (CF)–team meets on a regular basis to discuss project activities with stakeholders and uses feedback to confirm that the project is headed in the desired direction
  3. Constant Communication (CC)–team is colocated in the same room (on smaller projects) or in the same facility (on larger proejcts) so that teams have frequent access to the persons defining requirements
  4. Safety–team members meet in a “safe zone” where team members can communicate without fear or reprisal.  The concept of safety also enters into Crystal in that the “criticality” factor, that is, the amount of potential damage to an end user if a system does not perform as designed, is taken into account.
  5. Focus–top two or three priorities are clearly shared with the team and the team is given uninterrupted time to complete them.
  6. Access–team must have adequate access to end users of the system while it is being built.
  7. Automated Tests and Integration–testing and integration must be supported by automated versioning, testing, and integration of system components.

The only two levels for which there is authoritative information for applying Crystal is for the Clear and Orange levels.  Nothing has been published regarding the Crystal Yellow, Red, and Maroon frameworks.  The number of roles increases from Clear to Orange, and, although I will not delineate those differences here, the important matter to remember is that the number of roles increases as the complexity of the project increases.

This concludes the overview of Crystal.   There are two additional frameworks, Dynamic Systems Development Method (DSDM), and Spiral, which have such a small market share that John Stenbeck doesn’t describe them in his book.   However, I will do so for the sake of completeness, so the next post will be on the Dynamic Systems Development Method or DSDM, following the same format of describing its history, principles, and any distinctive features such as roles, artifacts, etc.