​We have all gone through this cycle of vulnerability detected and patches applied in our careers. Some of us still go through this vicious cycle of tense, challenging and nerve wrecking moments when you are racing against time and people in business are asking for updates while the customer support is assuring the customers with eyes on the screen waiting for the announcement "Patch Applied", "Service Restored" etc

Software Patch and Vulnerability Management continue to be a major challenge for many organizations. There is no single software product or vendor source of these vulnerabilities.  Organizations must consider patching at all levels of software and only applying Microsoft Patch through Tuesday updates to protect systems and data from cyber-attack is not sufficient.

​I don't claim that i am an expert on this subject and still there is a long curve of learning involved as my career grows in to new roles. What i am sharing here are some of my observations, notes references etc related to agile leadership and how well an organization should adopt them for survival.  Let’s examine some favorite ideas and concepts around agile leadership. 

In my experience, there are at least five criteria for successful agile transformations. Lasting organizational change happens:

1. When there are leadership and guidance, not command & control.
2. When there is alignment across the organization instead of the pursuit of local optimization efforts or personal agendas.
3. When the collaboration of all participants beyond hierarchies is the norm, not an exception.
4. When we acknowledge that management principles of the 19th century are unsuited to solve complex problems of the 21st century.
5. When managers become servant leaders.

​
The following  focus on the main concepts related to agile leadership: from servant leadership to the agile mindset to creating a learning organization. The lists are not supposed to be comprehensive but provide the interested reader with a starting point for further research.

​Scrum Artifacts – results/products of our management activities – are designed to increase transparency of information related to the delivery of the project, and provide opportunities for inspection and adaptation.

​There are six artifacts in Scrum:

1. Product Backlog: An ordered list of everything (aka stories) that might be needed in the final product
2. Sprint Backlog: Selected items (stories) from the Product Backlog to be delivered through a Sprint, along with the Sprint Goal and plans for delivering the items and realizing the Sprint Goal
3. Increment: The set of all the Product Backlog items completed so far in the project (up to the end of a certain Sprint)
4. Definition of “Done”: The shared understanding of what it means for a piece of work to be considered complete
5. Monitoring Progress towards a Goal: The performance measurement and forecast for the whole project
6. Monitoring Sprint Progress: The performance measurement and forecasts for a single Sprint

​Items 5 and 6 might look more like activities, but they are considered artifacts in the Scrum Guide, and therefore we will explain them as so. You can imagine their output (tracking information, burn-down charts, etc.) as the real artifacts and these two items as ongoing activities (like Product Backlog grooming) or part of the Scrum events (part of Sprint Review and Daily Scrum).

In Part 1 we extensively covered   the basics about Scrum, Agile Manifesto , the Principles, facts and myths about Scrum and the roles within the team. 

In this post we will concentrate on understanding  and will do a deep dive analysis of:

- Scrum Events
- Scrum Activity - Backlog Grooming
​- Scrum Activity - Slack

Scrum events are designed to enable critical transparency, inspection, regularity, and adaptation. You must prefer to use these predefined meetings with fixed objectives and maximum durations instead of ad-hoc meetings, which most likely waste our time.

There are just five events in a Scrum Project:

1. Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four other events (as represented in the above diagram), development effort, and the maintenance of the Product Backlog.

2. Sprint Planning: Sprint Planning is the first event inside a Sprint. The Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them.

3. Daily Scrum: The Development Team starts working on the objectives of the Sprint as soon as Sprint Planning is completed. During the Sprint, the Development Team holds a daily meeting (normally 15 minutes) to coordinate the work for the next 24 hours. This meeting is called the Daily Scrum.

4. Sprint Review: Before the end of the Sprint, the Development Team presents (demonstrates) the outcome of the Sprint to the customer and receives feedback. This meeting is called Sprint Review (also known as Sprint Demo).

5. Sprint Retrospective: After the Sprint Review and just before the Sprint is over, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint. This meeting is called Sprint Retrospective.

Time Box is an essential concept in Agile methods, a predefined fixed maximum duration of time in order to maximize productivity in which we freeze the target and work with full focus on certain tasks or objectives. Time-boxed events  repeat many times, until the final goal of the project is achieved. All the changes are applied only when one time-box is finished and we are ready to start the next one.

The duration of a time-box should be agreed upon and fixed. We are free to change the duration based on lessons learned, but not frequently, and never based on single occasions. For example, we are not allowed to say that “we have a lot to do this time, so let’s increase the duration for this particular case”.

What we are allowed to say is “based on the previous ten time-boxes, we realized that the duration of our time-boxes is not suitable, and a 30% increase in duration might better fit our needs. So, let’s increase them from now on”.

After some thought i have decided to write and share some of the basics about Scrum. A lot of people have different views, theories and ways of doing things which they call Scrum. While i do not contest some of those practices but its essential to understand the concepts and strongly agree that every organization team will need to mold and churn some process to make things work. 

So in this series of blogposts, the first one will be addressing the following:

- Scrum and Agile
- Agile Manifesto
​- Agile Principles
- When to use Scrum VS other Methods
- Facts and Fibs about Scrum
- Scrum Timeline
- Scrum Roles and Team

At a later time, i'll share the more advanced stuff and also touch base with SAFE.

It is not possible in some projects (especially in IT projects) to gather all the requirements upfront because of their extreme uncertainties. Therefore, we need a project management method flexible enough to deal with many change requests that appear during the project and keep the project team productive.

There are a number of systems designed to provide these two properties, and a group of them are called Agile Frameworks. Scrum is a project management method of the Agile group; it is the most famous and the most broadly used one.

Scrum is based on a certain process, which i'll explain in the next few blogposts as we progress. This Scrum process will not be effective, unless it is combined with certain roles and artifacts.