Tag: Methodologies

Design Thinking in a Waterfall World

Written by Oluwakorede Asuni on June 24, 2020. Posted in Articles.

As much as we like to think we are now in a dynamic and agile world, most delivery initiatives are still some shades of agile and all shades of waterfall.

These initiatives could have adopted an agile outlook and naming convention, but the businesses they support are often still predominantly waterfall – going from one clearly defined task to another until realizing value. Think for example, order to cash, just in time logistics etc.

We often have some outliers, mostly modern businesses without legacy overloads and whose core business is digital or relies heavily on digital who may have cracked the agility question.

Waterfall is seen by most agile advocates as a relic of a time that had been and that should be forgotten and buried.

Waterfall is expensive, time consuming and unforgiving of errors.

Design thinking, on the other hand may be equally as expensive especially for organizations with legacy burdens switching over to an agile way of work, has picking up errors early built right into its DNA and offers opportunities to succeed quickly or fail fast.

A variation of the plan-do-check management methodology – the decision is easy to reach if one strips down the elements of the methodology into its bare bones fundamentals –design thinking allows the business or the delivery team to involve the customer for whom a product or service is being designed early on in the delivery effort. Design thinking offers up an opportunity to build a product truly needed by the customer and not one that was assumed the customer needs.

The question one ponders then is whether an enterprise or delivery team can only be one or the other? Or be both?

An important point of departure is that agility is a mindset, a mindset written into an organisations’ DNA and not only those of its project delivery teams. Agility does not rest solely on the tools and techniques that an organisation or its teams chooses to work with, rather it relies heavily on the collective agreement between teams and individuals; the capacity to work quickly, to experiment all the time, to learn fast and to be honest with itself all the time.

That said, with an agile mindset, design thinking techniques can be applied within each phase of the waterfall methodology.

For example, in the requirements phase of a waterfall project, the elements of design thinking’s empathise, define and ideate can readily be adopted. A bold team may and should also prototype and test their assumptions and some of the features of their product/service with real customers. Done well, the requirements phase of a waterfall project doesn’t then just end with a signed off requirements specification, but also the knowledge of what the customer truly wants backed with empirical data. And potentially the design and implementation phases have a ton of knowledge of the market to go on with – in essence most of the work in these phases of waterfall delivery would have been completed during the define stage as done as described above.

The actual waterfall phases of design and implementation then just becomes opportunities for refinements of the work done in the requirement phase using design thinking, and for honouring the legacy requirements of phase gates.

The refinement efforts in each of the design and implementation phases could also leverage design thinking. For example, the design phase of waterfall could leverage prototyping and test multiple user experience approaches – building on the work started during requirements. And in the implementation phase will build based on the output from the design phase which has determined with a high degree of accuracy what the customer truly wants.

The test phase of the waterfall delivery effort, may end up being systems’ tests (regression and systems integration tests) and confirmatory usability tests – as actual usability tests would have been completed upfront during requirements and design phases where the team had brought in the real customers to empathise with, define and ideate with, prototype for and tested with.

One can then safely conclude that waterfall can co-exist with design thinking (and really most other agile techniques) if the organisation’s mindset focused on agility and not processes for the sake of processes.

Applying Maslow’s theory of Needs to Business Analysis

Written by Ashish Adike on June 17, 2020. Posted in Articles.

Having worked on multiple IT implementations and Transformation projects I have often found the evolution of user’s requirements follow the Maslow’s theory of needs.

Adoption of this theory in the requirement gathering process would turn out be fruitful for Business Analysts in efficient Requirement Elicitation from the Users.

Although most of us are aware about the Maslow’s Theory of needs, a quick memory refresh would be helpful:

Maslow’s hierarchy of needs displays the order of human needs in the form of a Pyramid with lowest levels made up of most basic needs moving on to the top of the pyramid with complex needs as depicted below.

Physiological Needs: The basic human requirements to survive would comprise the Physiological needs like Food, Water, warmth, and rest.

Security/Safety: Once the Physiological needs are satisfied, the need for security and safety arises. This comprises of financial, emotional, social security, and health and well-being.

Love/Belonging: These needs are driven by interpersonal relations like friendship, love, trust and acceptance among individuals.

Self-Esteem: The fourth level of needs arise out of the feelings of getting praised by others for self-accomplishments be it professional, academic, athletic, or personal.

