Choosing a webinar platform

by

In July I decided to start using webinars to interact with the users of our Scrum tool – the Banana Scrum. I also started to use webinars to broadcast seminars of the Polish Scrum Group.
Obviously, I needed a webinar solution to do this. Choosing which one of the many webinar/web meeting platforms available to use turned out to be quite a process. I share it here to help others who may have similar needs.

My requirements were pretty simple (or so I thought):

  • good for both demos (showing how to click around Banana Scrum) and presentations with traditional narrated slides (for the Scrum group),
  • easy to use for both presenter and participants,
  • recordings of good quality, preferably editable with standard tools, for subsequent posting on the pages,
  • event management (registration form, sending people e-mails with calendar attachments, links etc.),
  • cheap.

All in all I’ve looked at following platforms:
– Cisco’s WebEx,
– DimDim,
– Microsoft’s LiveMeeting,
– Cytrix’s GoToWebinar.com,
– Adobe Connect Pro.
(more…)

Great video about motivation

by

I just found a great video about motivation that explains why self-organization works better.

I think this neatly shows why the very term “human resources” which implies treating humans just like any other machine in a company’s inventory is not only unethical and repugnant, but also simply wrong.

To release or not to release?

by

A question I frequently see asked on the Internet is whether agile teams should release every iteration (or even more frequently) or not. When asked in relation to Scrum the question is usually if software should be released every sprint. With other methods – like now-popular Kanban – the question is what release frequency would be right, as the method itself doesn’t say anything about it.
I think that many times this question reveals an underlying confusion between keeping software releasable and actually releasing it to the public. I think one construct from Scrum can help clarify things here.

Scrum calls explicitly for a “shippable product increment” to be delivered at the end of each sprint. It means that the end of each&every sprint a new version of the software must be ready that passes the quality criteria (in Scrum expressed as the “definition of done“) and ideally includes all the features the team committed to delivering at the sprint’s outset. However, this new version is called “shippable” not “shipped” for a reason. This reason is that whether to release a new version of software to the users is ultimately a business decision.

This distinction is very important. Just like the shape of the backlog is a result of a whole series of business decisions made by the Product Owner the decision to go with the product to the public is a decision that can be (and quite frequently is) made by stakeholders. As such it is definitely out of the scope of any process/method managing the development itself or the team doing the development.

There are of course numerous benefits from actually releasing each and every “shippable product increment“: greater user satisfaction, faster user feedback, better discipline in the team and less risk (deploying smaller changes is less risky than deploying a big-bang, all-changing release). In fact this is what we have been always practicing, also when working on our Scrum tool.

However it has to be understood that situations (companies, products, etc.) vary and can be very different. Sometimes there are other factors involved – for example domain (in embedded software releasing every sprint may not be even possible), market influence (eg. developing a major feature and not wanting to let on before it is complete) or alignment with other elements (like when software is part of a larger project, where other things have to be in place for the new features to be used or usable).

So, a team can be agile even if what they develop is not released every iteration. They just have to work as if it was in terms of quality and effort spent testing the software to ensure that it could be deployed when needed.

Sprint retrospective vs. Sprint review

by

Someone has asked if management or project management should come to the sprint retrospective 1. Think the way this question was asked indicated that there was some confusion regarding sprint retrospectives versus sprint reviews which, I think, is worth clearing.
Sprint retrospective and Sprint review are two different things that shouldn’t be confused.

Sprint review is for everyone involved, especially stakeholders, to inspect where the project is and discuss how to adapt as needed. Sprint review revolves around what was built – the “shippable product increment” produced in the last sprint – and the overall product, not how it was produced.

It is good if Product Owner “represents” stakeholders, but it is even better if they come and see themselves what was accomplished, what runs etc. My advice is to welcome management of all kinds if they want to come to a sprint review, just being sure they know what the purpose of the meeting and their role in it is. Ensuring that and educating them is primarily Product Owner’s job, but of course the Scrum Master may assist him.

Sprint retrospective is primarily for the team to inspect their last sprint, concentrating less on what was done than on how it was done, and then adapt their way of work. I wouldn’t include anyone outside the team in those, besides maybe the Product Owner if he/she wants to join.

A common objection to bringing management of any kind into retrospective is that team may not be comfortable talking about their dirty laundry in front of them. It is indeed very valid – but it is also worth noting that from managements’ prospective this would be a waste of their time to, for example, listen to developers debating how to improve branching in their code repository. Even if the management knew what the heck the team is talking about this is not something they should waste their time on. Managers have lots of things to do (collectively called “bigger picture”) which no one will do for them – this is where their time will be better spent.

Having said that an overall retrospective on the project or on a longer chunk of it (like a quarter or half a year) that would include management may make sense, but it would not necessarily include all team members (if you have many teams that would make it even impossible to do). Such a retrospective would concentrate on “big picture” and could be very beneficial – if there is of course a right atmosphere within company for people to be honest enough in such a retrospective for results to be useful.

