SAFe: Epic Owner

Posted on by

Epic Owner
Epics are what drive the most economic value in the SAFe and agile enterprise. They are containers for important initiatives designed to help in directing value streams to the larger aim in the portfolio. This is essentially what makes drives great economic value towards the enterprise. Epics are characterized as investment intensive and offer far-ranging impact.
In simple terms, Epic is like a work that cannot be completed within just a week or shorter time. In essence, Epics take a full sprint, so it says in order to be completed. In order to complete one Epic, it takes about 5 to 10 user stories. In Epic, the cost analysis, formulation, opportunity and impact are very serious matter.
Epics have wide range scope which is why implementing them is never an easy task to do. As such, Epics are broken down to smaller chunks, called stories. On that note, it is important that the role of the Epic Owner is addressed and discussed. The Epic Owners have the responsibility of managing and controlling a portfolio epic, developing business case and working directly with key stakeholders.
The Critical Role of Epic Owners in SAFe and Agile Methodology
Epic Owners are responsible for driving individual Epics. They are what drive Epics from identification going through analysis process as well as the Kanban systems. Going through these, it goes through the go/no-go decision-making process in the Program Portfolio Management. Once the Epics are accepted for implementation, Epic Owners work together with the Release Train development and Product Management team in order to commence the activities needed in achieving the epic’s business objectives.
But the role of Epic Owners does not stop there. When the Epic is successfully initiated, they still ongoing responsibilities of stewarding and following on the Epic. The Epic Owner can return to other responsibilities or take up other epics when the current epic is successfully incorporated to the Program Backlogs. Only during this time that implementation can be securely assumed as it is the time when the program has full responsibility for the delivery of solutions.
In SAFe, the role of Epic Owner can be taken by a project manager, product manager, system architect, enterprise architect, program manager, product manager or any other stakeholder that is well-suited to this important responsibility. As it is a role and not a job title, SAFe allows for different individuals to assume the role as long as it falls in their area of expertise. Epic Owners generally work on one or two Epics according to their business mission.
The Collaborative Work of the Epic Owner
The responsibilities of Epic Owner are varied and wide in scope. They work with different stakeholders in defining the epic and the potential benefits. They also establish the delay cost as well as identify potential business sponsors and many other tasks until the presentation and implementation of the Epic.
The very role of Epic Owner is collaborative in nature as they work with different people and teams in the agile enterprise to realize the benefits of the epic. In short, they are those that fill in the gaps within the organizations in order to ensure that the vision is realized and that the epic-driven features are consistent and achievable.

–Slimane Zouggari

What’s jira?

Posted on by

JIRA is a software tool for project management, which allows tracking of incidents. Originally born to manage incidents, but in recent years it has evolved, but the original heritage as manager note incidents throughout the tool. In any case, it is today, project management, the most popular; very style to others like Red mine, but involve payment.
JIRA Agile has a complement to JIRA for Agile project management, providing boards Scrum or Kanban boards for monitoring tasks in this series of post i ‘ll focus on Scrum with JIRA.
However, it is fashionable JIRA, JIRA Agile is fashionable, agility is fashionable, Scrum is fashionable … but the application of the agile management using JIRA creates many teams still many more questions than solutions.
In this article, I will focus on the basic characteristics of the Product Backlog and terminology of JIRA (complicated sometimes if you come from the agile world), JIRA Agile Agile terminology
Let’s start with terminology. The terminology is often messy in JIRA when previously you come from world of agile or have read some Scrum. First, I will show a list containing the relationship between the terminology of JIRA Agile and Scrum can be more problematic Backlog, period, as used in JIRA Agile, refer to Product Backlog.
An incident can be of many types. What more we’ll use in this context is the incidence of type “story” that are “user stories “. Eye that this is confusing at first, since by “incidence” often comes to mind error in production and this incident will also be “user story “.
Here is one of the most difficult terminology troubles: Tasks.
Sprint Backlog tasks in JIRA Agile
Scrum terminology tasks compose a Spring Backlog (are how to do what you ask us business, usually through user stories), usually derived from user stories.

