This is so because software development is not really engineering – it only looks like it because it is so technical. If done right it is in fact a fusion of art and technology – very much like a craft only requiring mental, not manual abilities. If people are not emotionally attached to their craft (like those who code&test solely for the money) they will not care if they produce a mess of spaghetti code rather than an elegant solution, they will not care what the user experience will be and they will not really care what happens with the product after they no longer work there. The only way to make them care is to make sure work is fun for them and they see a reason for the product’s existence other than the revenues it will bring.

Of course, this rule is more universal – happy people work better in general. For example Southwest Airlines’ happy flight crews deliver a better passenger experience, happier dialysis providers at DaVita provide better treatment etc. However, in software development the difference has a more profound effect – an unhappy flight crew will get you from A to B as effectively, keeping development teams unhappy will in the long run ruin the products/systems they create if not the whole company. This is so, because the less fun their work is the more technical debt there is (of all kinds: bugs, low code readability, C&P programming, suboptimal ad-hock solutions limiting scalability etc.) – and technical debt is as lethal for a business as any other unpaid accumulating debt.

Why it is so? I could bring up some theories, but I think it is less important than realising it and taking notice. Big players do. Take Google for example. They go to great lengths to make the experience of working there as fun as possible. The most visible aspect of this is their offices (each is different, BTW) but it goes way deeper – the way they treat their people, the way they allow them to access all of their code for example, all of that shows that people running this company have a profound understanding of what makes development teams tick. And they are not alone in this, almost every leading business now goes to great lengths to ensure the work itself and environment make the experience as enjoyable as possible for the employees.

Just to be sure – “fun” means a lot more here than just a nice working environment, cool perks and good atmosphere. It also means a shared sense of purpose in what you are doing as a company and as a team. And it also means dedication to technical excellence – a policy of zero tolerance for makeshift solutions and lack of craftsmanship. This mixture means people working in such a company can be rightly proud of what they do, proud of where they work and want to continue investing their time&energy there.

The notion of seeing the workplace as fun is sometimes dismissed as childish. It is so because there are many jobs that simply can’t be made to be fun (think of garbage collectors, people working in slaughterhouses or on assembly lines – by now mostly Chinese – assembling over and over again same parts) and historically practically all work was “serious” – not fun at all. Luckily for us that idea is slowly eroding as people search for self-fulfilment. Spending at least 8 hours a day on a job you hate is definitely not self-fulfilment.

Globalization and shortage of talent, especially in software development and other high tech sectors, make it very easy to run away from jobs where the “fun” part is gone (or wasn’t there ever).

Therefore one of the key duties of executives in an IT company is to make sure people working there have fun at work. And that means not that they can play computer (or traditional) games in a special room or have fancy office furniture – this means ensuring they are having fun doing the actual work as I’ve already explained above. I’m joking sometimes that there are companies that badly need a CFO – Chief Fun Officer – to shake the boat and bring some fun back. But seriously I don’t think one such guy can make a difference – I think that rather this attitude must be at the very core of company’s culture.

How this looks at your current place? Is working there fun? If not – take my advice: don’t waste your life, move on.

The catch was that I was doing it as the company’s CIO – effectively being the boss of all the other people in the room. Given the culture that existed there before it meant there was a real risk they will stay silent and expect me to tell them what architecture I had in mind rather than discuss their ideas. Therefore I had to adopt a very different approach to leading it than when I’m acting as an external consultant/coach. The fact that I genuinely had no idea how to solve the problem at hand helped me do it – I had no architecture to push for.

On the first day I kicked the meeting off with a presentation nevertheless, as everyone expected. I invited the company CEO to present the business plans and the strategy the company leadership wanted to pursue in the near future. After he was done I presented the problem as I understood it by discussing all the systems they had both acquired and developed in house and how I thought they interrelate. I finished by asking the team what architecture we should have in a year from now to support business’ needs and plans. I then started the discussion by asking the group to split into four smaller teams and work on an idea by a flipchart (we had asked for many flipcharts so each group congregated around one of them in the rather large room where we were meeting in).

Then I… left the room walking the CEO to his car (him leaving at that point was of course agreed with him before). This gave the teams the room they needed to start working. When I came back they have been already immersed in a discussion. I could observe how different people participated – some very actively discussing their ideas as they came to them, few scribbling on sheets of paper to join the discussion later, some sticking by one flipcharts others wandering from group to group.

This is how we worked for the rest of the workshop. However, that doesn’t mean I did nothing more – in fact I was needed to moderate some discussions, ask questions but primarily to break stalemates. There were moments when no one was sure how to proceed further and the discussion just died – then I had to step in and push the meeting forward a bit. All that was needed to get them going again was just a question or a simple exercise like voting on what was proposed so far. However, mostly I was just walking around the room, listening to people discussing, watching their diagrams, stickies on the wall etc. – and on many occasions leaving the room altogether.

I have to admit that I had to make a conscious effort to behave like this. While I have no trouble in getting out of people’s way in normal work when I’m leading a meeting I tend to take charge of it and even if I don’t come to it with a pre-determined idea I still steer the agenda and the progress. Here, however, I was leading a workshop by being mostly absent and only facilitating when for one reason or another the participants stalled. This was – I think – servant leadership in a nutshell: what I did as the leader was to set the stage, fire up the discussion by presenting a problem and then get out of the way.

How did this workshop end? The team walked away with a general idea of their future architecture but also – most importantly – an understanding that they could not design it in advance and implement it, but rather that they would have to evolve it by changing what they have now over time. In other words, they decided to go for the emergent architecture approach and wrote down a couple of conditions it has to fulfill to guide the evolution in the right direction. Along the way they discovered a lot about what they did and did not know.

I was really satisfied with the outcome, it was more than I hoped to achieve – and certainly much more than I would have achieved if I tried to pressure and steer the discussion in some predetermined direction.

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.

Some, more radical agilists will perceive it as a failure just like some Linux activists perceived the fact that Microsoft Windows is still with us as a failure. As agile becomes part of the norm it will cease to be revolutionary – revolutionaries will not be happy now, especially when they will see tie-wearing consultants prepare people for PMI’s agile cert exam.

For me it is a sign of agile’s success. This is how the body of knowledge in any field grows – from time to time there is a new trend, new idea that comes in but for the most part it doesn’t completely invalidate all of the methods and knowledge that was amassed before it arrived. Here we see the field of management being enriched with the integration of the agile approaches and techniques into it.

On the tactical/market level PMI’s move is a logical consequence of Scrum Alliance’s failure. Ken Schwaber’s departure in 2009 and events that surrounded it marked the end of Scrum Alliance as an energetic movement able to reshape the certs market and establish itself as a key provider of project management knowledge in the field of software development. The lack of leadership after Ken’s departure and shortsighted concentration on protecting revenue streams of existing CSTs have proven to be fatal mistakes not only for the Alliance, but for the Scrum movement as a whole. Ken’s new initiative – Scrum.org – had to be started from scratch and it may well turn out that it came too late to save Scrum certs as valuable propositions in the long run.

Whatever the future will bring PMI’s move is a game changer for all providers of agile certificates. Given PMI’s reputation, size and resources as well as experience in managing certifications it has a good chance to win the market for agile certs with its new offering. Of course it doesn’t change much for us, practitioners, ideology-agnostic pragmatic managers who will just continue to employ the best methods we know to get things done.

With agile now mainstream it is clearly loosing its initial momentum and freshnes. While many would object I think this is a sign of maturity. Agile as a phenomenon merely follows a natural path of methods/approaches from new to commonplace. With that its position changes. From a separate specialty driven by a few “gurus” and a crowd of active followers (and consultants) it is now becoming a part of every good manager’s methods&approaches portfolio. From something that few people specialized in agile will now be transitioning into something everyone must know to a degree appropriate for their seniority and specialty.

