Chemaclass - xp

What Kills Agility?

2024-05-30T00:00:00+00:00

Dozens of documents and spreadsheets, meetings over meetings, and yet without much impact, result in team misalignments, realized too late.

How we manage an organization defines its quality. Excellent management is crucial to avoid the Waterfall trap if we aim to build an Agile environment. But why would we want that? What’s wrong with the way we already work?

If you are already happy with how you and your team work together, that’s okay. However, what about reevaluating how you work to look for potential improvements?

I am referring to evaluating your system and how you and the people around you act within it. What worked months or years ago might differ from what we could discover today, as part of continuous improvement.

I dislike politics in the workplace, where each team looks out for themselves instead of having a bigger shared direction. This results in daily work filled with fear from above, passed down to the people below, maintaining an unhealthy working environment. Game of Thrones is great as a fictional series, but not something to deal with in daily business.

Agile was born precisely as a response to the excessive waste generated by politics and organizational micromanagement.

Controlling and “slow performance” needed a more flexible approach. When people adopt a fixed mindset, they resist change, fear failure, and prioritize rigid processes and hierarchies. This conflicts with Agile’s core ideas of embracing change, continuous delivery with iterative development, flexible planning, and fostering collaboration and innovation.

A fixed mindset leads to fear of experimentation and a reluctance to challenge the status quo, reducing progress and the potential for learning and growth.

What kills agility? #

Fixed mindset: Resistance to change, fear of failure, and prioritizing rigid processes over learning and adaptation strangle innovation and flexibility.
Excessive bureaucracy: Complex processes and excessive documentation slow down decision-making and responsiveness.
Micromanagement: Over-controlling leadership undermines team autonomy.
Lack of collaboration: Poor communication and teamwork hinder progress.
Ineffective feedback loops: Prevent adjustments and continuous improvement.
Fear of experimentation: A culture that punishes failure discourages experimentation and learning from mistakes.
Inflexible processes: Strict adherence without adapting to project needs.
Misaligned goals: Conflicting priorities reduce efficiency.
Lack of leadership’s support: Without backing from upper management, Agile initiatives can struggle to gain the necessary resources and commitment.
Poor technical practices: Neglecting technical excellence and good design can lead to a fragile codebase that is difficult to adapt and extend.

What can you do about it? #

Learn the basics of Extreme Programming (XP) and Lean Software Development.

XP: Focused on software development practices and technical excellence, with specific practices like pair programming and Test-Driven Development (TDD).
Lean: Takes a broader approach, focusing on removing waste, optimizing flow, and improving processes across the organization.

Effective Pair Programming

2024-03-28T00:00:00+00:00

What is pair programming? Two people working together on the same problem, at the same time.

It is not about one person showing off their skills in front of another, nor one person afraid of making mistakes due to an impostor syndrome.

Each person will have a role:

Navigator: he will pay attention to the bigger picture; eg: architecture, relation between collaborators, object design, etc.
Driver: she will pay attention to the small details; eg: naming, code conventions, writing syntax, object design, etc.

The pair could, and should, switch roles occasionally; eg: every X commits pushed, every 10 mins, … up to them.

Pair programming should not be considered a practice only for “seniors” to juniors, but regardless of the team members’ experience level.

It is about the collaboration flow, the quality communication, the absence of feeling judged, and the idea of welcoming vulnerability with your peers, knowing they will support and help you.

It is about constantly challenging each other, seeking the most pragmatic solution while keeping it simple. Always looking for quick feedback when speaking to each other, but also on the solution you agreed to implement and its direction.

It is about the short, quick, and immediate feedback loop while talking to your partner, who reviews your code on the fly. You can guide as a navigator or help the driver validate their ideas in a broader picture.

It is about the constant sharing of knowledge atmosphere by default, reducing bus-factors and silo-knowledge areas to the maximum. Increasing the focus by having two minds working on the same task simultaneously.

It is about team cohesion and sharpening the feeling that we belong. When we understand each other’s strengths and weaknesses, we will realize how much we can help each other grow.

How can you practice pair programming? #

Pair programming can be done in different ways:

You can start and finish a task with pairing. You can time-box it to 30, 60, 90 minutes. Either way, it is recommended to have pauses in the middle - Pomodoro.
You can start the task together and stop when one of your peers feels confident enough to continue alone.

It is up to the team, and the task in context, to decide when and how to apply pairing to get the best out of it.

This does not mean you must constantly work “no matter what” in pair. This is not about creating rules; on the contrary, it is about embracing this practice to the point you feel confident to choose when and how to use it to get the best out of it.

Pair programming might become one of the best tools in your team toolbox for daily interactions. Not because you read it somewhere but because of the benefits you and your team will find.

