Agile Methods

Customers are demanding better service and they know they can get it and BAs have a duty to provide it through Lean Business Analysis (LBA). Not because customers see better service from a business’s competitors. But because they get it from all the other companies they interact with in their daily lives as consumers of Uber and Apple and Amazon and Netlfix and many more. They don’t care that one company is a bank and Uber’s an app.

How can a business analyst mindset transform the practice surrounding good retrospectives, create an engaging meeting, and promote active change across their team? There’s no tried and true formula to a Retrospective, but I have found the ones that are the most successful rely on the characteristics and practices of good BAs. Thus, conducting Retrospectives that are data driven, clear, honest, creative, and experimental. Why? 

One of the key aspects to be considered before implementation of Agile methodologies is the degree of agility suitable for the organization. Due consideration should be given to the ‘current state’ before we create a proposal for the ‘future state’ of agility desired. Neglecting this aspect may invalidate the very purpose behind the endeavor.  Degree of agility refers to the relative ability of an organization to adapt to the lightweight methodologies in conjunction with an assessment of current state process maturity.

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.