Chemaclass - agile

Ship, Show, Ask

2025-04-12T00:00:00+00:00

In fast-moving teams, one of the biggest tensions we face is this: How do we keep shipping without compromising quality or collaboration?

The traditional approach to pull requests often slows things down. We wait hours, or days, for approvals, even for trivial changes. But the alternative, merging directly, can feel reckless or invisible to the rest of the team.

That’s where the Ship-Show-Ask strategy comes in. Originally described by Rouan Wilsenach, this model offers a more flexible and thoughtful way to handle code changes. It’s not just a branching strategy, it’s a shift in how teams collaborate, trust, and take ownership.

What is Ship, Show, Ask? #

It’s a model that classifies changes based on how much review they require:

Ship: Merge directly to main (without a PR)
Show: Open a pull request, but merge it immediately
Ask: Open a pull request and wait for review

The key idea is to use Ask as the default for most work, fall back to Show when the context makes it safe, and avoid Ship (or reserve it for extremely trivial cases, if used at all).

Why I prefer to Ask and Show #

Treat every change, even the small ones, as something worth sharing. I always create a branch and open a PR. It provides visibility, builds a shared history, and creates a space for optional or asynchronous feedback. It’s working with the garage door open, applied to code.

But not all PRs need to follow the same review process.

I default to Ask #

I prefer to wait for a peer review when:

The change involves risky or complex logic
It could impact other developers or teams
It introduces architectural or structural decisions that haven’t been agreed on yet
It benefits from shared input or a second pair of eyes

That said, Ask doesn’t mean over-engineering the process. Often, one thoughtful reviewer is enough, especially if they’re familiar with the domain. If the change touches a specific area, I’ll ask for feedback from the person who owns (or best understands) that part of the code. It doesn’t need to involve everyone.

In small teams, requiring two approvals on every PR can quickly become a bottleneck and slow down the delivery of value. The goal is alignment and quality, not ceremony for its own sake.

I use Show for safe, low-impact changes #

I might merge immediately when:

Practicing pair programming (the review already happened live)
Fixing typos or broken links
Updating documentation or changelogs
Refactoring within a module I own
Adding tests for existing behavior
Making non-functional tweaks (formatting, logs, comments)
Applying UI or style adjustments with no logic change

The key principle: Show is optional, never mandatory. I choose Show only if the change is low-risk and fits within team expectations. When I use Show, I own the outcome. The responsibility is mine.

Why this approach works for me #

This model helps me:

Ship faster without compromising quality
Work with greater autonomy and ownership
Avoid bottlenecks, especially in small or async teams
Foster a mindset of trust, accountability, and thoughtful decision-making

It shifts the goal from getting approval to sharing intent and owning the outcome.

What makes a good “Show”? #

A Show PR might be the right choice when:

The change is trivial and within my area of responsibility
No one is available to review, and waiting would block progress
The PR includes clear context and reasoning
I’m open to post-merge feedback
I’m ready to follow up with adjustments if needed

Tips for making it work #

Some practical advice from experience:

Clarify team expectations for when to use Show vs Ask
Always provide context in your PR, even if merging immediately
Write tests for any new logic or behavior
Welcome post-merge feedback, review doesn’t stop at merge
Reflect regularly as a team and adjust the approach as needed

Ship, Show, Ask is more than branching hygiene. It builds a culture of clarity, accountability, and trust, where developers move fast while staying thoughtful.

If you’re tired of slow PR queues and over-engineered approvals, try it on your next change. Want to dive deeper? Read Rouan Wilsenach’s original post.

Match the review to the risk. Own what you merge.

What Is Waterfall?

2024-08-01T00:00:00+00:00

Waterfall is like following a straight path where you move from one step to the next in a defined order, like water flowing down a waterfall through different stages.

The problem is that each step can take a lot of time and resources to complete. Plus, you don’t get feedback until the entire stage is finished, which can lead to a lot of wasted time. This is especially tricky in software development, where things are always changing and evolving.

It usually follows a straightforward sequence like this:

The reality of Waterfall #

Waterfall can be like communism in theory, it seems perfect on paper but doesn’t work in the real world.

Clients often don’t know exactly what they want.
Requirements are constantly changing.
Businesses need to quickly adapt to market shifts and client needs.
Software needs to be flexible to keep up with these changes.

So, in a constantly changing world, Waterfall can really hurt a business. It tends to frustrate developers and teams, and it can also annoy clients and the businesses paying for the software. This usually leads to delays and extra costs.

Why companies still use Waterfall #

