Agile Methods

A long, long time ago in a land far, far away…. a project delivery team was busily spending their days delivering projects. They were tasked with delivering change projects and often these included software delivery. This team consisted of people with a variety of skillsets, personalities and experiences. Some of them were project managers, some were analysis and some were developers. Others were software testers and others were business experts and non-project people.

Agile adoption is not ‘a walk in the park’! Agile is a framework of lightweight methodologies aimed at fostering flexibility and evolved as a proactive means to challenge the conventional mode of software development (SDM). The Agile methodology relies upon an iterative and incremental process to accomplish the project objective. Agile is a sharp contrast to the traditional sequential developmental methodology that lacks the ability to adapt to challenges through the lifecycle of projects.

Enterprise Agility means the ability to adapt easily to change. In the business perspective, agility refers to a distinct quality that allows institutions and corporations to respond rapidly to change. It is the ability and capability of a system to respond rapidly to a certain modification by adapting its inceptive and stable configuration.  Agility is also viewed in relation to the results of organizational intelligence. It is the aptness to react successfully to the emergence of new competitors, abrupt shifts in the overall market conditions, and adaptation of industry-changing technologies that are based on the degree of agility in the organization.

User stories are a simple, yet effective way to communicate how a user or customer employs a product. But writing user stories that help a team build great software can be challenging. The article shares five common user story mistakes and how to overcome them.

Agile Manifesto is a means to achieve the end objective through ‘best practices’ that crystallize into an approach that efficiently resolves the competitive stand-off. Thus the Manifesto is a subset of principles that provide a working framework to attain Agility. The following are high-impact Manifesto principles...

The role of design still puzzles many agile teams I work with. When should the design activities take place? Who should carry them out? How are design decisions best captured? This blog tries to answer the questions by discussing a user-centric, iterative, and collaborative design process for Scrum and Kanban teams.

An effective product roadmap is a must-have for any successful software development project. A roadmap helps the product manager define the trajectory of a product, communicate progress to stakeholders, visualize goals and justify changes to budget. Product roadmaps are where both strategy and tactics combine to help teams build better products.

So I came to a conclusion that I found interesting and want to share with the public: when doing this transition, the companies do not want to implement agile, they just want to run away from waterfall. And running away from waterfall can come in many shapes and forms, so the overall popular idea of comparing “waterfall” vs “agile” as two competing extremes is not conceptually correct.

This is the last article in this current  “Deep Dive Models in Agile” series and covers Decision Models, which include both Decision Trees and Decision Tables. Decision Models include two RML System models (Decision Trees and Decision Tables) that detail the system logic that either controls user functions or decides what actions a system will take in various circumstances.

The paradigm shift towards agile and lean product development has brought collaboration between large cross-functional team in the spotlight. The existing literature is already mature explaining clearly how benefits can be reaped fast by executing a clean transition to agile delivery by enhancing the performance of the new cross-functional teams. However, in parallel, the time spent in endless meetings by product owners, business analysts, engineers, product managers and many others involved in the product creation, has grown exponentially. This leaves key product people with little or no time to do the critical activities they are employed for.

Consider an agile project on the other hand. Agile projects do not require massive documentation in advance. Moreover, in agile projects, the business owner might communicate directly with the agile team (developers) and sometimes the agile teams are even co-located, which makes the communication between business owner and agile team easier.

So, there is no role of a Business Analyst in agile projects you say!

I always see people go gaga over agile development methodologies. While I agree that agile has its own advantages, I disagree on the fact agile is an all-powerful and does it all kind of methodology. However, if executed right, agile does have the capability to be an all-powerful methodology. Although the advantages outweigh the perils of agile, the perils if not properly addressed can put the business value and relevance of the solution at risk.

A Feature Tree is an RML Objectives model that shows the full scope of features for a project or product on a single page in a tree format. A feature is just a short form description of functionality provided by the project or product that brings value to the end user. The Feature Tree is great for bringing new people on a project up to speed and showing executives, business stakeholders, or customers all the features that are in scope for a project or release.

Process Flows are usually used for user facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic.  When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.

With the rise in popularity of agile methods, business analysts and product owners often use the term “agile requirements” to label their work.  We do not care for the term “agile requirements” because it implies that the requirements for an agile project are somehow qualitatively different from those for projects following other life cycles. A developer needs to know the same information to be able to correctly implement the right functionality regardless of the life cycle being used.