I invite you to join me in supporting an interesting initiative – a petition to the Pope to declare St. Maximilian Kolbe a patron saint for startupers and entrepreneurs. You may have heard of St. Maximilian death – he offered to die himself instead of another prisoner in the German concentration camp in Auschwitz during the 2nd World War – and you may be wondering what does a heroic Polish monk have to do with startups and entrepreneurship? This is exactly the question I asked myself when I first heard of this project. Then I read more about St. Maximilian and now I can hardly think of a better patron for us.

You see, before he died St. Maximilian lived for 47 years and boy, was he active during that time. Between 1918 (end of WW1 – and of his studies) and 1939 (start of WW2):

  • he founded a new convent in Niepokalan√≥w – starting with just few other monks, no funds and no house under his leadership it became the largest Catholic convent in Europe at the time with 700 monks housed in a number of buildings on a multi-acre site,
  • he started a newspaper (the main mass medium of his time was print media) again, starting from nothing it reached a circulation of 750k copies, along the way he started ten other publications and newspapers as well as built one of the most modern printing houses in pre-war Poland,
  • he got interested in radio pretty early and was thinking of creating a network of Catholic radio stations covering the whole country and broadcasting to the world, before the war broke out he was already well underway to realize this too having set up a radio station in Niepokalan√≥w (and – just BTW – he was already thinking of television as soon as technology becomes more available),
  • he was thinking beyond Poland – in 1931 he went to Japan – again, having almost no funds, not knowing Japanese and having just few brothers as companions he moved on to start a convent on the outskirts of Nagasaki that remains prominent in the Catholic church of Japan to this day, of course he also started a newspaper there which also continues to be published,
  • having started a mission in Japan as well as China and India he planned to build an airport in Niepokalanow and sent two monks to… pilot training as the first step in that direction (can you imagine a fleet of transport aircrafts piloted by monks crisscrossing the skies bringing supplies and passengers to missions in India, Africa etc? That was St. Maximilian’s vision.),
  • he was even thinking about… space travel – he described a concept for a space vehicle he called “Ethereoplane”.

That is quite a lot for just 20 years of activity – and those are just the highlights. On top of all that he managed to be a priest – he was saying Mass every day, heard confessions and wrote articles, homilies and other works. Considering all that he achieved way more than most entrepreneurs achieve in comparable time – save those most successful in the world. IfSt. Maximilian had not been called into priesthood I am sure he would have been one of the most successful businessmen of his era.

His life reveals entrepreneurial zest – a constant drive to start and build new things, new endeavors, new ventures – and scale them up, prefect them, bring them to full bloom. This is the essence of the entrepreneurial spirit. That makes him indeed an ideal patron for all of us who share it.

If I convinced you too please sign the petition and spread the word. Thank you!

The empiricism underpinning all agile methods means that people live in a constant inspect & adapt loop. It is primarily about the product being worked on – but it also applies to teams themselves. The idea is that with agile not only the product evolves and gets better, but also the teams – and thus people teams are made of. This is one of the claims as to why agile is inherently better than waterfall – it not only produces better products, but also better teams. Some agile methods recognize improvement in teams’ ability as an important part of the process and prescribe tools to foster it – for example a retrospective producing actionable improvements every sprint is a required part of Scrum.

This is all very nice & good, but the problem is that improvement is a slow, monotonous process. It is rarely achieved by doing something spectacular. It usually means adjusting work methods, coding styles, design habits and daily routines. Often those are small adjustments or they are achieved by a series of small steps through time. It means taking the actionable improvements seriously and honestly striving to implement them every day, every iteration (sprint to use the Scrum term).

Why is this a problem? Because there is little joy in this as the change happening every day or every week is so small it is imperceptible for those involved.

How can we solve it? By making the improvement visible – and by keeping the work itself fun and engaging.

One great tool is retrospectives – they should not be solely about hunting down problems, but also recognizing, even celebrating improvements that the team achieved. There is a strong tendency to be negative during retrospectives, to concentrate on what didn’t go well as opposed to recognizing what was right. A more balanced retrospective gives team a chance to realize how much they have improved since the last time.

Another idea for making improvement visible is encouraging both internal and external sharing of knowledge and work through talks and conferences. If you talk to peers about a craft you share you will frequently find that what is already part of daily work for you is a discovery for others. This is the moment when you realize how much you have improved. Organizing a monthly, internal “tech talk” or encouraging people to submit talks to conferences is a way to foster this.

In any case I think it is the Scrum Masters (or Agile Whatevers) role & responsibility to make improvement visible, at least from time to time. It also part of the responsibility of managers overseeing the overall development organization. And it all starts with recognizing that improvement is boring…

This problem is not exceptional to software development. It is exactly the same in other crafts/skills – path to mastery leads through small improvements.

In fact, it should be easier for software developers, because in their case the improving quite frequently means learning something new – and this rewarding in itself. Others have it harder, because in other activities improvement comes through repeating same things over and over again. Musicians play & play same tunes for hours to get better. Soccer players repeat same standard moves as part of their training.

What is common, however, is that a) it takes discipline and willpower to improve and b) from time to time the improvement made is made visible (a musician plays a concert, a soccer players plays a match).

Bob Marshall wrote on his popular blog, that retrospectives make no sense if they are not about a hypothesis – or in other words, if they are not about analyzing why things didn’t go as we envisioned. This was followed with others voicing their agreement (example). While I agree with Bob on many things this time I think he missed the point of retrospectives as such.

Retrospectives for me are not a part of the process of “manufacturing” software

  • per se
  • , as they are not related to the product (software). Their purpose is not testing some pre-formulated hypotheses about the process – their point is discovery leading to self improvement. This discovery is achieved by stepping aside from the process, stopping and taking a look back to reflect on what happened, then considering our present state as a team and finally looking into our future. And key focus here should be us as a group of people – humans – being (experiencing our existence) together: how we related to one another, how we related to those not on the team, how we felt about what we were doing and – lastly – how we were doing it. By discussing this as a group we also develop stronger bonds – retrospectives are an important part of the true team-building process (as opposed to silly, artificial “team building” trips and parties).

    Retrospectives – at least the way I treat them – are akin to group therapy sessions for teams. I’m not using this analogy lightly, I think some elements of retrospectives are therapeutic. That’s why I see value in them being led – at least from time to time – by outsiders (coaches). Paradoxically it is easier for groups to open up with the assistance of a stranger, who is not part of teams’ internal dynamics nor local politics.

    No matter who leads a retrospective any pre-formulated hypotheses or (worse) outcomes are an impediment to the discovery process. We should approach a retrospective totally open-minded, curious maybe as to what will surface this time.

    That is why we should retrospect regularly, using varied techniques to avoid routine and stagnation. Retrospecting only when there is a hypothesis to test (as a lady from Target Processes said they do) is, in my humble opinion, a suboptimal practice – it is loosing most of the value retrospectives can bring.

    What I suspected for a long time will happen just did: PMI has announced its agile certificate. This is a significant development for many reasons.

    First of all it officially confirms agile’s position amongst respected management methods – as part of the mainstream. I wrote about it at length recently, so I’ll just point out here that PMI’s move spells the end of the “agile revolution” in one sense. Just like the Linux revolution before it agile came with a promise of radically reshaping the workplace. It will in some places, but overall (and just like Linux) it will not completely eradicate its older alternatives, but rather become one of them – another respectable, mature tool for managing projects/teams.

    Next Page »