Upcoming talks: 4developers and ACE! Conference

Next week I am presenting at two conferences: the 8th edition of 4developers (Warsaw) and the 7th annual ACE! conference (Kraków).

Together with Mariusz Sieraczkiewicz we will talk on “How To Transform Good Teams Into Awesome Ones”. We will share our experience from Agile transformations we worked on recently, including success and failure stories. Join us to learn the model we use and the steps we make while working with the teams.


ace-2016See you in Warsaw or Kraków.


PS I will publish the slides after the conferences.


Staying On Track – Video From AgileByExample 2014

There’s no point in driving faster in the wrong direction.


That’s why staying focused on what really matters during the whole the software development process is crucial. Which means  killing features that no one is going to use, shortening discussions and brining them back on track, and helping teams with difficult decisions (“Should we refactor this piece?”, “Should we allow deleting users?”, “What to work on next?” ) – I must admit I really enjoy this process 🙂

I gave a talk on this topic during the last AgileByExample 2014 conference. Here you’ll find the video:

and the presentation slides:


Kanban Beyond Taskboard and WIP Limits: Map, Measure and Improve your Flow

I was recently asked “What is more in Kanban than a Taskboard and WIP limits”? Actually, there is a couple of tools that may help your Team become even more effective:

Discover Your Real Developement Process

Your Kanban board doesn’t have to be as simple as this:

It may look like that:

It all starts with a process of Value Stream Mapping, which later helps you craft a Kanban board corresponding to your process. Discovering a real development process is an insightful exercise itself – it helps the Team realise it’s more than “Pick a task, code and hand over to QA” 🙂

Measure, Chart and Improve Your Flow Efficiency

Cumulative Flow Diagram helps you look at your flow from the brid’s-eye view. As you can see here it’s a single chart that brings quite a lot of information:

Source: http://paulklipp.com/images/Interpreting_a_Cumulative_Flow_Diagram.jpg

That’s why when it comes to measuring and analysing average Lead and Cycle Times I prefer to look at the Control Chart that graphs these numbers for each task, like this one:

Source: http://www.targetprocess.com/kanban/
Source: http://www.targetprocess.com/kanban/

It might be interesting to analyse which tasks (and why) took significantly longer time to complete than usual.

Flow Efficiency

Another interesting measure in Kanban systems is Flow Efficiency, which is basically:

Let’s say you start working on a feature on Tuesday morning and finish it a week later. Usually, what happens meanwhile during this week is a number of activities not adding value to this feature like:

  • waiting – e.g. waiting for graphics design, translation or QA
  • multitasking – working on other items.

If the actual time spent on this particular feature by the whole team is 2 days, then the flow efficiency for this feature is 2 days (work time) / 7 days (time passed) = 28.5%.

Other Tools and Measures

These are just few examples of tools and measures related to Kanban. I haven’t mentioned Classes of Service that help you handle urgent and fixed date issues as well as Cycle Time Distribution analysis that helps you define Kanban Service Level Agreement.

What do you find useful in Kanban beyond a simple Taskboard and WIP Limits?

Upcoming Public Trainings – “Effective Distributed Teams” and “Kanban in One Day”

I am pleased to join forces with Michał Bartyzel and Mariusz Sieraczkiewicz from BNS IT in delivering high-quality trainings for IT professionals.

This December you can register for one of our public trainings (in Polish) for a discounted price, including some of my workshops:

Full schedule. Feel free to contact me if you are interested.

Goodbye SoftwareMill. Time For New Challenges

Five years ago, together with my friends Tomek Szymański, Adam Warski and Jan Zborowski, I founded SoftwareMill.

SoftwareMill is a unique company – 26 awesome team members, all of them working remotely, flat structure with no managers and full financial transparency. I’m really proud of it.

That made the decision to leave an extremely hard one, but I feel it’s now time for me to look for new challenges. I have decided to leave SoftwareMill for two main reasons:

1) More face-to-face interactions

Over the last years my focus has moved from programming to organisation and leading and coaching people. In short – more talking to people, less talking to computers 🙂 I really enjoy it, but it’s much harder to do remotely, which is why I want to go outside my home office.

