Tag: Software

Don’t Force Typical Templates on Packaged Software Projects

Written by Angela Wick on July 14, 2014. Posted in Articles. 1 Comment on Don’t Force Typical Templates on Packaged Software Projects

One of the most interesting trends I’ve seen in my business analysis career is the shift from custom software development to package software implementation.

Traditionally, large corporations created in-house teams that supported business functions by developing software from scratch. Gradually, package software made its way onto desktops via word processors and spreadsheets. Then, package software began to take over organizational support functions like human resources, payroll, accounting, and niche functionality. Now, highly configurable cloud packages provide or supplement even core business functions in most companies; ranging from small functional packages to large enterprise software.

The context and scope of package software projects vary widely. Common package software projects include one or more of the following:

Upgrade: technical and/or functional
New implementation: out of the box, configuration, and/or customizing
Integration with other systems (in-house or vendor supported).

As packaged, third-party solutions become more common, BAs need to modify their traditional approach to meet the unique needs of package software projects.

I first started outlining these differences in my team practices and on my projects back in the late 90s. Since that time, I’ve seen a huge jump in the complexity of these implementations. While requirements analysis and implementation analysis for package software have not changed much, the risk of getting it wrong has increased dramatically.

The mindset that needs to change, not the techniques

The BA role remains the same for traditional projects and package software projects: protect and optimize stakeholder and organizational value. Many of the same techniques can be used, but the BA mindset and how it’s all documented and facilitated may change.

Worry about fit, gaps and change management

When working on package software projects, a fit/gap analysis mindset is crucial along with a keen focus on how the users world is changing and empathy for these changes.
BAs need to look at how the package “fits” the desired outcomes and processes, and identify gaps between the package functions and the current state functions. BAs should work with stakeholders to determine if gaps need to be “bridged”—can we operate within the package functions or do we need to adapt the process or technology to meet our needs?

Documenting this fit/gap decision process is a key BA role, including facilitating options and alternatives to minimize the gaps. Even when implementing “out of box,” this process and analysis is critical to success. “Out of the box” typically means process or operational changes somewhere, BAs are in the role to identify where the changes will happen and prepare the users for these changes.

Don’t force the templates

Once BAs enter the fit/gap mindset, then they need to determine how to effectively document the package software project.

I often see BA teams struggle as they hold on tightly to their templates, trying to make them work for package software projects. Many typical templates don’t serve package software projects well. Typical templates assume a custom development approach, and forcing BAs to use these templates creates a lot of pain and challenges for package software projects.

So PLEASE, challenge traditional practices and templates when participating in package software projects. You still need requirements, but timing, and level of detail/abstraction must be appropriate.

Careful not to waste time on detailed documentation of your organization’s current state. The vendor usually has current state documentation for the package and this will become the future state in most cases. Focus on the future state and what must happen going forward, only looking back to the detailed current state when we need to identify details to carry forward. Also, it’s likely project sponsors purchased the package to gain efficiencies and change processes and business operation—they don’t want an exact replica of current state.

Instead, manage your work at a function level. Before selecting the package, what an actor wants to accomplish and rules are important. After selecting the package, the future state and “how” the actor accomplishes it becomes important as a change management piece for piloting, testing, training, and implementation.

We don’t want to document functionality already built. Exactly how it’s done in the package can be redundant to document when the vendor typically has this documented. So, avoid documenting requirements for package software that duplicates functional specs and design of software already built.

Don’t rely on the vendors BA 100% for the BA role

You need an internal BA (or BA team) to support a package software project. If you rely solely on the vendor BA, you will not successfully identify and bridge functionality gaps. The vendor BA understands the product, but does not fully understand your environment—your systems, processes, culture, politics, pain points, exception processing, integration issues, etc.

Both BAs—vendor and internal—are critical to success. The internal BA does not fully understand the product and needs the vendor BA to validate functionality and fill gaps.

Whether it’s two people or two hundred, the internal and vendor teams need to come together like puzzle to teach each other, build trust, and work through issues.

Upgrades need BAs

It’s quite common to hear teams say that package software upgrades don’t need BAs or requirements.

Challenge this assumption! Upgrades almost always have user impact or at least a risk of user impact. If users use the system, there are requirements!

Whether the change is minor or technical, a knowledgeable BA should be consulted. Even if the upgrade has been successful at several other sites, there is still a chance that your organization’s unique configuration or system integration could be negatively affected by the upgrade.