In JIRA there are two ways to do this:
a) Incidents ( of course ) task type, the only problem is that these would be the same level as the incidence of type user story (in fact, when you create an incident can choose from a dropdown that is history, task, etc. ) remain in the Product Backlog and also could not link from which user story are these type incidents task. Therefore, it is usual for the task type incidents remain in the Product Backlog to stories style techniques.
b) Use subtasks, namely technical tasks, stemming from an incident, usually classified as history (user).
In short, once created the story incidence type enters it and subtasks are created. These subtasks not now appear in the Product Backlog (as happened in the case a) and will only be in the Sprint Scrum boards is performed where user story that corresponds to them, boards would become the sprint backlog.
The Product Backlog in Jira Agile
Starting with the basics, as described in the book ” agile project management ” and many other sites, Scrum Product Backlog is an ordered list and prioritized with all that is necessary to add to the product that has value, thus showing a unique insight throughout the project.
This is the origin of the requirements and needs to develop and modify the product, including errors that will be corrected in future releases. The product backlog stored items, ie, user stories or other needs.
The Product Backlog is continuously evolving and seeks to increase the value of the software product from the point of view of business. When prioritizing responsible for initiating and maintaining the Product Backlog is the Product Owner.
In JIRA Agile Product Backlog is called, as we saw earlier, simply Backlog where all incidents (eye which incidents can be type are stored user stories , technical stories, etc.) and are then assigned to Sprint that corresponds.

–Slimane Zouggari

Eliminating Mura Waste from Business Processes

Posted on by

The word mura stands for “lack of uniformity” and “unevenness”. This Japanese expression is one of the three terms collectively describing different forms of waste that occur in production: muda, mura, and muri.
Mura type of wastefulness can be seen in many business sectors. Being able to identify it and using certain methods to correct it can lead to saving a lot of revenue and company’s effort.

How Mura is Leads To Waste

Mura is not as widely cited as muda type of waste, but it is just as important to address within your business operations. However, it is quite different, and it is important to understand how the two relate.

Most people recognize muda easily and fast, but mura, or unevenness actually often gets overlooked. An expression of this type of waste is companies trying to sell out on their stock and therefore offering promotions that lead to a large amount of sales coming in during a short period of time, leaving the company extremely low in inventory. This technique is a part of muda practice, which suggests that excess inventory is wasteful.

As a consequence, the factories are prompted to manufacture massive amounts of new stock, which often leads to over-production. This results in clear unevenness of sales numbers, as well as too much fluctuation in inventory. Lack of stability is also wasteful as the decisions are being made from the reactive point of view and lack careful planning. Furthermore, this facilitates worsened work conditions, over-time, and that can be a patch to more waste: defects, over-processing, waiting.

Such lack of stability is deemed wasteful as it isn’t based on clients needs. Therefore, according to these waste principles of it isn’t adding value, and it corrupts the processes.

Lean Technique to Avoid Waste

These days agile and lean methodologies are the most popular practices to eliminate waste. These techniques are actually based on the same principles defined by muda,mura, and muri system. Lean manufacturing takes into account all three forms of waste and provides a model of the three method united into a system. Its key idea is focusing on that which adds value, and then reducing all other practices.

Agile Methodology

Agile traditionally refers to software development. It is based on a group of key principles which promote planning, active involvement of users, early delivery of products, testing, and frequent reviewing of achievements and methods. A lot of agile development strategies can help eliminate waste and focus on product quality and evenness of the system. Adapting the main agile principles in different business sectors can be a useful tool to reduce a number of wasteful operations.

There are many variables that determine how successful your business becomes. Mura and other types of waste can harm the workflow and negatively affect productiveness. Being aware of these harmful components gives the better understanding of how to structure the operations side of your business. Becoming a lean practitioner and working on reducing mura is a sure way to minimize unnecessary expenditures and promote a healthy business growth.

–Slimane Zouggari

Muda Types And Waste Prevention

Posted on by

Translated from Japanese word muda means “wastefulness; uselessness”. Any part of your process that doesn’t provide value can be called a wasted activity, or muda. It has two types:

• Type I Muda is a task which doesn’t provide value, but at the same time, it can’t be eliminated, because that would affect other processes
• Type II Muda is an activity which provides no value, and also can be eliminated. The goal is to detect and eliminate as much of such waste as possible.

The idea of muda is that useless activities should be avoided as they are wasting money and resources. This concept is often used in manufacturing when talking about minimizing the waste of production, but muda is also applicable to other industries, such as software development.

7 Muda Waste Categories

Transportation

A lot of waste can be eliminated by business optimizing their transportation and logistics. A lean manufacturing business would use this principle to plan the details transporting products, carefully plan routes etc. This can be interpreted in different ways and applied to different industries, but the general rule is to avoid too much movement which unnecessarily wastes energy.

Inventory

Whether in pre-manufacturing phase or finished products, inventory here stands for value which hasn’t yet been delivered to a customer, therefore it is considered wasteful. There is an obvious application of this principle in industries that produce goods, but it can also be meaningful to agile developers. An example can be creating code not requested by a paying customer. Since it doesn’t work to increase the revenue of the business, it may be considered waste.

