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

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.

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 http://www.ivarjacobson.com)

  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.