I’ve been really enjoying  working remotely for a long time. It has a number of benefits and I’d love to keep them. But since I’ve discovered how much joy face to face conversations bring to my life I want to have more of them.

2) New challenges for my personal development

SoftwareMill is doing great. There are, of course, things to improve here and there, but staying there would be staying in my comfort zone. 

To say I’ve learned a lot at SoftwareMill is an understatement. I’ve learned something from everyone who I worked with. I’d like to say a huge thank you for all the time we spent together, all the conversations and ideas we had. You guys are AWESOME. I am keeping my fingers crossed for your efforts in making SoftwareMill the best place to work for IT workers.

What’s next?

I am taking a short break for a while, but I am open to proposals for collaboration – short or long-term.

My passion is helping teams and individuals to discover and focus on what really matters for them. I enjoy working with teams and on the business side of IT. And in all of this, I aim to make myself dispensable by encouraging self-organisation. 

I have experience and a lot of passion to work in two areas of software development:

1) Building effective, self-organising, motivated teams

either as an Agile coach, trainer, facilitator

or as a servant leader a.k.a. Scrum Master

2) Bridging the gap between business and IT (and users)

as a Product Owner, Product Manager, User Experience specialist or all of them at once 🙂

So… if you think we could do something awesome together or just want to talk, ping me via e-mail, Skype (pawel.wrzeszcz.work), LinkedIn or Twitter.

Visibility Shift In Distributed Teams

“Distributed agile is hard” is what I often hear. And yes, after working remotely in various distributed teams for 8 years, I agree. But I am going to argue that this is a good thing.

Basically I believe that working in a distributed environment is like using Scrum – it does not solve your problems, but makes them more visible. I like to call this a “visibility shift”.

Visibility Shift In Distributed Teams
(photo by slackpics)

With the challenges being more visible, a distributed team can actually make it easier to adapt an agile approach to software development. Especially if it is a team where everyone works remotely (see “Remote Worker, Distributed Team”).

Value vs. presence

Working remotely makes it harder to verify whether someone is at work all the time or not. You cannot look around you and see other people sitting in front of their computers or having discussions.

And this is good. Because without this notion of presence, something else becomes more visible: the actual value delivered. Because at the end of the day what counts is not the fact that we have been to work, but the new feature or a fixed bug.

(Just to be clear: I am not saying that value delivered is not visible in the co-located environment. But in the distributed setup it is one of the very few visible signs that someone was at work. Which is great because this is what agile is all about – focusing on value.)

Communication challenges

If your team suffers from poor communication or endless meetings, working remotely will make this even more conspicuous.

It is really hard to stay awake during a long teleconference meeting. And this is good. Because it shows how useless meetings are in general. And by working remotely you will have less of them, in favor of more asynchronous communication.

Trust issues

Another thing that becomes painfully visible in the distributed setup is lack of trust.

I heard this statement from a manager on why distributed teams are hard for him: “Sometimes I have to go in person to make sure they are doing what they are supposed to”. Others are worried about their employees browsing Facebook instead of working. These are all signs that the level of trust in the team is low. And yeah… such a team would have a really hard time working in a distributed model, because the trust issue would be even more visible.

All in all

So yes, distributed teams do face challenges. But they face them because things that matter, like value delivered, communication and trust issues, are more visible to them. Which is good, because making an issue visible is the first step for improvement.

(originally published at SoftwareMill’s blog)

ALE 2013: Brain Dump After Mind Blown

Agile Lean EuropeHey, Agile Lean Europe 2013 Unconference was fabulous.

I have learned about a number of absolutely amazing things there. Here is just a couple of them:

Real Options – on distinguishing options from commitments and enabling options with more trust.

During the workshop I also experienced how Check In Core Protocol works and I really liked it.

Thank you Steve Holyer and Michael Leber!

#NoEstimates – Focus on what matters instead of useless estimates. Great to hear that there is now science and community behind that.

Thanks Vasco Duarte!