Even with its problems, a lot of companies still use Waterfall because it seems straightforward and logical. This makes them reluctant to take the time to learn Agile. Plus, getting management to agree to switch to Agile can be a tough sell, especially since it requires an investment in time and learning.

The big issue is when higher-ups dictate exactly how teams should work, leading to micromanagement. This messes up the flexibility that Agile brings. From what I’ve seen, this is a common problem.

Looking back, switching to Agile could have fixed a lot of issues.

Why Agile was created #

Agile was created to overcome the limits of the Waterfall method. It focuses on constant interaction with clients and teams.

Agile builds autonomous and responsible teams that handle tasks from start to finish, reducing wasted time and resources. It emphasizes flexibility, collaboration, and customer feedback.

Unlike Waterfall, Agile uses iterative development, breaking projects into small, manageable sprints or iterations that last 1-4 weeks. Each cycle includes planning, development, testing, and review, aiming to deliver value quickly and gather feedback to improve.

Key aspects of Agile #

Iterative Development: Work in small chunks and adjust as you go.
Customer Collaboration: Keep talking with clients to make sure they’re happy.
Cross-Functional Teams: Teams with different skills working together.
Adaptive Planning: Stay flexible and tweak plans based on feedback.
Continuous Improvement: Always look for ways to get better.

Read the original Agile Manifesto.

Where can you start? #

As a developer, you can boost your agility by diving into pair programming and TDD.

With pair programming, two developers work side by side, which means you get instant feedback and shared problem-solving, leading to better code.
TDD, on the other hand, involves writing tests before the code, which help specifying what you want to do, focusing on baby steps.

Together, these practices make your development process more flexible, collaborative, and high-quality, fitting right in with Agile’s focus on quick adjustments and continuous improvement. See more practices here.

The key is collaboration, baby steps, and quick feedback on everything you work on.

My experience with Agile #

I’ve talked about Agile at various tech events and explored it in depth because I’m passionate about how it can supercharge software teams. When done right, Agile can completely change how teams work, making them faster, more efficient, and better at delivering what clients and businesses really need.

2022-06-26 | International PHP Conference [Berlin, Germany] (EN)
2022-09-16 | Code Talks [Hamburg, Germany] (EN)
2022-10-26 | International PHP Conference [Munich, Germany] (EN)
2022-12-21 | IES Ginés Pérez Chirinos [Murcia, Spain] (ES)
2023-01-19 | devm.io [Remote] (EN)
2023-07-28 | WeAreDeveloper World Congress [Berlin, Germany] (EN)

WeAreDevelopers World Congress in Berlin #

The Phoenix Project

2024-05-31T00:00:00+00:00

This is a story about an impossible project in which the people around are constantly playing politics, busy fixing critical bugs and wasting constant efforts on quick patches instead of helping the business thrive.

If IT fails, the business fails.

DevOps Principles: Flow, Feedback, and Continual Learning and Experimentation. These guiding concepts promote advancements in responsiveness, dependability, and teamwork.

Summary #

The book starts with the promotion of Bill as VP of IT, and with that the responsibility of delivering an imposible (Phoenix) project. The CEO warns him that if the project does not deliver in time, then the entire IT department will be outsourced and the current IT employees will be fired.

Bill tries to understand the status quo, and finds out that the people are too busy firefighting constantly and dealing with too many responsibilities (in addition, they are understaffed). Everything is urgent and needs to be done asap. The deadline was already setup from above, and there is no planning or discussions with other departments. TL;DR: Corporate chaos, politics and bloodbath meetings.

However, Bill gets to know one person in the company that helps him improve the status quo, not by telling him what to do but by asking him questions to help find the solution.

For example, the first question: “What are the four types of work that IT does?” which is not answered immediately but during the story:

Business projects: these are the projects that directly affect business goals. They generate revenue and deliver value to customers.
Internal projects: these are regular tasks that keep the system working. Like system upgrades, security patches, etc. It tends to be invisible and can become a bottleneck for IT departments.
Changes: the result of the previous business and internal projects, to know what to change with and within them.
Unplanned work: this is the real productivity killer. This is related to all operational issues resulted from the previous three types of work.

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.

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.

The Lean Startup

2024-01-26T00:00:00+00:00

Most startups fail. But many of those failures are preventable. The Lean Startup is a new approach being adopted across the globe, changing the way companies are built and new products are launched.