So ask requirement-resistant team members a few questions like: Why are we spending money on the upgrade? How do the users benefit? What would happen if it’s not done? Help them understand potential impacts and how BAs bring value to all projects.

A note about configuration

Most modern package software is highly configurable with hundreds of settings that impact software functionality.

If your project team has not worked with highly configurable software before, be prepared for a new layer of complexity throughout the project lifecycle.

BAs may need to consider configuration settings when writing business rules or detailed requirements.
Projects may require a separate phase of “configuration testing” and piloting the package.
BAs may need to educate testers about configuration settings and help them trouble shoot issues/bugs to determine if the errors are configuration errors or system bugs.

BAs will be supporting even more package software implementations in the future. If you haven’t experienced a package software project yet, you will soon—be ready.

Don’t forget to leave your comments below.

Doodle images above provided by Dan Wagner. Learn more about Dan’s doodle art by emailing him at [email protected]

Gaudi and Steve Jobs Way of User Interface Design

Written by Emrah Yayici on October 22, 2013. Posted in Articles. 1 Comment on Gaudi and Steve Jobs Way of User Interface Design

In many companies, one of the challenges for business analysts is: “Designing Best User Interfaces”.

To achieve this objective business analysts should first shift their focus from designing the best “user interfaces” to designing the best “UX (user experience)”.

In case design thinking is limited to best “user interfaces”, the focus is only given to visual aspects and functionality. But the best “user experience” can only be achieved if usability is also positioned as a must have throughout the design process in addition to functional and aesthetic concerns.

To ensure usability of the interfaces companies have started to establish dedicated UX teams. These teams work on the low-fidelity prototypes created by business analysts and improve their usability by applying UX design principles. They also conduct usability tests with real users to find and fix the usability problems on the prototypes. Afterward they send the prototypes to visual designers who create the most aesthetic visual designs.

However in majority of the companies the role of UX teams is still totally played by business analysts. This may be due to budget constraints and unawareness on the importance of usability. At the companies that don’t have UX teams, business analysts have to spend more time and effort to improve their knowledge on usability and UX design principles.

The most important of these principles is “User Centricity”.

User interfaces are considered usable if they are easy to use and good fit for the people who use them. This requires a User Centered approach in the design process.

Throughout the construction history, Gaudi has been one of the most famous architects with his user centered architecture design approach. His story starts with a childhood suffering from poor health. This situation prevented him from going to school, and he spent most of his time in nature. His observations of nature inspired his design approach, which can be summarized as follows: “The great book always open and which we should make an effort to read, is that of Nature.” With this philosophy he designed buildings with “organic style,” which then became an important standard in architecture.

Another man revolutionized the high-tech industry in a similar way. By positioning users at the center of the analysis and design process, Steve Jobs led the innovation of the most usable consumer electronics products ever. He achieved to create natural-born users of his products. Even kids can use his company’s phones and touchpads with gestures similar to their natural behavior. This new design approach made his company the best performer in the high-tech industry.

In user interface design, the most practical way of adapting Gaudi and Steve Jobs way of user centricity is applying user profiling technique during requirements elicitation stage of the project. User profiling is grouping users according to their mental models and level of computer use based on their personal characteristics such as age, gender, education, income level and business background. Business analysts should define user profiles in addition to user requirements during requirements gathering sessions, define personas (imaginary characters) for each profile and should consider the characteristics of personas during user interface design.

This user-centered analysis and design approach ensures both functionality and usability and helps to provide the best experience on user interfaces.

Don’t forget to leave your comments below.

Four Cost Effective Ways to Perform Early Life Cycle Validations in a Software Testing Project

Written by Mugdha Divekar on October 22, 2013. Posted in Articles.

Early life cycle validation is not a new concept in software testing space. It focuses on practices of testing team validating the key outcomes of upstream life cycle phases of software development and testing. But still many testing projects have failed to implement these practices in an effective way. It is primarily due to inconsistent and incorrect manner in which the implementation of these practices has been done. This point of view is based on author’s experiences and describes four most effective ways of implementing early life cycle validation practices in a testing project. This helps the project to achieve better productivity and application quality. It also aims at overall cost reduction of the project as the defects are caught and fixed during very early stages of a project.

Why “Early Lifecycle Validation” in software testing?

Gone are the days when software quality used to be inspected only towards the last phase of its life cycle i.e. say during system testing OR performance testing. Early Lifecycle Validation (ELV) is Or Shift left (as often termed as) a norm which is getting popular in all kinds of software testing projects. In this approach, the focus is on thorough validation of the deliverables of upstream life cycle processes by the testing team. The key benefits of ELV include