This is good news, because it means the agile movement has succeeded in changing the industry – even if it means that I can envision agile practices becoming part of the Project Management Body of Knowledge (PMBOK) in three to four years. This is the book despised by many agilists (most of whom probably didn’t even read it) yet agile’s inclusion there will be a sign of its success – and an end to an era.

In hope that in the near future there will be much less need for dogmatic “agile coaches” and much more for good pragmatic managers, who will be able to use and apply both agile and traditional project management methods – as well as manage the operational, financial and human part of their businesses/units/teams. Key here is to use methods, tools and tricks that are appropriate to get things done – as opposed to trying to squeeze every situation to fit a method one happens to know best. Dogmatism that I crticized in my last post doesn’t help here.

Agile is about adaptive, creative approach to complex work yet amazingly average agilists are the most dogmatic people I know. If you read their blogs and follow their tweets you will soon see dogmas being proclaimed and anathemas being cast on heretics who don’t agree.

The irony is that those dogmas can be pretty obvious observations, just repackaged to look like great discoveries. A good example I’ve seen on Twitter recently: “If you haven’t met you are not a team”. Well, that’s pretty obvious that it is much harder for team cohesion to occur when people don’t meet – it has been known for years that colocated teams are more productive than dispersed teams. However, to say that such a team can’t be a team and can’t do anything meaningful is turning an insight into a dogma.

Part of dogmatism is also treating agile – a simple set of principles plus a couple of practices and methods that evolved from them – as the all-encompassing solution to problems not only in software development, not only in IT, but everywhere. While this kind of zealotry helps some to keep the momentum for me it is a fry cry from healthy pragmatism that I think is at the core of all good management. In the long run it doesn’t help spread agile (at least outside of the US where aggressive selling of everything, including ideas, based on exaggeration is the culturally accepted norm).

2. Sectarianism

Kanban, Scrum, XP – everyone follows their own method, and basically says others are useless or at least not as good. It is like if we had separate sects, each following its guru or gurus – and shunning others. Again, this is in the face of core principles of agile.

While there is lots of value in well-defined methods like Scrum and healthy criticism and debate are most welcome a bit of respect for other approaches would definitely help. Especially so when someone says something works for them. It is common sense (if it works don’t fix it) – but isn’t “the art of the possible” one of core agile principles?

3. Domination by consultants

Most if not all agilists that write, teach and coach do only this and have not run a software project (or a business) hands on for quite a while. This is all natural, especially given how much money was there in it for those who were in the movement early enough. But it has some bad side effects – dogmatism and sectarianism are amongst them.

Apart from that I firmly believe that if you just preach but don’t do you gradually loose your edge and become one of the “experts” – a true consultant, namely someone who can only talk the (pricey) talk but (no longer) walk the walk. It is interesting how pragmatic practitioners usually are and how creative they get when solving problems they encounter in their teams/projects – not necessarily following everything “gurus” say to the letter.

That’s why conferences and other places (sites, publications) where practitioners talk about their experiences, problems and solutions they devised to overcome them are crucially important for agile’s future. However, most are dominated by consultants.

Dogmatism, sectarianism and consultant domination are hurting agile, frequently reducing it to a sales message. How does it make the agile community look like? Does it help spread those methods, change the way in which projects are run etc? Is it really convincing for decision makers? Is it even a movement one wants to be a part of? Sad but important questions “thought leaders” of agile should ask themselves.

This moment reflects very well the mood of those involved in the agile movement back then. Everyone was sure that agile approach and practices will now take the industry by storm and reshape the way we work on software projects. For some time it indeed looked like Scrum, XP and other less known practices and methodologies will replace the dreaded waterfall and the poor quality it consistently delivered in software. Alas, three years later it is clear that even though almost everyone now claims to be ‘agile’ not everything turned out so great. In fact, it turned out that implementing Agile in teams is very hard and in large companies with many teams even harder. There were many success stories – but an also a great number of (mostly untold) stories of agile failing to deliver its promises. Clearly, Agile was working as expected only in some places.

Many suspected that where Agile fails it is simply not done right. A research done in 2009 that showed for example that about half of supposedly Scrum teams didn’t work in iterations. That means their Scrum was simply faked. This, however, doesn’t explain why those teams did fake it. As a wave of (for now) slight disillusion with agile can now be felt in the industry agile leaders try to keep the momentum going and find some explanations. Some laid blame on the Scrum Alliance and its program of quickly certifying many people to be Scrum Masters when all they did was sit for two days in class without falling visibly asleep. Others pointed out that technical practices in many teams were so poor that developing a truly tested, working increment every month was not possible – this is exactly what Ken Schwaber tries to address now with his PSD training programs focused on developers.

However, while all of this may be true there is one more reason why the picture of agile in 2010 is less rosy than expected. This is – I think – primarily a social problem, much less a problem of technical practices, methodologies or certifications.

If we look at agile as a social phenomenon inside the IT industry then this approach to development evolved within a very specific group of people. Despite all of the differences between them those were the people who were (and mostly are to this day) truly passionate about their work. They do care about software, about quality, craftsmanship and how people feel at the end of their work day. Furthermore, for the most part the original signatories of the now-famous Agile Manifesto were people who at some point in their careers had a very tough project to do – and managed to do it.

Agile in its initial years – until it entered mainstream – was spreading mainly among people who were similar to its founders – really interested in working better, in delivering good products, in improving quality. For those reasons they were prone to be quite optimistic when thinking about the way others approach their work. I feel – though they never confirmed it – that Schwaber, Sutherland and others truly believed that programmers, testers, analysts and others IT wizards wanted to do things right and knew how, and if only the burden of waterfall and dysfunctions it promotes will be lifted they will rise to the occasion and, well, do things right.

The problem, however, is that most people don’t care about the work they do. They are forced to work by the economic realities – because they need money to pay their bills.

Consequently, in their work they are not moved by passion for what they do but rather follow the path of least resistance to optimize the outcome – get more money while doing less. They get through the work week doing as little as required to keep their job, then joyfully devote their weekends to things they truly care about. As a result they don’t respond to agile as expected, they don’t embrace it, because they don’t like the clarity it brings and the level of engagement it calls for. They want to be told what to do, as strange as it may appear. Hence the attempts at dogging it by faking it (like telling management they do Scrum, but not delivering working software in iterations) and other forms of passive resistance.

While some companies – especially small startups – can have the luxury of selecting only employees that do care about software as such the industry as a whole can’t. First, because there is just not enough such people (and I can tell you this from first hand experience – for the last 5 years I’ve been almost constantly looking for good people to hire and I can tell you that no more than 1 in 10 are truly interested in what they do – the rest try to fake it). Second, because good people tend to gravitate towards interesting projects, new languages, challenging problems – stuff they can brag about to their peers over beer. Many software projects don’t meet this description, but still have to be done.

Just to be clear about one thing: I’m not trying to judge people and their attitudes here. While some may believe that approaching work as an unwelcome necessity is inherently bad this concept of work is deeply ingrained in our societies. In fact, up until the last (20th) century work as such was an activity of lower classes/castes and elites looked at it with disdain.

The industrial society only made it worse. Until the 19th century work meant primarily farming. Farming is very hard, but it can be very satisfying because one can see and use the (literal) fruits of his labor. The assembly line of the industrial age factory doesn’t give the worker even that – the only real benefit is the pay. A corporate office is not much different. So people adjusted – they train in skills needed to get a job, work to get paid, then devote the rest of their time to things they really do care about. This is the societal default. Blaming people – or anyone – for this is a waste of time.