Eric Ries defines a startup as an organization dedicated to creating something new under conditions of extreme uncertainty. This is just as true for one person in a garage or a group of seasoned professionals in a Fortune 500 boardroom. What they have in common is a mission to penetrate that fog of uncertainty to discover a successful path to a sustainable business.

Key Takeaways #

Test frequently and learn quickly
Observe and measure real customer behaviour
Focus exclusively on capturing actionable Metrics
Be comfortable pivoting based on key learnings
Embrace new accounting methods
Learn what is not working and apply changes immediately: stay lean

Summary #

Agile Project Management

2023-05-31T00:00:00+00:00

A basic and straightforward overview of what Agile is, presenting some framework examples that are well known today, such as Scrum or Kanban, everything condensed in a 100’s pages book that you can read in a couple of hours.

Chapters #

The fluid manifesto
Being agile
Agile process
Planning for success
Agile communication
Scrum basics
Introduction to Kanban
Building an adaptive team
Leadership and collaborative management
Common errors behind agile failure
Final words: agile is adaptation

“The benefits of Agile projects extend no only to the team using it, but also to the customer receiving the final product.”

“There is an underlying critical metric that consistently leads to the success of an Agile project: communication. Miscommunication, under-communication, or poor communication of any type leads to the collapse and failure of said project.”

Key takeaways #

Projects that followed a Waterfall methodology tended to exceed their expenses over time, while the product delivered was below standard and difficult to use.

That situation originated that a group of developers signed a brief, 68-word manifesto in 2001.

A brief background #

During the 1960s, software got into a big crisis; creating software was complex but changing it later became pure chaos. Waterfall to the rescue.

Waterfall outlined a simple, logical set of processes that a company would need to follow for a project to be successful. Its name comes from the metaphor of water gently cascading down a predictable, steady, incremental stream. Its life cycle of software development would be in six simple steps.

Requirements
Analysis
Design
Code
Testing
Operations

For 10 years, Waterfall was the standard methodology in the software universe. And for 10 more years, chaos persisted. Although the intention was good, the reality is that the ever-changing set of constraints does not cope very well with this methodology because each step is dependent on the previous one.

86% of the time a company uses the Waterfall method for project management, the customer receives inadequate or useless software. A lot of software projects were unused or never finished.

During the 70’ and 80’, Iterations and Incremental Development (IID) proved to be a viable option. In the 90’ surges an Evolutionary Delivery (ED), which changes the situation. The developer is responsible for listening to the user’s reactions early and often. The user starts playing a direct role in the development process.

A few years later, a new method surged Rapid Iterative Production Prototyping (RIPP), later called Rapid Application Development (RAD), which they claimed “Working software in 90 days… or your money back.”

Lastly, during the 90’ Extreme Programming (XP), Scrum, and Crystal were defined in detail.

These distinct yet similar solutions were decentralized, working independently of one another. This realization led to that night in Utag the unification of these ideas under one banner, in one document.

Agile became the definitive standard for software development.

The Agile Manifesto #

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the rights, we value the items on the left more.

Dedicated QA Teams in Software?

2023-05-17T00:00:00+00:00

This will be controversial, but let’s talk about the QA position. The hidden truth behind the lack of software quality and why this should concern you if you write software.

QA is a role, not a position #

As a software developer, when you write software, you are responsible for the quality of whatever you’re writing. A third person acting like QA could find that your solution doesn’t work like expected, but how come? You might argue they might catch edge cases, but how could that be possible if the software was already tested previously?

A software team’s final goal is to make the QA position useless because they should find nothing but well-working software. But how do you get to that point? How can we ensure that the software we write is working as expected and there is no need for a QA person in our team?

The hidden truth behind the lack of software quality #

Unfortunately, in our software industry, the demand for “fast, quick and dirty” projects ended up in poorly developed MVPs by simply applying patches and code over code with just manual testing checking happy paths, sometimes even ignoring edge cases.

“The deadline is in one week, so you better finish it on time!”

We don’t learn the importance of what automated testing can bring to our daily job, so we don’t take it seriously, and therefore, we don’t practice it enough. And, for that exact reason, because we don’t practice it, we don’t know how to perform it properly. Yes, I am talking about writing automated tests that prove the behavior of your software!

Our inability to write testable code results in software that is hard to test, and thus we delegate testing to other third parties shifting the responsibility for the overall end quality of the product or service we write.

Practice makes the master #

You must learn and apply proper testing techniques when they make sense. How and when effectively use test doubles, prepare solitary or sociable tests, which compromises and reasons backup your mind when choosing one or other paths toward your testing strategies?