Common Patterns #

Different strategies for effective pairing #

Driver-Navigator: One person is driving the code (with the keyboard), focusing on the detail aspect of the task itself. The other is a navigator (no keyboard), having a more abstract picture of the task in mind.
Ping-Pong: Frequent switching driver-navigator roles in small interactions, e.g., every N minutes, every N commits, etc.
Backseat driver: The navigator engages actively with the driver.
Tourist guide: The navigator passively learns with the driver.

Anti-patterns while pairing #

The silent partner: The navigator is not participating, and they are being silent.
The solo act: The driver ignores all inputs from the navigator.
Distracted pair: The pair does not focus on the problem to solve.
The Dictator: One person is telling what to do, ignoring the input from the other.
Philosophical pair: The pair is bikeshedding into irrelevant topics.
The code war: The pair does not reach an agreement and starts an unnecessary war, which wastes time and effort.

Want more? Check this out: Learning Through KATAS

The takeaway #

Pairing is not a rule to enforce, it is a tool to reach for. Use it when the task is complex, the knowledge is siloed, or the stakes are high. Skip it when the work is trivial. The goal is never “always pair”, it is better software and a stronger team. Pick one real task this week, pair on it, and switch roles often. The benefits show up faster than you expect.

Deployments on Fridays

2024-02-25T00:00:00+00:00

I have heard multiple times, from various people, the idea of panic towards deploying on Fridays. How good is that idea of banning the day before weekend from delivering new value to our clients or customers?

The main argument in favor of NOT deploying on Friday is based on the idea that we “should be paranoid” with our software and that it could fail when we touch it. So, we “should assume” the worst whenever we deploy a new release version of our system.

However, the critical factor here is Why? Why should we not deploy on Fridays? Is it OK to be afraid of our own software system, that we live in a constant panic of breaking it the day after we have done a deployment? How much impact should our releases have? How can we make sure the deployment won’t break the live system?

Your Continuous Integration/Delivery pipelines, end-to-end and other types of tests in place, automated scaling policies, a previous staging sandbox to perform even manual tests if necessary, etc., will determine the security and confidence for any of your releases. However, the quality of these topics is a deal-breaker to have enough confidence on how, when and why would it make sense to release to production.

The goal is build a system where deployments to production should be as often, smooth and easy as possible; any time, any day. Being afraid of your system should not be the aim. On the contrary, it should be something to work towards to fix it.

The team dynamics are also an essential factor here. If we establish fear of deployments on Fridays, and fear of our system, that will end up in lack of accountability by default. This reminds me of The Five Dysfunctions of a Team.

If you deploy small and frequent changes as soon as they can guarantee 100% quality value success, why delay such an incremental improvement to your system?

Coming back to “Why should we not deploy on Fridays?” The only reason I can think of is being afraid that we have to work on Saturday on the broken thing we delivered on Friday. However, I wonder if any option was available, so we could have identified such a broken thing during the working Friday itself.

Monitoring your live system is crucial to guarantee the health after each deployment. This is essential to ensure everything is working fine and smoothly. To build a resilience system, this should trigger alarms to notify someone responsible for addressing the issue, disable or revert the latest “broken” feature… there are many techniques to create awareness and act on them.

In case of doubt, you could use feature flags to disable the feature you will deploy. Still, you prefer not to enable it during the weekend while keeping the option of adding value and deploying anytime always open.

I believe frequent and small releases to production are key; any time, any date, as far as it makes sense, and there is a clear path to bringing value soon to the customer to get feedback ASAP.

Deliver quality value in small increments, as frequently as possible.

Being able to deploy on Fridays (if needed or wanted) impacts the team’s confidence. Similarly, forbidding deployments on Fridays impacts the team’s self-esteem as well.

How Do You Get Everyone on Board?

2023-08-02T00:00:00+00:00

I was invited to the WeAreDevelopers World Congress to give a tech talk about my experience with XP and the profound benefits of embracing change in your work and life.

With more than 12k attendees, 300 speakers, and ~10 tracks in parallel, I was invited to give not one but two talks. One is about my experience with Extreme Programming and the profound benefits of embracing change in your work and life.

I especially enjoyed the audience engagement and feedback they gave me after each talk. In particular, a question I had faced many times during my career: “How do you deal with people reluctant to change?”

This is one of the most complex topics affecting any team, regardless of their profession. But, especially in our constantly changing software industry, if you are reluctant to embrace change, you will do more harm than good to your team, career, and yourself.

As stated in Peopleware, “our software profession is less about computers and more about humans and their interactions”. This is usually the root problem for people; it’s a human problem first.

