Since I have posted here about things that are unrelated to my work and I want to do so in the future I decided to keep this site as my personal blog and continue to write about things related to management & leadership on a separate blog. I already copied the relevant content to the new site to maintain continuity plus there is a new post on organizational culture out there waiting to be read.

First, this is the first true innovation in computer UI in years. Last thing this innovative was iPhone’s UI. While Android is – in terms of its UI – merely a clone of iOS Windows 8′s tiles are something new and very different. It remains to be seen whether this UI will be accepted, especially by the desktop/laptop users. By necessity innovative UI has some learning curve that is much steeper between Windows 7 and 8 than it was between XP and Vista/7. But even if people will reject it and MS will have to revert to the “Start” menu (invented for Windows 95 almost twenty years ago) they should still be praised for at least trying something totally new. Brave, risky – and, I’d say, a bit unexpected coming from an aging corporation.

Also, the concept of unifying the UI across devices to deliver a coherent experience on all of them is interesting. It is not exactly new – last time Microsoft tried it the other way round: Windows CE had desktop’s UI that required a stylus to navigate. In Windows 8 the desktop did get the Start screen that was clearly designed for touchscreen devices. While it usefulness on a laptop/desktop is dubious I have to say it is surprisingly easy to work with using keyboard and mouse.

But this concept serves another purpose. I think I see the MS’s strategy behind it. They want to regain lost position in the mobile world by leveraging their dominance on the desktop. They hope people will like Windows 8 on laptops and tablets enough to buy Windows phones to go along with it. This is both clever, daring and something they successfully did before – when they overslept the Internet phenomenon they fought they way back by winning the browser wars from their Windows stronghold. Now they want to do it again and the time is high, because if things continue as they are few years from now keyboard-equipped computers may be used only by professional software developers and the like. So current desktop dominance will become less relevant and it makes perfect sense to us it now while it still matters.

All of that of course explains why they sell Windows 8 for around $50 – much cheaper than before. They will do everything in their power to make sure everyone will be familiar with the tiles interface. One company that certainly hopes this will work is Nokia – but this is a completely different story.

This is a pattern that I see often: a manager that is trying to be everything for “his” team, play all the roles at least a little bit – and in the end fails to do any of them well. I think drivers of this behavior can be different in each case (for example this guy is not a power freak, but rather is intellectually drawn to everything: to him all is interesting and worth exploring, knowing, so he tries to get at least a bite of everything), but the net result is always the same – employees’ creativity is stifled, after a couple of tries their own initiative is gone and healthy self organization has no chance of occurring.

This is, of course, nothing new: delegation was always a challenge faced by leaders. However, the “traditional” delegation was the delegation of tasks – what we call for now is delegation of power, delegation of problems to solve. Even more challenging – so even more managers fail to do it right.

Key takeaway: if you are a leader don’t try to be everything, focus on what value you can provide (most likely strategic decisions or providing a compelling vision or coaching) and don’t get in the way of the team.

Innovation is, by definition, trying new ways of doing things that have not been tried before. If you look at it from this angle it is obvious that more often than not this must end up in a failure. Most things no one tried before are not good ideas – only a few are, but you won’t know it until you try them. And even if you stumble on a really good idea it will need a lot of perfecting and improving before it will be a useful product. “The devil is in the details” – so this process will also involve a lot of failures.

Therefore, in order to have innovation you must make ample room for failure. That means you have to make it safe for people working for you to try new things. They have to know that if they try something new and it won’t work they will praised for trying rather than punished for failing. That is what “investment in innovation” really means. It is not about creating an “innovation department” or buying new hardware or “managing innovation”, it is about being ready to pay for things that very likely will get thrown away.

Someone may ask: what if we can’t afford it? What if we don’t have money to spend on things that won’t work? Then you can always be at least honest with your people (which is always a good idea anyway) and tell them: don’t try new ways of doing things, lets stick to what we know will work, because we have very little room for maneuver this year/quarter/whatever. They will understand. And you will not fool yourself you are “innovating” when you can’t.

But does it really take that much investment in terms of cash to foster innovation? I don’t think so, but this is a topic for a separate post.

This is a fair complaint, the only problem I have with it is that the developers generally deliver. The managers in the end do get what they asked for – at least it looks so on the surface. No wonder they come again and do the same thing. Their whole experience tells them this is how things work and many of them genuinely believe they act correctly by pushing unrealistic deadlines on their subordinates (known under a number of euphemisms like “challenging workers” or “driving folks hard”). How are they supposed to know this is achieved by degrading quality of the end product? Usually they lack knowledge and time to thoroughly check the product and many ill effects of poor craftsmanship in software take months if not years to become painfully visible (technical debt).

In other words developers just train their managers in dysfunctional behaviors, over and over again confirming their experience that those behaviors will produce desired outcomes.

So, if you are a developer: yes, your boss is probably a moron and yes, he demands stupid things – but it is also you who trained him that way by delivering those things. No wonder he comes for more. It is a vicious cycle. Want to break out of it? You have three options available to you:

• keep on doing the same thing – write poor code, quick hacks upon hacks, with no tests under pressure just to keep unrealistic deadlines and occasionally complain out of your boss’ earshot to other developers or a passing trainer/coach/consultant hoping in wain things will change on their own,
• change jobs in hope of ending up in a better environment
• or try to change the current environment by saying “NO!”.