You are the latest and main responsible person in charge of your knowledge, so you better invest in yourself because no one else will do it for you.

Look at everything you do as an opportunity for learning. Practice and get better by default at everything you do.

If you don’t know how to start, here is my favourite tip: you can always practice and improve your testing skills using code-katas. Read more about this topic here.

Nice theory, but… why bother? #

Manual testing is, of course, necessary. It is another testing strategy that I am not blaming or attacking. We might still need a dedicated person in charge of discovering what new features we want to build to satisfy our clients. But this blog-post is not about that position.

It is all about shortening the feedback loop. If you can write software to work in specific ways, can’t you write automated tests to prove that the software you wrote behaves the way you expect?

If you have covered with automated tests the behavior of your software at any level that makes sense, what’s left for a dedicated QA person?

Next time you think about “We need a QA person to test this,” try the exercise of thinking instead, “How can I write an automated test that verifies what I would expect if a QA person were checking this?”

And that’s how you change the “full-time QA position” into a “role mentality for everyone that writes software.”

Code never lies and never forgets; once it’s written and automated in your pipeline, you can run it anytime at zero cost.

Accelerate

2023-03-19T00:00:00+00:00

Accelerate explores how software development teams using Lean Software and DevOps can measure their performance and the performance of software engineering teams impacts the overall performance of an organization.

Note: DevOps is about integrating and automating software development (Dev) and IT operations (Ops), focusing on improving (and shortening) the systems development life cycle.

Key Capabilities #

Continuous Delivery #

Use Version Control for all Production Artifacts
Automate Your Deployment Process
Implement Continuous Integration
Use Trunk-Based Development Methods
Implement Test Automation
Continuous Delivery (CD)

Architecture #

Use a Loosely Coupled Architecture

Product and Process #

Gather and Implement Customer Feedback
Make the Flow of Work Visible through the Value Stream
Work in Small Batches
Foster and Enable Team Experimentation

Lean Management and Monitoring #

Have a Lightweight Change Approval Processes
Monitor across Application and Infrastructure to Inform Business Decisions
Check System Health Proactively
Improve Processes and Manage Work with WIP (Work-In-Process) Limits
Visualize Work to Monitor Quality and Communicate throughout the Team

Cultural #

Support a Generative Culture
Encourage and Support Learning
Support and Facilitate Collaboration among Teams
Provide Resources and Tools that Make Work Meaningful
Support or Embody Transformational Leadership

Four Key Metrics #

Change Lead Time
- Time to implement, test, and deliver code for a feature
Deployment Frequency
- Number of deployments in a given duration of time
Change Failure Rate
- Percentage of failed changes over all changes (regardless of success)
Mean Time to Recovery
- Time it takes to restore service after production failure

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.

Ignoring Scrum to Get More Agile?

2022-12-06T00:00:00+00:00

Talking to a friend about agile, he asked me a fascinating question remarking how badly sometimes Agile and Scrum fit together, especially regarding meetings. These are my thoughts about this topic.

“Do you think it would make sense to just use agile and ignore scrum (sprints) completely in a product based development company. I feel it’s hard to be agile when you have 10 hours of meetings per week.” Filip G.

That is related to the essence core of Extreme Programming, which is the first value: Effective Communication.

“Probably some companies just don’t know how to properly use meetings and just have them out of habit.” Filip G.

I wouldn’t say completely ignore Scrum. Scrum (when done well) is a great “Product Management” Framework. To improve your understanding of Scrum I recommend reading: Scrum: The Art of Doing Twice the Work in Half the Time.

The main issue with scrum nowadays is that management took control over the whole thing, and developers are not really educated about how to practice Scrum properly (in a real Agile way), and that’s where the problem starts. For this, I recommend a book that addresses pretty well the common issues that most Scrum teams face in a fun and easy-reading book Zombie Scrum Survival Guide: A Journey to Recovery.

It’s not about Agile yes, and Scrum no. They are totally compatible. The issue is to create awareness about how to focus the team processes from an agile point of view.

Agile in a nutshell #

I recently wrote a blog post about agile fundamentals, which I recommend you to read to get into the details: Working agile with non-agile teams. But, the tl;dr: Agile is about quick feedback. It’s about effective communication and reducing waste while aiming for simplicity.

Agile is about keeping these values always present:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

While there is value in the items on the right, we value the items on the left more.

Scrum in a nutshell #

Scrum is a framework for project management emphasizing software development, although it is used in other fields like sales, marketing, and more. It’s designed for teams of 5 to 9 people (see Dunbar number) who are totally autonomous and responsible for breaking down their work into small chunks that can be completed in a time-boxed iteration, called sprints, usually 1, 2, or 4 weeks.

