Piotr Nowinski

Software Engineering Manager, Agile Coach, PMP, PSM, SPS

About

Hi, I’m Piotr and I’m a host of this independent blog where I share stuff that I deal with in my professional life. It’s mainly about software development management and team management, though it wanders into other areas at times.

I live in Gliwice, Poland with my wife and daughter, and I consider myself a reasonable experienced software engineering manager with a particular interest in Agile and cultivating strong, self-organizing teams.

More about me

Latest stories

Definition of Ready

Most (if not all) Scrum teams have a more or less formal Definition of Done (DoD) that dictates when a given user story can be considered as completed (done) and ready for shipment. At the same time, only a few Agile teams have a Definition of Ready (DoR) which, if used smartly, can also give the team a lot of benefits and prevent them from wasting their precious time. To be fully transparent I...

To estimate or not to estimate [bugs]?

At some point in time, many Agile teams struggle with how to handle bugs and/or maintenance tasks they are faced with. And the core of this problem is whether bugs should be estimated or not. As always, each approach has its pros and cons, but based on my experience I reckon that estimating bugs is not worth the hassle. Let me explain why. Bug is a waste The main goal of every Agile team is to...

Innovation is easy, isn’t it?

Early this year Harvard Business Review published an interesting article about innovative organizations by Gary P. Pisano. Most organizations perceive innovative culture as a key to their future competitive advantage and therefore something leaders want to establish and invest in. Also, employees value innovative organizations and consider them as a great place to work for. Moreover, it seems...

Too many meetings

One of the most common complaints you may hear about Scrum is that it introduces too many meetings. Let’s have a closer look at this problem. Summary of Scrum meetings Scrum framework defines several meetings that are designed to address 3 pillars of every implementation of empirical process control: transparency, inspection, and adaptation. All Scrum meetings are time-boxed and for a 2...

Confessions of a Change Agent (by Henrik Kniberg)

Recently I’ve come across a presentation “Confessions of a Change Agent” done by Henrik Kniberg at Agile Rock Conference 2018. Highly recommended for everyone who is or wants to be an internal or external consultant helping organizations to improve (well, change). The main points: Attitude not a roleChange is easy if people want itInspire > ChangeSlow down to speed upPlant...

Stack Overflow Developer Survey Results 2019

Few weeks ago Stack Overflow presented the results of their annual Developer Survey. I recommend having a look into that as there are lot of interesting insights in there. Link to the results: Technologies Top 10 of most popular technologies (programming / markup / scripting languages) are: Top 10 of most wanted technologies are: And Python is the fastest-growing major language today. Challenges...

Benefits of using Scrum [over waterfall]

Agile is probably the best approach when it comes to developing complex IT solutions. It’s widely used in product development, but unfortunately, it’s still not that straightforward when you’re working for external clients. The problem is that in far too many situations it’s the corporate purchasing department that awards the seller with a contract, and fixed-scope, fixed...

Tracking progress of the release

Having a potentially shippable product every sprint lies in a heart of Agile, but in many organisations – especially the ones that don’t work in SaaS model – a product is not released to the market every sprint. Sometimes frequent delivery is not possible (i.e. in case some additional tasks like a translation of a documentation, legal approval, etc. have to be done at the end of the...

Splitting large features into smaller stories – Elephant Carpaccio

Many teams transitioning to Agile struggle with delivering a potentially shippable product every sprint. Producing a piece of software that provides a business value to a client every 2 weeks seems impossible. Usually, teams say that they can deliver either front-end, or backend, or architecture design for a given feature, but not all these together. It’s a common problem for many teams...