Agile Pricing – Consider models like Pay Per Feature, cause neither Fixed Price nor Time&Materials are good billing approaches (e.g. T&M does not encourage productivity).

Thanks Kurt Häusler!

I got a number of insights on making code reviews fun, which I hope to use while working on Codebrag:

I really liked the experience report from Barry O’Reilly and Kate Logan, especially the way they replaced User Stories with Hypotheses:

2013-08-30 10.35.23

Finally, a photo from Keynote by Jurgen Appelo with a slide on why learning works best with experiments:

Photo by Sebastian Nachtigall

Oh, and a comic book to read this autumn is “Commitment” (on Real Options).

I do have more insights, but I would not finish this post at all if I carry on 😉

Many thanks to ALE 2013 organisers for making this awesome event happen!


No Backlog Policy

I hate Product Backlogs’ unrestrained tendency to grow, get messy and unmaintainable.

Photo: Grant Hutchinson on Flickr

How Backlog Was Supposed To Work

Ideally, a Product Backlog should give the whole team a clear roadmap on work to be done.

I remember times when I actually believed this is really possible, even with a huge Backlog, but in practice in every project I worked on I struggled with keeping the Backlog up-to-date, prioritised and consistent.

Then, thanks to Roman Pichler (see Top Ten Product Backlog Tips for example) I understood that the Product Backlog requires a lot of care (well, the same way like codebase does). This includes:

  • Finding right wording for user stories
  • Writing acceptance criteria for stories
  • Managing stories on various level of detail, decomposing them when necessary
  • Removing(!) no longer valid entries from the list
  • Rewriting other ones
  • Getting stories estimated
  • Prioritising
  • and that is probably not the end of the list.

All of this done regularly!

Woow, that is a lot of work!


In practice, most of Product Owners or people responsible for Product Backlog (including myself) do not perform most of these tasks regulary, because the only really important horizons (at least in agile/lean approach) are:

  1. This iteration/week
  2. Upcoming release or other important date, usually within a couple of weeks from now

This means that what actually matters is on the top of the Backlog. All other stories are… well… you can either say “less important at the moment” or, I believe more correctly, “waste”.

No… Well, Maybe

I am a huge fan of “Start With No” approach.

Photo: Nathan Gibbs on Flickr

Hovewer, over and over again I observe the following scenario:

Customer: Hey, could we have feature X in our product?

Development Team: Well… it all depends on your priorities.

Customer: Yeah, this X is really important.

Development Team: OK, in our Backlog next things to work on are Y and Z. Should we do X before?

Customer: Ah, no! Y and Z are crucial too. Hm… Maybe we could implement X immediately after Y and Z?

Development Team: Yeah, sounds like a plan. Although we will still have several important things to do after Z for the upcoming release, so we will have to see how X fits.


Development Team: OK, let’s put X to the Backlog and we will see.

And you know what? Quite often this X stays in the Backlog forever.

This is what I call saying “Maybe”, instead of “No”. Backlog is a safe option to close such a conversation, but unfortunatelly later on no one dares to remove anything from there, so lower part of Product Backlog becomes Idea Trash.

Possible solution

Here is what I suggest:

  • Keep very small, focused “Backlog” (better name “This week” or “This release”)
  • Put a hard limit on number stories in it. In other words, limit WIP, where story in the backlog is also considered as “in progress”
  • Anytime you are tempted to break the limit, remove less important stories from the Backlog
  • Most importantly: Have a clear working agreement that removing an item from the Backlog does not mean rejecting to do it at all. You can add such a story later when it becomes important enough.

I am using such an approach on my Personal Kanban board and I would love to give it a try in a project. Actually, this post is triggered by our hassles with managing Backlog in Codebrag and by writing my thoughts down I hope to convince my teammates to give it a try 😉 [update: We have tried it in Codebrag and it works very well]

The idea behind this is making an issue of “There is always more to be done than our capacity” more (frequently) visible. I believe that having a clear backlog helps having clear mind and making better decisions.

The argument against this approach I hear mostly is that something important or innovative might be forgotten if not written down. I disagree. If a user story really “loves” me, it will come back. Otherwise it is not worth my effort.