It’s common to find certain ceremonies/meetings like:

Stand-up: 15 min (or less) to keep everyone in the team sync and updated about the work and call out for action when anyone is blocked or needs special attention or help.
Refinement: 2h? meeting to make sure the tickets are in a good shape before planning them to be worked on in the next sprint.
Planning: 2h? meeting to plan the work to be done in the next sprint.
Demo/Review: 2h? meeting to show the work done for the whole team, stakeholders and other interested people.
Retrospective: 2h? meeting intended to enable the team to reflect and improve.

The critical question is how your team organizes these meetings and, most important of all, how effective these are. These above are just some of the important meetings you have in any “Scrum Team” nowadays.

Still, apart from those, you might encounter a lot of additional meetings that pile up, and suddenly your entire working day is gone, and you feel you didn’t produce the value you expected. Unless your job is being in meetings every time, like coordinating projects and talking to people all the time, it seems something is wrong.

Boring meetings #

Have you ever been in any of those meetings and thought, “This is boring, what a waste of time…”. Well, I’ve experienced that more than once. Who’s to blame? That would be the very first question that could come to your mind. Followed by, “My boss, obviously, because he/she organized that meeting, to which I got invited, therefore I am forced to attend, and this wasting time is their fault.”

This is a tricky question, and I don’t think it is an honest answer. However, there is an easy explanation for this answer: pushing away responsibilities and blaming others rather than yourself is way easier.

“I am forced to attend, and this wasting time is their fault” it could be that that’s actually the actual fact. You were really forced, and you’re wasting your time, and there is no other way… but is there no way to act on it, really?

When something doesn’t work the way I expect (e.g., I don’t like the outcome, or I think something is off), before blaming and pushing away responsibilities to others, I want to reflect on it and identify the root of the issue. What could I do to make the situation better?

What can you do about it? #

Coming back to this context of “many meetings”, if you see yourself in a meeting again that feels off or boring, try asking yourself:

Am I feeling bored? Why so? Is it possible that I am not participating in the desired outcome of the meeting? And if so, is my presence here in this meeting really necessary? Could I simply ask for a summary afterward and jump outside the meeting to do something more productive?

Contrarily, is it OK to feel bored in this meeting? Or should I participate and engage with my peers to contribute to the outcome of the meeting?

In these situations, I encounter a pattern such as:

If the meeting is not boring, it is productive and will produce a rich outcome for you and, hopefully, all participants.
If the meeting is boring, then either A) it is OK to be boring, politely ask to leave, and you will get the summary afterward, or B) it is not OK to be boring. Your participation is necessary for the outcome of the meeting. Try being more engaging with your peers, and the meeting won’t be boring.

In the end, there are a lot of strategies, and it’s up to you to act on them whenever you see something that could be improved.

It’s OK to point out the “elephant in the room” and ask for help to improve any situation you think (or feel) is not working as it should.

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.

Continuous Discovery Habits

2022-08-21T00:00:00+00:00

This book explores how product managers and designers can keep making a positive impact on their customers’ lives. It explores an optimal decision-making process for product teams, so that they can continue to improve their offerings.

Part 1: What is continuous discovery? #

The What and Why of Continuous Discovery
A Common Framework for Continuous Discovery

Part 2: The continuous discovery habits #

Focusing on Outcomes Over Outputs
Visualizing What You Know
Continuous Interviewing
Mapping the Opportunity Space
Prioritizing Opportunities, Not Solutions
Supercharged Ideation
Identifying Hidden Assumptions
Testing Assumptions, Not Ideas
Measuring Impact
Managing the Cycles
Show Your Work

Part 3: Developing your continuous discovery habits #

Start Small, and Iterate
What’s Next?

Focusing on outcomes over outputs will help you create the right products for your customers.

The What & Why of Continuous Discovery #

The Project Management Triangle

2022-07-25T00:00:00+00:00

A triangle of time, quality and cost. It’s an indicator that these three parameters are interconnected. You can fix one or two of them, but not three.

The triple constraint #

Cheap and fast: the quality will suffer.
Cheap and good: it will take more time.
Fast and good: it will push the price up.

Waterfall vs Agile #

In software methodologies, you can adapt this idea by changing quality to scope:

Waterfall #

In waterfall projects, the scope is fixed, while the time and money will be more variable. Depending if it’s more important finishing on time or on budget.

Agile #