Speaking of retrospectives – definitely worth buying is “Agile Retrospectives” Esther Derby and Diana Larsen. There is not much to read there – just a couple of introductory chapters – but it is a great cookbook of various techniques to use in different phases of a retrospective based on how much time you have and what is the retrospective about. Each technique has a description of how much time to set aside for it, how to facilitate it and where its place is the overall sequence of a retrospective.

Great help, since classic “what we did well? what we didn’t do well?” etc. becomes boring pretty quickly. Anyone who facilitates retrospectives on a regular basis should have this book.

[1]original question.

Oath of Non-Allegiance

by

Jesse Fewell – a long time proponent of building bridges between the world of traditional project management and agile – has brought to my attention the newest initiative by Alistair Cockburn – “The Oath of Non-Allegiance”:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

This should be obvious in the context of looking for ways to better run projects, but clearly it is not. The world of agile is full of divisions, bickering and discussions that remind me of good old days of comp.os.advocacy. As Jesse points out, even the thought leaders of the agile community practice very little collaboration that is the cornerstone of this whole approach. Why?

I think there are two reasons for this.

First, for some agile – or, worse, just one flavor of it – has become something akin to a secular religion that gives their lives sense and meaning – the one and only true way to not only run software projects, but also “transform the world of work” and people’s lives worldwide. It doesn’t matter if this attitude is true or faked – believers will fight with each other over slightest details always defending their chosen flavor of agile. They will also savagely attack anyone who dares to suggest agile is just a tool.

Second, once money is added to the mix things are bound to get hot. People have built their livelihoods around teaching and promoting certain “labels” and, naturally, they will fight to protect what they consider to be their turf. This is exactly same reaction as the one we are getting from “traditional project managers” when promoting agile – they feel their jobs are at risk from methods with no room for someone that will tell workers what to do.

Both attitudes are normal and very human indeed, however they should not shape the world of agile. I think most of us – people involved in agile – want to get things done. I’m enthusiastic about Scrum not because I think it will put the whole world as we know it on its head – but because I know from first hand experience that Scrum simply works on software projects. I’m pretty sure there are projects where it would fail – and I would use other, more appropriate methods there.

I’m sure there are more pragmatists like me and it is a good thing that their voice is heard. I signed the Oath.

What’s wrong with Toyota fascination

by

Last Saturday I attended a mini-conference called Agile Tuning here in Cracow. Kanban was what was talked a lot about and there was the usual automotive reference: Toyota. There is a lot of fascination with Toyota in the agile community (and elsewhere) and it has always bothered me a bit, but I didn’t really understood why. Somehow this came to me during that event.
You see, there are two problems I have with this “Cult of Toyota”.

First, clearly some of stuff that is inspired by Toyota’s approach to making cars is about how they manufacture them. For example, the whole Kanban system has its roots at Toyota but it was used there to optimize the flow of material to the assembly line and thus the line’s effectiveness. However, software development is not, repeat, not about churning repeatable products from a production line composed of machines and people performing endlessly same tasks. Software development is an inventive process. Therefore we should rather look at similar fields, like product development – we should look at how Toyota designs their cars, not how they assemble them. This whole notion of looking at software as manufacturing is utterly nonsensical and ignores the reality of how software is created.

But, secondly, one thing that is clear to me is that whoever got fascinated with “Toyota way” clearly wasn’t a petrolhead. Toyotas may be reliable and Toyota surely is a great company in business terms, very well organized and managed but their products are anything but fascinating. Toyotas are generally boring small cars and family sedans, not very innovative, not very beautiful, just means of transport to get from point A to point B and not think about it too much. In a sense Toyotas are mediocrity perfected.

I personally would be way more interested in observing and trying to understand how companies that produce outstanding, breakthrough products – or at least products one can be passionate about – work. I would prefer to know how Tesla car came to be than how Toyota Corolla was design. But we don’t have to look at automotive industry for examples – within our own industry we have way lots of creativity and passion. Take Apple. It did produce more innovative, great products people do care about in the last 10 years than Toyota did through its entire corporate existence.

The only problem is that we will have to wait until Steve Jobs dies before management science would be finally able to analyze how Apple works on the inside. Before then his legendary paranoid secretiveness and unending myth-building would, I guess, prevent any serious study of this truly amazing company.

That doesn’t mean, however, that until then the best thing we can do is try to mimic Toyota’s assembly line.

The real danger for Scrum

by

