We often get questions about the combination of USoft and Agile. This is a background article. You can skip it unless you are looking for backward information.
The USoft Approach is an early Agile approach
The USoft approach originated in the early 90s of the previous century and was associated with early Agile methodologies such as DSDM.
The main concern at the time was to provide tools and methods for making software in a more rapid and flexible way than was possible with the traditional "waterfall" method. In "waterfall", software requirements were drawn up following rigid step-by-step protocols. This required discussion and ratification of lengthy design documents before the first steps were made to actually code the software. Flexibility was sacrificed for control. This control was necessary because, with the available tooling, it was almost impossible to change software unless you carefully planned in advance what you wanted to achieve.
There are overlaps and differences compared to Agile
Because of its Agile origins, USoft has important overlaps with later and more widely known flavours of Agile such as Scrum, which developed in the wake of the 2001 Agile Manifesto. But there are also important differences.
Here are some overlaps:
| USoft | Scrum |
|---|---|
| Requirements can be itemised so they are more easily managed, regrouped, prioritised and validated than lengthy document texts. The items are business rules. | Requirements can be itemised so they are more easily managed, regrouped, prioritised and validated than lengthy document texts. The items are user stories. |
| Frequent prototypes are a mark of quality. They allow constant feedback and avoid misunderstandings. | Frequent delivery cycles or sprints are a mark of quality. They allow constant feedback and avoid misunderstandings. |
Here are some differences:
| USoft | Scrum |
|---|---|
| The primary focus of business rules is to capture how the client organisation wants to operate. | The primary focus of user stories is to facilitate the development process.Specifications are tailored to developers. They are broken down into concrete, sprint-ready task descriptions that developers are able give a cost estimate for. |
| The best way to improve software development is to capture business content: to formulate the desired business conduct that the software must support. | The best way to improve software development is to clearly define and control the manufacturing process: aspects: the roles that people have, the individual deliverables they complete, and the ceremonies that take place. |
USoft and Agile are easy to combine
USoft and Agile are easy to combine but it is necessary to organise this combination.
With Scrum, you create collections of user stories. There are many excellent tools available for storing and presenting user stories, such as Atlassian Jira.
With USoft, you create formulations of business rules.
The principal danger when you combine the two is that you may be tempted to duplicate information: to write down (nearly) the same information in two slightly different places or formats. This is harmful to the project because it is almost impossible to keep duplicated or near-duplicated information in sync. You risk making changes in one place and not the other. This leads to inconsistency and confusion.
The solution is first of all to make sure that all team members understand the different purpose of USoft specifications and Scrum user stories.
USoft gives you well-structured specifications of business rules and business vocabulary (terms and definitions). These are not just about project deliverables. They also take in the business context in which the software must operate. They are an information asset for a wide variety of target groups. This asset is valuable before, during and after the project. Think "knowledge base".
Scrum user stories articulate and support the development process. They are specialised in facilitating Scrum team members: this is their primary target group. They are increasingly valuable as they become sprint-ready. Their value diminishes when their purpose has been served and the deliverables have been achieved. Think "progress board".
You need to organise USoft specifications and Scrum user stories in such a way that they support each other and no information is duplicated between them. This requires two things:
- All those concerned must have constant access to the USoft specifications. The USoft specifications must be available from anywhere and feature Single-Point-of-Truth: a central database that always shows the latest state, as opposed to versions of documents being sent around in e-mails and spreadsheets. The USoft Studio tool is designed to offer exactly this.
- Clear work instructions must be given so that Scrum user stories refer to USoft items by ID where necessary, as opposed to duplicating information also found in USoft. The nature of business rules and business vocabulary is that they may be needed again in different situations and at different times. This is why user stories must refer to business rules and not the other way around.
Sign up for the USoft Community