Effort and cost to fix the defects is less as cost of fixing a defect rises exponentially with each Life Cycle stage
Ensures best in class quality of the system as it ensures good input quality for every stage of the project
Software Development Life Cycle (SDLC )
Detecting defects early in the lifecycle saves in overall cycle time for the project and thus ensure better time to market

Key success criteria

The key success criteria for implementing early life cycle validation approach is –

Collaborative approach – To perform ELV activities, it demands for a collaborative approach of having various relevant teams involved in it like – client stakeholders, business users, development team, architecture team, functional testing team, performance and other special testing teams, help documentation team etc. Every team needs to have a single vision of best in class application quality in optimal cycle time. They should be open to accept suggestions and issues to their work product which are pointed out by some other team members.
Availability of appropriate skill sets to perform these activities – Key people who are going to perform these activities need to possess following skill sets
- Excellent domain and application knowledge
- Very good understanding on the IT technologies that are getting used in the project
Customer willingness to invest on ELV activities – ELV does not recommend any cuts in any existing appraisal activities of SDLC like design reviews, code reviews etc. These are some additional activities that are suggested on and above the basic appraisal activities. Hence it is important to have client willingness to spend extra money on the effort and time needed to perform these activities. The expected ROI on these investments is huge as compared to the investment made to perform these activities.

In absence of any one of the points below, the overall approach for ELV will not be effective.

Various approaches of ELV

There are multiple approaches to perform ELV. But in my opinion, following are the top 4 approaches to implement ELV in the testing projects.

1. Requirements Review (RR)

The testing team can get started on this approach as soon as Business Requirements Document (BRD) and System Requirements Specification (SRS) are base lined by concerned stakeholders from client team/development teams. So before starting on subsequent SDLC phase i.e. design phases there should be a phase to perform thorough review of business and system requirements by testing team. Within QA team, there should be profiles available that can play effective role of “User Proxy” who can wear client’s hat to understand the essentials and details of the system from user’s perspective and hence can think of from user’s perspective. This user proxy should also have very good knowledge about the application under consideration. S/he should also possess skills on domain and overall industry trends. For instance if the system under consideration is for some legal compliance perspective, then the user proxy should be aware details around

Complete knowledge on legal aspects for which the compliance system is made
Industry trends like what other companies/competitors are doing to comply to the same

The user proxy can pick up some more members from the team and perform these activities in a group review mode. Both the requirement documents (BRD and SRS) are thoroughly reviewed from key 3 perspectives i.e. functional verification, structural verification and conformance verification.

Functional Verification – Team ensures that the business requirements give an accurate and complete representation of the business goals and user needs. The same are rightly translated in the form of system requirements. For ex – The team can come up with observations like ones mentioned below

Comment	Implication/Objective
BRD – “All past salary slip should be made available to employees”. SRS – “Last 5 years pay slips should be made available to employees” Clarify.	Need to resolve this right away rather than getting this caught in testing OR production phases
SRS – Mention of financial requirement X is deviating from SOX compliance. Why?	Need to discuss and close this now otherwise may lead to penalty if this would have realized during production

Structural Verification – ELV Team checks the requirements from structural perspective i.e. they check for ambiguities of expression, seek clarification, restate it in structured natural language (say English) and apply “Cause Effect Graphing” or “Decision Table” techniques for better and clear representation. They also consider some natural language related checklist and tools like ambiguity checker to verify the requirements against the pitfalls of natural language.

For ex -The team can come up with observations like

Comment	Implication/Objective
SRS – “If it is transaction x then update relevant corresponding data like EPF, the salary structure etc.”	What is meaning of this “etc.”? Are any more records needed to be updated? We cannot leave this to interpretation of an individual.
SRS – “Accounts are reviewed for discrepancies at the appropriate time”	Need to explicitly and clearly mention of what the appropriate time is.

Conformance Verification – ELVTeam will ensure conformance to requirements management processes in terms of Requirement Traceability Matrix (RTM), requirement prioritization, requirement change procedure, process adherence etc. So the team can come up with observations like

Comment	Implication/Objective
Check RTM and review the traceability from BRS to SRS. For ex. BRS talk about 5 policies but SRS mentioned about only 4 policies.	Need to clarify and sort out the exact number of policies to be implemented
Check if there is any process defined for Requirement Change Requests (RCR).	Primarily to check if is it adequate? Does QA team get any role to play in the RCR management process? When will QA team come to know for any RCR?