To become truly agile, you must have a good foundation of trust among your peers. Without trust, there is no team, and the primary responsibility of a good leader is to help create a trusted environment without fear of healthy conflicts. Everyone feels they can speak and express freely in a safe environment.

A safe environment means you don’t need to carry on armor the whole day to protect yourself from others, so you will have more energy to drive excellence in your workplace.

But still, despite your effort to create a trustable and safe environment, you might encounter people reluctant to change. For those, you might need to try different approaches. How can you help create trust among everyone?

Don’t be afraid of failure; instead, think that everything you do is an experiment from which you will learn something. And anything that brings you closer to a better state is better than nothing.

The key here is to find a way to connect with people by understanding how they understand their potential so you can empower them and help them grow.

Grant time for reading #

1:1 meetings are ideal for establishing personal connections with your peers. However, you might feel that the situation requires an additional push, especially if you have someone who doesn’t like to speak about themselves, and it is hard to know what they think about what’s happening.

Here is an idea you could try:

Give them a book containing ideas or knowledge that could benefit the whole.
Allow reading this book during work time, eg: on Fridays after lunch. This is a company investment for the development of your team.
The book should be read in 3-4 hours, or a couple of Fridays, depending on the number of pages.
Don’t wait until the book is finished to talk about it. Follow the progress.
You will have great topics to discuss during your next 1:1.

You could use any book for this exercise #

Any book would be fine. Still, if you are looking for great examples, these are my favourite three to start thriving a conversation:

Who moved my cheese? is a metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change.
Extreme Programming Explained contains a compilation of values, principles, and practices highly related to the human touch in our software industry. Focusing on the team aspect, collaboration with your peers, and creating a sense of mastery and purpose in our craft.
Start with Why addresses the importance of starting with “Why?” in order to define a purpose for anything we do.

Experiment with any book, timeframe, person, or group to create a shared understanding of the team’s foundational values and motivations. The goal is to engage in active knowledge-sharing while cultivating a team that feels they belong, fostering passion at work. This will help create trust, and you can start building on top of it.

If you are looking for books to help scale up your leadership skills, there you go: “Great Leadership”.

You cannot force people to change. On the contrary, the more you try to force it, the harder they will make it for you. Instead, focus on understanding them by acknowledging what they feel and thinking about what they do to create a common ground of understanding each other.

Photos from me at WeAreDevelopers World Congress, Berlin 2023.

Interview About XP and Agile

2023-01-09T00:00:00+00:00

My interview with devm.io regarding Agile and Extreme Programming.

devm.io: We talked to Chema, a software developer and an Extreme Programming expert, about his favourite topic and his upcoming live event Update Your Team To Be More Extreme.

Could you tell us a little about yourself, who you are, and what you do? #

Chema: My name is Jose Maria Valera Reales, but everyone calls me Chema. I’m originally from Spain but have lived in Berlin since 2015. I’ve been working as a software developer since 2013. In recent years, I have focused on achieving excellence and figuring out how to help my peers and, with them, the entire software community to improve in our profession.

I am currently a Tech Lead at Lautsprecher Teufel GmbH, where I work with the e-commerce webshop team. I also enjoy open-source software, so I enjoy creating pull requests for other repositories, and I also love when I receive pull requests from others.

How would you describe Extreme Programming? What makes it so “extreme?” #

Extreme Programming is the most straightforward and pragmatic approach to embracing Agile in your software team. It incorporates solutions based on values, principles, and practices. You don’t have to use or do everything, but rather whatever fits you and your team in your context. However, these are helpful general solutions that work better when combined.

From my experience, the word “extreme” can be misleading, but I see it as an opportunity to emphasise the difficulty of the fundamentals behind it. The critical point is realising that our “common sense” is not as “common” as we tend to think, nor the best practices for practical teamwork. Therefore, this is about pushing ourselves to extreme effectiveness, collaboration, and satisfaction while working with others.

You will host a live event on devm.io on the topic on January 19th. Could you give us a sneak peek of what your audience can expect? #

We will explore how a software team works nowadays, the common issues we encounter, and what solutions we could apply to improve our team routines. We will look for the real meaning of Agile, focusing on Extreme Programming ideas.

In addition, I will share some ideas to help your team create learning opportunities with concrete examples that any team can incorporate into their current work.

During the event, you will also tell us something about Katas. What exactly are Katas? #

The term “kata” comes from the repetitive movements done in karate that help you improve your fighting skills.

Why “code katas?” Because as a group, we need to practice more. Most of our learning takes place on the job, so most of our mistakes are also made there. And because we want to keep PROD, we’re reluctant to try new things.

