Disclaimer: I am experimenting with different formats to create presentations, blog post, and other documents, mixing sketch noting and using index cards... I will appreciate your feedback.
I prepared these notes for the past AOS 2017, but finally, the session was not selected... The initial idea was to describe our process for creating an agile software development team and create a discussion to identify next steps to expand our agile culture to the rest of the organization
Honey Badger Team / The visual history
In the beginning, there was a bunch of developers at TheMotion starting to create the product. But there was no process and the "established" tendency was to try to optimize the
resource usage. As we already know, optimizing the resource usage have some serious problems:
- People are not resources :) (so this not work very well outside some simple industrial processes/pipelines that don't involve humans)
- This process generates busy work but not necessarily good outcomes.
- To optimize the resource usage, we need:
- Push until all of the resources are 100% used
- To create buffers to have everybody busy
- Generate SILOs / Specialization for each skill (front end, backend, video)
The result of this process was:
- An incredible high bus factor
- Stress and bad quality code and practices
- Tons of WIP/inventory and unneeded features as we develop based on how is available (frontend, backend...)
I arrived at this point to the company... There was a Funny party going on :)
One thing was clear (at least for me), using a Lean and Agile approach can help to create a product in a startup.... It also can help to improve the overall frustration :)
I am completely biased because I like the agile mindset... but I sincerely think that in a startup the agile approach is the right choice: Fail (
agile is not recipe for success) and learn as fast as possible :)
For me, Agile is a set of values and principles, not a methodology and
two pillars:
- A healthy culture focused on people (collaboration, respect, teamwork, creativity...)
- Looking for quality and technical excellence (for example XP practices are a great starting point).
So my first target was introducing quality and technical excellence
to be capable of delivering software in small cycles (days instead of weeks)... My idea was to introduce the culture at the same time that we improve our technical capacity. Any software developer is more open to a new ideas if he shows improvements in the code and in his day to day work. :)
But how can we detect if we are in the right path?
I discovered that a good KPI for measure these improvements was
how much anxiety was generated in each team member when we change the frequency of a development event (deploy, merge, etc...)
For example, the target was:
- Deploys frequency, from 1 a month, to several per day (the deploy is not an event).
- Integration frequency, from branches that last forever to trunk based development.
- Feedback time:
- For review, from code reviews and pull request to pairing and continuous review.
- Subsecond for unit tests.
- Seconds for integration tests.
- Minutes for production monitoring.
But How can we improve the quality and our technical capacity???
For me, the response is agile development, XP practices and modern agile... In summary being professionals and pragmatic delivering software. And mentoring is the only way I know to introduce this technical practices....
Initialy, I was the only one that started to send the message about XP, Craftmanship, cloud native, etc... At the same time, we were trying to improve the day-to-day work improving the infrastructure and the base platform.
We, as a team, was making improvements, but learning TDD or pairing have an important entry barrier so we need external help with experience teaching this practices (by doing of course).
To improve the "mentoring power", the collaboration of
Modesto San Juan and
Alfredo Casado from
Carlos Ble y Asociados (now
codesai) was key. They help us to improve our TDD and to introduce other XP practices (shared ownership, pairing, etc). At this point, our internal alignment started to be evident.
The first day that I detected that the mentoring effort was having a profound effect was when one developer, talking aloud, explained what Modesto or Alfredo would say about his code, and immediately he started to improve the code :-)
Another key point was that from day 0, we assumed that everybody wants to make a good job so the smarter approach to improve is to "Make easy to make the right thing". Instead on focus in preaching how the things should be done and instead of forcing to do the things in a certain way, our focus was on creating an awesome tooling and platform that make very easy to create microservices, include instrumentation, metrics... We pushed very hard to have an automated infrastructure and a very good tooling.... This includes rolling deploys, standard makefiles, a devbox (now deprecated), containers, etc.a great monitoring.
With this platform and this tooling, it was easy to introduce a DevOps culture, with microservices and improve our deployment cadence day by day.
An important note here.... during this process, the most important factor was to use an agile process and make small improvements, with low risk in parallel to the normal development...
Right now, our practices include, continuous delivery (several times a day), automatic tests (TDD in the way but not the default option yet), simple design, immutable infrastructure, infrastructure as code, collective ownership and we work as a high-performance team with our own identity and a high level of trust….
We have a lot of things to improve, including our quality at the front end (software design and practices), more solid understanding and usage of the XP practices, and so on... but I can say that the agile mindset, the learning culture, and the eager to improve, are already there. :)
We continue our journey, improving continuously...
At a company level, we passed for some periods with lack of alignment, but this is changing very fast and seems that in the next months we will have very clear goals at a company level. This is great and can help us with our next challenge... Expand the agile mindset to the rest of the organization...
A final note:
IMHO now that we are capable of creating/evolving a software product, is the right time to expand this culture to the rest of the organization... I see a lot of times that there is a huge effort trying to introduce the agile mindset at the company level but without having a solid technical capacity, and I think that this is a huge mistake for software/tech based companies. In such cases, the story usually goes as follows: Huge effort to transmit the benefits of the agile mindset, everybody is very excited, the change begins, but the core of the systems is not capable of generating software at a sustainable pace, the technical debt begins to grow without control, and the product collapse... The cultural change fails, and everybody thinks that Agile doesn't work...
The explanation is easier than that:
You don't know how to make software. So first, learn how to make software and later you can introduce other parts of agile. (See:
the two pillars of agile).
A culture of Agile software development with a good quality is a prerequisite for introducing Agile at a company level for software based companies.
References:
Thanks:
- To Jorge Jardines for the fast feedback and some improvements
- To the Honey Badger team :)