On the other hand, in an agile environment we usually work on a few weeks’ iterations, so this is the fix part: the time, in order to deliver value as soon as possible, and so get feedback and recalibrate again and again.

The costs in a software team are also fixed by the people that belong to it.

Time is fixed, cost is fixed, so by the rule of the iron triangle, the scope must be variable.

An agile team cannot predict the scope of their work in one-year project, however, they don’t need to. Their focus should be on deliver constantly value as much as possible, or at least at the end of every iteration, reflecting their learnings and recalibrating their priorities again and again.

As you can see, one funny fact is that the waterfall and agile share an inverted triangle with their fixed and variables parameters. Really interesting indeed.

Reference #

Modern Software Engineering

2022-06-29T00:00:00+00:00

This book presents software development as an engineering practice at every level. To master software engineering, we must become experts at learning and managing complexity.

Optimize for learning #

To optimize for learning, the book presents five behaviors to consider:

Working iteratively
Feedback
Incrementalism
Empiricism
Being Experimental

The main idea is to work on small steps, collect feedback, and adjust.

Optimize for managing complexity #

The book presents other five ideas to manage complexity:

Modularity
Cohesion
Separation of Concerns
Information Hiding and Abstraction
Managing Coupling

We need to manage the complexity of our systems.

Tools to support engineering in software #

Going deeper into some ideas that were already discussed in the book, like:

Testability
Deployability
Controlling the variables
Continuous Delivery

A great video explaining the core ideas behind this book by his author:

Team Topologies

2022-03-31T00:00:00+00:00

Team Topologies focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions, and achieve fast and safe software delivery.

Team structure #

High cohesion: Group related things together.
Loose coupling: There must be clear boundaries between the teams.
Cognitive load: It’s like the RAM of the team. The team can burn down if you load with more than the team can handle.

In order to avoid bottleneck teams, you need to make sure their cognitive load is not very high.

Conway’s Law #

The organization structure will influence the architecture of the team.
Conway’s Law says that organizations will design systems that copy their communication structure.
In other words, there will be no focus on the optimal architecture for the project.
First you need to define the architecture of the project, and then form the teams.

Team-First Thinking #

Who is in the team matters less than the team dynamics.
When measuring performance, teams matter more than individuals.
Team = group of 5-9 who work towards a shared goals as a unit.
- Check Dunbar number.
Forming a team takes from 2 weeks to 3 months.
Cognitive load is the total amount of mental effort being used in the working memory.
3 Types of cognitive load:
- Intrinsic: Fundamentals of the problem space. Example: programming language.
- Extraneous: Environment related. Example: how to deploy.
- Germane: Special attention is required. Example: business domain.
Heuristics:
- 3 types of domain: Simple, complicated, complex.
- If the domain is too big, split it into subdomains.
- One team, either:
  - 2-3 simple domains.
  - 1 complex domain.
  - Avoid 2 complicated domains, better split the team.
Define a Team API:
- Code: endpoints, libraries, clients, …
- Versioning.
- Documentation.
- Practices and principles.
- Communication tools.

Team Topologies #

Instead of structuring teams according to know-how or activities, organize teams according to business domain areas.

Success of topology depends both on team members and surrounding environment, teams and interactions.
Split responsibilities to breakdown silos.
Types of dependencies: Knowledge, task, and resource.
Four types of teams:
- Stream-aligned: deliver features, projects, products to the market asap.
- Enabling: grow the capabilities for the Stream-aligned team(s).
- Complicated-subsystem: reduce the cognitive load of the Stream-aligned team(s).
- Platform: make the Stream-aligned team(s) autonomous.

Team Interactions #

Collaboration. Work closely between teams with different skill sets.
X-as-a-Service. Clear ownership, small cognitive load.
Facilitation. Helping to clear impediments, focus on quality interactions between other teams.

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.

Red Work vs Blue Work

2021-10-21T00:00:00+00:00

“Blue Work” and “Red Work” are concepts that David Marquet describes in his book Leadership is Language. Both require different mindsets and have different languages.

“Doing” in our traditional leadership style will not take us to where we need to be in the future.

What is “Red Work”? #

Red Work is about doing and reducing variability. Red Work focuses on a proving mindset and a performance mindset.

In Red Work, you seek to complete a task without a lot of need for deciding what or how. Red Work is being in control and taking control. Such as:

Process work and avoid errors.
Having predictability and controllability.

We need a mechanism to stop Red Work and ask: are we doing the right thing?

What is “Blue Work”? #