So the real question that agile practitioners, trainers and coaches, now face is how to convert teams of people less willing than the initial early adopters. This is the real test of agile as a method for “changing the world of work” – whether it can work with “the rest” – also because old tricks may not work. They shouldn’t give up, of course, but realize it will take a long time to change old habits, convert people, re-ignite their interest in work (if they ever had any) and make them more willing to be part of self organizing, self managing teams.

However, looking at it from my experience as a manager I think that it well may be that agile is simply not appropriate for some teams. And instead of struggling to adopt something that is squarely against who they are some people would be better off practicing well whatever they are practicing now. At least they would not have to waste their energy faking practices they abhor.

A pragmatic manager should recognize such teams and balance the potential benefits from trying to force agile methods there against the costs and risk (incl. potentially loosing people who will leave). Even if agilists will call it heresy.

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.

I already evaluated WebEx back in 2006. Back then I even signed up for a paid account and had major problems with it (it didn’t work on a Mac, poor sound quality, didn’t have dial-up lines in CEE etc.). Since then it is said to have been improved technically a lot – the problem is it is way too pricey for a single host of small events (<100) like me. After looking at the prices it I didn't even bother to register for a demo.

I also looked at Dim Dim briefly. I even registered for a free demo, but the presenter UI hanged twice and I did get 500 errors when trying to access meeting organizing panel a couple of times I gave up on them. I didn’t even run real webinars on it – didn’t want to fight with technical problems while having real participants on line. So Dim Dim is a nice name but it needs a lot of improvement – as of now it is technically not reliable enough to be even considered.

Finally, I did sign up for free trials of Citrix’s GoToWebinar and Microsoft’s Live Meeting and I’ve run a couple of real webinars using each.

The main difference between the two is that GoToWebinar is a simple screen share, while Live Meeting allows also content (PowerPoint presentations, pdfs, images) to be pre-uploaded on the site before the webinar. The uploaded content is then processed by Live Meeting servers, scaled and (I think) pre-downloaded and cached on the client.

The effect is very good – as a presenter I can switch slides back and forth, and with almost no delay they switch on attendees’ computers without any loss of quality etc. And if I need to demo something I still have the option to share my screen or just one window etc. Sound quality was also very good and while files produced when recording were huge they could be easily processed with various free tools.

What I liked about GoToWebinar was the overall simplicity of the UI of both the site and the presenter toolkit. You can pretty much start using it within five minutes without reading manuals or watching training videos.

The Live Meeting’s admin UI is so ugly and unintuitive it reminds me of the very early web apps from late nineties. It is not easy to use all the power Live Meeting has with its horrible UI. In contrast, with GoToWebinar’s few features everything is simple and easy to set up. I think that despite Live Meeting’s technical superiority GoToWebinar would have won this contest if not for the price.

GoToWebinar is much more expensive than Live Meeting, even taking into account that you have to purchase a minimum of five Live Meeting accounts. Those five Live Meeting accounts still cost less than one GoToWebinar account. And all of this provided you won’t exceed 100 people on your event, if you do GoToWebinar pricing goes off the scale into thousands of USD. I don’t think that just having a slicker UI warrants charging such premium prices, especially considering the very limited feature set of Citrix’s solution.

So, I’ve almost purchased Live Meeting subscription, but then I discovered a huge problem with it which I should have expected from the start: it works only with MS Windows, even on the client side. There is a Java-based web client, but it doesn’t provide audio on a Mac and doesn’t run at all on Linux – so I don’t even why Microsoft bothers with developing it.

Of course, this is normal for Microsoft (they assume everyone uses Windows), but has proven to be a huge problem for me as I run into complaints from Mac and Linux users after the very first webinar I hosted using trial Live Meeting account.

Enter Adobe Connect Pro. Based on Flash it works on all platforms where Flash does, so it solves that problem. It also offers a quite rich feature set – screen sharing, pre-uploaded content & presentations, webcams, chats, live polls, breakout rooms etc. It has no meeting management at the price level I was looking at (less than $100/month), but this can be easily done with simple Google Spreadsheets forms or other tools.

It takes a while to get used to the Adobe Connect Pro’s presenter UI though, where “templates” serve the purpose of changing the screen layout for participants. Also, because of the way the presenter display is structured it is not easy to present from a device with a small screen – like one of those smaller laptops or netbooks. At least a 15″ screen is needed to run the show with any comfort.

Where I run into problems with Adobe was when I finally decided to purchase a subscription. The tool does propose a competitively priced plan ($45 / month) – the problem was it didn’t say anywhere how many meeting participants this plan allows. During my demo period I filled in their “contact me” form twice, but no one ever reached out to me – maybe because I’m not located in the US. Finally, with my webinar approaching fast, I called the local Adobe help line – there I spent about 20 minutes talking to a lady who promised to find out for me how many participants I do get for my $45. Finally I did get that information on the next day via e-mail, but it was already past my scheduled webinar which I had to run with… GoToWebinar (again, Linux users complained, but at least Mac fans were happy!).

To wrap it up: I ended up choosing Adobe’s solution. It offers best feature set for the price at my intended audience size (less than 100 people) and has no compatibility problems of other solutions. High marks for GoToWebinar/GoToMeeting for simplicity but their pricing is too high. If I wouldn’t have to support Mac and Linux users I would probably stick with MS Live Meeting – most powerful of them all, despite its ugly looks.

Updated on 2010-12-08: In the end it turns out I can’t buy Adobe Connect Pro – the competitive price they offer – $45 – is only available in the US and Canada. No way to purchase it on-line from Poland. So for now I keep on using the GoToWebinar.com which doesn’t treat me as a second class customer just because I happen to live outside of the US.

GMail’s “Priority Inbox” is basically a spam filter in reverse. Rather than trying to guess what is junk it tries to guess what is it that the user would really like to read. Great idea – and pretty well implemented.

I was already using a GMail extension called “Multiple Inboxes” so my GMail screen was divided into three regions: the inbox, just unread e-mails and starred e-mails. Priority inbox plugs right into this set up and creates a fourth region – e-mails Google’s filter “thinks” I want to see.

Since I still keep on using an e-mail client (Thunderbird) with my GMail accounts I was glad to find that the “Priority Inbox” is also exposed as an IMAP folder.

So far I’m really enjoying this new feature. Even though it makes me more addicted and dependent on Google’s GMail service it came at exactly right time for me.

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.

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.

I think what it shows is rather Google’s failure to properly position the product on the market – or even turn the technology they have developed into a product. What they had was a potential Exchange killer – a system that could have been a real game changer in corporate communications as I wrote when it was unveiled. Instead of trying to get general Internet user community to adopt it Google should have packaged Wave as a corporate messaging/integration/collaboration system and market it bundled with support services to large corporations.

Someone else can still do this if they will indeed release much of the technology behind Wave to the public as open source code. Heck, maybe even Microsoft will adopt some of the concepts (and maybe even protocols) into their next release of Exchange/Outlook pair.

Still, this shows us Google is not immune from the problem of many great tech companies: inability to market great inventions. This has happened before many times – companies developed brilliant technology, but then failed to turn it into a product or market it successfully. Some didn’t survive it (Commodore, DEC), some did, but just failed to grasp a great opportunity (like Xerox for example).

So far Google still has its huge revenue stream from their basic product – pay per click advertising driven by search results – so failure to market Wave won’t hurt them. However, some research suggests ppc ads are declining in value as people learn to mentally avoid them (even if they don’t use the great Ad Block plugin as I do). So, dear Big Brother Google, better think twice next time before you throw away some great product in the making.

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.

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.

It turned out to be an interesting experience. Since SA’s bylaws didn’t prescribe a process we should follow, so we had to self-organize and devise a process that would be – in our opinion – fair. It worked out better than – I think – anyone of us expected. We managed to come up with a pretty good selection pretty quickly with just e-mails and two confcalls.