Scrum community is now debating – how Scrum Alliance and Ken Schwaber and certification programs and trainers and all kinds of related stuff will play out or should look like. In the meantime Scrum is in a real danger, which I don’t think is being noticed.
This danger for Scrum and community that grew around it over the years is not in the politics and debates, but in their fallout and the “me-too” frenzy (everyone desperately wanting to write and speak about Scrum and contribute or – more frequently – appear to): Scrum risks being diluted in the babbling of multiple voices each presenting his own version. If anything can be called Scrum and if things ranging from metrics to back rubs can be claimed to be part of Scrum, then Scrum ceases to mean anything.

Why it is a danger? Because Scrum’s biggest advantage over the years has been that it was a very definite, distinct method. Scrum meant three defined roles, three defined meetings (later expanded to four by adding retrospectives), two artifacts and a bunch of rules. There were Ken and Jeff and the organization they created defining what it is, there were trainings available and certificates (no matter how weak) backing them. It was therefore a “product”, something you could take, apply in your company and even check if it was done right.

Figuratively speaking Scrum was standing out like a rock in the cloud of “agile”. Agile is a philosophy, an approach – Scrum is something that is rooted in this philosophy you can take and use without becoming a philosopher.

And that clarity was, I think, the important part of Scrum’s success – the reason why most agile teams use Scrum now (or at least try to). If Scrum looses its focused clarity it would slide back into obscurity and irrelevance, back into the agile “cloud”.

Ken was trying to fight Scrum being diluted with his campaign against ScrumBut, and he is still doing it. Scrum Alliance is, as far as I can see from the lineup for the last Scrum Gathering, sliding towards doing everything agile, even everything “soft skill”. This is what community seems to like, maybe being bored with “pure” Scrum. But it is not what businesses will like when looking for methods to use to improve their processes. Businesses need solutions delivering results, philosophies they are less keen about.

In the meantime PMI is still the winner in the business world because it is still seen as a respectable provider of serious, business centered methodologies – and “fad boys” of the Internet Web 2.0 community are already abandoning Scrum in favor of Kanban or Lean. This may be good in the grand scheme of things, but if Scrum community wants to stay relevant it should refocus on providing the clear cut “product” Scrum was until recently.

To that end healing internal animosities, abandoning “soft skills” (including pure nonsense like my “favorite”: back rubs on daily scrums) and shelving dreams about conquering other industries would definitely help. Scrum practitioners and trainers should focus on helping teams deliver great software using Scrum – focus on what we should be able to do best, on our “core” and make sure we really succeed there.

Overcomplexity

by

Someone has sent me a link to a quite emotional but interesting article by Tim Bray on why the world of enterprise systems delivers so many failed projects and sucky software while the world of web startups excels at producing great software fast. Tim makes some very valid points about technology, culture and approach to running projects. It is true that huge upfront specs, fixed bid contracts and overall waterfall approach are indeed culprits behind most failed IT projects, and that agile, XP and other key trends of recent years can help.
However, I don’t think they can really cure the problem, because we are facing a deeper issue here: the overall overcomplexity in our civilization.

Main drivers of this overcomplexity are bloated states and economy dominated by corporations. Both states and corporations have IT systems today – and the complexity of those IT systems has to reflect the complexity of organisms and processes they try to cover.

The IT system for a national health care system or a state run compulsory social security “insurance” is a very good example. It must be a complex mess because what it is trying to model and run is a complex, overbloated mess – in most cases a constantly changing mess. And it can’t be launched early because it is useless unless it covers the whole scope of what it is supposed to do: because most of what it covers is regulations and laws you can’t deliver a system that meets half of the regulations or 10% – it can’t be used. By the very nature of the domain the system has to be launched as a finished whole.

Plus, on top of all that, comes the scale. If you can imagine a completely privatized health care no system will ever cover all citizens – each doctor, hospital, insurer etc. will cover just its clients, a subset of the population. A system like NHS has to handle all of the UK’s population by design.

Same problem with corporations, especially those that have been around for long (by long I mean decades, not years): scale and mentality. You just can’t manage 75 thousand people easily, especially if they are spread around the globe, in a simple and agile way.

Just think of all accounting requirements global corporations have to handle with their IT systems – but this is just the tip of the iceberg. Whole world economy floats in a sea of legislation – legislative diarrhea of the last decades produced a legal swamp which is a nightmare to understand let alone model a system to comply with it. For a global corporation multiply that by all the countries it is in and stick some international regulations on top of this. This is something corporate systems have to cope with.

What is also important – much of that overcomplexity is computer driven: it would not have been possible if not for the existence of IT systems and computers that run them.

Take VAT tax – it is so complex I always wonder what idiots gave the Nobel prize to the moron who invented it (well, I used to wonder about that when Nobel prize had any credibility). Clearly, implementing it is completely impossible without computers & systems everywhere.

