Refuse single-used solutions

I can find a correlation between ecology rules and software development. The way we think and work, implements potential solutions for tough problems.

If we care about the environment, about people, we’d probably be more mindful at work. We’ll look for improvements and make our surrounding a better place.

Refuse (verb) – derived from Zero-waste philosophy – means to limit waste in your life – no matter if it’s about plastic waste or time waste in your project. By refusing unnecessary or harmful work – you can easily save time and came up with new brilliant ideas for development or testing.

@GrumpyCat

When an eco – freak goes to the super market – he looks not only for good quality of food, but also for non-plastic containers to reuse them for something else in the future. I think that  the same rule should be applied in development. Single – used solutions in the code, in testing, unnecessary work done as a shortcut to satisfy our customer’s demands are the things that often kick people’s back in the future.

Once, I had a chance to take part in the project, where a rush was a day-to-day routine. I don’t think this is an unique situation in an IT world 😀 Anyway, in that project, our Project Manager never said no to the customer. In addition, the customer started to be greedy, because he was allowed to act this way. He wanted constant changes, “improvements”, made phone calls to my team members in the evenings and during the weekends, knowing that we don’t support the product in those hours.

You’d say – their fault – they shouldn’t have allowed the customer to do so. Agree, but there are some people on this planet, who have more difficulties to say NO than I do 😉

We ended up with massive over-hours, frustrated team and the unhappy customer changing his mind twice a day.

He paid for our time, sure he did, but we paid for that effort as well – with people. My friends quit the job and we don’t remember this work as something that we could be proud of. The development was not easy, but constant pressure and rush made it even harder. As the team wanted proper solutions and the Project Manager always kept saying “We don’t have a budget for it”, we were in constant fight.

Developers were forced to skip unit testing and any other kind of testing, so you can imagine the results. Constant hot-fixes in production.

For me, a single-used solution would be not only a shortcut in the code, but also each piece of documentation, test session, power point presentation or any other work done, that has had consumed your time. Valid time, that could have been dedicated for testing and improving quality of the product.

Today I am a bit more experienced than I was during the project, I’ve mentioned, so probably I would fight a bit stronger for my standard. Sadly, back then, I was not able to win every battle.

What’s the conclusion?

When a manager comes to you and asks for doing development fast instead of proper – remember that this is nothing else but a technical debt –
a single-used solution that you don’t want to have.

Discuss, propose, think, but when you agree on a shortcut – for example skipping performance testing or postponing some exploratory sessions due to lack of time – be aware of the consequences in the future. You’ll save some time now, but you’ll be in the real trouble soon.

https://render.fineartamerica.com/images/rendered/medium/metal-print/images-medium-5/cat-in-trouble-sari-oneal.jpg

I would always think of my application as something precious and brilliant, not a piece of trash. You should do so as well.

That’s why, today, I refuse single-used solutions. That’s why I always tend to refuse tasks that I reckon as unnecessary or harmful to my project and time use. I believe that our job is always to assess and discuss possible actions with the team and a manager and making wise choices. That’s why we have the ability to talk 🙂

Our quality duty is not to accept blindly each job we receive to do. For me – refusing means taking responsibility for the project and overall success.

In case of any comments – write down below or stalk me on Twitter.

Why you should always record your demo sessions

@KingaTest

Some time ago I had a pleasure to work with two brilliant teams as a Product Owner. The entire company was working on one product, so every team and the entire business was about to achieve a common goal.

Our cooperation was great, despite the fact that most of our business was working in different time zones.

It was quite a painful fact, because, the “common” time for demo sessions was outside everybody’s working hours – too late for us in Poland and way too early for the business. Everybody in the team were eager to present their fantastic work once per sprint, but at the same time the time was an obstacle.

It helped us came across a great and simple solution for demo sessions – recording. The tool was not so important, but we’ve been using Zoom meetings, if you’re interested.

How did it work?

We met at a certain hour, convenient for the team and did a proper session. If anyone from the business side was determined enough to take part – he could. If no one attended – the recording was sent to everyone interested. After that – we’ve gathered questions and comments after the session and explained them during the next session or during regular chats if they were straight-forward. It felt at bit awkward at the beginning, but after a few sessions both – the team and the business got used to it and felt comfortable with the solution.

https://www.zastavki.com/pictures/originals/2015/Animals___Cats_Cat_playing_with_a_camera_097377_.jpg

Of course, I, as a Product Owner, have been meeting the business anyway, so I was able to act as a middleware, if necessary 🙂

Additional benefits

There is more in the story apart from just recordings for the business. We’ve also archived all our demo sessions in Confluence to enable everybody to have access to it. Business, other teams, management and we were able to watch our recordings and learn from it.

Guess what? it started to work not only as a tool for demo and archive but also as training material for other interested parties – customers, support team, developers and testers. It was also fantastic for the new team members, as a base of their knowledge about the project and the product. This is great because our initial frustration was transformed into a valuable tool.

Since then I recommend everybody to record their demo sessions as the artefact they can be proud of. It might be not only evidence of their hard sprint work but also very beneficial for the entire organisation and yourself in the future.

Do you have any good experiences with recording your demo sessions?