Self-Actualization: The final level of needs reflects the realization of individuals to utilize the complete potential, so that they can do the best that they are capable of doing.

Now coming back to our original discussion on following the Maslow’s theory of needs for requirements elicitation, the below framework often works to elicit requirements from users starting from basic system requirements to the complex analytical requirements to explore the full potential of the system.

The 5 evolving stages of requirements are Data Capture, Data Security, System Integration, User Experience, and Analytical Capabilities. As we progress from bottom to top of the pyramid, the responsibility of BA to make recommendations to elicit the requirements from the users increases. Let us look at each of these stages by taking an example of a Salesforce CRM implementation

1. Data Capture:

The first stage is critical and forms the major portion of requirements as this serves as the foundation of the implementation just like the Physiological needs serve as the base for human survival.

In general, any IT implementation would start with a problem statement where the Business has an issue with missing data capture or users spending their valuable time on mundane repetitive tasks which could be automated. It is the responsibility of the Business Analyst to capture the basic needs from users in terms of data they would like to capture, and the level of automation required to perform their everyday job.

In our example of Salesforce implementation, the information that needs to be captured like Leads, Opportunities, Accounts, Contacts need to be captured at parameter level with respective UI forms for data capture along with validations. Also, the automations that govern the system functionality need to be captured. For example, updating a parameter in Accounts from the corresponding parameter on Contact.

2. Data Security:

Once the basic requirements are established with respect to Data storage, User Interface and automations, the security of the data recorded in the system becomes critical just like need for Security in human life.

Different sets of users would need access to different data elements and the level of access in terms of Read/Write would differ as well. The BA needs to carefully gather the requirements of Data Security from users and work on profiling of these users.

In our example of Salesforce implementation, the Sales team would needs read/write access on Opportunity data whereas the Finance team would only need read access to Opportunities to perform forecasting and the Operations team might not need access to Opportunity data at all. There would also be scenario when one Sales Representative would not want other Sales Representative to access his Opportunity data. Hence, the Security of the data forms the next level of User needs in order to feel secure while using the application.

3. Data Integration:

Once the data is recorded in the system and is secure within the system, the next need is to have communication with other systems so that there is proper exchange of information between the systems to complete the end to end transactions. This is like the need for interpersonal relations like friendship between humans.

Different systems serve as the system of record for different data elements within an IT Architecture. Also, in most cases there is always a Master data system where all the critical data gets stored. As a BA it is important to identify the need for the required data for an application to work as expected and identify the downstream systems which would use the data from the application. This information may not be directly provided by the end users, but it is the responsibility of the BA to study the IT landscape and identify the different source and destinations of data.

In our case of Salesforce implementation, the Customer Account information would generally be recorded in the ERP, so Salesforce needs to integrate with the ERP to get the Account information. The Order information from Salesforce was used by downstream order fulfillment application, so Salesforce needs to integrate with this downstream application to complete the Order fulfilment process.

4. User Experience:

Once a working system is in place with the required basic functionalities to fulfill everyday job of the user, the user experience factor comes in which would further drive the requirements to make the system more user friendly and intuitive, hence leading to appreciation of the system by the users. This is like the self-esteem needs of human life.

Now that the basic functional requirements from the user are gathered, it is the responsibility of the BA to drive the requirements for better user experience. This would encompass aesthetic requirements like the look and feel of screens, user guidance while using the system, mobile usability etc. Although this type of requirements might not sound critical during the initial implementations, they turn out to be critical once the users start using the system, and there have been projects purely focusing on improving user experience.

In our case of Salesforce implementation, the choice between using Salesforce classic which is traditional user interface as compared to Salesforce Lightning which has an advanced User Interface would be critical in determining the user experience.

5. Analytical Capabilities:

Once the requirements for a fully functional and user friendly system are established, the insights that the data stored in the system could provide to the user becomes important, as it would enable the user to utilize the complete potential of the system and make business decisions. This is like the need for realization of individuals to utilize the complete potential so that they can do the best that they are capable of doing.

The Analytical requirements would be predominantly in the form of Reports and Dashboards that could be derived from the data stored in a system. With the advancement in Artificial Intelligence, the data could be used to provide suggestions to the user as well. Many a times, the user may not be directly able to give requirements with respect to Analytical capabilities, so the BA needs to determine the KPIs for the business users and recommend the suitable reports and dashboards around the same.

