Minimum Viable Product in Agile

Coming up with an MVP is an art of brainstorming, identifying, splitting, including, excluding features which will result to deliver highest business value to the customer first. Sometimes more than one MVP combined as shippable release and it is known as Minimum Marketable Product (MMP).




 Setting the right expectation for MVP and MMP with stakeholders (especially with business) is very important and what can be expect from an MVP. Else business might expect each MVP will hit into market with all functionalities. Also you can experience a lot of love from business to keep all their features in a single MVP and not like to exclude features and its sub features is a common trend.
Each project/product priorities are unique, so identifying and defining MVP will vary from project to project or product to product.

So instead of following an MVP template, teams should more focus on collaboration and communication along with right set of stakeholders to come up with an MVP.


User Story Mapping is one of the popular way to derive MVP. In general, MVP should be a testable and have a left to right workflow or it can be a prototype too.
Product Backlog is the single source of input to the team for development. So MVP will be gradually turned into top prioritized PBI’s in your Product Backlog.

Product Owner is sole responsible person to come up with MVP with the help of other stakeholders.
A MVP can/cannot be shippable to the market and it will be decided by the Product Owner.

Scrum

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:


Lightweight
Simple to understand
Difficult to master


Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques

Ability to manage changing priorities' is one of the top 3 reasons for adopting Agile

How to Split User Stories   

Scrum vs Kanban

Scrum & Kanban are Lean and Agile. Kanban is not an Agile Method!

With agile methods such as Scrum,customer or the product is on focus and the product is created in a team-oriented manner in iterative incremental cycles. And the switch to Scrum is a disruptive change for many companies in the classical world (from projects to products, no project managers, separation of business and personal responsibility).

At Kanban the optimization of the process is at the forefront. Not the customer. Not a team. And Kanban is an evolutionary approach for continuous improvement.This is why the book by David Anderson, the inventor of (IT-) Kanban, is called "Successful Evolutionary Change for Your Technology Business".

Any comparison between Scrum and Kanban is utterly pointless. It is like comparing a hammer with a screw driver.


Top 5 Agile Adoption challenges

Company philosophy odds with core agile values
Lack of expereince with agile methods
Lack of management support
General organization restiance to Change

If you want to know more about Scrum . Refer this link


Scrum Masters Check List can be downlaoded from here

ESB

The central concept is that the ESB provides the middleware and interfaces that allow businesses to connect their applications without writing code.

This could include mediation to reconcile incompatible protocols, data, and interaction .

An ESB is a any technology that you can insert into an SOA (Service-Oriented Architecture), allowing you to connect disparate systems together.

An ESB is basically a MOM (message oriented middleware) with an added data model and structure definition management. You have a common data definition for all applications and adapters on that bus (could be XML with a shared XSD). An Enterprise Service Bus (ESB) is fundamentally an architecture. It is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure.•

The "bus" concept decouples applications from each other. This is usually acheived using a messaging server like JMS or AMQP.

• The data that travels on the bus is a canonical format and is almost always XML.
• There is an "adapter" between the application and the bus that marshals data between the two parties.

ESB are similar to other untyped/typed choices:

•REST vs. SOAP
•unvalidated XML vs. XML validated with an XSD
•Groovy vs. Java
•interpreted language vs. compiled language

An ESB is used for service virtualization, typically manage a much larger set of services, and is positioned inside the Intranet.A general rule of thumb to note is that when services are exposed to the outside world, an API gateway is a tool to be considered. It is positioned outside of the Intranet

Oracle ADF - Part1

ADF framework knowledge

Everybody on the team will need basic knowledge of the ADF framework. This includes project managers, testers, graphics designers, and usability experts too. Having a common understanding of what the framework can and cannot do will make communication within the team much easier.

The programmers will, of course, need a deeper understanding of the framework, but not everybody has to be an expert. An experienced programmer should just need a basic one-week training class and a couple of weeks work under experienced supervision in order to be productive with ADF.

Finally, you need at least one person with a deep understanding of how ADF works. This person will define project standards and provide guidelines for how to use ADF effectively. The same functionality can be implemented in many ways in ADF. It is the task of the ADF expert to ensure that you use the framework as much as possible and do not code things that ADF can handle declaratively.

XML

The ADF framework is meta-data driven. This means that most of the application is not actually programmed in a programming language like Java, but is instead defined through JDeveloper. These definitions are stored in the form of XML files. You will notice that, for example, business components have a Source tab, allowing you to see the raw XML file.
You do not have to write XML files to use ADF, but it will be an advantage to know a little bit about XML so you can read the files JDeveloper builds.

The ADF framework is meta-data driven. This means that most of the application is not actually programmed in a programming language like Java, but is instead defined through JDeveloper. These definitions are stored in the form of XML files. You will notice that, for example, business components have a Source tab, allowing you to see the raw XML file.
You do not have to write XML files to use ADF, but it will be an advantage to know a little bit about XML so you can read the files JDeveloper builds.

Web technologies

When your ADF application is running. the end user is interacting with a web page in a browser. This means that your application must use the web technologies the browser understands: HTML. Cascading Style Sheets (CSS), and JavaScript. The ADF framework takes care of most of the details for you. but it is good to have someone on your team that understands these technologies. That person can both help you understand any limitations you might encounter and how to work around them.


Regular expressions

JDeveloper allows you to use regular expressions to define validation rules. Regular expressions are arcane. almost magical constructs that can express complex requirements in very compact form. For example, the following regular expression can be used to validate an e-mail address:
[A-Z0-9. -]+@[A-Z0-9.-]+\.[A-Z](2,4}