Goodbye SoftwareMill. Time For New Challenges

Posted September 10, 2014 by pawelwrzeszcz
Categories: Agile, Why, Working Remotely

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

Posted November 22, 2013 by pawelwrzeszcz
Categories: Agile, Why, Working Remotely

“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

Posted September 3, 2013 by pawelwrzeszcz
Categories: Agile, Conferences

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!

-Paweł

No Backlog Policy

Posted July 3, 2013 by pawelwrzeszcz
Categories: Agile, Scrum, Why

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

Backlog

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, prioritized 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!

Reality

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.

NO

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.

(silence…)

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.

-Paweł

Two Highly Recommended TEDxWarsaw 2013 Talks

Posted June 4, 2013 by pawelwrzeszcz
Categories: Conferences, Video

One in English

What We Don’t Know: Jonathan MacDonald

And one in Polish

Reforma dla Polski: Cezary Wójcik

Both of them changed my way of thinking (and a perspective from which I think:)) about myself and the world around. I hope you enjoy them as much as I do.

-Paweł

Decoding Conference Presentation Titles For Busy Developers

Posted May 21, 2013 by pawelwrzeszcz
Categories: Conferences, Fun

Have you ever hesitated which session to attend on a multi-track conference?

Here is a short guide that should help you quickly figure out what to expect on a presentation, just judging from the title ;)

Foo Bar and Beyond (or The Future of Foo Bar)

Expect lots of history of Foo bar, slides with a timeline, and a little or no statements about the future. But at least, you will leave the room assured that “Foo bar is moving forward”.

What Is New in Foo Bar 2.0

Agenda:
1. Old Foo bar API sucked
2. We wanted to change it and had a lots of discussions
3. Early preview of new API, with multiple protective statements from the stage that what you see is not yet approved and subject to change (but really cool, indeed)
4. Release date unknown

Live coding session

You will learn how to change font size in an IDE.

In general, the session will assure you that it is still impossible to create an application in half an hour and your work still makes sense.

Foo Bar Anti-patterns

Even though this will be sad presentation, people will laugh every time new anti-pattern is presented.

Unfortunatelly, some of the anti-patterns will be close to your heart. At least hopefully you will learn some cool names for them.

Discussion Panel

Invited speakers will be answering each others questions, hardly ever looking at the audience.

Advanced Foo Bar

Special type of a discussion panel (see above) held in Chinese. The presenter will be either debating with himself or with a small group of Foo bar fans.

Is Foo Bar Dead?

Agenda:
1. Foo bar’s initial success
2. But… there are several issues with it
3. So… is it dead?
4. Real part of the presentation
5. Conclusion: Foo bar is not dead – we just have to care more!

Foo Driven Development

This talk will go beyond TDD practices, which for sure you are doing, but… “TDD is not enough”. There are other xDD’s and you should follow all of them, especially FDD, which provides you yet one more layer of safety (and one more test case to re-write for every small change).

Foo Bar For Busy Developers

Probably a simple tutorial, cause the presenter is a busy person too and had little time to prepare. The title is adjusted in order to attract more people (who is not busy these days?).

If you are really busy, do the tutorial from the website instead.

Other

If a talk does not fall under any of these categories, I do encourage you to identify a new pattern and comment on this post :).

Also, beware that if it is hard to figure out what will be the content, the talk might be a sponsored presentation :evil:.

Enjoy your next conference!
-Paweł

PS Thanks to Michał Ostruszka for the blog post title suggestion.

High-altitude Projects

Posted April 10, 2013 by pawelwrzeszcz
Categories: Agile, Mountain guide

Altitude sickness has taught me two important insights about speed and trends, which can be applied to software development projects (and probably many other areas as well).

IMG_5637

Photo: Krystyna Kupiszewska

Altitude sickness

After trekking above approximately 3,000 meters one has to take care not to climb too fast. The general rule is not to ascend more than 300 meters daily to acclimatise.

If your organism does not adapt to the height you reached, several symptoms appear (headache, fatigue, stomach illness, dizziness, and sleep disturbance).

This once happened to me in Nepal. The symptoms usually disappear within couple of hours. However, in some cases they may be getting worse, especially if you climbed significantly more than 300 meters within a day.

Altitude sicknes is quite a simple illness. If a patient is feeling worse and worse the end is always the same – death :( The only reliable treatment is to descend.

Speed limit

The first general thing I have learnt from altitude sicknes is existence of hard limit on velocity. Attempting to get above this limit is asking for trouble.

This applies to projects and speed of development as well. I like to keep that in mind when planning software development releases. Usually there is hardly anything we can to quickly achieve higher output (I am not talking about long-term improvements here) and the only reasonable option is cutting down on requirements.

Trends

Moreover, the way altitude sickness develops and comes away shows that it is all about the trends.

For instance, a percentage of code coverage in your project is relevant, but it is more important whether it is increasing or falling. The same applies to more general matters like quality, moods, financial situation and so on.

If we are on the wrong side of the trend, doing nothing and just waiting for better time to come will not help, exactly like in the case of sickness getting worse and worse.

All in all, I find those lessons on velocity limit and trends very useful – much often than in the high mountains.

-Paweł

I used information about altitude sickness from wikipedia and altitude.org

This post is a part of short series “What a ScrumMaster Can Learn From a Mountain Guide”. I previously wrote about preparing breakfast and getting up from breaks.


Follow

Get every new post delivered to your Inbox.

Join 311 other followers