The process was pretty simple – on the first call we decided we want to learn more about potential candidates who expressed interest, especially what they want to bring to Scrum Alliance, so we have created a simple questionnaire for them to respond to. Some obviously didn’t saving us work, but 17 people did submit responses varying in length. As it turned out on the last call all of us took time and read through those responses, some even more than once. Thus prepared we were able to reach a consensus during the second call and present a very balanced list of candidates.

Personally, when reading the submissions, I was looking for concrete vision and addressing SA’s real problems (damaging and unnecessary rift with Ken and Jeff, certification process in dire need of an overhaul – incl. the CST process, lack of vision and openness in what the board does, Scrum being pushed aside by the “Kanban camp’s” marketing efforts etc.) rather than general statements on promoting Scrum etc. I think a board member is responsible for steering the organization in a (hopefully) right direction, not for defining what is Scrum for example (“Scrum Guide” by Ken and Jeff does this well enough).

Overall, I’m pretty satisfied with the candidates that we selected – the list will be published on the SA site pretty soon.

Now it is up to members to vote and choose, keeping in mind that those two board members will have limited influence and can be outvoted by the incumbents anyway. However, at least they can probably influence the Scrum Alliance in the right way or tell the rest of the members how the board works or what it decides and why.

It is about time to reinvigorate the Alliance and save it from fading into irrelevance – which is what can happen if those pressing points I mentioned above are not addressed – so vote carefully.

Ever since “personal computers” (as they were called back then) made it to people in late 70-ies owners could load whatever software they wanted onto their machines. They could code their own, buy a copy or upload a shared (“pirated”) software. Whatever they wanted. No one knew what they have on their machines and no one could change that.

Apple’s model is that you can only get software from the central App Store run by Apple. Period. You can’t download off the Internet. You can’t buy a box at a media market nearby. You can’t use Open Source stuff from someone’s site. And you can’t make your own – unless you have another full-blown Apple computer and sign up for a special account in the Apple Dev program. That means your machine is no more entirely yours, it’s just a terminal to a store with shiny toys you have to pay for. And Big Brother Steve controls what toys are there.

This also affects the software business by introducing a new risk for software vendors. Normally your sales don’t depend on the operating system or machine maker. They can intimidate you, buy you out, introduce nasty tricks in the OSs new release you will have to work around, introduce their own bundled, free product to compete with yours (IE) but they don’t control your distribution. Host OS vendor could make your life harder but not kill you overnight.

Numerous times I’ve read complaints about Microsoft being a bullying, ugly monopolist – in fact I wrote a couple myself – but even in the maddest fit of furry Steve Ballmer can’t pull the plug on your entire business just like that. Steve Jobs can and will, with a smile. One day you might be selling hundreds of downloads of your app on the App Store and the next day your revenue stream is gone and your business with it. If that doesn’t make Apple an evil monopolist I don’t know what else they have to do to earn the title.

To be fair Apple didn’t invent this model. It was first introduced on a large scale by Amazon with their Kindle device. It is in fact a terminal to a paid library of books you can’t ever really own – you just rent them at a price to read them (I think Amazon’s stating that you “buy” them is misleading advertising). It is the ultimate perversion of the great concept of public libraries on steroids. Apple just applied that first to iPhone with great results and now it tries to do the same with computing. I’m afraid it won’t end with the iPad…

The thing is I can whine on my blog, and so can others, but this won’t change anything. The carrot, the bait is too big for both consumers and vendors. Consumers get easiest possible way to get software, vendors get instant access to huge market. So everyone will, sadly, play along. It could have been done better – for example through a community-run “App Store” or something – but for the time being the only thing I can do is buy a Linux-powered netbook and thus revert to my roots.

Judging from blog posts by other participants Nigel’s talk was definitely a highlight of the conference – many wrote that other talks paled in comparison to his outstanding presentation. In fact I think it is a pity Nigel doesn’t do more public talking on the conference circuit and only participants to his trainings (which we have a pleasure to organize in Poland) had so far a chance to experience his zest for Scrum & Agile.

Enjoy!

(I plan to make a high-res version of this available using BitTorrent later on)

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.

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.

Some of the discussion is highly political and I feel some prospective from outside of the “club” is really due. Seen from where I live (Cracow, Poland) it looks like this:

• Back in 2008 there is Scrum Alliance, led by Ken Schwaber, all Scrum gurus are together and everything goes fine, everyone wants to be a CSM. However, some point out this is a phony certificate, because to get it you just have to sit through a two day class and don’t be visibly asleep.
• To address that there is talk of introducing an exam. By October of 2008 the exam is ready to be rolled out, participants to Stockholm Scrum Gathering can take the “test version” of the exam and report what they think of it. Exam is expected to become official pretty soon (January 1st if memory serves me well).
• Then, exam implementation date is pushed back – I was back then told unofficially by “someone close to the Scrum Alliance”, that the reason was some CSTs sold classes promising CSMs without exams and were threatening to sue for lost revenue if exam is implemented.

  Whatever was the reason the exam implementation date is pushed back again and again through 2009, which looks bad – Scrum is supposed to be an effective project management method, however the organization behind it is unable to roll out a simple exam and keep its public commitments.

• Finally, the final date for exam introduction is announced to be October 1st. Then there is an announcement from the Scrum Alliance posted on September 12th that the exam won’t be introduced until 2010 (the pretext this time is supposed need to translate the exam into other languages), then it disappears from site, then on September 15th Ken Schwaber disappears from Scrum Alliance. Then Scrum Alliance announces the exam-that-is-not-an-exam – the exam is introduced, but everyone passes (so calling it an exam is, well, not exactly true) – a true pearl of corporate-style wisdom.
• Then comes the first real test for Scrum Alliance’s leadership – the Munich Scrum Gathering which is not an exact success for the board. None of the hard questions or real problems are met with clear answers then and since. Lack of leadership is clearly visible. Seems no one has not only vision and skills, but above all time and will to push Scrum Alliance forward. Enthusiasts like Tobias Mayer join in, stuff like “innovation games” is taking place, so there is some hope for the future – but overall Scrum Alliance stalls.

Amidst all that Scrum as such looses clarity and edge. Everyone jumps on the bandwagon now that it is seen as a clear winner – and everyone wants desperately to contribute, publish, write, record YouTube videos – anything, just to be known.

Some want to introduce Scrum in all industries, some want to dilute Scrum and agile into some soft-skills bag of tricks (as exemplified by this guy who proposed – apparently seriously – that members of Scrum Teams should offer one another physical affection and backrubs – link, link to prove I’m not making this up).

That leads to much noise about Scrum entering the Net – which, in turn, leads to a lot of ScrumBut. Thanks to all those “experts” who write and write and Tweet tirelessly about what they think Scrum is confusion increases, and with confusion come problems. And indeed voices appear that Scrum is failing in teams where it was introduced.

Clearly, something is wrong with the way Scrum is implemented – and that can indicate a problem with the way Scrum is taught and promoted. Maybe CSTs “club” doesn’t work all that well after all (I know, most CSTs do a great job, but “some trainers” clearly do not)? Maybe some “method creep” between trainers coupled with lack of exams makes CSMs inadequately prepared to implement Scrum?

Ken Schwaber’s Professional Scrum Master tries to address this. There is a body of knowledge (“Scrum Guide”), there is an exam already, there are clear rules as to both becoming a Scrum Trainer (as opposed to CST) as well as rules to retain that status (to ensure there won’t be “creep” of what is being taught) plus the course content itself is updated. Finally, there is clear focus on software development.

Now, I know there were hurt feelings etc., but from my prospective back here I welcome Ken’s initiative. While others were talking Ken simply moved ahead, created something new that tries to address the problems. If it is the right solution – we’ll see, but at least it is a move forward.