Katas exist to help developers get the same benefits you would get from practice in any other profession. These simple, simulation exercises let you experiment and learn without the pressure of PROD. There are no right or wrong answers in any software kata: the benefit comes from the process, not the result.

There are katas to help you improve your refactoring skills (such as Gilded Rose Refactoring Kata by Emily Bache) or your testing skills (easy ones like Fizz Buzz or Roman Numerals, or more advanced ones like the Bank Kata by Sandro Mancuso). They’re also great for building confidence when programming with others, watching and practising different roles collaboratively, fostering team cohesion, etc.

What role do Agile methods play in software development for you? #

The very first question here is to define what Agile methods are. In the end, everyone communicates somehow, provides feedback to others, and simplifies to some level. Sometimes people have the courage to speak their minds and sometimes they do not, and usually, they try to respect their peers. So, for me, Agile is more about “how” you do certain things rather than “what” things you do.

Agile is a highly collaborative working process at any level, which might have a challenging learning curve at the beginning, but it pays off sooner than you might expect.

Which topic in the area of agile should receive more attention? #

Team building and embracing agility, starting with asking “why?” We need to challenge the status quo more often and ask ourselves why we work the way we do and how and what we could do differently to keep improving and never stop learning.

You can also read the interview from the original link: https://devm.io/agile/extreme-programming-agile.

Working Agile with Non-Agile Teams

2022-11-11T00:00:00+00:00

Let’s assume you already know what the agile manifesto is. Let’s consider that you apply most of the “extreme programming” values, principles, and practices. How can you work with other teams that aren’t agile?

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

You’re using short feedback loops, where things are constantly changing. You can feel that the team is alive and every one is essential.

You embrace the change to the point that you enjoy going out of your comfort zone whenever needed. Seeking to create value for your team and its dynamics, and always considering personal growth.

But sure, let’s assume all that, and everything else I might have missed regarding “agility,” how could you work with an external team that is not agile? How could your “perfectly agile team” work with another group of people with nothing to do with software? For example, a doctor.

A doctor has no time to learn about your “agile values and principles for software development.” A doctor has no time to learn about “extreme programming.” Similarly, they don’t have time to learn about testing, design, architecture, and good practices related to software in general.

How could you create a bridge between that doctor and your software team?

How could you work agile with that doctor? #

If you need to work with that doctor is because he/she should be a domain expert. I suggest getting one or two of your team members to meet with that expert for 30/60 min, so they can talk and share their impressions. And then repeat this as much as possible to shorten the feedback loop. For example, once a week.

Collecting those requirements and impressions from the experts and then driving the design of your software according to that is Domain-Driven Design. You can find a lot of documentation about DDD in books (like Domain-Driven Design Distilled) or in many blogs on the Internet.

However, the critical aspect here is not what requirements or impressions are being resolved but how. How could you work agile with that doctor?

Agile is about quick feedback. It’s about effective communication and reducing waste while aiming for simplicity.

By truly applying these five values, you’re already acting agile #

Communication
Feedback
Simplicity
Courage
Respect

These abstract goals apply to any profession, and even life, not just software.

Continuous communication helps shorten the feedback loop, which simplifies the tasks. Always with the courage to address the truth and respect for each other.

Practices are the things that you do #

Sit Together
Pair Programming
Test First
Incremental Design
and many more

And despite having a technical name, they might apply to any profession:

Sit Together & Pair Programming: think and do with other peers

Test First: verify your assumptions first, then solve the problem

Incremental Design: whatever you do, make it better incrementally

Principles guide and motivate the practices to the values #

Mutual Benefit
Diversity
Failure
Opportunity
Baby Steps
Quality
and many more

Mutual benefit is the most important because it’s about finding practices that benefit us now, us later, and the customer too.

Other principles include the diversity of ideas. Don’t be afraid of failure. Look at everything you do as an opportunity for learning. Avoid giant steps because they have a higher risk of failing. Aim for a high-quality system because they are more predictable and easier to change.

The question remains: are you agile? #

I truly believe an agile team is the one who can cope with change at team level. Therefore, you must first master agile within your team, and then you can collaborate with other teams in an “agile way”.

Once you have internalized these points above, you can apply them while working with anyone from any team.

While these isolated ideas are good, they are even more powerful when combined. They create an atmosphere of curiosity and active learning. It might even wake up some passion for your profession that builds an aura of team cohesion, and just like that, the team breathes on its own.

Everyone cares and takes full responsibility for keeping the team healthy by building trust. There is no fear of healthy conflicts. They feel empowered and accountable to their commitments. The team celebrates their results and learns from their mistakes; there is no need for masks anymore.

That’s when the magic starts to happen, and suddenly you can work agile with any team, especially yours.

Different Beliefs About Software Quality

