Author: Mark Whitfield

Welcome to my site! After graduating in Computing in 1990, I accepted a position as a programmer at a Runcorn based software house specialising in electronic banking software, namely sp/ARCHITECT-BANK on Tandem Computers (now HPE NonStop). This was before the internet became more prevalent and so the notion of enabling desktop access to company accounts for inter-account transfers and book keeping was still quite a cutting edge idea (and smartphones only ever hinted at in Space 1999). The company was called The Software Partnership (which was taken over by Deluxe Data in 1994). I spent 5 years in Runcorn developing code for SP/ARCHITECT for various banks like TSB, Bank of Scotland, Rabobank and Girofon (Denmark) to name but a few. I then moved onto a software house in Salford Quays for further bank facing projects. After a further 23 years in the IT industry and now a Senior IT Project Manager (both Agile and Waterfall delivery), I thought I would echo out my Career Profile in this corner of the internet for quick and easy access.

Mark Whitfield PM – Website & Blog focus areas

The blog posts by Mark Whitfield, a Senior IT Project and Engagement Manager, primarily focus on practical project management (PM) frameworks, methodology implementation, and digital delivery execution.

Mark Whitfield PM - Website and Blog focus areas

Hosted on his platform, PROject Templates, the blog acts as an extension of his 30+ year career transitioning from mainframe engineering to leading large-scale Agile and Waterfall digital transformations.

Blog Overview and Key Topics

The core purpose of the blog is to guide project professionals through real-world deployment challenges while showcasing an ecosystem of over 200 editable Microsoft Office templates.

The main content focus areas include:

  • Framework Implementation: In-depth overviews on aligning project lifecycles with PRINCE2 (7th Edition), Agile Scrum, and Kanban methodologies.
  • Detailed Project Planning: Actionable steps for setting up Software Development Life Cycles (SDLC), defining dependencies, establishing milestones, and handling project baselines.
  • Operational Checklists: Daily, highly practical guides tailored for specific team roles, such as his “Daily Checklist for Scrum Masters”.
  • Risk and Governance Control: Best practices on organizing and managing RAIDs logs (Risks, Actions, Issues, Dependencies), change requests, and corporate project governance.
  • High-Level Reporting: Frameworks for structural communication with stakeholders, utilizing Plan on a Page (POaP) examples, dashboard designs, and financial budget tracking templates.
  • Digital & Cloud Delivery Lessons: Real-world insights drawn from his corporate and public sector experiences, covering topics like middleware architecture deployments and hybrid cloud application refactoring.

Agile for Business Analysts BA

Agile for Business Analysts BA
Agile for Business Analysts BA

In an Agile environment, a Business Analyst (BA)acts as the crucial bridge between business stakeholders and the technical team. Rather than gathering all requirements upfront, Agile BAs focus on continuous analysis, delivering value in small increments, and writing lightweight user stories that adapt as the product evolves.

Transitioning from traditional (Waterfall) analysis to an Agile framework requires a fundamental shift in how requirements are handled, documented, and delivered.

The Core Shifts in an Agile BA Role

  • Continuous Discovery: Instead of producing a massive Requirements Document at the start, BAs analyze and refine requirements just-in-time and just-enough to keep the development team moving.
  • User Stories over BRDs: Traditional Business Requirements Documents (BRDs) are replaced with collaborative user stories and acceptance criteria.
  • Value-Driven Prioritization: The BA continuously helps the Product Owner (or acts as the Product Owner proxy) rank the Product Backlog so that the highest-value features are built first.
  • Shared Understanding: The focus is on face-to-face communication, workshops, and visual modeling (like wireframes) to ensure developers fully grasp what needs to be built.

Key Responsibilities

Agile BAs operate across several domains throughout the sprint lifecycle:

  1. Backlog Refinement: Collaborating with stakeholders to break down large, complex requirements into smaller, manageable chunks (Epics to User Stories).
  2. Definition of Ready (DoR): Ensuring that user stories are clear, testable, and have defined acceptance criteria before they are pulled into an active sprint.
  3. Sprint Support: Answering questions from the development team in real-time, clarifying business rules, and helping to remove blockers.
  4. Acceptance Testing: Assisting Quality Assurance (QA) teams or business users to validate that the delivered software works as intended and solves the underlying business problem.
Agile BA versus Traditional BA
Agile BA versus Traditional BA

Common Frameworks for Agile BAs

  • Scrum: Working alongside the Scrum Master, Product Owner, and Developers in short iterations (sprints), typically lasting 2 to 4 weeks.
  • Kanban: Managing a continuous flow of analysis work, prioritizing items on a visual board as development capacity allows.
  • AgileBA: A specific certification and framework designed by the Agile Business Consortium that provides BAs with practical tools for working in Agile settings.

Recommended Resources for Skill Building