Having said that the best next thing that could happen to Scrum is some form of reconciliation between Ken and the Scrum Alliance. Last five months have shown that without Ken at the helm the SA drifts, but it would be a terrible mistake to waste all the enthusiasm and work invested by so many involved in that organization.

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.

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?

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.

This big picture is – in short – that we humans are damaging the planet Earth, causing catastrophic global warming driven by CO2 emissions due to burning fossil fuels (mainly in cars), as well as having kids, eating meat etc. We are also facing a huge energy crisis, economic crisis, swine flu pandemic and terrorists. Doom is just around the corner, there is no hope unless we submit to a whole portfolio of totalitarian policies proposed by the very same politicians in the very same media outlets.

Apart from whether all of this picture is true (most is not) what is interesting here is a complete lack of any positive program for our civilization.

It seems the only thing our elites can come up with is downsizing humanity by all means possible from contraceptives to choking off industrial production with this whole "carbon tax" scheme. But this is not a positive program, it is at best an idea on how to prolong status quo for those left, especially those on top of the chain. Let’s suppose we will cut human population by 90% (as some "ecologists" – or rather antihuman madmen – are suggesting) – what next? Where is the path upwards, not downwards?

What is amazing is that people in general are not noticing this lack of any long term prospective. They seem so scared of (mostly fake) dangers they see in the media each day they don’t see our leaders have no idea what to do. Or, worse, they have an idea, but it doesn’t include most of us.

All of this is extremely short sighted. Notice that in all of those doom scenarios Earth is being presented as a limited, closed environment – something akin to Eco Spheres. Global warming models, for example, generally don’t factor in the influence of the Sun, space radiation, Earth orbit cycles & changes and so on. So do those who talk about energy and resources scarcity.

The fact is, however, that Earth is just a part of the unimaginably huge and complex system called the Universe. This is our world, not just this tiny rock. And universe is full of energy and matter. Even our own solar system is full of energy and matter way beyond anything we humans may need for centuries. Just the solar energy descending on Earth in the visible spectrum every day is way beyond all energy needs we have or may have in foreseeable future.

Also, as it has been shown, the limit of Earth’s atmosphere is as much a hard limit for life as the water surface is for fish. Fish can’t walk on the land, we can’t get to space without lots of energy and technology – but it doesn’t mean the world just ends there (like they thought flat Earth ends in Middle Ages). Even the limit of Earth’s atmosphere is just an arbitrary line drawn by humans to simplify things – in fact it is a changing continuum between the dense atmosphere on the ground and the vacuum of space above it (and even that vacuum is not completely empty). And that space influences what happens here on Earth in a powerful way – much more so than anything we humans can come up with.

How all that relates to the current picture of doom and gloom? Well – my question is: if we know we’ll run out of resources at some point why we are not trying to get to the resources beyond what is available on Earth? And since when did we forget that for any sane human being fellow humans should come first, before whales and bats? Why instead of trying to kill off humans (or prevent them from being born) – which is what our leaders seem to be busy doing – we are not trying hard to make sure that a) everyone is fed and b) we can have a future in space?

It’s not a problem of technology or money. The technology is there – we have heavy lift rockets, most are just not being produced anymore (like the famous Russian Energia). We even have nuclear technology that could give even better lift and could propel us further than just the Low Earth Orbit, but it never was really used. In fact it seems that when it comes to space technology we are not advancing, not stagnating, but actually falling back.

The money is also there – just the bailouts for the “too big to fail” would have funded NASA for years. This is not mere rhetoric. NASA’s budget for FY 2008 is approximately $17 billion or 0.6% of US Federal budget. The bailouts did cost between $4 to $8.5 trillion according to different sources. That is between 235 and 500 years of NASA’s funding. Or 29 to 63 Apollo programs (cost of whole Apollo program is estimated at $136 billion of 2005 US dollars). And some say the total cost of bailouts etc. is $23 trillion – you can calculate yourself how many trips to Moon, Mars and elsewhere would that buy – even at NASA, known for its wastefulness and reckless spending on bureaucracy etc.

Those numbers show how mad this is, how we risk our collective future by massive misallocation of resources. Can you imagine how much technology and knowledge we could have obtained if just a fraction of those heaps of money wasted on Wall Street would have been allocated to space exploration? How many good, real jobs would have been created – jobs that actually create something, not “service” jobs that mainly mean people flipping burgers and waiting tables?

So something just doesn’t add up here. Either all our leaders just never look up into the sky at night and can’t use their brains for anything other than campaigning – or there is a barrier there we are not being told of. In any case instead of pursuing the only positive path we are being told the best thing we can do is planet-wide civilization suicide.

Which is why I’m sick when I see attempt by mass media and major corporations to create an illusion of grass-root support for the Copenhagen meeting and tax on breathing they want to impose there on the whole world (like this one). What’s really sickening is that this scam seems to work, that people do believe in this whole heap of lies they are being told without questioning them, without thinking. And without realizing there is a positive path – we just don’t follow it, we don’t even consider it.

People usually start their talks with the notion that in the basic time&materials contract (the only truly agile contract if you ask me) all the project risk is on the client’s side and other contract types somehow move some of the risk to the supplier. Some go as far as to say that in a fixed bid contract (fixed time, scope & cost) all the risk is on the supplier side.

First time I heard this I thought this is clever, but over time it dawned on me that this “risk sharing” is as much illusory as is the security of the fixed bid contract. Here is why.

The single biggest risk anyone faces when they build something is that this something won’t fit the purpose it was intended for. Causes for this can be numerous: the needs might have been not understood properly or the idea doesn’t fit the market, the needs have changed or the thing built can’t be used because of defects. Finally, the thing being built may be delivered too late for it to be used as intended.

No matter how hard you try the biggest share of this risk is always on the client’s side, because it is the client who won’t get expected benefits in the end. You may add as many penalties and harshly sounding clauses to a very fixed and rigid contract as you want, you still won’t get away from this risk.

Imagine you’ve spent 3 months writing the initial spec, then next two months on RFP/bidding process, then contract negotiation, then two years on developing your complex software system only to discover at the end of all this that the product is not exactly what you intended, is full of bugs and is irrelevant because in the meantime the world moved on (the usual, flawed, waterfall process). What then? Yeah, you can sue the unhappy supplier all the way, but how much good will it do to your business? You can not pay them and even bankrupt them if they were not careful – will that repay all the lost opportunity? Make up for lost time? No way!

This risk is like a boomerang. I’ve heard someone define a boomerang as a piece of wood that no matter how hard you throw away from you will come back and smack you in the face. Very fitting. The harder you try to move away from this risk with complex contracts the more you will be hurt in the end. You don’t need rigid relationship based on distrust to tame this risk, you need an adaptive relationship with people you trust but can check all the time.

That’s exactly what agile offers: tight control of the product being developed in short inspect&adapt cycles. Instead of trying to write clever penalty clauses and waste time on lawyers clients can closely monitor the progress of the team(s) that build their software. They can spot any problems early on and correct them. Or readjust the backlog to changing situation keeping their product relevant. Or change the team.

I’d say there is way way less risk here. What clients pay with for this is their time and involvement – they have to see test builds at least every sprint, they have to speak to the team, readjust the backlog and overall stay on top of their project. But all the time they have all the tools and controls to navigate the project to a successful end. A fixed contract just kills all the outset.

So, next time when people will again define contract negotiation as risk pushing I’ll definitely interrupt them with my little boomerang analogy, because I feel we must all realize this is yet another (paper) illusion.

After the lame keynote session on Tuesday I decided to sleep in on Wednesday and I missed Harvey Wheaton‘s talk. It didn’t appear particularly interesting on the mini-agenda we were given, looked like another boring life story. My friend Tomek went in, and thanks to him I know I’ve missed a very interesting talk, a real world experience of implementing agile & Scrum in a startup company run by Harvey. Well, next time I’ll be in for Harvey’s talk.

