4squareviews

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 »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

in Chapter 2 “Introducing Agile Project Management” of his book “PMI-ACP Exam Prep PLUS Desk Reference,” John Stenbeck describes three of the most widely used frameworks for agile project management methodology, namely Scrum, Extreme Programming (XP), and Lean Software Development (LSD), because they are covered in the PMI-ACP exam.   In the next section on “Other Frameworks”, he includes frameworks which have smaller market share in the agile world, but which he thinks are nonetheless worthwhile knowing because of their features.

This post covers the second of these other frameworks, Agile Unified Process or AUP, which is a simplified version of the Rational Unified Process or RUP created by the Rational Software Corporation, a division of IBM.   It is an ornate framework because it specifies many activities and artifacts for each process.   It accounted for only 1% of all Agile methodologies used, and development of AUP ceased when it was superceded in 2012 by DIsciplined Agile Delivery.

1. AUP 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
• 2006–IBM tailors RUP to agile projects and creates Agile Unified Process (AUP)
• 2012–AUP is superceded by Disciplined Agile Delivery

2. Six Philosophies behind AUP

1. Competence–the team doesn’t read detailed process documentation, but knows what it is doing and only requires high-level guidance
2. Simplicity–describes things concisely on a few pages
3. Agility–AUP conforms to the values and principles of the Agile Alliance
4. Activity–Focus on only high-value activities that count
5. Tools–Simple tools are often the best, so AUP is independent of any toolset; it only requires that the tools be used that are best suited to the job
6. Tailor–AUP works best when tailored to the needs defined by the context.

An additional philosophy not listed above relates to risk management:  AUP prefers that high-risk elements be prioritized early to development.

3.  Four Phases of AUP

1. Inception–cultivates a shared understanding of the project scope and defines architectural choices
2. Elaboration–develops understanding of the system into requirements and validates architectural choices
3. Construction–occurs until system development is completed
4. Transition–testing and system deployment to production

4.  Two Types of Iteration

1. Development release iteration–reaches the Transition milestone when it is deployed to a non-production environment (e.g., quality-assurance and testing environments)
2. Production release iteration–reaches the Transition milestone when it is deployed to the production environment

5.  Seven Disciplines of AUP

1. Model–use to represent the organization’s business approach, the problem domain, and any viable solution to solve the problem
2. Implement–code the model(s) into executable code and perform unit testing
3. Test–apply additional tests to find defects, validate the system design works, verify the requirements are satisfied, and ensure code quality
4. Deploy–plan and deliver the system for end users
5. Configuration Management–control all project artifacts, including version tracking and change management
6. Project Management–Provide project management, including management of scope, resources, risk and progress, and coordinate external interfaces to achieve completion on time and on budget.
7. Environment–provide process guidance standards and ensure needed tools are available for the team

The next blog post is on Crystal, which is actually a family of frameworks based on project size and criticality.

Filed under: Uncategorized | Leave a comment »

in Chapter 2 “Introducing Agile Project Management” of his book “PMI-ACP Exam Prep PLUS Desk Reference,” John Stenbeck describes three of the most widely used frameworks for agile project management methodology, namely Scrum, Extreme Programming (XP), and Lean Software Development (LSD), because they are covered in the PMI-ACP exam.   In the next section on “Other Frameworks”, he includes frameworks which have smaller market share in the agile world, but which he thinks are nonetheless worthwhile knowing because of their features.

This post covers the first of these other frameworks, Feature Driven Development or (FDD).    FDD has a process map, which is described below.

1. Five Steps of the FDD Process Map

1. Develop Overall (Domain) Model–Domain Knowledge is collected from subject matter experts or SMEs (who are referred to as Domain Experts in the FDD Framework) and integrated into a cohesive model that accurately represents the problem domain, which is called the Overall (Domain) Model
2. Build A Feature List–from the Domain Model, general business activities are defined as Subject Areas, which are decomposed into business activities that are called Feature Sets.
3. Plan by Feature
4. Design by Feature
5. Build by Feature

A “Feature” is defined as a small, client-valued function, and it is expressed as an action that cases a result to an object.

2. 9 Roles of FDD Team