In our case of Salesforce implementation, once the Sales users have a well-functioning Opportunities module in Salesforce, it would be great if they are able to generate reports on the Opportunity pipeline and even better if they have a dashboard depicting the Opportunity Pipeline which would enable them to make quick decisions.

Requirement elicitation is often complex with users not being able to articulate the exact requirements in a proper order. Following the bottom-up approach from the Pyramid would help to a great extent in eliciting the requirements from users, starting from basic to the complex requirements.

References:

1. https://www.simplypsychology.org/maslow.html

4 key activities for a Business Analyst in the Alpha phase

Written by Nick Stowers on May 14, 2020. Posted in Articles.

On one of my earlier blogs, I described what I thought are the 3 key activities a BA should be doing when they were in a Discovery phase of a project.

The feedback I received was positive so I thought I’d give, what I consider to be are the 4 key activities are for a BA in an Alpha phase.

So what exactly is an ‘Alpha’?

In the UK, the Government Digital Service (GDS) defines the phases in an Agile delivery lifecycle as; Discovery, Alpha, Beta, Live and Retiring the service. GDS also cover in detail how the Alpha phase works, but what’s not covered in the article is what each role in a delivery team does within an Alpha, including Business Analysts.

If you’re not familiar with the names of these phases, they are the same for pretty much all Agile project delivery. The most common themes I’ve come across are;

Concept, inception, iteration, release, production, retirement

Moving Discovery outputs in to an Alpha

Key outputs from the Discovery the BA should have been heavily involved in include:

Stakeholder analysis
Understanding and defining the problem
Starting the product backlog

Each of these outputs now need to be taken through in to Alpha by the BA and here’s how.

Stakeholder analysis – Use your stakeholder knowledge

An Alpha to me is the exciting part of the Agile delivery lifecycle as this is where you actually start putting ideas and concepts in front of users and you learn ‘how’ they will really interact with your product and get valuable feedback. To ensure you get as honest and realistic feedback as possible, it’s important to try and create as real-life scenarios as possible to test the prototype with users. To do this, the BA should use their knowledge of working with stakeholders in Discovery and take this in to the development of the prototype with the designers on the team. After all, if you were the BA involved in Discovery, one of your key outputs is understanding the users and their needs, and that includes the needs of the business. Therefore, armed with this insightful knowledge, you should work closely with the design team to ensure they also understand the users.

Understanding and defining the problem – Keeping the product vision in view

During Discovery, the team will have (or certainly should have) defined the problem that needs to be fixed and from that, a product vision should also have been defined. Roman Pichler has an excellent article on how to create a compelling product vision which I highly recommend you read as well as all the other articles he has on his website.

For me, the product vision is one of, if not the key outputs from Discovery and is something that should be visible and referred all the way through the delivery lifecycle. All too often I’ve seen the product vision put up on the team wall (or worse, in a folder on the Product Owners laptop) but no one seems to take any notice of it and it becomes just a part of the wall space along with user research findings, sprint boards, etc. To make sure the product vision stays in view, and you have wall space, have it beside your user story map (coming up in the next section). Pretty much everything that’s in your user story map should stem from the product vision, so keep them close together.

Starting the product backlog – Make sure prototypes stem from user needs (building your user story map)

How prototypes are developed is different for all teams but in my view, the quicker you get to an interactive prototype, the better. I’m all for sketching out designs to protect costs and save time, but only once a prototype is in the hands of users and seeing their interactions with it, will you start to get valuable (and workable) insights to develop the prototype further. And remember, as the BA, you’re going to start building the product backlog based on the findings and create your user story map. If you’re even half serious about being a Business Analyst, I don’t need to tell you the powerful impact of user story mapping but if you need reminding, here’s Jeff Paton (the guy who came up with the idea of user story mapping) showing you how to create one.

Help the team design iteratively

Having your user story map on the team wall (or online if you are a in several locations. I recommend www.storiesonboard.com as a user story mapping tool) is a great way to galvanise the team and ensure what you’re doing aligns with the product vision (hence having the vision next to the map). As we know, agile delivery focuses on building products in an iterative way and this principle should apply to designing prototypes in Alpha. I quite often see designers go off and start building complex, end to end user journey. For this very reason, having a user story map will encourage the design team to not think too far ahead. After all, your map will have an ‘MVP’ (or Release 1 if you’re not comfortable with the term MVP) swim-lane where you’ll define as a team what features will (or might) go in the MVP and this is what the design team should be focusing on prototyping.

