4squareviews

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 »

In chapter 2 of John Stenbeck’s book “PMI-ACP Exam Prep PLUS Desk Reference,” he goes through the various agile project management methodologies.    The most prominent one, Scrum, was discussed in the last post.    In this post, I summarize his presentation on the second most prominent framework in terms of adoption rate and marketplace usage, that of Extreme Programming or XP.

This is a list of features of XP that one should be aware of in studying for the PMI-ACP exam.

1. XP History

The ideas of XP were created in response to two changes in software development:  1) procedural programming was beginning to be replaced by object-oriented programming, and 2) speed-to-market became a strategic growth issue and shorter product life-cycles demanded agility to handle rapidly changing customer requirements.

1. 1999–Kent Beck formalized his ideas for XP in his book Extreme Programming Explained.     This focused on technical practices that promoted skillful software development.
2. 2004–XP continued to be developed, and the second edition of Extreme Programming Explained
   expanded the list of best practices to include:   continuous code reviews, pair programming, unit testing, modularity, bottom-up design, incremental design patterns, and refactoring of all code.

2.  Five Basic Activities of XP

1. Coding–most important product of the development process is software code
2. Testing–the more flaws testing can eliminate, the more working code can be delivered
3. Listening–listening to customer needs so they can be understood well enough to discern the technical aspects of a viable solution
4. Designing–limit system complexity by creating modular designs that organize the system logic with the minimum amount of dependencies
5. Communicating–the opposite direction of 3. Listening, this is communicating to the customers the need to have system requirements for the developers to work on

3. Two Goals of XP

1. Rapidly create and distribute organizational knowledge to the development team
2. Create a unified with the customers and users of the system

4. Four XP Team Roles

1. Customer–creates and prioritizes the stories (deliverables) to be developed.   Customer can vary release date by adding or removing stories from the backlog to be delivered (this is unique to XP).
2. Programmer–estimates stories (i.e., how much effort is needed to complete a specific deliverable), writes code, usually working in pairs with another programmer, and writes tests
3. Coach (OPTIONAL)–monitors process, mentors the team on XP processes and techniques, helps team identify risks and optimization opportunities
4. Tracker (OPTIONAL)–monitors team progress and warns when schedule adjustments require redistributing of tasks.    A programmer can double as a tracker for another pair of programmers.

5. 12 Core Practices of XP

1. Planning Game–technique used to elicit new requirements from the customer, with the team then giving an estimate of the effort required to develop and implement it
2. Small releases–begin with the smallest useful feature set.   Release often, adding a few features each time.
3. Product them–each product has an underlying theme or metaphor,
4. Simple design–employ simplest possible design to get the job done
5. Test-driven development (TDD)–write a test before adding a feature
6. Refactoring–constantly improve a product’s internal design by rewriting code to make the product more reliable and adaptable
7. Pair programming–two programmers work together, the first programmer (the driver) typing in code and focusing all attention on tactical choices and completing the current programming task, while the second programmer (the observer or navigator) reviews each line of code as it is written, considering potential problems with strategic choices, as well as suggesting ideas for improvements.    They switch roles frequently.
8. Collective code ownership–everyone shares responsibility for the quality of the code, so that anyone can make necessary changes anywhere.
9. Continuous integration–all product changes to the code base are integrated at least daily.
10. Forty hour work week–if additional overtime is needed on a regular basis, this is considered a serious failure of the agile process.
11. On site customer–development team has continuous access to an on-site customer or a proxy.
12. Coding standards–everyone codes to the same standards and conventions

6.  6 Criticisms of XP

Although it is a very rigorous framework, there are some who have criticized the XP framework.  Among these criticisms are the following:

