In my work, I have been confronted a lot with the crucial question of how to establish an effective connection between business and IT. In the pre-Agile era, this responsibility typically fell on the Business Analyst, who would hand over business requirements (needs) to the Functional Analyst for conversion into a functional design (solution). However, even then, discussions revolved around:
Should a business analyst be part of the business or IT team?
Where are the boundaries of a Business Analyst versus a Functional Analyst, considering cost and technical restrictions that may challenge certain business needs.
Who takes care of small enhancements for which there is no need of a detailed and complex analysis and process?
Who makes the bridge with the end-users and all non-IT activities (like marketing roll-out, process adaptations…)? To fulfill these requirements, organizations often introduced additional roles such as Process Analysts, Business Owners, or Business Application Owners.
…
With the rise of Agile methodology, the traditional roles of Business Analyst and Functional Analyst have given way to new positions like Product Managers and Product Owners. Although the way of working has evolved and these new roles come with different responsibilities, the pain points and discussions remain the same as before.
In these discussions everyone seems to have a proposal for the perfect organizational model. However, in reality, organizational models are always a compromise, depending on the skills of individuals and the nature of the work. Considerations include:
Project Size: the organization for a 1000 manday project differs from a small 2 manday evolution.
Project Type: a technical project (e.g. refactoring or setup of new monitoring system) requires a different organization than a business project. And even 2 business projects can be very different. E.g. a project which is very UI oriented requires a different approach than a project, where a back-end workflow is modified, despite both having significant business impacts.
Existing Logic vs. Building from Scratch: projects that adapt existing logic/code are organized differently from those that involve creating new applications or features. Similarly, implementing a custom-built application varies significantly from implementing a packaged solution.
Programming Approaches: Low-code/No-code applications enable developers to work closely with the business and iterate more rapidly, unlike traditional programming languages. AI/ML projects also follow a distinct approach, even though they ultimately result in algorithms.
Perspective and experience of individuals¨: the background and experience of the persons involved in the project will also impact the approach. Technical experts with deep application knowledge approach the work differently from junior product managers or owners with a stronger business orientation.
In essence, context is paramount, and there is no one-size-fits-all rule. Nevertheless, I often encounter posts making absolute statements such as:
The Scrum Master and Product Owner must be different individuals.
Product Manager and Product Owner roles cannot be separate.
Product Owners should not impose solutions while defining stories.
Product Owners should not be part of the Scrum team.
Development tickets should be written in the form of user stories in the format "As a [persona], I [want to], [so that]".
While these statements hold merit, they excel in ideal and theoretical scenarios where
The scrum team is only occupied with 1 project
The project is rather large, but not too big either (around 100-200 mandays)
The project will result in a new custom-built application
The application is strongly end-user facing
This situation rarely exists in reality, i.e. in reality IT teams have to deal with a mix of
Small and large projects
Back-end and user-facing work
Changing priorities and budgets
Evolving teams (people joining/leaving the company)
Different profiles (full-stack engineers versus front-end/back-end engineers, junior versus senior profiles, people who already know well the application stack versus people who are discovering the application stack…)
…
To address these complexities, each Scrum team must find the best organizational approach for their specific context and continuously adapt and improve based on lessons learned.
Some key considerations include:
Keeping Scrum teams relatively small (following the "two-pizza team rule").
Granting teams a high degree of autonomy.
Making teams accountable for end-to-end outcomes, embracing both the challenges and rewards.
Establishing a set of guiding principles (5-10 golden rules) that cannot be compromised.
This combined with a good dose of pragmatism and a hands-on approach, will propel your team a lot further than any rigid theoretical framework imposed in many organizations.
Check out all my blogs on https://bankloch.blogspot.com/
Comments
Post a Comment