All these observations should be discussed with relevant teams and stakeholders. Also we need to ensure that both business and system requirements documents are updated as per the observations.

Thus this step ensures that the requirements are clear, unambiguous and complete.

2. Design Quality Assurance (DQA) – applicable for both high level and low level design

If the thorough “Requirements Review” phase is carried out then it is assured that the design & architecture team is getting clear requirements on which they need to create design i.e. system architecture (high level design OR HLD) and low level designs (LLD). Once the high level design OR architecture phase is over then the ELV team again comes together to perform design quality assurance i.e. DQA activities. Here it is expected that the ELV team possesses good working knowledge of technology, databases, reporting tools etc. The team can take following approach for DQA

Based on business/system requirements, come up with the list of top requirements and priorities for which we need to verify the system architecture
The architecture team explains the overall architecture of the system to the ELV team
ELV team audits the design to verify that the architecture will provide the intended business requirements of the system.
Some sample design audit questions /observations can be

Comment	Implication/Objective
In the interfacing applications, MyApp should pull in data from 7 databases and 5 systems? But architecture diagram shows only 7 databases and 4 systems.	Check for that and ensure that provision for data pull from all the relevant interfaces.
In the architecture diagram, there is no component shown for “Reporting”. But there is a separate tab for reporting in the SRS.	Is this a genuine miss OR represented the same in a different way?

All such observations should be discussed with relevant teams and stakeholders and ensured the high level design and architecture documents are updated as per the observations.
Thus this step ensures that the high level design and architecture caters to the technical needs of the business and system requirements.

Similar approach can be taken once the detailed design phase is over. In this case the ELV team can plan to do audit of low level design on sample basis. So they will request architecture team to walk them through the detail design of some critical functionality. Some sample audit questions can be

Comment	Implication/Objective
Security aspect – For banking information – Are you taking extra login to retrieve this information for user?	To check security implementation
Trigger based activities – For ex – Email on trading window closure on respective dates–– How are they implemented? From where dates are getting picked up?	To validate trigger based approach

All such observations should be discussed with relevant teams and stakeholders and ensured that the corresponding design documents are updated as per the observations.

Thus this step ensures that the low level design and architecture caters to the technical needs of the business and system requirements.

3. Code Quality Assurance (CQA)

If the “Design Quality Assurance” phase is carried out, it is assured that build team is getting clear design on which code needs to be created. Once the build phase is over then the ELV team again gathers to perform code quality assurance i.e. CQA activities. Here it is expected that the ELV team possesses working knowledge of technology, databases, reporting tools etc. The team can take following approach for CQA

Based on business requirements, come up with the list of top requirements and priorities for which we need to verify the implementation in code
The development team walks ELV team through the key code implementations for the critical functionality and features that the ELV team wants to audit.
ELV team audits the code to verify that it will provide the intended business requirements of the system.
ELV team can also use some Product Quality Analyzer tools which can analyze the code in the statistical way to check the structural quality of the code. Such tools can create detailed report on the health of code from various aspects like maintainability, performance best practices, security related best practices, if the code is written in optimized way etc.
Some sample audit questions for CQA can be

Comment	Implication/Objective
If requirement traceability matrix is complete till coding phase for all BRS requirements	To check the traceability
Coding standards for the underlying language are followed or not? Some evidence? Some filled in checklists?	Assures consistency and best practices of coding are there in the artifacts
Explain the critical algorithm and logic of income tax calculation.	Try to understand basic logic of a key feature

All such observations should be discussed with relevant teams and stakeholders and ensured that the observations are implemented back in the code.
Thus this step ensures that the build phase considers all important aspects of business needs for the system.

4. Group Review of testing scope, requirements and strategies

In the above 3 processes, we saw that QA team reviews the deliverables from upstream processes of SDLC i.e. requirements, design and coding. In this practice, the upstream phase outcomes of STLC are validated by other concerned stakeholders. This is a very simple but powerful step that we can take to ensure that the testing scope, test requirements and test strategies outlined for the system are adequate and in alignment with the desired outcome from the system. We can use the group review approach for the same. All stakeholders from relevant subgroups can perform this activity. QA lead can coordinate this activity. All the relevant docs which capture the test scope, test requirements, test strategies and approach should be reviewed to check

If the testing is going to be adequate
Any obvious issues that these groups can see in the testing approach
Choice of test strategies
Correct understanding of test scope and test requirements

Sample audit questions for such group review can be