1. Stability of requirements (customer can add or remove stories from the backlog at will)
2. Lack of design specifications at the architectural of systems level
3. Lack of a document trail defining compromises made to solve user conflicts
4. Demand to have the customer/proxy on site (principle #11) is unrealistic
5. Requirement to have a unified customer viewpoint versus a single programming organization (principle #11) is unrealistic as well
6. Scalability seems to be an issue in XP framework

The next post will cover Lean Software Development, an agile framework which attempts to apply lean manufacturing principles that descend from the work of W. Edward Deming to the application area of software development.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s PMI-ACP Exam Prep PLUS Desk Reference, he exhaustively lists the various agile project management frameworks in chapter 2 “Introducing Agile Project Management”.

This post will cover the very basics of the Scrum approach which is the dominant approach in Agile Project Management right now.

1.  Scrum History

• 1986–Hirotaka Takeuchi and Ikujiro Nonaka write The new new product development game in Harvard Business Review, 64(1), 137-146, describing a holistic or “rugby” approach of having one cross-functional team moving through overlapping phases “passing the ball back and forth” as it were, similar to what happens in a rugby scrum.
• 1991–Peter DeGrace and Leslie Stahl first refer to this approach explicitly as the “Scrum approach” in their book Wicked problems, righteous solutions:  A catalogue of modern software engineering paradigms (New York: Prentice Hall).
• 1993–Jeff Sutherland, John Scumniotales and Jeff McKenna refer to this approach using the single word “Scrum” in the approach they developed at the Easel Corporation.
• 1995–Jeff Sutherland and Ken Schwaber collaborate in writing, sharing experiences and suggesting industry best practices, creating the first public presentation of Scrum.

2.  Scrum framework definition

Scrum is a project management framework that uses

• iterative cycles and
• incremental deliverables

to develop solutions.

3.  Scrum ethos–mutual commitments between the organization and the team

The organization agrees on the stability of

• the size of the timebox for all sprints (iterations)–usually two or four weeks in length
• specific deliverables for each sprint

This commitment creates a stable work environment which allows the team to focus on the work uninterrupted.    The team, on the other hand, commits to

• delivering the specific deliverables at the end of the sprint regardless of challenges that may occur

by promising to be as creative as necessary to solve problems.

4.  Scrum roles

• Scrum Master (SM)–ensures the process is understood and followed, removes impediments in the form of outside interference for the team
• Product Owner (PO)–also known as the “voice of the customer”, represents the stakeholders and the business, and sets the priorities for deliverables
• Team–cross-functional group which implements solutions to create deliverables

5.  Scrum key principle

Customers need to be able to change their minds about requirements.   This flexibility allows solutions to complex problems to emerge through a process which provides transparency, inspection and adaptation towards a solution which satisfies the emerging customer’s requirements.

According to John Stenbeck, 75% of organizations using agile use the Scrum approach–this is why he has synthesized a review of the specific Scrum framework and the general Agile PM framework in his “PMI-ACP Exam Plus PLUS Desk Reference”, the PLUS being the material on Scrum.

In the next post, I will describe Extreme Programming (XP), second to Scrum in terms of its adoption rate and marketplace usage.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s “PMI-ACP Exam Prep PLUS Desk Reference” guide, in his second chapter “Introducing Agile Project Management”, he takes on the huge topic of explaining the relationship between the development of lean manufacturing principles and the development of agile project management.    It’s important to understand this connection not only to understand the motivations behind agile project management, but also to dispel one of the common misconceptions about agile, that it is limited in its application to IT.

In this second part, I am going to elucidate the connection between Lean Manufacturing Principles and Agile Project Management.   First a brief recap:  here are the five core lean principles, which I’m repeating from the last post (Part 1).

A.  Five Core Lean Principles

1. Define the value the customer desires.
2. For each product, identify the value stream that provides customer value.
3. Challenge all of the wasted steps not directly providing customer value and remove them, so that the remaining value-added steps flow continuously through to the product.
4. Use “pulling” (production based on actual demand) between steps to create continuous flow.
5. Continuously move toward perfection by reducing the number of steps, and the amount of time and information needed, to provide the customer value.

B.  The Relationship between Lean and Agile

Okay, now that we’ve spelled out the lean manufacturing principles and the core beliefs that underlie them, let’s go into how agile project management draws upon them.

Applying manufacturing principles to project management means that rather than the processes of production, you are now dealing with the processes of product creation or development.    The output of production is a series of finished products, and the output of the development process is a new product.

Let’s take a look at Agile Project management concepts and how they map to Lean concepts (principles and core beliefs from the above lists).

1. Agile prioritizes business needs which are defined to create customer value (→ Lean Principle #1, 2).   Top priority is reserved for requirements that are most important to the customer, involve safety, and involve technical issues such as scalability.   The second tier of requirements should be those that focus on improving marketability, performance, and flexibility.  Then and only then should you focus on third-tier requirements that leverage opportunity or create comfort and luxury.
2. Agile focuses on speeding up time-to-market by removing delays in the development process (→ Lean Core Belief #1).   This reduces the elapsed time from idea generation to delivery of value to the customer.
3. Agile eliminates waste (→ Lean Principle #3).   This means waste in terms of time, in terms of money, and in terms of complexity of design (because it creates a lot more quality control work).  (→ Lean Principles #3 and #5)
4. Agile defers commitment on decisions until sufficient information is available.   If decisions are made based upon assumptions that turn out not to be true, then this will turn out to waste time, which is Agile principle #3 above.   These decisions are usually in two areas, 1) defining requirements and 2) planning and estimating.  (→ Lean Principle #5).   On the other hand, decisions cannot be made too late because of an arbitrary desire for increased accuracy.   This is because increasing the accuracy of any estimate requires resources, and at some point, spending more resources on an estimate than is necessary to get a useful level of accuracy will turn out to waste money (→ Lean Principle #3 and #5).
5. Communication with the customer is improved by developing the solution in increments and consulting with the customer at each increment   Instead of “pulling” production based on actual demand, which is the principle in lean manufacturing, in agile project management, the “pulling” that goes on is the clarification at each stage with the customer to make sure that the customer’s valued requirements are being translated into the technical characteristics of the product (→ Lean Principle #2, #4).   The design process can therefore be described as emergent rather than trying to be specified in detail at the very beginning stages as in traditional project management.

You can see by this set of correspondences between lean manufacturing principles and principles of agile project management that the frameworks share a lot in common, but that is because they have evolved in response to decreasing product design cycle times and increasing pressure on resources.

In the next series of posts, I will start a review of the agile frameworks, which include Scrum, Extreme Programming (XP), Lean Software Development, Feature Driven Development (FDD), Agile Unified Process (AUP), Crystal, Test Driven Development, and Agile Modeling (AM).   This will introduce the “agile lexicon” which is needed to understand the overal agile process map and the more detailed agile PM processes grid.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s “PMI-ACP Exam Prep PLUS Desk Reference” guide, in his second chapter “Introducing Agile Project Management”, he takes on the huge topic of explaining the relationship between the development of lean manufacturing principles and the development of agile project management.    It’s important to understand this connection not only to understand the motivations behind agile project management, but also to dispel one of the common misconceptions about agile, that it is limited in its application to IT.

In this first part, let me reiterate John Stenbeck’s exposition of what the lean manufacturing principles are and the core beliefs that have evolved from them.

A.  Five Core Lean Principles

1. Define the value the customer desires.
2. For each product, identify the value stream that provides customer value.
3. Challenge all of the wasted steps not directly providing customer value and remove them, so that the remaining value-added steps flow continuously through to the product.
4. Use “pulling” (production based on actual demand) between steps to create continuous flow.
5. Continuously move toward perfection by reducing the number of steps, and the amount of time and information needed, to provide the customer value.

“Lean thinking” based on these core lean principles started in manufacturing, but the tools and principles were adapted into other application areas or settings such as

• service sector
• healthcare
• construction
• non-profit
• public sector

B. Six Lean Core Beliefs

The five core lean principles evolved into the six lean core beliefs which are articulated as follows (again, thanks to John Stenbeck for his thorough exposition).

1. Measure of success for any system or process = the amount of time between when ideas come in and when value is received by the customer.
2. Any ad hoc (undefined) system or process will produce unacceptable delay in customer value because it cannot be analyzed and improved upon.   Processes must be defined in order to improve customer value.
3. Most process errors are caused by the system, not operator error (i.e., by people who work in the system.
4. The goal is to optimize the whole system, not merely individual steps.   Rather than optimizing the efficiency of each individual step, it is better to look at when the steps occur (i.e., the transitions between the steps).
5. Management must work with the team in order for the system to improve.
6. Teams are most efficient when the amount of work expected is within their capacity; efficiency is best improved by minimizing the amount of non-value or low-value work in any process.

These core beliefs of lean thinking became a paradigm for agile project development.    How this process occurred is the subject of the next post (Part 2).

Filed under: Uncategorized | Leave a comment »