Using Agile In A Quality Driven Environment

Clicking on the image opens a PDF document containing an overview of my book.
The book documents a business analyst's experience with agile projects; Scrum in particular. It describes activities performed outside of the sprint cycle and identifies the benefits and quality that they bring to the implementation of a deliverable product. These activities are captured within a process named Quality With Agile, or QWAP for short. This book documents the QWAP process and how it is applied to Scrum, SAFe and Kanban.

Analysis Through Pictures

Clicking on the image opens a copy of my book that can be downloaded for free from lulu.com.
This is a book that I wrote between 2008 and 2011 about requirements analysis using Unified Modeling Language and the software development life-cycle with the Rational Unified Process. The intention is to demonstrate that a RUP-like SLDC with UML, can be performed without having to spend a fortune on expensive UML and software management tools. Instead I translate the procedures and artifacts that I would normally perform using the Rational Analyst Studio Suite, into equivalent artifacts and procedures using MS Office Suite, SharePoint and Visio. It also includes some examples of manging the life-cycle with MS Project.

MS Visio no longer supports the modeling features that are demonstrated by the process described in the book. The model in this book was created using MS Visio v2007, however there are many other available tools that support this process, for the same cost as Visio or less. Enterprise Architect and Visual Paradigm are 2 common modeling tools that be substituted for Visio 2007.

Agile Through Pictures

Clicking on the image opens a presentation containing an overview of the Quality with Agile process.
After 6 years working as a business analyst on agile projects I decided to document my experience with Scrum in a book titled 'Using Agile In A Quality Driven Environment'. My experience taught me that the Scrum process framework is not the complete story. Scrum does not identify roles for the business analyst, system architect, tester, UI designer or deployment engineers. Instead, the work normally performed by these roles is performed by the development team or the product owner. It is possible that the Scrum development team includes people with all of these skills, but the problem is that all the development team work is performed within a sprint cycle. The only activity that Scrum identifies outside a sprint cycle is maintenance of a product backlog (and even then it is not documented as an activity in the Scrum framework). This article provides an overview of this book, in which I detail activities that are performed outside the sprint cycle, and identify the benefits that these activities bring to a deliverable product.

Model of BABOK Version 3

The Business Analysts Body of Knowledge is a guide to business analysis, which includes standards, guidelines, tools, activities, techniques and core competencies for business analysts. Version 3 was released in 2015 and expands the scope of business analysis, providing essential direction and support for practitioners in areas such as agile, business intelligence, information technology, business architecture and business process management.

There is a wealth of information contained within this book. It contains a framework of tasks, techniques, guidelines and artifacts, but it is organized in a manner that it makes it difficult to extract only the information that is needed for a specific situation. Clicking on the BABOK cover image will open a document that shows an object-oriented model of the BABOK content organized by artifacts. It shows how inputs, outptus, tasks, techniques, workers, tools and guidelines that are associated with each artifact. This alllows the reader to view only the information relevant to their current situation.

A presentation containing an overview of this work is located here

An article that demonstrates the notation and organization of the model is located here

BABOK Artifacts Mapped To Artifacts

Clicking on the image opens a document that shows how BABOK artifacts are related to each other. For each artifact, 4 diagrams show:

• the full traceability of the artifact
• artifacts related to the artifact and their attributes
• the tasks, techniques and guidelines and tools used in the generation of the artifact
• the stakeholders involved with the creation of the artifact.

BABOK Tasks Mapped To Artifacts

Clicking on the image opens a document that maps BABOK tasks and elements to analysis artifacts and their attributes. The intention of this article is to identify and specify the artifacts listed in the BABOK. These artifacts are listed within the Outputs section of the BABOK tasks. Outputs are described by a paragraph of text within each task. In this article I attempted to expand on these descriptions by adding detail to their content.

BABOK Stakeholders Mapped To Artifacts

Clicking on the image opens an article that shows a mapping between BABOK stakeholders and artifacts. The intention of this article is to demonstrate the artifacts that stakeholders contribute to and artifacts that those stakeholders consume.

BABOK Techniques Mapped To Artifacts

Clicking on the image opens an article that shows a mapping between BABOK stakeholders and artifacts. The intention of this article is to demonstrate the artifacts that stakeholders contribute to and artifacts that those stakeholders consume.

BABOK Guidelines and Tools Mapped To Artifacts

Clicking on the image opens an article that shows a mapping between BABOK stakeholders and artifacts. The intention of this article is to demonstrate the artifacts that stakeholders contribute to and artifacts that those stakeholders consume.

BABOK Recommendations

Clicking on the image opens a document containing a number of recommendatins for improving my understanding of the BABOK.
These recommendations are the result of creating ad Object-Oriented model which captures the information contained within the BABOK version 3. Types of recommendation include:

• Errors or ommissions from the text or diagrams
• Clarifications of ambiguities
• Suggestions that simplify the reader's understanding, without losing any of the original information

Let me know what you think or if you have any additions to these suggestions.

Models And Diagrams

I see the terms 'model' and 'diagram' used interchangably. This is especially true when discussing computer aided software engineering (CASE) tools. I find that using distinct definitions for these terms can save a lot of confusion when talking about business and software processes and architecture.

Clicking on the Lego house diagram opens an article in which I demonstrate various models and diagram types and the benefits of their use.

Analysis of a Jigsaw Puzzle

Clicking on the jigsaw puzzle image will open a presentation that I use to introduce readers to the benefits and complexity of requirements analysis

Requirements Management and Traceability

Clicking on this image will open a presentation that I delivered to the IIBA in September 2015, about requirements traceability.
Presentation Overview

Shopping Expedition Part 1

Clicking on the business objects image will open part 1 of a multi-part series of presentations about improving the average shopping process. This presentation describes a business model of a typical shopping expedition and presents ideas for improving the process.

Shopping Expedition Part 2

Clicking on the class diagram image will open part 2 of a multi-part series of presentations about improving the average shopping process. This presentation describes a logical model for systems that could be used to improve the shopping process.