Tag Archives: Agile

Talk: Short Guide to your Agile Transformation

Talk: Short Guide to your Agile Transformation

About

This is a talk I delivered in Bucharest for the Agile Software Meetup Group. More and more companies want to transition to agile, because the benefits of faster delivery are essential in today’s software market.

Agile Transformation

Me and Mozaic Works’ approach to transforming an organization to agile has a lot to do with our core beliefs of small steps and fast feedback. For us an agile transformation is a tailored process for each organization, and the context is always essential.

Starting with the WHY is very important. I want to understand the internal values of the company and then decide together with the management, sponsors and the teams why they want to make this transformation. Without having the active involvement in any transformation, the whole process becomes very difficult or even impossible to put in place.

I don’t want to start from “what process to use” (Scrum, Kanban, DSDM, SAfE, etc), but rather discover the process while working with the people from that organization and understanding their needs. Together we create the process by applying things I know work well and by experimenting some things that might or might not work. As with any type of design, I prefer taking decisions as late as possible, because the more I learn the better the decision is.

Don’t commit unless you know why Chris Matts

 

Agile Transformation

Read More →

Talk: Behind Agile Practices (RO)

Talk: Behind Agile Practices (RO)

About

I gave this talk about Agile Practices at the Bucharest Agile Software Meetup Group, Agileworks. It’s in Romanian, because that’s what the audience wanted.

One by one I explain how some of the most common agile practices emerged. Also I explain when and why it’s a good idea to apply them. As seen in practice, some practices are just a hype, and they are very difficult to implement in an organization. Due to that you should always take into account the negative impact of introducing a new practice. Also be prepared for the consequences. There is no such thing as a perfect practice, you can always generate negative effects.

Agile started to become a hype because more and more companies are forced to deliver software faster. Because the markets are changing faster, the production and delivery speed is essential in this fast-paced world.

The last topic I am addressing is the apparent need or organizations to scale agile. There are multiple ways of scaling agile (horizontal, vertical, etc). Most of all we must ask ourselves if we really need to scale. Scaling agile too fast may generate counter-effects. Probably the worst effects are the decrease in productivity and minimizing the focus on the product value. Finally we can scale an organization and focus on the agile format, but not on its values.

Best Practices Read More →

Talk: Easier to change CODE

Talk: Easier to change CODE

This is a talk from I T.A.K.E. Unconference 2016, Bucharest.

It is a hands-on talk, where I refactor some code live with the help of the audience.

Techniques

During this talk you will see techniques that are useful for tackling legacy code issues. You will be able to see how, with the help of the audience, the code can be improved to become easier to change. We want to change existing code in just a few situations: solve bug, add feature, improve the testability of the system. Remember that when you change existing code you understand what is the reason to do this.

Before changing the code is important to have some tests as a safety net. For that I am using Characterization Tests. Only after having these characterization tests, we can start to refactor the code, but with care in order not to introduce defects. Even though we have a safety net, it is not enough and bugs might appear. So to make sure we have more trust in tests the first refactoring steps are made with the purpose to be able to add unit tests.

Adding unit tests gives me better quality feedback, because if I introduce a defect I will know better what I have done wrong. A characterization test is too big, and I might need to dig a while to find the reason.

Changing legacy code needs to be done with care, in small steps and try to always remain with the tests on green. The longer I stay on red, the riskier is that I introduce defects and I lose my refactoring direction.

Easier to change CODE means the total opposite of the Legacy Code is Fear concept. I have my toolbox with legacy code techniques. I know how to use them,  and so I am able to make the code to be easier to change.

Video

 

Call for Speakers I T.A.K.E. Unconference 2017

Call for Speakers I T.A.K.E. Unconference 2017

I T.A.K.E. Unconference

Code. Craft. Learn. Share. Repeat.

Software craftsmanship movement is raising the bar in tech industry. Are you also challenging the current practices, making experiments and trying new techniques?

Share your findings at the 5th edition of I T.A.K.E Unconference.

Call for Speakers is now open and waiting for practical, hands-on sessions, strong case studies, and personal experiences, delivered in an attractive manner.

Taking place in the tech rising city Bucharest, 11-12 May 2017, I T.A.K.E Unconference brings together 300 top-notch tech professionals, from 15 countries.