Comment	Implication/Objective
The chosen tool by QA for test automation is “X” and technique for automation is “data driven”. But the tool should be “y” and technique chosen should be “keyword driven”	This is input from one of the group review members based on her experience in similar other project wherein they faced issues in tool X and “data driven” methodology. If this Fagan inspection has not happened, this team would also have faced similar issues with their choice

With this review, the possible issues and hindrance will come out and QA team will have a chance to correct these things in the very beginning of the STLC phase rather than these issues traversing through various STLC phases and discovering at a very late point in time. Also involvement of every individual subgroup ensures that there is enough and correct testing approach for each part of the system.

Conclusion

As we have seen that software quality can be dramatically improved by adopting these simple but powerful techniques mentioned above and as summarized in the diagram below.

We can catch these defects at much earlier stage of SDLC OT STLC rather than catching them towards fag end of the process. We have also seen the sample ROI of performing these activities. There has to be a collaborative approach adopted by all the concerned stakeholders to make it effective. We have seen its benefits in project that implemented them in our organization. These benefits from the select case studies are as below

Improved test case preparation and execution productivity in the range of 19-34%
Defects detected using ELV techniques – ranging from 600-750 defects (which otherwise would have got detected only at the time of QA)
Cost of quality saving in the range of 300 K USD to 3. 4 M USD
About 99-99.8% of testing effectiveness ensuring extremely high quality of product/application when it reaches UAT/Production stag

Effort and cost incurred to conduct these activities is exceptionally low and was in the range of 10-40 K USD thus fetching us very high returns on the investment

Hence these methods are observed as most cost effective methods of early life cycle validation in case of testing assignments.

Don’t forget to leave your comments below.

References

Infosys validation methodology

How to Use High-Level Requirements to Select the Right Supplier for your Project

Written by Joy Beatty on September 10, 2013. Posted in Articles. 1 Comment on How to Use High-Level Requirements to Select the Right Supplier for your Project

If you know ahead of time that your organization will be purchasing rather than building software, how can you use high-level requirements to ensure good outcomes? And how does the requirements process for purchased software differ from that of a standard development project?

The key difference in a supplier selection process: you are buying functionality that already exists. While you will likely customize and configure the software, that customization is not necessarily going to yield exactly the same end result as if you developed the software internally.

Given that difference, it makes sense to gather high-level requirements to short-list vendors, and select the winning supplier using that level of detail. You can then work with the supplier to specify the detailed requirements necessary to configure and implement the supplier solution, integrate it to existing systems and custom build any missing functionality.

Inherently, you will be forced to really focus on the core requirements and leave design out of the picture while you choose the supplier. Once you have selected a supplier, you will find it very challenging to speak about requirements without talking about the design of the solution you selected.

As you compare supplier software, you will probably have to make some tough decisions. For example, let’s say you have four features. One supplier may support features one through three. Another supplier supports features two through four. A decision maker on the project has to weigh all of the factors to make a choice, including (but not limited to) factors like: cost to buy and implement each solution, price to build the missing feature in each case, cost of not having one of the features, and time to implement.

Without scoping high-level requirements, you could be well into evaluation when end users or others decide that feature four wasn’t really a requirement after all!

Step-by-Step Approach to Selecting a Supplier

We use the following process to select our suppliers and minimize throwaway work:

Define the high-level requirements. This may take the form of named use cases or features.
Define the actors that will use the functionality.
Specify more detailed requirements based on the highest risk areas.
Research the marketplace to identify a list of potential suppliers. This can be done by surveying SMEs, doing web research or and/or speaking with peers, colleagues, and trusted advisors.
Narrow the list of suppliers down to the top three to five, based on how closely they match the requirements gathered.
Have the suppliers do high-level demos of the solution. Eliminate any that do not seem to be a fit at this point.
Create test cases using the requirements gathered to sufficiently demonstrate how each supplier measures against the requirements.
Have the suplliers demonstrate how their solution satisfies the detailed requirements, measured by execution of the test cases.
Create a comparison matrix with each test case (and all other measurement criteria you care about) to directly compare the suppliers.
Gather information from the supplier beyond just the functional capabilities.
1. Gather pricing data – licenses, support, installation, training, etc.
2. Ensure the supplier’s business operations are acceptable
3. Determine if their support structure is acceptable
4. Understand what their development roadmap looks like
5. Perform reference checks with colleague
Decision maker chooses a supplier.