Blue Work is about deciding, thinking, planning. Blue Work focuses on improving with an embarrassing mindset.

The correct place to do Blue Work is at the beginning and at the end of a decision point.

Blue Work is crucial for a good starting point, allowing us to decide the best way to do something with the information that we have right now.

It’s also important to establish short iterations between the different actions or activities that we want to complete, so we can have some “Blue Work time” and reflect again. Blue Work is perfect to do retrospectives and see what could be improved.

It’s the time to stop and “control the clock”, collaborate and make a commitment for the next iteration. Blue Work is also about:

Thinking work.
Decision-making.
Looking to achieve excellence.
Getting more people to do independent thinking answers.
Embracing variability and looking for different inputs.

Blue Work in isolation is useless. The job of Blue Work is to make Red Work better. Endless Blue Work, planning without outcome doesn’t bring any real benefits.

Nowadays, especially in our modern software industry, there is no room for the old school of “Red-Workers” and “Blue-Workers”, but “Red Work” and “Blue Work”, and everyone should be involved in both.

It is, therefore, everyone’s responsibility to be aware of these different types of work and find a good balance between them. Leaders involve everyone in both Red Work and Blue Work.

References #

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

Let’s talk about the benefits of Pull Requests and Pair Programming, and my thoughts on these after some years of experience with them.

Pull Requests #

A Pull Request (PR) is basically a way of showing your suggested code changes such that they are easily comparable with the existing source code. This is part of a workflow that helps developers to share knowledge about the changes that are being done within the system.

A Pull Request is the moment where you ask your peers to review and check out your code changes.

Usually, it’s also used:

For discussions about code style.
To spot potential bugs.
For architectural or design discussions once the solution is done.

Pull Requests aren’t the best tool for everything #

The main problem with these topics above is that PR’s are usually ready when the feature/bug is already being worked on and in the last stage of its development process. It [a PR] is an “already changed proposal [I have already worked on this change, here’s the code] to be merged into the current system [someone please look it over]”.

The concept of “Draft PR” exists to make explicit that a PR is not ready to be merged, so it’s still a “work in progress thing”, but that’s another topic.

Pull Requests are, indeed, one of the best tools that we have in our industry to share knowledge about the changes that we are doing in the system, but sometimes they might be misused, as for example:

Discussions about code style. Code style shouldn’t be discussed in a PR. There should be already a CI running a code style checker, that’s all. If you want to talk about code style, request a change in your code style checker, but not in a random PR.
Spot bugs. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic.
Architectural or design discussions. Once a particular solution is developed and ready for review, it is usually really hard to “rollback” that idea and rewrite it again. Because “why would you do that? For some subjective opinion? It’s done already. And it seems to work just fine.”

Having an extra person looking at the changes that we have done for “designing decisions” might be beneficial, but we could have addressed “potential disagreements” in a sooner stage.

What should the purpose of a Pull Request be? #

Sharing knowledge about the proposed changes with the team.
Ensuring the team aligns and agrees across the multiples changes that are getting submitted every day in order to keep a healthy direction for the project. Yes, this might include double-checking the outcome design, but… What if that is now too late? How could we solve all those issues?

Pair Programming #

The concept of “Pair Programming” can be understood from different points of view. Pair thinking and pair programming, driver-navigator roles concepts, or pure live coding from one side. Actually, this is way easier than it looks like at first instance:

Either you watch and help the other person to write code,
Or you type while getting another pair of eyes watching and helping you.

Pair Programming helps the team to work together.

Pair programming is the joy of working with an extra brain and another pair of eyes, where the key is to build a context where you two share the same goal in order to find the best possible solution. All of this while learning from each other every single second. Pair Programming is not about developing the best solution at the very beginning. It’s about making it work, sharing ideas, and finding a better solution together. After that, you can refactor and clean the code.

Pair Programming is a continuous code review #

Pull Requests are an asynchronous way to share code changes, while Pair Programming is totally synchronous because it happens at the same time.

That said, Pull Requests and Pair Programming aren’t mutually exclusive, they can coexist. They are tools, and we should wisely choose them in order to achieve our objectives.

The most common fear that I saw while encouraging to do Pair Programming is that some people are shy and they don’t like to have other eyes around them while they are coding because of:

Fear that they don’t know what to code or where to start.
Fear that others will laugh at their solutions.
Fear to not succeed in public.
Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge.
Fear to change your mind in front of others.
Fear to discuss and make decisions loud.
Fear of disagreeing with others.

After several years of experience on this topic #