The only problem is that if you refuse to do stupid things you risk your job. And this is where courage comes into the picture. The rule is: if you want to change anything in your workplace you must be ready and willing to get fired over it. Otherwise you will give in, you will buckle – and things will stay as they were.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As you may remember at the end of the second day I made the observation that if I were to describe you with one word I would choose “everything”. This is so because many times you collectively tried to cover everything in your designs, plans and other considerations in an attempt to get it perfect on the first try. That’s why you were unable to complete your sprint planning within the timebox.

It is easy to get drawn into discussing all the possibilities, options and potential risks in the end producing nothing. Our minds get overwhelmed with complexity and paralyzed with the desire to get the right solution on first attempt. Agile approach is to break big, complex problems into small chunks and then fully solve them within small iterations producing working software. So, the agile way is to do something rather than everything – but to do it well and keep on doing something each and every sprint all the time improving both the product and ourselves. By keeping doing something well each day, week, month you can build anything in the long run.

That is how agile breaks complexity with consistency.

This obligation is very much linked to the so-called structural quality (how well the code is built), because this aspect of software has a great effect on our clients and future users of the software we produce, yet it is completely hidden from the clients. Clients can, for the most part, detect visible functional defects (application no doing what was intended, system ill-behaving etc.), but they are usually not equipped to assess how well the software they pay for has been built internally. However, in the long run it is the structural quality that has a higher impact on the total cost of ownership and other financial parameters of a software project. The customers are obviously not professionals in the field of software development, but they trust that developers they hire are. Therefore, clients have all the right to expect good quality (understood as well built, testable, extendable, maintainable code) even if it was not explicitly requested in the contract. However, for now software developers yield to pressure and produce horrendous code just to meet time constraints (commonly known as “deadlines”).

A good parallel is civil engineering. If we hire a construction company to build a building for us we expect it to be structurally safe, built from safe materials and adhering to widely accepted engineering standards. Clients are not expected to be civil engineers or construction foremans capable of personally ensuring it is the case – clients trust builders will do their job properly and by virtue of clients’ trust it is the builders’ ethical obligation. This ethical obligation is so widely recognized in societies, that is has became a legal obligation almost everywhere in the world.

It is only logical then that the same will happen to the software development profession at some point. What I wait for now is a lawsuit that will claim damages from a software development company for poor structural quality of a working software product “delivered on time and within scope”. A client will finally come to claim damages after they find out two years after delivery that while the product works its code is unreadable, it doesn’t have an automatic test harness (unit testes, automated acceptance tests etc.) and it is therefore very costly or impossible to extend it further. I am not a lawyer, but I do think it would be a winnable case.

I wonder if those in the software development profession really need such a wake-up call from the legal system before they will understand that it has their obligation to do things right – not just “on time, within scope”.

[1] By “developers” I understand everyone involved in building a software product – not only programmers, but also test engineers, DB gurus, usability designers etc. etc.

This thinking spills into business. Many startups are created because people want to follow in the footsteps of others who cashed in big selling one (looking at some of them the thinking seems to be: “create a cool service, get noticed, sell to Google/MS/whatever, live happily ever after”). Also, the whole concept of a project is built on the idea that it is an effort with a definite end occurring at a predictable moment – and we can say it was successful when it reached this end as predicted. Done. Successful, closed.

The problem is all of this is incompatible with the current reality. This reality can be characterized by two key aspects:

• Increasing pace of change – technology, social customs, fashions, regulations, markets – all of that changes much faster than it used to and the rate of that change still accelerates. We can safely say we live now in constant change.
• Everything becomes more and more complex. This is largely a function of connectivity. Everything is now more connected and interrelated. Globalization means supply chains are long and complicated – a flood in Philipines impacts now manufacturers in Europe, China and consumers in the US.

  In IT specifically we build much more complex applications and we create way more complicated systems out of them than, say, 10 years ago. Much of this complexity comes from interconnectedness – when we connect systems together their complexity increases exponentially. We also use programing languages and environments that are much more abstract than 20 years ago – this may simplify programmers work, but in the end the applications produced are much more complex.

  To make things worse constant change seems to have just one direction: towards greater complexity. This means increasing complexity.

Clearly, if we consider it the notion of success as an event is visibly absurd in a constantly changing environment of increasing complexity. The basic assumption of the classic project definition is also clearly wrong. Completing a project as planned can’t be considered a success in this environment, because the assumptions made when creating the initial plan will in most cases be long invalid by the time the project ends.

This means we have to re-define success. My proposal is as follows:

Success is a state in which an organization (or a system, a team etc.) adequately responds to its environment.

By adequate response I understand delivering what the environment needs/expects while meeting internal goals/visions. Maintaining that state over time is much harder than attaining it once. To do it an organization must constantly analyze both the external conditions and itself then if necessary readjust itself as quickly as possible. In other words, in a highly complex and unstable environment the only way to maintain the state I call “success” is through empirical control. The problem now is that modern world as a whole is now such an environment.

This has deep consequences. The old management model in which someone bright at the top (a prince, a president or a CEO) would think, invent, plan then communicate to others who will just do as they are told doesn’t work anymore. The level of complexity we face now overwhelms the brightest minds, so we need all the brain power we can harness. This means we must form cells (teams?) and tackle the complexity in small chunks – just like we do when building systems using agile methods.

It would seem then that what we know as “agile” is in fact the only way to deal with the modern world and stay successful in it.

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.