Another session I attended was supposed to be about agile contracts by Peter Stevens. To the surprise of both speakers this talk was squeezed into the same room and time slot with Regina Mullen‘s talk. In effect both had time to speak, but not to take many questions from the audience (crowded, as usually, on chairs and in between). Peter’s talk was a mild disappointment for me. I had a chance to talk to him a few times and I read his blog, so I know he knows a lot more about agile contracting. Maybe he just decided to cut his talk to leave some time for Regina. In any case, I didn’t learn much stuff that I would not know before, but I think it must have been a good introduction for the first-time attendees. One thing I’ll remember from this talk is his story about Zurich trams contract. And it also reinforced my resolution to finally write about my take on risk in client-vendor relationships.

Regina’s talk was, on the other hand, an unexpected, entertaining diversion for me. Though she did include her life story into it (like way too many speakers at the Gathering), she did it in a gracious and humorous way and her thoughts on making lawyers use agile were quite interesting, even though I’m clearly not in her target group (IANAL). Nice talk, I just hope she has a chance to present this to lawyers and indeed change their ways. Part of the challenge throughout my career in the IT world, especially as a manager in the last couple of years, has been finding lawyers that would really understand what we are trying to do before helping us draft contracts, user agreement, licenses and so forth. We need more people like Regina there – I definitely would love to talk to a lawyer who does know outright what a sprint is.

After lunch the best regular talk to attend was probably one led by Nigel Baker (I suppose so, as I know Nigel – it’s not possible to get bored when he talks), but tired of all the Scrum politics over lunch I decided to go to the haiku workshop led by Liz Keogh. I was amazed by the results. I really did learn something new I didn’t know before, and it was really easy. It took Liz a couple of minutes to get us to write haikus, and since then they keep on popping up in my mind on their own. Two examples of the ones I did and really like:

Worn green carpet
carries us all patiently.
Thunderstorm!

Engulfed in our own little worlds
between iPod earbuds.
Autumn leaves.

(Haikus composed during the workshop and sent in afterward can be read here).

I resolved to try and write at least one per day. I think they are more than a diversion – they are a great tool to awaken our pattern-matching R-mode processing (read Andy Hunt’s book for more on L&R-modes). Haikus being by definition based on surprising matches can increase creativity by encouraging the R-mode “search engine” to produce more unexpected matches, useful not only for more haikus.

The event ending session was a big surprise. I expected some energizing talk, so I took out my camera to record it. Instead what happened was that after some small talk and a round of due thanks to different people by Tom Mellor a “wave” exercise was performed. It was so jawdroppingly stupid I thanked God I had my camera out so I had a good excuse not to participate in this idiocy without attracting attention. I kept on recording though and I wonder now whether I should put up this video or not, as I’m afraid it could only damage the reputation of the Scrum Alliance.

Interestingly, most people I talked with afterwards agreed it was stupid, but during the round after the “wave” they said BS like “powerful” or “energizing” – only me and one other guy were honest enough to say it was “silly”. To me it was a clear example that whoever was supposed to lead this session just didn’t have anything meaningful to say, so came up with this thing instead.

I think this failure illustrates a deeper problem Scrum & Scrum Alliance has. Scrum is part of the IT industry’s response to the failure of traditional, waterfall based project management in software development that that is called “Agile”. Scrum is a simple framework for managing requirements, work and team during software development projects. Yes, it doesn’t say anything about “software” as such, but this is where its roots are. In other words – it is a way to manage projects (because, I’d argue, Scrum projects are still managed, even if there is no Project Manager as such) created in our industry.

Now we have to decide – is Scrum just that or is it something more? Should we focus on merging Scrum with technical practices in teams and keep focus on software (which is what Ken Schwaber seems to be doing with his new training program aimed at developers)? Or should it be treated as a industry-agnostic project management methodology that could take on PMBOK, Prince-2 and other heavy methodologies everywhere? Or maybe should it be part of the soft-skills portfolio for coaches, HR etc. together with “waves”, collaborative drawing etc.?

The problem here is that traditional management methods work quite well in heavy industries they evolved in, and there are lots of very good people in the soft-skills department – usually better than ex-software developers discovering their “emotional intelligence”.

In any case a choice must be made before Scrum dissolves into mist. Ken, Jeff and Mike did agile movement a great service by laying out Scrum as a clearly defined, tangible thing as opposed to agile’s vagueness. Scrum was something anyone could start using and derive benefit from following its simple rules – because even ScrumButt was giving more productivity than waterfall. That’s why it was so successful – exactly because of its sharply defined edges and simple clarity. Now this clarity can be lost amidst empty motivational talks and silly exercises lifted out of kindergarten.

I know what I wrote will be harsh for some, but well, that’s what I think. And being a nobody in this movement, a nobody living in a place most of you never heard of I can afford the luxury of being honest. And of course one thing will stand: Scrum itself and other agile methods and practices. No matter which Alliance trademarks what you can use them and be better off in your projects.

To close on a more optimistic note some appreciations:

• Thanks to Boris Gloger and his team: they not only provided real, freshly pressed juice and real, freshly brewed coffee but also filled in where organizers couldn’t in a truly agile fashion. Their idea of just copying the materials on pen drives and handing them to people at the end was brilliant. Plus he paid for the beer on Monday.
• Tobias Mayer: another true agilst, when everyone complained about the lack of Open Spaces and the board said they will make them next time Tobias singlehandedly organized “guerrilla Open Spaces” the very same day greatly enhancing the Gathering experience for many. Also, it is Tobias who told me to go to the haiku session instead of political discussions – thank you!
• Howard Sublett and Cory Foy: Scrum Alliance needs more of you guys, not just 5 hours / month.
• Stefan, Robert and other German friends who helped me find my way around Munich and explained some customs during the beer evening.
  Everyone I talked with during the breaks.

Overall, I liked the event as a whole, I hope next one will be way better – and that clouds over Scrum Alliance’s future will be gone by the time we meet again “somewhere in Europe”.

(There will be one more post in the Scrum Gathering series – about Scrum Alliance as such).

First the talks quality is a bit lower than in Stockholm. Or maybe I did end up in wrong ones because I didn’t choose well. Nothing besides the talks titles & speaker names was announced so I could only guess.

Initial remarks by Jeff Sutherland were delivered with his usual zest, but seemed to be just an incremental update from his presentation in Stockholm and his other talks. Must have been quite interesting for first time attendees though. One thing I picked up there is that I really need to read the original Takeuchi & Nonaka paper that started all of this. And I think it is worth exploring what those guys are up to now. If their one paper started this whole movement, then maybe their other work is also valuable.

On to other first day talks: “Coaching Scrum Teams with a User Centered Approach” with Mike Sutton turned out to be much less interesting than I thought. Two things I picked up there were Prezi presentation software and a book about brain functioning – that is before I left 30 minutes into the talk. Simon Bennett did a much better job with his talk on applying game theory to agile contracting. Though his conclusions were certainly nothing new for me his exercises were interesting and kept the group involved. Also Roman Pichler’s talk was interesting, though his delivery style – slow, calm and quiet – is not what I like. He discussed anti-patterns for Product Owners – or common mistakes made by Product Owners. One point we didn’t agree on is what he called “bungee product owner” – I think I’ll write more on this separately.

As far as the first day goes, though, it was Mike Cohn‘s talk that was the highlight of that day for me. I recorded the whole talk and with Mike’s permission I’ll post it on-line when I get back.

Second day opened up with some guy from Sweden – Petric Palm – telling us his life story and showing quotations from famous people and nice pictures. Certainly not a keynote level talk. I used that time to do my e-mail.