2022-10-08T00:00:00+00:00

I recently got a great question on Twitter which got me thinking for a while and I decided to share my thoughts about it.

The tweet that started this #

But first, some context: I am feeling great because the codebase where I work is getting better and better, so I am tweeting this:

“As software improves with time, you can feel you’re doing right.”

And then I got a question asking for suggestions:

So there we go…

My answer #

Create agreements #

The first thing is to create agreements about what quality software means for your team and yourself. This helps clarify what software culture you want to establish and work towards that direction. Leaving your company should be the last resort once you have no other option.

Before thinking about leaving your company, I would ask you:

Why do you think you cannot improve the working codebase of your company?
What can you do to reduce the friction between your different beliefs regarding what quality means for software?

There is no perfect codebase to work on because software is a living entity and constantly changes. So, at least for me, quality software is the one that can cope with change smoothly.

Once you have agreed on that goal, and while there are multiple ways to achieve that result, my favorite way of working is keeping an agile mindset with doses of extreme programming values, principles, and practices in mind.

Software is about people #

Software is not just about writing clean and solid code. This is indeed desired, and we should aim for that, but we must first understand why we want that. The “why” is based on the values that you have as a team.

If you don’t share the same purpose, the same “why,” then you won’t enjoy working together, and in such a case, I would advise looking for another company that shares your values. But, before that, I would strongly suggest fixing the deeper issue and helping your team improve.

Understanding your why #

You first need to deeply understand your “why” so you can transmit this to your peers and the people around you. Have you tried all you can to create awareness about your “why”?

Some ideas include encouraging collaborative programming (pair/mob), presenting some internal tech talks, creating a culture of sharing knowledge on a regular daily basis, creating awareness about the current status quo, and looking for opportunities to improve everywhere.

Your career path #

If, after several months of (really) trying these ideas, none of them work, look for a new company that shares your beliefs. After all, you’re the first and primary responsible person for taking care of your career path.

Original twitter thread.

Extra thoughts #

If you want something to be different, don’t wait till it’s changed automatically. Try to change it; if it’s not working, leave it. Maybe you don’t belong in that place.

On the other hand, it’s crucial to reflect if you see that pattern often repeating (changing companies too quickly). In such a case, maybe the problem isn’t the companies but yourself.

Software development is not just about code but business. It’s essential to be aware of finding a fair trade-off between speed, costs, and quality, depending on the situation. You might want to use some tech debt to conquer the market as soon as possible.

It doesn’t make sense to have “low quality” as part of the identity of any team. Every team has certain quality expectations. Therefore, the key here is to agree on what good quality is.

Clean Craftsmanship

2022-07-11T00:00:00+00:00

The book is divided into three parts: the disciplines, the standards, and the ethics.

The 1st part is the most technical one. It guides you with TDD examples, showing how testing can help you to design your code.

The 2nd part is about productivity, quality, and courage.

The 3rd part is about how did we get here in terms of people who develop software, and our responsibility within our ethics about do no harm, integrity, and teamwork.

One of my favourite parts from the book:

Our software industry is wildly dynamic and changing; therefore, we must all be continuously aggressive learners.

How and when do you do this learning? If your employer provides you the time and space to do this kind of learning, then take as much advantage of it as you can. If your employer is not helpful, then you’ll have to learn on your own time.

Be prepared to spend several hours per month on it. Make sure you have the personal time set aside for it.

Yes, I know you have family obligations, bills to pay, planes to catch, and you’ve got a life. Okay, but you also have a profession. And professions need care and maintenance. I expect us all to be continuous aggressive learners.

Chapter 11. Courage - Continuous Aggressive Learning

Index #

Part I: The Disciplines #

Chapter 1. Craftsmanship #

Extreme Programming
Test-Driven Development
Refactoring
Simple Design
Collaborative Programming
Acceptance Tests

Chapter 2. Test-Driven Development #

Overview
The Basics

Chapter 3. Advanced TDD #

Getting Stuck
Arrange, Act, Assert
Test Doubles
Architecture

Chapter 4. Test Design #

Testing Databases
Testing GUIs
Test Patterns
Test-Specific Subclass
Humble Object
Test Design
Breaking the Correspondence

Chapter 5. Refactoring #

What Is Refactoring?
The Basic Toolkit
Extract Method
The Disciplines

Chapter 6. Simple Design #

YAGNI
Covered by Tests
Coverage
Design?
Maximize Expression
The Underlying Abstraction
Minimize Duplication
Minimize Size

Chapter 7. Collaborative Programming #

Chapter 8. Acceptance Tests #

The Discipline
The Continuous Build

Part II: The Standards #

Chapter 9. Productivity #