And finally…

Don’t misunderstand me, and this is based on the feedback from my ‘BA in a Discover’ blog, these are not the only 3 activities a BA will carry out in an Alpha and you will no doubt carry out more than this (e.g. writing the user stories for Beta, working with technical architects/software developers to ensure what is being designed and tested with users can actually be built, continually developing the backlog, etc) however I’ve seen projects where the BAs have not been involved much in the design process and this which has led to problems further down the delivery process. Remember, you as the BA are the bridge between the design team and the developers/testers!!

An Alpha (or iteration) phase can last several weeks and if you as the BA follow these activities, you’ll ensure the product is designed with the users in mind, in an iterative way, and that when you get to the Beta phase (blog coming soon), your product will be delivering the value defined by the product vision.

Requirements in Context 2020 – The Trips-R-You Case Study (and Benchmark?)

Written by Dan Tasker on April 30, 2020. Posted in Articles.

The objective of my 2016 Requirements in Context series was to help business analysts elicit requirements

through an improved understanding of the difference between high-level requirements (HLRs) and detailed requirements (DTRs).

The Trips-R-You case study is an addendum to that series, offering end-to-end examples of requirements documented using spreadsheet-based templates.

In IIBA® BABOK® V3 terminology, end-to-end means from Business Requirements to Stakeholder Requirements to Solution and Transition Requirements. Both the original series and the case study use the more traditional business terms Goal, HLR, and DTR. Also both only address functional requirements within the context of a project chartered to deliver an IT-based solution.

NOTE: A business may choose to organize their IT solution-delivery resources following Agile principles. But if the delivery of those solutions are managed by a project manager, or the Agile teams do not include a ‘real’ product owner – able and available to prioritize and refine user stories, then requirements still need to be documented and managed.

The Case Study

The case study involves a fictitious organisation — the Trips-R-You Travel Agency. It deals primarily with the requirements phase of an equally fictitious project, established to deliver a web-based customer self-service flight booking capability — commonly referred to as an Airline Reservation System.

The case study is divided into three sections, based on the three levels of requirements. The first section introduces the organization and a problem it faces. A goal is set that is intended to eliminate the problem, and a business case is commissioned to examine potential solutions.

The second section sees a project initiated to deliver the solution recommended by the business case. That project’s scope is shown, and how it leads to high-level requirements for the project.

The third section takes five HLRs to the detail level – one HLR involving each of the primary capability types a business information system is able to support:

User Interface (UI)
Report
Data Import
Data Export
Automated Function

To support capturing the details involved in each of the above capability types, type-specific spreadsheet-based templates are utilized.

The third section also discusses and uses a Data Dictionary template. As the detail for a given HLR is discussed, the data-specific business needs involved are captured using this template. Once captured, those data-specific details are available for referencing in the other templates when those needs come up again, as they will, during discussions involving other HLRs.

NOTE: The Data Dictionary template incorporates the concepts presented in my 2018 “Well-defined Data” series.

Detailed Requirements vs Detailed Requirement Statements

It’s natural (and correct) to assume that for every HLR, there will be some number of DTRs. But what, exactly, should a detailed requirement look like? A formal requirement statement is expected to be a single sentence that includes the word ‘shall’ (rather than a term implying a priority such as ‘must’ or ‘should’). More typically, to accommodate detail, a textual requirement statement involves a number of sentences or paragraphs.

Requirement documentation techniques that make use of ‘fully dressed’ UML use cases describe an Actor interacting with ‘the system’ performing a given business activity. That description includes the individual steps within the activity, organized into different flows — one main flow and any number of alternate and/or exception flows. The step description includes names of individual fields and ‘controls’ (e.g. buttons) involved. The requirements documentation technique may treat each flow or each step within the use case as an individual DTR, or treat the entire use case as a single DTR.

The spreadsheet-based templates used by the Trips-R-You case study uniquely identify individual rows, each representing a detailed requirement (but not in ‘statement’ form). Three separate worksheets (tabs) are used to capture different categories of detailed requirement. Those three categories address:

The capability’s operation – E.g. who needs it, when.
An Individual element – E.g. a field, control, or step within an automated function.
An Element Grouping – E.g. an area on a screen or report (see mock-up below), a record being imported or exported.

Tabular format allows for separate columns to represent different types of detail (i.e. characteristics) applicable to a given item. E.g. for an individual field element within a report area, characteristics identifying the font to be used and whether the field is to be justified left, right, or centered. The templates also support visual representations of the detailed requirements, such as screen or report mock-ups (see example below).

Because all of the details for a ‘unit of delivery’ (a specific UI, report, etc.) are captured in an individual spreadsheet file, those DTRs can be represented by a single ‘formal’ DTR statement (similar to a whole use case being treated as a single DTR). The following is an example from the case study of one of the HLR statements for a report, and its corresponding single formal DTR statement representing the template-based DTRs for that report:

REQ008 (HLR) – A customer shall be able to access and print the booking confirmation details.

REQ015 (DTR) – The system shall be able to produce a Booking Confirmation report for a specific Booking – as specified in DR015 – Self-service Booking Confirmation Report v1.0.

The template-based DTRs for this report consisted of the following:

Worksheet	# of Rows
Operational	15
Elements	65
Report Areas	6

The spreadsheet file also included the following mock-up, visually representing the six Report Areas and the Elements contained in each:

Individual Statements, Templates, or a Requirements Management Tool?

Requirements have a reputation for taking too long to document. They have probably earned that reputation from projects where: Requirements were ‘hand-crafted’ requirement statements; HLR statements were allowed to include too much detail; And DLR textual statements were written that included varying combinations of details about fields and/or field characteristics.

Keeping HLRs to the capability type-specific level (i.e. specific UI, report, etc.) is intended to avoid time wasted at this stage of requirements elicitation. Using capability type-specific templates is intended to save time by representing and providing space for capturing values for the specific types of details that need to be addressed for each capability type and category.

NOTE: The templates used in the Trips-R-You case study represent an amalgamation of detailed requirement types and characteristics based on my years of experience as a business analyst working in project teams delivering IT-based solutions. That experience included working for software package vendors, for organizations acquiring software packages, and for organizations outsourcing parts of a solution.

Better than spreadsheet-based templates, where affordable, would be a commercially-available requirements management (RM) or application lifecycle management (ALM) tool that supports the requirements-related concepts presented in the Trips-R-You case study.

The Trips-R-You Case Study as a Tool Benchmark

In addition to being an aid to understanding concepts related to HLRs and DTRs, it was hoped that the Trips-R-You case study would serve as a benchmark utilized by RM and ALM tool vendors. While their tools would not be expected to support all of the concepts out of the box, most tools currently on the market offer some degree of configuration. Any organization looking to acquire a commercially-available tool to support the requirements phase of IT-based projects might ask their candidate tool vendors to demonstrate their tool’s ability to support this case study.

NOTE: Any tool vendor that believes their tool to be capable of supporting the “Requirements in Context” concepts represented in the Trips-R-You case study is welcome to contact me for assistance with the benchmarking exercise.

Where Exactly Do Waterfall BAs Best Position Themselves on Agile Teams

Written by Laura Paton on October 24, 2019. Posted in Articles.

Let me begin by establishing who it is I am speaking about, when I use the phrase waterfall BA.

I use this reference to speak to the business analysts who have worked waterfall projects but have zero experience working on agile projects. I also include in this group the business analysts who are working in organizations who ‘say’ they are following agile practices – but really aren’t. While the size of the waterfall population continues to diminish, this is not to say we don’t still have a pretty good sized audience out there who are delivering their projects using a waterfall approach or who have minimally mature agile skills.

In fact, the 13^th annual State of Agile Report by Collabnet VersionOne informs us that 83% of organizations are still coming up to speed with agile.

With this being the case, I am still coming across many business analysts who question their ability to transition to agile, the best approach to get there, and where they best fit in, on an agile team once allocated to one.

In this article, I wish to address the latter.

So you hear that your organization is going to start running projects using an agile approach to delivery. If they choose to follow Scrum – you understand there are 3 main roles:

Product Owner
Scrum Master and
Development Team

But as a waterfall business analyst – where do you fit?

The good news is that the answer to this question is ‘anywhere you want to’!

Let’s quickly break down the objective of each role and then discuss why business analysts are well positioned to fulfill the responsibilities of any of these positions on an agile team.