Next, organizers switched sessions – the one I wanted to go to was replaced with a product owner panel discussion I wasn’t all that interested in. When I realized that I wanted to go to Erez Katzav’s session but the room was already so full of people it wasn’t possible to get in. More e-mail then plus an interesting chat with another guy who did not get inside for the Katzav’s talk.

After lunch finally the highlight of day two came: Serge Beaumont‘s talk on tools for product owners (tools meaning practices and mental tools not software tools or anything like it). Learning from the previous sessions I came 20 minutes before the talk so I didn’t have to sit on the floor. Serge talked about ways in which Product Owners can organize their work and collaboration with the team, especially around that part of the backlog that is not yet inside the sprint. Serge’s observation is that once team is running at high speed with Scrum POs quickly run out of backlog or they are not fully prepared at the outset. The cure is to define a READY state for items that can go into sprints – an equivalent of the DONE state at the end of sprint – then build a Kanban-based flow that feeds the backlog of READY items so that it is never empty. Great talk and I’m looking forward to seeing the slides posted.

Finally, the day ended with the Scrum Alliance board – or part of it – answering questions. I have to say that it was a depressing experience. Both Jeff Sutherland and Mike Cohn were not present, I think they have left earlier, which was a surprise. The four board members present were looking sad, devoid of energy and vigor as they sat collapsed in their chairs. Sadly, the Alliance’s support staff – Howard Sublett, Cory Foy and others – looked much more energetic and alert than the board.

Plus the style of board’s answers was like on a corporate meeting: very diplomatic, rather avoiding or deflecting questions than giving any straight answers. For example someone asked if the board will be elected by the membership rather than elect itself. The short answer was NO, but instead of saying so one of the board members went into a lengthy discussion which included a story about some football coach from his college or university or whatever.

In summary it is quite clear that the Scrum Alliance is suffering from leadership deficit. “Improvement communities” are a great idea, but they can’t be an excuse for lack of leadership. After all self-organization occurs around goals, and it is not clear what Alliance’s goals are now. This apparent lack of vision is normal after what happened recently, but it can’t be allowed to last too long. Right now everyone is, I think, willing to cut Tome & others on the board some slack and give them time to find the direction but this won’t last long.

Personally I think the Scrum Alliance should open up, especially to members outside of the “old boys club” (as someone called it), to move ahead. Pushing Scrum outside of software development is IMHO unrealistic and in places wrong. The Alliance should rather focus on improving the quality of projects inside our industry. There is still a lot to be done in this sphere. The complexity and importance of the Product Owner role, for example, has been only discovered over time. The problem of awareness in the industry that is reflected in everyone still wanting fixed bid contracts is an ongoing problem. I think everyone could add to this list.

Making the CSM exam a real test of knowledge as soon as possible would be the first step in the right direction. I think exams should be like PMI’s PMP exams – there are no certified PMP trainers, anyone can train or learn PMBOK on their own, but the exam itself is known to be hard and is administered in a controlled environment to ensure one can’t cheat with a book or search engine. Such a structure promotes honesty and certificate value plus it is much more open and fair. I think this is a good example to follow. In the long term a good structure of exams like this could even make CSTs obsolete – which would help the promotion of Scrum greatly. Right now the existence of this closed club with unclear entry rules is choking the growth, especially in the parts of the world where English is not the primary language.

To wrap up my rant a short list of organizational failures:

• venue: rooms too small, at times crowded – people had to stand in some workshops,
  
• lack of proper events folder or plan – short plan in the conference ID is good, but without a brochure with descriptions of talks and speakers profiles one is left guessing as to what talks are about, it is way harder to make good decisions as to where to go, amazingly this information was even missing from the Scrum Alliance’s web site even though all speakers did submit it,

• lack of Open Spaces – that was a great idea, one of the greatest advantages of Scrum Gathering in Stockholm, don’t understand why it got dropped,
• lack of free Internet – at 1200€ one could expect that (was fixed on the second day).

To ballance it with some organizationa positives:

• all most talks in English,
• food – good and abundant!

Ken Schwaber departed Scrum Alliance abruptly, most probably after an internal conflict over the introduction of the CSM exam and he is starting something called Scrum.org. Scrum Alliance is now led by Tom Mellor – a guy mostly unknown in the European Scrum community. And the Alliance announced exams will be introduced Oct 1st as scheduled, but for some unknown time everyone will get a passing grade, which basically is the same thing as before. Last Friday it was also leaked on a discussion group that a new certificate – Certified Scrum Developer – is not only planned, but already offered as a course by… Microsoft. Scrum Alliance representatives on the list reacted with surprise – at the same time this program’s description can be found on Scrum.org.

It remains to be seen how things will develop in the Scrum community. The whole exam fiasco is clearly a result of some internal infighting and it damages the Scrum Alliance’s reputation a lot. The introduction of an exam that is not really an exam and doesn’t prove anything is a typical compromise from the world of corporate politics, much worse than just another postponement. Unclear circumstances of Ken’s departure and his surprising new Scrum-related venture put more clouds over Alliance’s future.

But whatever happens out there amongst the Scrum gurus and luminaries (and whatever they will fight for – if they will) Scrum as a method – a simple framework to consistently deal with complex problems – is as sound and effective as it was before. This is what counts in the long run and what will cause Scrum, I hope, to continue to be adopted despite all the bad things that happen around the organization created to promote it.

UPDATE: Good news – Mike Cohn joined Scrum Alliance’s board! Now, I know Mike and I’m glad he’s back at the board.

I did get the FoxIt’s eSlick first and I immediately liked it. The device is very light and therefore easy to carry around. It supports SD cards, but has enough internal memory to hold dozens of books. It connects to any computer with a standard USB cable and is visible as a USB drive, so it is easy to manage books stored on it on any operating system. And of course it loads its batteries from USB too.

But what I liked most about eSlick was its display – very crisp and paper-like, with characters clearly rendered in a very print-like manner. It was a pleasure to read in any light and I did read a lot over those few days I had it.

I tried it with some books and articles I had on my computer in PDF form, but I was mostly reading Peter Schiff’s “Crash Proof” which I have in both electronic and paper form. I was able to get a hundred pages further into this great book within just a few days – while the paper version has been collecting dust on my bookshelf for some time now. The reason is simple – eSlick is lighter and smaller than even this one book and therefore so much easier to carry around and get those quick reads while waiting for a bus, taking a break from work etc.

However, eSlick did have one annoying quirk with advancing pages. The device has just a few buttons (probably to reduce costs) and they are laid out in such a way that only the biggest square selector button is comfortable to use. This main button also serves the purpose of advancing pages – again, not very comfortable but enough to serve its purpose. However, the problem was the device was like falling “asleep” during the time it took me to read a whole page of my book. When usually just one press got me to next page after reading through it I had to tap the button a couple of times to get any reaction. This was distracting, because I had to mentally disengage from reading and keep on looking at the LED at the top of the device while taping the button to see when I’ll get the device to react. And it also did hang badly a few times – once I had to press simultaneously reset and power buttons to get it back to life.

Also, eSlick can only do PDF and text. And it can’t handle password-protected PDFs, so my attempt to read my copy of the PMI PMBOK failed with “corrupted file” error message.

But even with all those quirks and limitations I was starting to like the idea of having an e-reader after those couple days with the eSlick. So, when Paul handed me his Sony PRS 505 I expected an even better experience. After all Sony has been into ereaders for some time now and PRS 505 is a very popular reader.

The PRS 505 is much sturdier than eSlick thanks to its metal casing and – frankly – has a way better design. It is also significantly heavier. Keys are laid out in a way that makes it much easier to operate even with one hand and the navigation software is also superior to eSlick’s. However, I was utterly disappointed with it.

