Sunday, August 14, 2016

Why I use the term "software craftsman"

I like to think that I can consider myself a professional software developer after 20 years or working on it. Since some years ago I feel very aligned with agile software development movement and lately with the software craftmanship movement. I started to be interested in agile in 2002-2003 and in the software craftsmanship in 2012.
Currently when I try to describe myself I use the words “software craftsman” as an equivalent to “software developer, continuously trying to improve his skills and craft”.



Let me explain what I mean by “software craftsman”:
  • I mean being professional as software developer
    • Trying not only to create working code, trying to create simple, easy to maintain code.
    • Trying not only to create the code that the business required, also trying to help the business to growth (with different solutions, even without using code). Adding steadily value to the business.
  • In order to be a good professional there is a strong need to learn and improve our skills, tools and practices. Or even look for new ones.
  • IMHO a good process for learning or improving ours skills is participating in the community of professional software developers. In this process the mentor / apprentice format works very well to improve our skills.
Why not using the “agile software developer” denomination?
In fact, for my, this definition can be a good option, but currently, the term agile is even more confuse that craftsmanship.

For me, at least in my experience, the development of applications and systems has more in common with a craft than with an engineering. Engineering is the application of mathematics, empirical evidence and scientific knowledge, so it is possible to plan, predict and control. IMHO software development for non trivial systems requires sense and respond and other approaches can derive in a false sense of control.

Some kind of software efforts are more adapted to a engineering approach (algorithms, compilers, software for science), but in my case, this is the exception, not the norm.

So, currently in my linkedin profile I indicate that I work as Software Craftsman… I also indicate that I work as a Shaman, but this is different history :-)

References:

aws-sdk-go spikes and small examples

I am developing the initial support for aws checks for the library https://github.com/aleasoluciones/gochecks

gochecks library allow us at TheMotion and at AleaSoluciones to create programmatically highly concurrent monitoring apps.

This post is an autonote with the initial spikes created using the aws-sdk-go

aws_golang_examples

Saturday, July 30, 2016

Interesting talks about Work Culture and Leadership (June and July)

This are some interesting talks/podcasts/presentations about work culture, leadership, teal organizations, etc that I watched during June and July. Lot's of inspiration...
Work Culture

Leadership (Tribal)

What would you do if you weren't afraid?

Tuesday, July 26, 2016

Initial Scrum includes XP practices

The following quote explains many of the existing problems of agile methodology.
"I learned from Jeff Sutherland that the first Scrum actually did all the XP practices. But Ken Schwaber convinced him to leave the engineering practices out of Scrum, to keep the model simple and let the teams take responsibility for the tech practices themselves. Perhaps this helped spread Scrum faster, but the downside is that a lot of teams suffer because they lack the technical practices that enable sustainable agile development."
Henrik Kniberg "Scrum and XP from the Trenches

Interesting talks about DevOps and Agile culture (June and July)

This are some interesting talks/podcasts/presentations about DevOps and Agile culture that I watched during June and July:

Monday, July 11, 2016

Agile Open Space 2016

1,2th july Santiago de Compostela
Official site: http://aos2016.agile-spain.org/
Twitter: https://twitter.com/aos2k16
Twitter official hastag: https://twitter.com/hashtag/aos2k16?src=hash




Sessions

Design Sprint (https://twitter.com/artzis)

Artitz explains the complete process of a “design sprint” created by Google Ventures to initial design of a product, or to understand a startup product.
They use this artifact to put all the team on the same page and answer important questions for the product in 5 days (it can be prototypes to test with real customers).
It can be complementary to agile inceptions or a substitution sometimes.
Seems very useful and can be a good technique to be explored by our product "discovery" team.

References:

Lean workshop for kids https://twitter.com/agiletorrezno



This was a very interesting lean workshop for kids (4yr-10yr old)
Using a real example to create paper t-shirts the kids learn about organizing the work around a flow, making continuous improvements and avoid waste… Very funny and interesting… WIP, rework, SILOS avoidance, true collaboration.
For me was a pleasure to be in this session with my 4yr old daughter :)

Improvement Kata https://twitter.com/antoniolopezg

We make a practical session Improvement Kata, resolving collaboratively a set of puzzles for kids.
All the people was splitted in two teams and each team made 6 interations defining the expected result, the changes/improvements to test, executing the tasks and analyzing the results of the experiment and the difference with the expected results.
Very good exercise to explain the improvement kata to others and to experiment the process.
The same session can be facilitated using the following materials
http://www.katatogrow.com/#!instructor-materials/ctzx

Product Discovery (https://twitter.com/artzis)

Only 1 of 3 of the product ideas / features are good for the product and even to make this idea successfully normally is need 5 - 6 interactions
The other 2 of 3 product ideas don’t improve the value of the product or even worse, they are counterproductive for the revenue, KPIs or for the customer satisfaction.

To work in this ideas we can use a Product Discovery team that have the goal of identify this 1 of 3 ideas and define the experiments and changes to identify the real features to implement in the product.
Product Discovery Team: Product manager + UX + Tech Lead. This can identify the intersection for ideas that are Useful/Valuable Usable and Factible.

The important metric is the lead time from Idea to Cash. Normally more than the 80% of the time is waiting, so this product discovery process try to minimize this timing using some techniques like design sprint


References:

Adaptive leadership (joserra_diaz quesitosgiver)

Interesting but there was at the same time other session more technical that I wanted to see, so I use the two feet rule.
References:

OOP and Connascense / Coupling (Fran Reyes / Alfredo Casado)

It was an interesting description about the different types of connascence with examples and different approximations to try to avoid this problem of at least to refactor to less problematic types of connascence
References:


eXPeriencias (Carlos Ble David Fernandez)


This session was an open discussion about practical experience using XP. The format of the session was a lean coffee and I remember that we talk about:

  • Pairing
  • Mob programming
  • Continuous integration
  • How to introduce a XP culture
  • ...

Let’s Talk about Values (Pablo Jimeno)

This session was focused on examples about good defined Missions, Visions and Values. We talk about the experiences at Deiser (Guillermo Montoya), Magento, Spines and Liferay.
Interesting points:
  • Values as simple words (not express to much). Better to have phrases that defines the limits or the default behaviour
  • Exercises for definition
  • At Magento, each team have his values and they will create a global values proposition in a global retrospective.
  • As interesting exercise they will try to define the values trying to answer to the question “If the company/team/office is a person, what kind of person would be? young, expert, humble….
  • Use the values as a reference in any meeting/discussion
  • The Atlassian Values seems to be a very good example… As Guillermo Montoya comment seems that they really use this values.
  • Sometimes the values can be used as limits to all the employees know the constraints or the lines that the company shouldn’t cross.
  • To define this kind of constraints sometimes is more easy to define What company we don’t want to be or define which lines we wouldn’t cross.

Final conclusions and Notes

  • As always I come back from the AOS full of energy and eager to help, improve and change
  • I like a lot the Open Space format. For me is pure "agile" format.
  • As usual the number of technical sessions was low. I think we can improve this. It is very important the cultural and management part of agile, but there are too few agile developers available so any improvement of this situation is fundamental. Anyway, whatever happens is the only thing that could have :)

I have an special thanks to the organization and to agiletorrezno for making this conference a pleasure for going with the family.


Other references and Notes


The next AOS (2017) will be organized by agiletorrezno at Segovia.