Defects

This is one of the most obvious ways of wasting, as defects always result in loss of money, and additional energy needed to resolve the issues. Repairing physical product defects is a common problem for manufacturers.

Waiting

Any product that is not being sold, shipped, or otherwise transported to the consumer, is waiting. This doesn’t produce any increase in business value. In software development, this could mean programmed delays.

Motion

This category refers to waste that occurs due to the physical movement of items. Motion waste can happen in many different circumstances, including product handling, machines wearing down due to too much intense usage.

Over-processing

Anything you do, that has not been required by the client is unnecessary as it isn’t what is being paid for. This happens a lot when businesses don’t fully understand the needs of their client and create unnecessary features.

Over-production

Producing an excessive amount of products is another version of muda activity. It is likely to lead to too much inventory. Anything that is above of the required number may result isn’t immediately adding to business value, thus, it is also to be avoided.

To avoid unnecessary energy expenditure and money loss businesses should apply lean methodologies to their operations. The best practice to eliminate muda in manufacturing, agile development, retail, or any other industry to plan, test, and review the processes carefully and on a regular basis. Most muda can be successfully avoided with these diligence tactics in place.

–Slimane Zouggari

Disciplined Agile Delivery

Posted on by

An Introduction to Disciplined Agile Delivery
While organizations today recognize the benefits, for software development projects, practices of agile methods such as Scrum, Extreme Programming (XP), Lean or Agile Software Development Modeling; there is also a concern about how to scale agile practices at the enterprise level where projects are larger, more dispersed teams work and the architectural, technological and even contractual restrictions are very demanding. The basic methods require important to scale beyond eight teams of people working together in the same place settings.
The DAD can be defined as an iterative and incremental approach to software development that produces regularly and cost-effectively high-quality solutions and at the right time, through a life cycle oriented to risk and the solution value. It is performed in a highly collaborative, disciplined and self-organized way within a governance framework that has active participation of those involved to ensure that the development team understands and applies the evolving needs of the form of actors to maximize the value of business provided by the product (software).

The DAD is a methodology created by IBM Rational that can be seen as an expansion to the Scrum lifecycle in three aspects:
• Explicite phases of the project, recognizing that the delivery of agile project is iterative and also sequential;
• It includes requirements and architecture forecasting practices to the project start to increase the chance of the correct product construction, and contemplate delivery practices of the product in production;
• It includes more robust agile practices (AMBLER, 2012).
The formation of an effective agile team is a crucial point in the DAD and there are some indications that an effective Agile team was formed:
• He has the expertise to get the job done;
• They are as small as possible;
• There are people dedicated to the project;
• It has a unique Product Owner;
• It has a unique team leader (which is not the product owner);
• It has general analysts;
• May include experts, but in the direction of becoming generalists;
• They are self-organized into an appropriate framework for governance.
The more we deviate from this situation, the higher the project risk.
In the image below, we can see the life cycle DAD and its activities. Notice how are explicit project phases (Design, Construction and Transition).

In Disciplined Agile Delivery roles are divided into primary and additional roles.
Primary roles:
• Stakeholders;
• Team Leader;
• Product Owner;
• Team member Nimble;
• Architecture Owner.
• Additional roles:
• Expert in the field;
• Expert technical;
• …
Stakeholders are the people who affect or are affected by the success of the system.
The Product Owner, Scrum as in promoting the goals and vision of the product so that the team can make decisions. He owns the product backlog, defines the scope of a release and when the product is ready to be delivered and deployed.
The Team Leader is responsible for the success of the project and how the ScrumMaster in the Scrum framework facilitates cooperation between roles and functions, remove barriers and problems, protect the external interference team and ensure that the process is followed.
Members of Team Agile are the other members of the team. Also known as developers are generalists, collaborative and self-managed.
The Architecture Owner is responsible for the architecture of the system or subsystems in which the team is working as part of a team of Architecture Owners. He mentor and guides developers in architectural problem and is also a technical team leader. It has the final word on the architecture, but seeks a collaborative approach with your team.
As to additional roles, they are typically large team. The Expert in the Field knows details that are not always the end user domain or stakeholders. We can illustrate this role in the figure of an expert in finance charges. The Expert Technical features detailed areas of expertise, for example, create builds scripts or database. Independent testers are used by teams working regulatory standards or domains and complex technologies. The team may still need Integrators, responsible for the integration of complex subsystems and experts that can focus on issues such as security.

–Slimane Zouggari