Once a supplier is selected, the detailed requirements gathering process should continue. Your detailed requirements should be focused on the scope dictated by the supplier you selected. In standard development projects you would expect to go into more detail on most areas of the system, to ensure you understood the requirements to build a complete solution. In supplier selection projects, however, there will likely be pieces of functionality they demonstrate to you, and, based on high-level requirements and risk, you realize their solution is sufficient and do not need to explore it further.

If there is an area in which there is a lot of flexibility in the supplier solution, you should specify that in more detail. Obviously if there is a gap between critical requirements and the solution the supplier provides, you should go into greater depth on those requirements. Points of integration should be explored in detail. It is worth noting that you will typically spend more time updating existing processes to work with the supplier solution, whereas in standard software development you may build software that fits into existing processes.

Don’t forget to leave your comments below.

The Five Most Important Technology Shifts in Business Analyst Tools

Written by Derwyn Harris on August 27, 2013. Posted in Articles. 1 Comment on The Five Most Important Technology Shifts in Business Analyst Tools

Over the past 15 years, major shifts in technology have made the work of the Business Analyst more efficient and have increased product-delivery success.

#1 Software Engineering

Building software differs significantly from building something like a car or a house—hence the rise of “software engineering.” In concert, process and methodology took on importance and gave rise to debates, refinement and adaptation, including books and articles such as “Mythical Man Month” and “No Silver Bullet“. Because BAs building software faced more choices in what they could do, the idea of “engineering” helped instill some process into less predictable environments and placed more emphasis on how we work as teams, how we plan and how we manage change.

#2 DOORS

As processes continued to evolve so did tools and technologies, particularly software. Word processing capabilities and legacy tools such as DOORS enabled teams to capture the planning and process involved in software engineering. The introduction of DOORS ushered in the current boom of requirements-management solutions available today. For the most part, the initial swath of RM tools helped BAs focus on supporting existing processes to improve, rather than innovate around, product delivery.

#3 Rational Unified Process

This was a major shift. With Rational—and the RUP methodology—the process and the tools were built in parallel and interdependent. Thus Rational is referred to as a “software process product”.

The ultimate goal of RUP was to mitigate and control change. The predominant thought was that poor design and unclear requirements resulted in costly change. Change was treated as a problem that needed to be mitigated through a clearly defined series of phases that included a combination of textual but also visual representation of what’s being built.

As we’ll see, it’s this attitude around change that really shifted the mindset.

#4 Agile

When the Agile Manifesto was announced to the world in 2001, BAs considered Agile revolutionary after so many years of process, structure and rigid planning. As Agile-specific tools were introduced in great numbers, we returned to an era of process-driven technology, only this time the drivers were the engineering teams and the BAs found themselves struggling to fit in.

There’s no doubt Agile will stick around, but it is experiencing a backlash of sorts, specifically by those outside the core software-development teams. Many BAs must juggle ramifications rifts between product (and the business stakeholders) and engineering over misalignment around structuring requirements. This lack of communication and visibility is somewhat ironic, given its initial goal was to increase communication.

Agile continues to be top of mind and hotly debated. Many BAs adopt hybrid approaches to better align teams and seek ways to bridge the gaps across the organization.

#5 Social & Mobile

Social marries technology with the way people naturally engage to bring people together to communicate, plan and make decisions. Facebook, which ushered social into the mainstream, states as its mission to:

“…give people the power to share and make the world more open and connected.”

A broad, bold statement, yes, but it summarizes how our world has changed with technology. It was unimaginable back in 2001 that we’d be so quick to share details of our lives in 256 characters or less with people we didn’t necessarily know. Yet, as we’ve realized the benefits we are readily adopting social constructs. The idea of an @ mention or a # suddenly isn’t something only the kids do. It is part of our lives, our culture and increasingly part of our work.

Mobile devices have freed us from needing to be in a physical location. They also free us to live and work more in the moment. Embarking on a trip requires little more a confirmation email. Meeting friends at a sports event requires much less detail than it used to: via text, voice call or an app, we work out the details once we all are on our way or have arrived.

In the case of mobile, technology is driving the process. Communication has been completely reinvented. This is a huge shift for BAs and can have enormous benefits to product delivery. The intersection of social and mobile with Agile could be the driver for Agile to take root across larger, distributed teams.

Technology and Process in the Balance

Throughout the shifts over the past few years, the business analyst has been introduced to new tools and processes designed to make product delivery more efficient and successful. Social is doing this by applying best practices from 10+ years of agile implementations and layering on the technology to accelerate how we work.

Don’t forget to leave your comments below.