The pattern which rejects Pair Programing is basically “fear”, and being out of your comfort zone. And this is due to the misunderstanding of the roots of the actual Pair Programming concept.

Pair Programming is not “to show off in front of your colleagues” or “to be screwed by your peers”, but to be transparent (showing your skills as they really are) and improve as a team lifting up each other.

Programming is an iterative process that needs a continuous refactoring of our way of thinking in order to achieve better solutions, day by day. Therefore, programming with another person next to you (with a different way of thinking) will help the team to get the best from each other while discarding the waste or bad habits if necessary.

Pair Programming doesn’t need to be always set for everything. As a tool, it’s flexible, and we can choose how, when and for what reason.

A personal rule of thumb, before starting tasks that might involve touching multiple modules or complex business rules, think about a quick Pair Thinking/Programming with another more experienced colleague in that field.

Everything depends on a particular context and people: the developers, the pairs, the tasks, the mood.

Still uncomfortable with Pair Programming? #

If you still feel uncomfortable having another person next to you while you write code, it might be because you aren’t particularly happy with your own code, or the process that you follow in order to achieve some result. My favorite way to work on this is by exercising on your own and working on improving your skills as a software developer.

Create and play around with your own pet projects.
Work on code katas on your own and with others.

Practice makes the master.

Keep pull requests, add pair programming #

Don’t get me wrong, Pull Requests are great. Keep doing them.
Team collaboration is essential. Pair Programming aims for this.
Pair Programming encourages the team to proactively work together.
Don’t be afraid of coding while having eyes around you. Ask questions when something is unclear. Ask for help when you don’t know how to solve something.

It’s totally ok not knowing everything. The most important thing is to know how to work together.

Zombie Scrum Survival Guide

2021-03-01T00:00:00+00:00

I really enjoy the ideas and experiments presented in the book. It points out a lot of “big elephants in many rooms” for a lot of teams claiming to do Scrum or Agile in a really questionable way, aka: Zombie Scrum.

Summary #

Zombie Scrum Survival Guide reveals why Scrum runs aground and shows how to supercharge your Scrum outcomes, while having a lot more fun along the way. Humorous, visual, and extremely relatable, it offers practical approaches, exercises, and tools for escaping Zombie Scrum. Even if you’re surrounded by skeptics, this book will be the antidote to help you build more of what users need, ship faster, improve more continuously, interact more successfully in any team, and feel a lot better about what you’re doing. Suddenly, one day soon, you’ll remember: that’s why we adopted Scrum in the first place!

Learn how Zombie Scrum infects you, why it spreads, and how to inoculate yourself.
Get closer to your stakeholders, and wake up to their understanding of value.
Discover why Zombie teams can’t learn, and what to do about it.
Clear away the specific obstacles to real continuous improvement.
Make self-managed teams real so people can behave like humans, not Zombies.

This is a nice webinar, when they offer a fresh perspective on Zombie Scrum, share key insights from the book, and discuss their latest findings on the relentless ongoing research.

Agile Product Management with Scrum

2021-02-22T00:00:00+00:00

Coverage includes #

Understanding the product owner’s role
Envisioning the product
Grooming the product backlog
Planning the release
Collaborating in sprint meetings
Transitioning into product ownership

Scrum

2020-06-10T00:00:00+00:00

Every organisation, whatever its size, constantly has to come to grips with delivering a product or service on time and on budget. Scrum shows you how. It explains how to define precisely what it is that you are seeking to achieve, how to set up the team to achieve it, and how to monitor progress until the project is successfully completed.

Clean Agile

2020-03-12T00:00:00+00:00

Clean Agile comes from Uncle Bob, one of the founding fathers of Agile, one of the seventeen people who authored the Agile Manifesto back in 2001.

This talk is about Agile. What it was, what it is, and what it will be. This is a back-to-basics talk that covers the history of Agile, what motivated it, and what has happened to it since. The talk covers the basic practices of Agile, and compares and contrasts those practices with the current menagerie of Agile processes.

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.

What is XP? (in 2 min) #

Tech Talk by kent Beck: XP 20 years later #

Sprint

2016-09-01T00:00:00+00:00

“Sprint offers a transformative formula for testing ideas that works whether you’re at a startup or a large organization. Within five days, you’ll move from idea to prototype to decision, saving you and your team countless hours and countless dollars. A must read for entrepreneurs of all stripes.” - Eric Ries, author of The Lean Startup

From three partners at Google Ventures, a unique five-day process for solving tough problems, proven at more than a hundred companies.