Continuous Integration (& Mr Jenkins)

Starting from the XP Principles and Practices, I want to make a short introduction about Continuous Integration describing pipeline, rules, practices, pattern, anti-pattern with a short introduction about Jenkins as Continuous Integration tool.

continuous-integration

You can find slides on my slideshare 

0

Make better decisions and actions during the Agile retrospective… with XP principles

Many companies are adopting even more Agile Methodologies… but how many workgroups are applying Agile correctly?

Many “Agile team” do not have enough culture and training and I often hear phrases like:

“We don’t have much time to apply Agile”

“We do not believe in the Agile value”.

Application of Agile should allow to organize the work in a better way, avoid bottleneck, etc… but when it applied in a wrong way, it can become a problem!

What should be the value to apply an Agile method?

For my personal experience a team who applies an Agile methodology is more reactive, efficient and it has better performance.

The user stories depend on business requirements which depend on customer trends and market developments, for this reason the feedback plays a key value to decide the evolution of a product or service… each new feature should have a big value for the end user and it is necessary to know the user feedback continuously to make the better decision 😉 … Agile and in particular XP gives a focus on importance of feedback…

What kind of feedback can be KPI for an agile team?

Feedback from end-user/customers are important for the Product Owner because he/she can give different priorities influencing the roadmap. The roadmap should be alive and in order to satisfy the user needs, it can change in the time.
Feedbacks from end-user also play a key value for the dev team (e.g. to analyze user behavior to improve UX) or for the marketing team:

Are we sure that a customer has really understood the value of the new feature?

Can we improve the communication?

Agile and in particular XP gives a focus on importance of communication.

Feedback from the team are important to solve the impediments, create best practices, improve the velocity and work with the better working conditions. Agile uses the retrospective meeting to analyze the improvement areas and possibly solve the problems… the goal of a retrospective should be the continuous improvement.

Are we sure that the retrospective always works?

An “Agile” team does not sometimes perceive the retrospective’s value and this meeting is seen such as a waste of time and it can fail for several reasons:

  • Each retrospective is focused on the same topics;
  • People talk about problems without think to solutions;
  • The team does not speak of real problems;
  • The team loses the direction and the goal of the meeting;
  • The meeting finishes without concrete actions;

What can be the reasons behind the failure of retrospective?

Lack of sensibility and Agile culture, the retrospective’s format and maybe the confidence…

… the meeting can be seen as the moment when you give the blames….

…and the people are afraid to discuss the real problems because other people can take offense….

What suggestions can we follow to have a better and efficient retrospective?

Don’ t forget the XP Principles!

Simplicity: Do the simplest thing that could possibly work!

A retrospective format too complex (for example with lots of categories to be discussed) is hard to understand and it may further discourage the achievement of the goal. Let’s start with the simplest format, two categories to discuss: “What went well” and “What improve” and then we will think to evolve the format according to the team confidence.

RetrospectiveFormat

Communication

During the retrospective all team should take word and for each topic (good, bad or improvement) should give a short description in order to facilitate the discussion that should have more focus on solutions rather than only problems..

Retrospective2

Courage

Each member of team should have courage to accept feedback from others and tell their own point of view, so that the team can arrive at the root of the problem and take concrete actions…. otherwise the same topic will be discussed again in the future.

RetrospectiveCommunication11

Feedback

It is important listen to the other opinion and if no other better solutions do not exist, the found solution should become a concrete action and one or more members of team must care to take it forward.

Don’t forget: The retrospective meeting must always finish with a set of concrete actions.

RetrospectiveActions

And last but not least… Respect

If you want to know more about me, please visit my linkedin profile or  follow me on twitter (@CyrusD87)

0

Improve knowledge, share passion breaking down silos b/w workgroups

The 21st of July 2015, I have participated such as organizer, tutor and speaker at the first dojo event organized by SCAI Consulting.

This initiative was born because I think that in a small organization or in a big company, the communication and collaboration between people is a very big value.

I have often seen each workgroup on a specific set of projects or products, the communication is only inside a team and often the people between different teams do not know each other.

In this scenario, each workgroup is a silo… and its focus is only for single areas of expertise.

Starting from these assumptions I thought to create a dojo  and meet  my colleagues with the aim  to communicate with them and share passions, ideas, knowledge, solutions and break down the silos between workgroups.

What means dojo?

Dojo is a Japanese word which indicates a place where take place practices of martial arts and where you can reach the perfect unity between the mind and body and therefore the perfect psychophysical balance.