To deepen your expertise in Agile business analysis, explore these highly regarded methodologies and guides:

  • Use the AgileBA Certification guide to understand official best practices.
  • Read the IIBA Agile Extension to the BABOK Guide for authoritative frameworks.
  • Review Bridging the Gap for practical, real-world implementation strategies.

Agile Scrum vs SAFe (Scaled Agile Framework), Key Differences

Agile Scrum vs SAFe (Scaled Agile Framework), Key Differences
Agile Scrum vs Scaled Agile Framework (SAFe)

The fundamental difference is scale: Agile Scrum is designed for a single, autonomous team (typically 5–9 people), whereas Scaled Agile Framework (SAFe) is built for the enterprise level to coordinate dozens of teams (50+ people) working toward shared business goals.

Scrum prioritizes team flexibility and speed. Conversely, SAFe trades complete autonomy for centralized alignment, consistency, and structural predictability.

Industry Perspectives on the Trade-offs

While SAFe solves enterprise synchronization challenges, it faces regular scrutiny from product leaders who argue that its highly prescriptive nature can stifle the true spirit of agility.

A popular comment from an agile practitioner on Reddit’s Scrum Community highlights the developer sentiment regarding the process overhead:

“I’ve never seen SAFe implemented without a meeting explosion. More planning, more roles, more acronyms and way more time blocked on calendars.”

Another developer shared a similar perspective on Reddit’s ExperiencedDevs Community:

“Number of meetings have increased 4x. More time is spent for planning to build software than actually building software. Bureaucratic rituals are more important than getting things done.”

Ultimately, SAFe does not replace Scrum. Most organizations implementing SAFe still utilize standard Scrum practices at the team level, leveraging the macro framework solely to manage the dependencies that threaten to derail massive initiatives.

Choosing the Right Approach

  • Choose Scrum if: You have a small or mid-sized setup, your teams operate independently, you are early in your Agile journey, and your primary pain point is a need for fast market-feedback loops.
  • Choose SAFe if: You are coordinating 50 to 1,000+ engineers across complex legacy systems, cross-team dependencies frequently delay your releases, and you need strict regulatory compliance or top-down executive alignment.

Agile Scrum Master, a Typical Day

Agile Scrum Master, a Typical Day
Agile Scrum Master, a Typical Day
Agile Scrum Master, Typical Day

Convincing a Team During PM Planning Sessions

Convincing a Team During Project Management Planning Sessions
Convincing a Team During PM Planning Sessions

Time Boxes for the 5 Scrum Events

Time Boxes for the 5 Scrum Events
Time Boxes for 5 Scrum Events
Time Boxes for Scrum Events

PRINCE2 and Waterfall, an Overview and Comparison

PRINCE2 is a structured project management framework, whereas Waterfall is a linear-sequential software development lifecycle (SDLC) methodology. While people often compare them, they are not mutually exclusive. PRINCE2 tells you how to manage a project, while Waterfall defines how to build the product.

PRINCE2 & Waterfall Overview and Comparison
PRINCE2 & Waterfall –
Overview and Comparison

Here is a detailed overview and comparison of both.

Overview of PRINCE2

PRINCE2 (PRojects IN Controlled Environments) is a process-based method for effective project management. It provides a highly structured framework that focuses on business justification and clear roles.

  • Core Logic: Divided into 7 Principles, 7 Themes, and 7 Processes.
  • Structure: Focuses on high-level management, governance, and organization.
  • Flexibility: Product-based planning allows it to wrap around any delivery method.
  • Roles: Explicitly defines responsibilities (Project Board, Project Manager, Team Manager).

Overview of Waterfall

Waterfall is a traditional development methodology where a project moves sequentially through distinct phases. Each phase must be completed before the next one begins.

  • Core Logic: Requirements → Design → Implementation → Verification → Maintenance.
  • Structure: Linear, rigid, and heavily reliant on early stage documentation.
  • Flexibility: Extremely low; changes to requirements are costly once development begins.
  • Roles: Focuses on execution roles (Business Analysts, Developers, QA Testers).

Key Structural Differences

PRINCE2 and Waterfall, an Overview and Comparison
PRINCE2 and Waterfall, an Overview and Comparison

How They Work Together

PRINCE2 is frequently used to govern Waterfall projects.

  • The Management Layer: The Project Board uses PRINCE2 to manage budgets, risks, and business justification.
  • The Specialist Layer: The technical team uses Waterfall to execute work packages (e.g., designing, coding, testing).

Which One Should You Choose?

  • Choose PRINCE2 if: You need robust corporate governance, clear stakeholder accountability, and a way to manage high-budget, high-risk projects.
  • Choose Waterfall if: Your product requirements are completely fixed, the technology is well-understood, and the physical architecture cannot be easily changed (e.g., construction).

Project Management Office PMO Roles, Responsibility

The Project Management Office PMO Roles, Responsibility
Project Management Office PMO Roles, Responsibility