Same about the legal diarrhea I mentioned – I think it can be largely attributed to Microsoft Word. Ever wondered why the EU Constitution (now disguised as “Lisbon Treaty”) has hundreds of pages while the US Constitution is simple and elegant? Well, they couldn’t have possibly written a couple hundred page document with a quill pen which forced them to produce something concise.

But going back to the key issue of whether the corporate IT systems can be better: they can, but a deeper shift in thinking is needed. Instead of creating huge, complex systems corporate IT should rather be a cloud of simple, small systems built and maintained to provide just one simple service (exactly what web startups are doing – each of them provides simple a service, together they create a complex ecosystem). However, this shift would have to occur on the organizational level too – large organizations with complex rules should be replaced with small, focused entities with simple rules for interaction between them.

But to get there we would need a world-wide “agile adoption” reaching well beyond IT. But that means a huge political change, that is nowhere on the horizon. Unless, of course, one other enabler of our civilization’s overcomplexity fades: cheap, abundant energy.

Brandt’s Law of NDAs

by

As agile software developers providing outsourcing services we are frequently asked to sign different NDAs and MNDAs. After over two years and dozens of NDAs I noticed a certain pattern which I will call “The Law of NDAs”.
It goes like this:

“The originality and value of the idea protected by an NDA is inversely proportional to said NDA’s length, penalties involved and insistence on signing it.”

In other words, on average, the more harsh and menacing the NDA is the less original and innovative the idea supposedly protected by it turns out to be.

Interestingly, not only average NDAs and ideas fall under this law, but also do extreme cases. For example, I remember one guy who had a 7 (seven) page long NDA to protect his revolutionary idea that turned out to be yet another social network (which, as far as I know, didn’t in the end see the light of day). Conversely, we had a group of high-profile European entrepreneurs who shared with us their truly revolutionary idea (related to multimedia) without even asking us to sign anything.

One may wonder why it is so, but for now I’m satisfied with having observed the pattern. Has anyone else noticed it?

Scrum picture is quite right

by

David Harvey wrote a piece on his blog entitled “The Scrum picture is wrong” where he says that the well known, canonical even, picture of Scrum loops errs by focusing too much on the product (deliverable, “potentially shippable product increment”) and forgetting that continuous improvement of the team is another important outcome of each sprint that should be shown with another loop.[Go and read David’s piece now if you haven’t yet]

As much as I agree with David’s insight I don’t think his version of the Scrum loop should be used to “sell” Scrum outside of our community. I very much value all the focus on teams and their improvement, but it helps to understand that this is something that is important (and should be!) only for us, sitting deep in the software development community. Clients ultimately pay for products, not for our methodologies, our teams improving or our overall well being and happiness.

Let’s take the case of outsourced development, which I know firsthand. Our clients pay us for the product they get from us, but once the project is done they are gone and I don’t think my team getting better on their project is something that even crosses their minds. And why should it, anyway? Unless they would want us to extend their product or start another project with us there is no benefit there for them. What really counts is whether the product we delivered will allow them to meet their business goals, their commitments – and their bottom lines. So when I work to convince them to forget fixed bids and go with Scrum I don’t waste the attention they give me on telling them that thanks to Scrum my team will get better.

But also if you have your own, in-house teams, building your product then in the long term it is that product that counts more than the teams. Why? Well, because not only your clients don’t pay for your teams, but for the product – you also don’t really own your teams. People change jobs (one call from Google’s recruiters to your best people can make your life very hard, believe me), get sick, even die – that’s inevitable. And (as I have learned the hard way) pampering your best people won’t prevent them from quitting – so is probably not worth it. In the long run – measured in years – it counts how much value your clients get from your product, not how perfect your team has become. If your team is getting better with every sprint but your product doesn’t sell you will hit the bottom hard sooner or later. Yes, your company may be then one of those legendary places that excelled technologically but are no longer around (Commodore, SGI etc.) which may be fine for the employees – they will just change jobs – but is not fine for owners and/or investors who will have to cover the loses.

So, team getting better is a tool, a mean, to get a better product, not the other way around (unless you run a monastery – there indeed work is just a tool for monks to perfect themselves spiritually).

Just to make sure no one misunderstands me: I’m not saying we should forget about team improvement, not care about our workers’ well being, career development etc. Yes, we should do all that and more, help everyone excel in what they do, make sure as much as we can people like what they do, heck, do it with passion and care, using fully their potential. All that is important and valuable. But we should not forget that in the end it is the client paying for a product who makes it all happen. And all our methodologies, frameworks and diagrams, all our “management science”, all techniques and research is aimed at improving efficiency – and that means, sorry to be blunt, getting better products faster and cheaper.

So I think the current Scrum picture is quite right in its focus on the product. And the message is spot on. It should be still used to “sell” Scrum to managers, clients and businessmen. David’s diagram is insightful and fine, but let’s keep it within our world of process freaks, agile activists and scrum preachers.