Simon Brown, James Lewis, Michael Feathers, Rebecca Wirfs-Brock, Tom Gilb, and Sandro Mancuso contributed to the previous editions as keynotes.

If joining, expect to meet software crafters, architects, DevOps, technical leaders and managers, startup CEOs, and CTOs.

Submit your proposal(s) here by December 5th!

Talk: Java User Group Łódź – Legacy Code is Fear

Talk: Legacy Code is Fear (Łódź, Poland)

Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk.

This is a talk from last year, before Global Day of Coderetreat Lodz.

You are a programmer. Someone from the company comes with an idea to add a feature and they are sure this new feature is very easy to add. And it should be. But the code is old. The code is a mess. Nobody in the firm knows any more that part of the system. You need to change that ugly piece of code. You are afraid that you might introduce defects. Legacy code is fear.

This talk is about how our unknowns make us feel frightened. We need to get passed that and learn techniques, practice them, understand how and when to use them. Only with more knowledge we will be able to tackle legacy code. But how do we acquire knowledge? We need to read, try, experiment, fail, and many more with some learning code base. Then we need do the same with production code. My advice is to never try these legacy code techniques on your legacy code base at work. You will be disappointed in the beginning because they will be difficult to apply. That is why it is important to start small, with an easier to understand code base in order to learn. And only after you can refactor that simpler code base, it is the time to start using the legacy code techniques on the bigger code base from work.

 

Here are the slides for the talk:

Software Lost Video: Vasco Duarte – #NoEstimates

Vasco Duarte talks about #NoEstimates. This video is from the Agile Croatia Conference in  2014. You will find out how to use the concepts of #NoEstimates, how to work on software projects without using too much time on requirements engineering, and especially on estimations.

 

 

 

Talk: Wildcard Conference 2013 – Sherlock Holmes and Pairing

Even Sherlock Holmes was pairing. Are you? Let’s find some good practices in the talk below about Sherlock Holmes and Pairing!

During my work I am used to pair with my colleagues on basically anything. I do pair-programming when I develop software, we use pairing when we deliver trainings or when we write articles. I often do remote pair-programming with strangers. The most things I learned during the last years were by working in pair with someone I barely knew.
Pairing for me has the following main advantages:
– I learn a lot from my pair
– I extend my comfort zone and I collaborate better with anyone
– the product we work together is a lot better because four eyes are better than two

Please find examples from the activities of the well-known fictional character Sherlock Holmes on how his pair Dr. Watson helps him become better and finding the answer to their riddles.

 

 
And here are the slides for the talk Sherlock Holmes and Pairing

Software Lost Video: Olaf Lewitz – Increase Trust in your Organization

This video was recorded at Agile Lean Europe (ALE) Unconference 2014 in Krakow.

Olaf talks about how we could increase trust in our organizations by considering that the people we work with are adults. Another topic is de-scaling organizations, so that the people have a happy working place where they can take decisions and further more, they are invited to take decisions.

 

Read More →

Software Lost Video: James Shore – Rigorous, Professional Javascript

James Shore is one of the promoters of TDD in Javascript. He is presenting codecasts on his website Let’s Code Javascript about how to work effectively in Javascript.

As James says:

“JavaScript Needs Test-Driven Development

If you’ve programmed in JavaScript, you know that it’s an… interesting… language. Don’t get me wrong: I love JavaScript. I love its first-class functions, the intensive VM competition among browser makers, and how it makes the web come alive. It definitely has its good parts.

It also has some not-so-good parts. Whether it’s browser DOMs, automatic semicolon insertion, or an object model with a split personality, everyone’s had some part of JavaScript bite them in the butt at some point. That’s why using test-driven development is so important.”

Rigorous, Professional Javascript

Read More →

Talk: Agile Lean Europe 2014 – Being a Community Bumble-Bee

During the last five years or so I have been travelling Europe and meeting a lot of people in local communities of practice. My main purpose is to teach the local groups and to learn from them. My purpose was and is to pollinate ideas from one community to the other. If more of us do this, our knowledge will grow richer and faster.

The main visible activity of the Agile Lean Europe community is the ALE Unconference that moves each year from city to city. But there are a lot of less visible activities, people meet each other and learn across the country or language borders.

During this talk I want to share my learnings with you about local communities and how rich those experiences can be.

 

Here are the slides for Being a Community Bumble-Bee

Acknowledgements

Many thanks to Thomas Sundberg for proofreading this post.