We Will Never Ship S**T
Inexpensive Adaptability
We Will Always Be Ready
Stable Productivity

Chapter 10. Quality #

Continuous Improvement
Fearless Competence
Extreme Quality
We Will Not Dump on QA
QA Will Find Nothing
Test Automation
Automated Testing and User Interfaces
Testing the User Interface

Chapter 11. Courage #

We Cover for Each Other
Honest Estimates
You Must Say NO
Continuous Aggressive Learning
Mentoring

Part III: The Ethics #

The First Programmer
Seventy-Five Years
Nerds and Saviors
Role Models and Villains
We Rule the World
Catastrophes
The Oath

Chapter 12. Harm #

First, Do No Harm
Best Work
Repeatable Proof

Chapter 13. Integrity #

Small Cycles
Relentless Improvement
Maintain High Productivity

Chapter 14. Teamwork #

Work as a Team
Estimate Honestly and Fairly
Respect
Never Stop Learning

I found this chat in YouTube where Uncle Bob talks about most of the topics form his book Clean Craftsmanship.

Listen out for:
* Quote & Intro - [00:00:00]
* Career Journey - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programmer as a Profession - [00:15:31]
* Craftsmanship - [00:18:45]
* Disciplines - [00:22:45]
* Disciplines: Test-Driven Development - [00:28:49]
* Disciplines: Refactoring - [00:34:31]
* Code Coverage - [00:39:02]
* Standard: Never Ship S**t - [00:42:35]
* Standard: Always Be Ready - [00:47:15]
* Ethics: Do No Harm - [00:50:00]
* Ethics: Estimate Honestly - [00:53:56]
* 2 Tech Lead Wisdom - [00:57:50]

Update Your Team to Be More Extreme

2022-02-26T00:00:00+00:00

Our software profession is constantly evolving; it demands a non-stop learning process. We must embrace the change in our industry.

We need to create spaces to get out of our comfort zone, so our cognitive brain can train and improve how to adapt to our surroundings, which are constantly transforming.

Why code katas, tech talks or research Fridays? #

The goal is to help create an environment that aims for continuous improvement towards looking for learning everywhere, all the time, as the core attitude for the individuals and the group.

Create learnings opportunities #

Schedule some time every X weeks for practicing together.

At the end of each iteration, or even 2 or 4 weeks, we celebrate and work on katas in pairs/mob for 2 hours. That space is also an opportunity to create an internal tech-talk presentation to share exciting knowledge with the team non-directly-related to our “regular daily business”.

The goal is to get out of our comfort zone, improving our recognition for change in general while learning other subjects regularly.

What is a code kata? #

As a group, software developers don’t practice enough. Most of our learning takes place on the job, so most of our mistakes get made there as well.

The term “kata” comes from the repetitive movements done in karate that help you improve your fighting skills.

Code Katas exists to help developers get the same benefits as practicing in any other profession. There are simple, artificial exercises that let you experiment and learn without the pressure in a production environment.

There are no right or wrong answers in any software kata: the benefit comes from the process, not the result.

Motivation #

Work on refactoring techniques.
Work on TDD examples.
Work on SOLID principles.
Work on live coding sessions.
Work on driver-navigator concepts.
Work on team cohesion.
Have fun while learning and practicing together.

If you’re interested in my thoughts about TDD and katas, I wrote a post about it not long ago: Test-Driven Development.

What is a tech-talk? #

Tech talks allow us to share some knowledge related to our tech industry with our team members.

It can be any FrontEnd, BackEnd, DevOps related. But I encourage also:

a new programming language that you are learning,
a summary of one book that you finished,
a new technology that you are studying or feeling curious about,
a piece of software that you would like to share and present thoughts about it,
a new tool that helps you to improve your productivity,
really: anything related to creating value or knowledge.

How can I present a tech talk? #

I wrote this article with some tips about how to improve your tech-talk. Some key questions that might help you to find something on your own:

What have you learned recently (in the last X months)?
What knowledge might be interesting to be shared with your peers?
Which aspect of yourself you’d like to improve professionally and/or personally?

Just one rule: Be curious and “embrace the change.”

Research and learning Fridays #

Block the last Friday of the month for research and learning purposes. The whole team will have a dedicated space for growth and experiment.

It’s crucial to build trust with your team, so you all know everyone will use this time as good as possible. Don’t micromanage this time forcing keeping a record in a wikipage with what everyone does in detail.

Although, it would be nice that the team shares what they do during this time, mostly to create transparency among themselves. A verbal announcement to the peers the day before, with their intentions. Even the day after with the learnings key-takeaways.

Summary #

You can help your team to be more extreme by helping with a dedicated team space for growth and experimentation.

