Agile Methods

Let us look at it from a different angle now and derive the requirements out of the customer journeys.  It is impossible to introduce a change... if the change is big and you try to implement it in one go.  This is the reason we tend to break any solution into smaller components. Each solution component should be small and independent enough to be changed individually in a controlled manner. So that eventually we will compose a new experience out of them. Pretty much like using a set of Lego blocks.

In recent years, agile software development has been the classic example of this pursuit of magic solutions, so I’ll use that as an example here. Over the years, though, people have leapt onto the bandwagons of numerous new software approaches. They all have merits, they all have limitations, and they all need to be applied to appropriate problems.

DevOps is based on a culture of trusted partners. This partnership is between software development, quality assurance, security and controls, and operations. The result is a smooth and fast transition of software from development to operations. However, like Dover, if the trusted partners are somehow reorganized into formal handoffs each with their own software acceptance procedures, the movement of software is no longer smooth nor fast.

In this article, I want to share my knowledge on how to manage product backlog using Jira. The article will be useful not only to business analysts or product owners but also to scrum masters, project managers. Basically, anyone who works with backlog and requirements on a project will benefit from reading it. There are certain rules and approaches that you have to follow to achieve good results.

Before we take a look at it I want to point out that this approach is not a market standard yet. However, over the last 3 years, I’ve completed a good number of projects using the approach I’ll be describing here

On the image below I tried to emphasize the main activities and processes that should be presented in your project. You also have to keep in mind that each artifact and process has own goal and definition.

For almost 10 years we have enjoyed reflecting on what’s happened the previous year and making predictions for the upcoming year in the realms of Business Analysis, Project Management, and Agile. Some of the recent trends we have discussed: The digital BA, Lean business cases, BAs and PMs in a Dev Ops environment, BAs and PMs in the gig economy, etc.  Here are five industry trends that we have chosen for 2019:...

As more organizations move toward agility, development and project management teams still struggling to define a common language and standard regarding the agile framework. In addition, many organizations that are implementing agile approaches have not fully planned the transition and are still unclear on how to fully optimize the approach. One area that continues to remain vague is the role of the business analyst (BA). Below are some steps to help business analysts navigate their way through the transition to agile and add the most value to their agile teams.

First of all, let’s get this out of the way. Gamestorming is not new. Gamestorming is a collection of ‘games’ put together under the banner of ‘gamestorming’. As a business analyst (BA) I can assure you there will be many games in the book and on the website, that you have used in your role under different guises. 

Dave Gray (co-author of ‘gamestorming’) put it best when he described himself and his fellow authors as the Grimms brothers. The Grimms brothers, if you are not familiar with them- they brought together different fairy tales and published them in a book.

The purpose of this article is to cite an example of using Lean-Agile project management for a small home construction project – a bathroom remodel. The remodeling firm unknowingly uses a Lean-Agile project approach that was the result of lessons learned over years of experience. In fact, when I questioned the remodeling firm about Lean-Agile, the firm’s response was “What is that?” Regardless of what you call it, the firm uses their construction approach because it works.

When speaking to a business analyst on a busy project, I am often told that ‘at the end of a working day, I feel like I have achieved nothing’. Even, though we may feel like that but when looking back on the day you will see that you have probably carried out invisible work. Invisible work is a concept that is frowned upon within the agile world but it is something that we are all guilty of doing. In this post, we look at what the key blockers, which can slow your workflow and why working in visually will help you overcome these blockers. By making your work visible you can reduce the amount of time you waste in a day and be able to do things that you like to do.

Naturally, us Business Analysts are facilitators, whether we're running workshops or holding stakeholder meetings, we're always the ones engaging with people. And it should really be no different for the running of a Design Sprint; use your best facilitating skills to lead the Design Sprint and make it a really good week for everyone involved! In addition to hosting over the five days, you should consider yourself responsible for reporting on the outcomes of the week to stakeholders, this will include making a decision on what to suggest taking forward as an idea and what should simply be forgotten about.

Efficient and smooth workflow practices are believed to be accomplished through Agile methodologies with an emphasis on flexibility and rigor to optimize utilization of resources. Two popular implementations of Agile are Scrum and Kanban. In would be fitting to compare and analyze these processes, in an attempt to understand the dynamics behind their respective methodologies.

In at the deep end So, you’ve just heard you’re going to be the Business Analyst on an Agile team that’s going in to a Discovery and it’s your first one.  For my first Discovery, it was daunting let me tell you. I already knew quite a few tools and techniques a BA should use during the lifecycle of a project, but wha...

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.