For a developer have a place where is free to learn without the work and project constraints can be useful and an help… a developer often has a hard life and too little time to study and improve his knowledge.

But not only… The dojo is an attitude

During a dojo we are not colleagues and there are not corporate hierarchies. We become people who are free to meet and share the same passions, ideas, technologies, solutions…

How did we organized?

Every month, we open a call for paper where each person can suggest a topic or a list of topics (the topics are usually about technology, methodology, business, experiences, etc..) then the topics are voted from the participants.

Topics top rated are discussed at the next dojo and each proposal can be discussed with a presentation, a tutorial, pair programming sessions or finding new ways to learn … Enjoy ! 🙂

trello1

We use Trello to organize and plan the dojo events…

Diapositiva1

In the first dojo event we have discussed about MongoDB for Developers, if you want to know more about this, please you can see my slides on slideshare.

If you want to know more about me, please visit my linkedin profile or  follow me on twitter (@CyrusD87)

0

Working with Agile

Let’s talk about methodologies…

First of all, I think that every team should use a methodology to work or reach a target.

In my experience such as a software developer, I have lived the differences between work without a methodology and work with a metodology…trying these two approches, I have understood that a methodology is really essential…

Some years ago I have discovered the Agile movement, in particular two Agile frameworks: Scrum and Kanban.

Scrum is an Agile framework and is very useful to work on a product such as a software product. I believe that in Scrum a product is like a baby and each actor involved in the Scrum process has the priority to care this baby.
The main actors involved in a Scrum process are the Product Owner, the Scrum Master and the Dev team and the Scrum process provides several meeting during a Scrum cycle.

Kanban is an Agile framework and is very useful to work on projects. In this case there aren’t main actors because in Kanban there aren’t fixed roles. The Kanban process is like a flow without end and a key concept in this framework is the WIP limit (Max number of activities that can be in progress at the same time).

For Scrum and Kanban is essential render visible the work flow on a board which can be a physical board (I usually prefer this kind of board) or a virtual board (this kind of board is useful for teams in different locations).
Display a flow is very important because in this way is more simple to disclose bottlenecks and solve it.

I want to close this article talking about some software to use for Scrum and Kanban. The first one is Trello and the second one is Kanbanize, I have experience with the first one and I have used it with my Dev Team for several cases (collaboration cross-team, public roadmap, etc)….

 

0

BEM

During my experience as web developer, I have met some problems with the maintenance of CSS. For small project this could not be a very big problem but when a project survives for long time is necessary a way to manage them.

In fact, I believe that if the web developer does not use a way to manage the stylesheets these can only grow in the time and a change in a class or in an html element can change the style in an unexpected way and to minimize this risk the web developer will change the CSS only adding styles.

Today, I want to talk about a methodology to manage CSS stylesheet, this is BEM.

BEM is acronym of Block Element Modifier and is a methodology very similar to OOP, in fact while in OOP there are classes, properties and methods in BEM there are blocks, elements and modifiers.

 

What is a Block?

A block is an independent entity and can contain other blocks or elements.
(in a base HTML page examples of blocks could be the header, content and footer)

What is an Element?

An element is a part of a block that performs a function.
(in a base HTML page examples of elements should be an header’s content)

What is a Modifier?

A modifier is a property of a block or an element which is different for look or behavior.
(in a base HTML page with two images having same properties (size,border, etc.) except to the background where the first one is yellow and the other is red. In this example the two images have two different modifiers on the background property)

In the following picture the header, content and footer are blocks, the search box is an header’s element, instead the images are content’ elements with different modifiers (size and background color).

Diapositiva2
After describing what is BEM, this is the syntax to adopt in html and css for each element in a page:

<block>__<element>–<modifier>

In the give example for the header we have (using SASS syntax):

.header {
     &__searchbox {
     }
}

.content {
     &.__image {
     }

     &.__image–first {
     }

     &.__image–second {
     }

     &.__image–third {
     }
}

Using BEM gives the following advantages:

  • Each element in a web application has a unique identifier well defined and it is easily understandable the link between CSS and HTML page;
  • The CSS is organized in blocks, each block contains elements and modifiers. If the developer uses also tool to generate CSS automatically such as Sass or Less can improve the code adding variables, mixin, etc;
  • More controls on CSS, the CSS file becomes changeable and maintainable;
  • The dev team has a methodology to write CSS which is understood from everyone.

 

0

Create a website or blog at WordPress.com

Up ↑