Provide flexibility to experiment with these ideas as they see fit.
It is an opportunity for self-growth and learning at the same time.
It is, ultimately, up to the person and the team.

Do not micromanage this dedicated time. Focus on the outcome. Help your team to grow, and they will enjoy growing with you.

Tech Talk #

After writing this blog post (originally in Feb, 2022), I was invited to do a tech talk in different conferences about this topic.

Extreme Programming Explained

2020-03-05T00:00:00+00:00

Definition #

Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.

Values #

The five values of XP are communication, simplicity, feedback, courage, and respect and are described in more detail below.

Communication #

Software development is inherently a team sport that relies on communication to transfer knowledge from one team member to everyone else on the team. XP stresses the importance of the appropriate kind of communication: face to face discussion with the aid of a white board or other drawing mechanism.

Simplicity #

Simplicity means “what is the simplest thing that will work?” The purpose of this is to avoid waste and do only absolutely necessary things such as keep the design of the system as simple as possible so that it is easier to maintain, support, and revise. Simplicity also means address only the requirements that you know about; don’t try to predict the future.

Feedback #

Through constant feedback about their previous efforts, teams can identify areas for improvement and revise their practices. Feedback also supports simple design. Your team builds something, gathers feedback on your design and implementation, and then adjust your product going forward.

Courage #

Kent Beck defined courage as “effective action in the face of fear”. This definition shows a preference for action based on other principles so that the results aren’t harmful to the team. You need courage…

to raise organizational issues that reduce your team’s effectiveness.
to stop doing something that doesn’t work and try something else.
to accept and act on feedback, even when it’s difficult to accept.

Respect #

The members of your team need to respect each other in order to communicate with each other, provide and accept feedback that honors your relationship, and to work together to identify simple designs and solutions.

Principles #

Humanity #

Human beings are the ones developing software. It is a fact. The book mentions 5 points that are needed for developers to become good: basic safety, accomplishment, belonging, growth, and intimacy.

The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together.

Economics #

Software costs. Someone or multiple people paid or invested in it.

Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximizes the value of the project.

The earlier software makes money, the sooner the development is valuable.

Mutual Benefit #

Mutual benefit in XP is about activities benefitting all concerned. This principle is about finding practices that benefit me now, me later, and the customers as well.

The book brings up 3 points how XP mutually deals with communication-with-the-future problems:

I write automated tests that help me design and implement better today. I leave these tests for future programmers to use as well. This practice benefits me now and maintainers down the road.
I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter it later.
I choose names from a coherent and explicit set of metaphors which speeds my development and makes the code clearer to new programmers.

Self-Similarity #

This principle is about copying the structure of one solution into a new context.

For example, the basic structure of development is that you write a failing test and then make it work. This structure operates at all different scales. Take into account, this principle is a good start, but it may not always work.

Improvement #

Do your best today but strive to do better tomorrow, strive to have a deeper understanding tomorrow. XP shines in this aspect, it is about always improving.

Put improvement to work by not waiting for perfection. Find a starting place, get started, and improve from there.

Diversity #

Teams need to bring in people from different backgrounds, with different experiences, attitudes, etc. In order for the team to have different ways of thinking and solving a problem.

The principle of diversity suggests that the programmers should work together on the problem and both opinions should be valued.

Reflection #

Good teams reflect after action, regularly. They think about why and how they are working.

Why did we succeed? What should we continue doing?
Why did we fail? What can we do better or differently?

Reflect and strive to improve. Even if everything seems perfect, know that there is always room for improvement and throw in the question:

Why do things seem perfect? What are we doing well? What can we do better in order to succeed even more?

Flow #

Flow in software development is delivering a steady flow of valuable software by engaging in all the activities of development simultaneously. Don’t deliver software in big portions. Deploy smaller increments of value more frequently.

Opportunity #

Learn to see problems as opportunities for learning and improving.

Part of being extreme is consciously choosing to transform each problem into an opportunity: an opportunity for personal growth, deepening relationships, and improved software.

Redundancy #

The difficult problems in software development should be solved in multiple ways.

The cost of the redundancy is more than paid for by the savings from not having a disaster.

Failure #

Sometimes it is extremely difficult to implement something, we don’t know which way or approach to take, try the ideas you have, even if they fail! Failure isn’t a waste, rather a learning experience.

Be aware of falling into the trap of discussing or thinking forever and not getting things done.

When you don’t know what to do though, risking failure can be the shortest, surest road to success.

Quality #

Projects don’t go faster by lowering the quality. Actually it’s often the other way around (if not always). It results in later and less predictable delivery, especially due to the amount of time spent on fixing bugs for example.