Product Owner – the representative for the business or user community. The person who takes responsibility for setting the priorities of the requirements and choosing which features will be addressed in each iteration and release.

Scrum Mater – the facilitator for the team. The person who takes responsibility for ensuring the team adheres to the agile principles and practices they have agreed to uphold.

Development Team – everyone else. All members of the development team work collaboratively to deliver a product of value to the business/customer. Development team members self-organize and therefore ‘collectively’ take ownership for delivering the final solution.

You might be thinking ‘wonderful’ but I still didn’t see something like ‘the person responsible for eliciting and specifying the requirements’ …so where do I really fit?

Let’s tackle that question by looking at the skills a waterfall business analyst possesses and then tie those skills to the 3 Scrum roles. We’ll then close out and speak to how requirements elicitation and specification on agile projects are different…and why you didn’t see this spelled out specifically above.

The following word cloud was created using the skills as listed in A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) v3. There are close to 30 skills identified as being critical skills a business analyst should possess in order to effectively perform their role.

This means that if waterfall business analysts have been performing their current roles with a mature skillset – they possess some of the most important skills needed by agile teams!

Here is a ‘very’ preliminary mapping of business analysis skills to the Scrum roles. I indicate ‘preliminary’ because you could really make an argument for a lot of the skills listed above for each of these roles.

Product Owner

Business acumen
Conceptual thinking
Decision making
Industry knowledge
Listening
Organization knowledge
Problem solving
Visual thinking

Scrum Master

Conceptual thinking
Decision making
Facilitation
Leadership and influencing
Listening
Negotiation and conflict resolution
Non-verbal communication
Methodology knowledge
Problem solving
Trustworthiness

Development Team

Adaptability
Creative thinking
Facilitation
Learning
Personal accountability
Problem solving
Solution knowledge
Systems thinking
Teaching
Teamwork
Verbal/written communication

When discussing where the waterfall business analyst ‘best’ fits, it ends up being more of a discussion about which position is most appealing to a business analyst and which would they ‘prefer’ to do.

For example – an analyst wishing to move into a Product Owner role would be someone who has in-depth business domain knowledge, strong customer empathy, and understands how to make tradeoffs based on value and risk. For someone who can envision the holistic view and enjoys sharing their business insights to others, enjoys setting vision and scope – the product owner role might be your calling.

If an analyst has strong leadership skills, has a passion for addressing issues, finds motivation from helping others, understands agile principles and enjoys teaching others, then serving as Scrum Master might be your passion.

For waterfall business analysts who enjoy facilitating discussions to discover requirements, has strong writing and communication skills, and enjoys a more tactical role of defining requirements in the format and deliverables expected on agile projects – then lending business analysis skills to develop user stories and acceptance criteria and facilitating discussions around this work is your place.

My last point is to make sure waterfall business analysts understand that transitioning to agile requires more than just a robust set of skills. While several of the activities a business analyst performs on waterfall projects is similar to work that is performed on agile – there are some BIG differences. This is why you didn’t see me spell out requirements elicitation and specification – which are traditional names for activities business analysts perform on waterfall projects.

On agile, we see the differences between waterfall business analysis and agile business analysis appear in 3 main areas:

What we call the activities we perform e.g. we conduct a process called approve requirements in waterfall versus activities called backlog refinement and iteration planning in agile to determine the requirements the development team will work on.
The approach to our work e.g. we perform our tasks sequentially and prior to any development work on waterfall versus performing our tasks iteratively and incrementally in agile, and
The types of deliverables produced e.g. we produce business requirement documents and software requirement specifications on waterfall vs. user stories and acceptance criteria in agile.

If you are interested in knowing more about how business analysis is tailored for agile – check out The PMI Guide to Business Analysis referring specifically to the tailoring tables included within that standard.

Retooling and acquiring new skills for agile means you will require new knowledge and new experiences. Knowledge is acquired from ‘your’ hard work – reading and professionally developing. Once you feel you have acquired enough knowledge and understanding about agile – pair that up with your robust skillset and start looking for opportunities to start gaining on the job experience on an agile team.

The good news for waterfall business analysts is that there is a position for you on an agile team. You bring with you a strong set of core skills and fundamentals. Decide which position ‘best’ fits your passion, set your professional development goals, and attain the knowledge and experience you need. Good luck!