1. Who uses WholeTEAM?

2. Is WholeTEAM agile (nimble, adaptable, efficient, etc.?)

3. Is the WholeTEAM SDLC model agile?

4. Will WholeTEAM make my enterprise more agile?

5. Is WholeTEAM simple?

6. Is WholeTEAM easy–to–use?

7. Is WholeTEAM free to use?

8. In WholeTEAM, who is the effective product owner of a mission–critical application?

9. In WholeTEAM, what is the makeup of a mission–critical application team?

10. In WholeTEAM, who is responsible for facilitating requirements?

11. In WholeTEAM, who is the ultimate decision–maker for a product's requirements, i.e., who is the ultimate decision–maker for a product's functionality?

12. In WholeTEAM, who is responsible for having GOOD REQUIREMENTS?

1. Who uses WholeTEAM?

For a sample of organizations who use WholeTEAM—who have adopted WholeTEAM as one of their standard tools—see our WholeTEAM Case Studies page located in the 'Community' section of this website. We use it too, for our own mission–critical applications.

Yes, WholeTEAM is agile (nimble, adaptable, efficient, etc.)

Yes, the WholeTEAM SDLC model is agile (nimble, adaptable, efficient, etc.)

There are three key indicators of whether or not a software development and a software maintenance approach is agile: (1) requirements definition period of performance, (2) release (a.k.a. Sprint, Iteration, etc.) duration, and (3) release execution.

1. If requirements definition period of performance is the early phases only of a release then an approach is not agile. On the other hand, if requirements definition period of performance spans all phases of a release then an approach is agile.
    
2. Secondly, if release duration is months only then an approach is not agile. On the other hand, if release duration can be also weeks, days, or even hours, and can be variable, then an approach is agile.
    
3. Lastly, if releases are executed sequentially only then an approach is not agile. On the other hand, if releases can be also executed in parallel then an approach is agile.
    

The WholeTEAM SDLC model is agile.

Yes, WholeTEAM will make your enterprise more agile (i.e., more nimble, more adaptable, more efficient, etc.)

Yes, WholeTEAM is simple. It has a small set of features. Each feature can be accessed from the framework home page left navigation menu or sub–menu. Each feature can be accessed in full with just one click. And, each feature is well–defined.

Yes, WholeTEAM is easy–to–use. To use it, simply: learn it, share it with your teammates as needed, and speak in it on your projects. (See How To Use.)

Yes, WholeTEAM is free to use and it always will be. (See its Terms Of Use.)

In WholeTEAM the effective product owner—the product owner from a requirements perspective—of a mission–critical application isn't a specific person or persons. Neither is it a particular group, a department, a division, an office, the business, or the enterprise. Rather, it is the product team—and, by definition, each and every member of the product team—and just the product team.

Simply put, in WholeTEAM the effective product owner—the product owner from a requirements perspective—of a mission–critical application is the whole product team.

In order to have GOOD REQUIREMENTS, it is essential to get right the following two things:

1. the makeup of the whole product team, and
    
2. the whole product team's requirements–related (product–functionality–related) decision making process, or, expressed another way, the whole product team's requirements definition and management (RDM) process.
    

Therein lies the secret to keeping your mission–critical applications always successful, always meeting business needs well.

In WholeTEAM a mission–critical application team is made up of Senior Leaders, Business, PMO, and IT.

In WholeTEAM the persons that are responsible for facilitating requirements are product managers, business analysts, and IT business analysts (business systems analysts.)

In WholeTEAM the ultimate decision–maker for a product's requirements, i.e., the ultimate decision–maker for a product's functionality, is the product's chief product architect (CPA.) A product team can have zero or more CPAs. There are three distinct requirements—three distinct product functionality—ultimate decision making modes that can be in effect:

Mode 1: Zero CPAs = Ad hoc (i.e., by SMEs, team leads, etc.)
Mode 2: More than one CPA = By a Product Leadership Team
Mode 3: One and only one CPA = By a Product Leader

In most cases, the ideal requirements ultimate–decision–making mode, i.e., the ideal product functionality ultimate–decision–making mode, is Mode 2 — by a product leadership team.

In WholeTEAM the one that is responsible for having GOOD REQUIREMENTS is the effective product owner — the whole product team, the whole team — oneself included if and only if oneself is a member of the mission–critical application team, and no one else.

Nov 2024