Pushing quality higher often results in faster delivery.

A concern for quality is no excuse for inaction. If you don’t know a clean way to do a job that has to be done, do it the best way you can. If you know a clean way but it would take too long, do the job as well as you have time for now. Resolve to finish doing it the clean way later.

Baby Steps #

Take baby steps. Making big changes in big steps is dangerous. People and teams can take many small steps so they appear to be moving forward rapidly.

Baby steps acknowledge that the overhead of small steps is much less than when a team wastefully recoils from aborted big changes.

Accepted Responsibility #

Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren’t.

Practices #

While it is possible to do these practices in isolation, many teams have found some practices reinforce the others and should be done in conjunction to fully eliminate the risks you often face in software development.

Sit Together #

Since communication is one of the five values of XP, have your team sit together in the same space without barriers to communication, such as cubicle walls.

Whole Team #

Include on the team people with all the skills and perspectives necessary for the project to succeed.

Informative Workspace #

Set up your team space to facilitate face to face communication, allow people to have some privacy when they need it, and make the work of the team transparent to each other and to interested parties outside the team.

Energized Work #

You are most effective at software development and all knowledge work when you are focused and free from distractions.

Pair Programming #

Pair Programming means all production software is developed by two people sitting at the same machine. The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. You effectively get a continuous code review and quicker response to nagging problems that may stop one person dead in their tracks.

Teams that have used pair programming have found that it improves quality and does not actually take twice as long because they are able to work through problems quicker, and they stay more focused on the task at hand, thereby creating less code to accomplish the same thing.

Pair programmers:

Keep each other on task.
Brainstorm refinements to the system.
Clarify ideas.
Take initiative when their partner is stuck, thus lowering frustration.
Hold each other accountable to the team’s practices.

Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.

Though, if you need privacy and time to work on an idea, go ahead and do it. We need both companionship and privacy. Make sure to rotate pairs frequently and take frequent breaks, pairing can be tiring, but surely is rewarding.

Stories #

Describe what the product should do in terms meaningful to customers and users. These stories are intended to be short descriptions of things users want to be able to do with the product that can be used for planning and serve as reminders for more detailed conversations when the team gets around to realizing that particular story.

Give the stories a short title and a description. Write them on cards and put them on a wall that is often being passed.

In XP stories are estimated extremely early, which gets the team thinking about how to get the largest return from the tiny investment.

Weekly Cycle #

The Weekly Cycle is synonymous to an iteration. In the case of XP, the team meets on the first day of the week to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team determines how they will approach those stories.

The intent behind the time boxed delivery period is to produce something to show to the customer for feedback.

Ten-Minute Build #

The goal with the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten minutes.

Continuous Integration #

Continuous Integration is a practice where code changes are immediately tested when they are added to a larger code base. The benefit of this practice is you can catch and fix integration issues sooner.

This practice requires some extra discipline and is highly dependent on Ten Minute Build and Test First Development.

Test-First Programming #

Write a failing automated test before changing any code.

The book mentions 4 problem Test-First Programming addresses at once:

Scope creep: It’s easy to get carried away programming and put in code “just in case.” By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding. If you really want to put that other code in, write another test after you’ve made this one work.
Coupling and cohesion: If it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.
Trust: It’s hard to trust the author of code that doesn’t work. By writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.
Rhythm: It’s easy to get lost for hours when you are coding. When programming test-first, it’s clearer what to do next: either write another test or make the broken test work. Soon this develops into a natural and efficient rhythm: test, code, refactor, test, code, refactor.

Incremental Design #

Invest in the design of the system every day.

You do a little bit of work up front to understand the proper breadth-wise perspective of the system design, and then dive into the details of a particular aspect of that design when you deliver specific features.

This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available.

Roles #

Although XP specifies particular practices for your team to follow, it doesn’t really establish specific roles for the people on your team.

Depending on which source you read, there is either no guidance, or there is a description of how roles typically found in more traditional projects behave on XP projects.

The Customer #

The Customer role is responsible for making all of the business decisions regarding the project including:

The XP Customer is assumed to be a single person, however experience has shown that one person cannot adequately provide all of the business related information about a project.

The Developer #

Because XP does not have much need for role definition, everyone on the team (with the exception of the customer and a couple of secondary roles listed below) is labeled a developer. Developers are responsible for realizing the stories identified by the Customer.

The Tracker #

The main purpose of this role is to keep track of relevant metrics that the team feels necessary to track their progress and to identify areas for improvement.

The Coach #

This is usually an outside consultant (or someone from elsewhere in your organization) who has used XP before and is included in your team to help mentor the other team members on the XP Practices and to help your team maintain your self-discipline.