First, the display is much worse than eSlick’s, which was a surprise as it is based on the very same e-ink technology and I think made by the same company. While eSlick’s screen was crisp and sharp Sony’s looked dull and grey. The background was light grey and characters dark grey – not black on white paper-like display of the FoxIt’s reader.

But even worse, the Sony’s software can’t handle PDFs properly and above all fails utterly at zooming in any format maybe except plain text.

Only after trying PRS 505 I was able to appreciate way eSlick handled PDFs – and especially zooming in on them. eSlick zoom is what you expect it to be: when you zoom in it is the same page, laid out in exactly same way, with same typeface, same diagrams, pictures and sidebars only bigger. Not so with Sony – there zoom means reflow, that is a crude attempt at extracting plain text from the file and displaying it with built-in fonts. So on my “Crash Proof” PDF I had the option of either trying to decipher minutely small print of the 100% zoom or suffer with the reflowed version, without diagrams, with sidebars text just messed up with the main text etc.

Paul suggested that Sony’s zoom may work better on books from Sony’s ebook store which are specifically optimized for the device, so I tried “The back of the napkin” which Paul had on the device (great book BTW, will have to read it one day). Again, zoom failed miserably – while it zoomed text nicely it completely failed to zoom the images, so again it was hard to decipher them – and in this book they are quite an important part. Maybe there is a way to zoom them that I was unable to find, but certainly not by just pressing the zoom button as one would expect.

So, for those two reasons I didn’t read much on the Sony and in fact look forward to giving it back to Paul to get rid of it. To my utter surprise eSlick offered an overall better experience, especially thanks to its way superior display and better PDF handling. If they only fix the software glitch with advancing to new page I think I would be happy with it. In any case even as is it’s the clear winner in this comparison.

Also, after considering it I think that I like some design decisions Foxit made to keep eSlick reader simple. The fact that it handles only PDFs and not dozens of ebook formats like other readers maybe a very good design decision – after all almost anything can be converted to PDF and it is definitely the most popular format for books, articles – any written material other than web pages. The fact that it doesn’t have connectivity means you are kind of forced to focus on reading and are not tempted to browse the web, check blogs or download new content as would be the case with other readers.

Overall Paul did succeed to converti me to the idea of having an ereader and I think I’ll be buying one myself pretty soon. I’d just love to test hands-on (or, rather, eyes-on) the BeBook before I finally decide.

Anyone out there willing to lend me one for a week?

Every new programming paradigm or idea coming along since computers crawled out of government labs had “better quality” as part of its promise. Yet somehow we are still surrounded by unreliable, poorly designed software. Making it more graphical didn’t change it fundamentally. And sadly web applications are no exception.

At first at least “hard to use” part was partially solved, because the web interfaces were simple which made them clean and easy to grasp. It also made them fast. Now, however this is quickly becoming a thing of the past. Modern web apps are full of heavy graphics, JavaScript is being pushed to the limits of its capabilities and the result is heavy UIs browsers barely cope with. Opening a few of those modern web apps in Firefox makes it the most CPU consuming process on my system, usually eating lots of memory (and frequently leaking). Frequently sites display errors, get overloaded or otherwise malfunction.

Why it is so? Let me offer two reasons, that don’t exclude each other so both can be true.

First, I think we are all spoiled by the computing power and memory getting cheaper and more abundant. In the past machines changed very slowly. For example the C64 I mentioned didn’t change at all over a period of 10 years, yet software for it did improve immensely. Programmers studied the hardware and by late eighties made it perform things the machine’s original designers didn’t think it would be capable of. That was truly pushing the limits.

Now if an application is a resource hog it is easy to just give it enough to make it run. That’s why each release of MS Office is slower and bigger than previous with marginal functional improvements. Same happened to web browsers and almost all desktop apps. Increase in speed & memory sizes mask the fact that today’s desktop apps are usually bloated and slow, but only to a certain degree. The subjective perception is that they work as fast as the previous generation and everyone accepts that – even though everything should run way faster considering how much the machines this software runs on improved.

Clusters and now cloud computing made it an easy solution for server-based software too – and that’s what web apps are apart from the UI. You can throw a whole bunch of servers on the problem and forget about optimization. And this works, also economically. Sites still make profit on mediocre codebases, because the computing power is cheap and because usually very little depends on web apps. If they break or run slow no one dies and nothing of importance is lost – the impact of low quality is not easily seen. So, there is no economic incentive to improve.

This and overall acceptance of software as buggy (effect of customers being trained for decades to accept dismally poor software from Microsoft) causes buyers of software products to accept low quality as the norm. They learned to live with it and it takes some effort to bring quality into their prospective at all. In fact, I think even some of our clients don’t appreciate all the effort we put into optimization and testing because they don’t see benefits of having a piece of web software that is robust and scalable.

Second, I think many of the web applications today are created by people with little or no education (formal or otherwise) in computer science as such. I think many of “cool web 2.0 kids” have no idea how the computers they use really work inside. I don’t think many of them know for example what preemptive time sharing is let alone are able to calculate the computational cost of the algorithms they use (if they know this difficult word with Greek roots). Very few know and understand the operating systems they use or ever heard of highly available design and other such practices.

Tim O’Reily’s predicted in late 90-ies that easy web technologies (which back then meant PHP and early CMSes) will allow people with little or no technical knowledge to express themselves on the web. And indeed they do – but much of this “creative expression” is, well, crappy software.

All this means that despite everyone saying a lot about quality there is very little push to actually deliver it in web apps. In fact, quality is squeezed out of prospective from both sides. Client’s don’t care for it when they order their web apps and developers frequently don’t have the knowledge necessary to deliver it.

The upside is that this will change as more and more will depend on IT systems that are based on web technology. Crashes, data loss or hour-long “scheduled downtimes” (like Twitter’s) won’t be acceptable. And also the buyers will with time bear the cost of neglecting the quality from the start and – learning from their mistakes – will insist on it in their next project. Which is great news for us, because we already have the knowledge and practices in place to deliver web apps that are also good software. In the meantime we have to keep on educating people that even in web apps quality counts.

This tool supposedly invented to help people share what they are doing with friends has become one huge fest of shameless self promotion, a true 21st century global vanity fair. This self promotion seems to be centered on one thing: being “cool”. Maybe it’s the people I follow but in many of the tweets (that are not re-tweets and links) I see a disproportionate amount of words like “great”, “awesome”, “exciting”, “kick ass” and – of course – “cool”. All those messages paint an image that is reflecting our current culture as we already see it through mass media’s twisted lens: everyone is doing something exciting on groundbreaking projects in fancy offices of superb companies, then “chills out” at chic clubs or doing some “crazy” activities. Then goes back again to their “cool” work. Everyone is young, physically attractive, smart and interesting. Everything is “cool”.

This image is not new. It has been the backdrop for most advertising for decades, as vendors promised people entry into the paradise on Earth if they buy a pack of coffee or a fancy car. The change here is that before it was just the advertisers pushing this type of BS out in paid slots and now it is the masses trying to market themselves, their jobs, their lives – and in that and through that live up to the ideal they all try to follow and seem to subscribe to: the un-holy grail of coolness.

The desire to follow this ideal – or anti-ideal rather – is not new, too. Ever since mass media – and especially all-persuasive moving images coming from TV screens – started to push this unreal model of life people wanted to live up to it. But before masses could only buy products advertised and try to imitate the behavior and look of the “stars”. Now they can join the band and broadcast their own version of the “brave new world”. On Twitter. And Facebook. And possibly other sites like it.

In this sense the “social media” both reflect the state of society and amplify the trends that shape it.

I hope this is just a shinny facade people put up there and deep inside they realize life is so much deeper and more meaningful. But some are so good at advertising I start to suspect they believe it.