1. Project Manager–PM is responsible for all administrative, financial, and reporting facets of the project
2. Chief Architect–CA controls the design of the Domain Modle and solutions; manages the technical architecture, design sessions, and code reviews
3. Development Manager–DM manages daily development activities
4. Chief Programmer–CP is a senior developer responsible for a specific Feature Set
5. Class Owner–CO is a developer who reports to the CP
6. Domain Expert–DE is a business SME and stakeholder who defines requirements as features that the solution must provide (often these are BAs)
7. Tester–tests that features perform as defined
8. Deployer–responsible for validating that features perform as defined
9. Technical Writer–TW creates and maintains documentation that users will need to operate the system

3. 3 Differences between FDD and other Agile Frameworks

Because of the number of specific roles in FDD, it does not use the principle of shared ownership of code and artifacts the way that other agile frameworks do.

1. Shared ownership means that every programmer is responsible for all of the code, and that every programmer is allowed to change any part of the code.
2. Artifacts are data records that document the projects inputs, outputs, and progress points.   FDD does not use these, but Scrum for example has 4 principal artifacts:  Product Backlog, Release Burndown, Iteration Backing, and Iteration Burn-down.

4.  Feature Set Progress report in FDD

FDD has very specific report style for reporting project progress.   The Feature Set Progress report tracks feature development progress by subject area using specific color codes and percentage complete:   Dark Green means Feature Set has been completed, Light Green means that the Feature Set is on schedule, and Light Grey means that the Feature Set is behind schedule.   Each feature is documented in a table with six specific milestones:

1. Domain Walkthrough
2. Design
3. Design Inspection
4. Code
5. Code Inspection
6. Promote to Build

Stakeholders can see from the progress report how each feature of the project is progressing.

The next framework to be discussed is Agile United Process or AUP, to be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

This is the third post in a series giving the features of the various agile project management frameworks that exist, starting with Agile and Extreme Programming, the most widely used frameworks, and ending with the “minor players” in the agile world.    These have been mapped out by John Stenbeck in chapter 2, “Introducing Agile Project Management,” from his book “PMI-ACP Exam Prep PLUS Desk Reference”.

1. Lean Software Development (LSD) History

• 1950s–W. Edward Deming develops Total Quality Management, with its focus on process and the idea that those who use the process must be those who improve it.
• 1999–Dr. Elihayu M. Goldratt in his book Theory of Constraints (TOC) stresses the need to identify constraints and them remove them (or at least improve them) in order to improve the business organization

2. Points in Common with Scrum

1. Both Scrum and LSD focus on the project management aspects of software development rather than the technical ones; this makes it easy to integrated LSD with other agile frameworks such as XP (which focuses on the technical facets of software development)
2. Both Scrum and LSD seek to manage costs and improve the project’s Return on Investment (ROI)

3.  LSD team roles

1. As opposed to Scrum and XP, which have stricter role definitions, team members are cross-trained on functional and technical facets of the system.

4.  7 Principles of LSD

1. Eliminate Waste–eliminate it if it does not add customer value
2. Build Quality In–validate all assumptions and use metrics throughout the process to ensure practices create value
3. Create Knowledge–Use short iterative cycles to get continuous feedback
4. Defer Commitment–Don’t make decisions until a clear understanding of the problem, the solution choices, and the trade-offs of each solution choice are available.
5. Deliver Fast–Identify business issues as quickly as possible and then deliver a system that solves them
6. Respect People–Only the employees using the system can improve it, so empower the entire team to succeed
7. Optimize the Whole–Always use cross-functional teams so that critical facets of the problem aren’t overlooked and the solution design will solve it

The three agile frameworks that are required for the ACP exam are Scrum, Extreme Programming (XP), and Lean Software Development (LSD).   The other agile frameworks are not part of the knowledge base required for the ACP, but John Stenbeck has listed them in his “PMI-ACP Exam Prep PLUS Desk Reference” because he feels it is worthwhile to have a cursory understanding of them   These are:

• Feature Driven Development (FDD)
• Agile Unified Process (AUP)
• Crystal

The next post will cover the first of these three, Feature Driven Development or FDD.

Filed under: Uncategorized | 1 Comment »