Wood for Trees

Basketball ... wasn't that team sports?

2010-11-29T09:03:00.000+01:00

My son plays basketball. This weekend, they lost the game. The guest team was simply too strong, well maybe that's too much honor for the "team". There were two players in the team, talented and strong, who scored all - but 4 - points, the rest of the team was "tolerated".
In our team, we do have a star player who put 1/3rd of the points on his account, but almost all other team members scored as well. My son is not that star player, but he's doing well and made a number of nice points. I'm glad he's in our team and not in the winning camp. What happens when one or both those top scoring players get injured, sick or simply move on ... game over.

Throwing work at people or throwing people at work

2010-07-09T09:24:00.000+02:00

Shuffling people around, moving them from project to project, pushing them into multitasking is one of those management errors we seem to be making all the time. The scary thing is that still a substantial part of the management population is convinced that this is the most optimal way to use scarce resources ("human resources", people are treated the way we treat machines, as if they were "mechanical", swapping in and out). We have tasks to do, well let's throw the right people at it, done.
In the agile mantra, we believe that throwing work at people - instead of throwing people at work - is a much more effective way of working. We learned the fundamental importance of team dynamics, the fact that it takes time to build and that the fastest way to make it vanish is to the frequently change the team composition by swapping in and out people.
The recipe is to define projects with a broad enough goal/mission (expected throughput time at least a couple of months), assign a dedicated team to it with people full time assigned to it (exceptions are allowed, but stick to exceptions). When new tasks/stories pop up, push them to the most appropriate team (task closest to the project goal/mission), and let it be handled as another requirement/story on their backlog. Don't micro manage, but ride the waves of team dynamics.

When the Wolves try to speak Sheep

2010-07-06T16:02:00.004+02:00

My "agile" adventure started back in 1999 when I first read Kent Beck's "eXtreme Programming explained - embrace change". Those were the glory days of RUP and CMM ... process, process, process. Kent's story was - like Tom Demarco's "Peopleware" classic - about people, people, people and the craftmanship of software engineering.
But making the move from process-focus to people-focus in order to achieve hyper productivity in software development is a fundamental paradigm shift which is in our industry, not the natural next thing. When hitting the radar, the process and Command&Control guys laughed ... a couple of years later, they showed wrong.

Over the past 10 years, the agile wave hit the shores of many businesses and service companies (first in the US, later on in Europe and the rest of the world), and many organizations adapted to the agile slang. The wolves learned to speak Sheep, but they're still wolves. They preach "self-organizing-teams", but continue to micro manage and fill books with rules, roles and responsibilities. They preach "refine your plan as you go", but still expect detailed do-or-die gantt-charts with quality/scope/means/time all fixed and carved in stone. They preach no-big-design-up-front, but expect massive architectural diagrams in iteration 0. They preach trust, empowerment and engagement but manage by fear.

They speak the language but didn't make the paradigm shift, and I doubt that they will ever do as it's about embracing change and uncertainty, something most of us fear.

Nothing against wolves, as long as they speak Wolf.

Breaking the spell

2010-07-06T15:30:00.003+02:00

The team I inherited has a bad reputation. They live in their own little world, don't see the big picture, there's always someone else to blame first ("them"), and nagging is like second nature. I recognize a bunch of losers when I see one, but this team is not. It's a talented and committed crew, hidden away in it's silo for years.
I'm committed to let this team break the spell. I'm questioning and challenging everything to blow the "that's the way it's always been"-dust out of our minds. As a wake-up call to not wait for the future but make our own future happen. Over the last couple of weeks I feel the energy is loading again with small sparks of new life. This morning, someone who was assigned to leave for another team asked me if he could stay ... we are moving! It's worth to stay on board! You can not imagine how it filled me with joy. Thank you team!

2 years of silence ... I'm alive!

2010-02-15T15:46:00.003+01:00

On Wednesday, it will be exactly 2 years since I'v written my previous blog message. It's been a hectic period of focus with hardly any time to reflect. Now, with a next tidal wave of change ahead, looks like looking at the compass is the right thing to do.

Casting - or How to get rid of the Sandbox organization

2008-02-17T12:21:00.010+01:00

Nowadays, the “sandbox” metaphor is frequently used when talking about security and trust where the sandbox restrictions provide strict limitations on what resources the can be used for what. This same metaphor I see applied to organizations. Essentially, people that act only within the sandbox, much as children are allowed to make anything they want to within the confined limits of a real sandbox. The boundaries of the sandbox provides security to the outside world – what happens within the sanbox has little to no impact to the outside world – as well as to the sandbox itselft – what happens outside the sandbox has limited impact on the inside world.

Have you ever worked in a Sandbox organization? Let me illustrate what I mean. In a Sandbox organization, people are empowered to get things done, as long as they stay within the borders of their 'sandbox' (area of responsibilities). These same people – and even more their managers – guard the sandbox boundaries for interference from “outsiders”. In these organizations, business processes are chains of sandboxes. Each sandbox takes care of internal optimization which works well ... at least for that sandbox. But the overall effectiveness of the process chain offers "room for improvement".

Roots of Sandboxing:

Sandbox organizations emerge through - fast - organizational “growth” flavored with spices of "change" and “heroism”. These organizations typically do not take the time to "refactor" which again is catalysed by growth, change and heroism leading to a next level of Sandboxing eventually leading to a state of imobilism.

When it comes to growth and change, these are factors that are required throughout the whole lifecycle of an organization. The heroism factor, what people typically call a "cowboy mentality" works fine in start-up organizations that need to provide results in a limited time frame and with limited resources. To state it more bluntly, in these start-ups, going the "heroism" way is a matter of survival. But once an organization has passed this stage, it needs to apply a more long term strategy, also for the development of the internal organization. What worked fine yesterday, is maybe not what is working today, and is probably not what you need tomorrow.

The reason I stress on this “heroism” factor is because it’s the factor that sneaks in – like the Trojan horse – and settles down in terms of legacy achievements.

Effect of Sandboxing on corporate culture:

Getting "involved" in someone else's sandbox is "not appriciated". This leads to a reaction of protectionism that after some time gets embedded into the corporate culture. People defend the borders of their sandbox as if it were a matter of life or dead. People who act outside the sandbox are "they", people in the sandbox are "we". "They" are losers until the day they get transferred to our sandbox, than they become "experts". Managers, in charge of a sandbox, in many cases stimulate this and turn the optimization of their sandbox in to a top priority.

Tearing down the Sandbox culture:

Corporate leaders who become aware of the fact that their organization has become sandboxed, typically start by reducing the number of sandboxes. Departments get merged and as people become part of a same sandbox - after the transition period - their way of working together improves and a new suboptimal process link emerges. Until the new sandboxes have become legacy and the problem starts all over again.
Removing all the sandbox bounderies is not feasible and even if it would be feasible, it would lead to chaos. The problem is not the organizational structure (as we know by now, the "ideal" organization structure does not exist). Departments will always become "sandboxed" as long as we do not tackle the sandbox thinking between the ears of management. In most organizations, this sandbox thinking is stimulated through incentive programs that focus on the suboptimal instead of on the end-to-end process performance.
Dealing with the Sandbox culture takes courage and the more “heroism” that was required to build the organization, the more courage it will take to refactor it.

End-To-End process thinking:

What is causing the sandbox thinking is the fact that people are not able to or even refuse to reflect on the big picture and the effect their activities have on this big picture. Literaly: “thinking out of the box”. Senior management needs to become aware of this and of the negative effect lack of it has on the overall performance of the company.

Casting:

Casting is about "The right man/woman on the right place". In the context of sandboxing, senior management needs to be aware of doing effective casting. Giving a "sandbox" manager a bigger "sandbox" is not going to make him and "end-to-end process" manager. It will ease the pain for some time, but the root cause has not been removed. He/she will again run into the borders of the new sandbox. When he/she finally becomes CEO of your company (that's the biggest sandbox you can offer), you'll find out that he runs it as a sandbox, refusing to see that your company is also "only a link" in a bigger end-to-end process. The longer you wait to deal with the real root causes, the harder and more painfull it'll get. Soft doctors make stinking wounds.

incremental development

2007-09-04T21:45:00.002+02:00

When years ago, I first introduced RUP based software development life cycle into the software organization I worked for, the first main hurdle we had to take was moving towards iterative developent. To many developers and managers this was a shockwave very hard to deal with. Eventually, it all worked out. Probably because iterative is much like waterfall, but than a series of little waterfalls instead of one big waterfall.
Did we increased our capability maturity by doing this? Yes we did. And honestly speaking, we were quite happy with the result. This success was probably making the next step more difficult.
The next step was the real paradigm shift: incremental development. Convincing people who did big-upfront-design driven development all of their life to switch to incremental developent is not an easy task at all. Those people live and dream in terms of future proof designs and database models before the first line of code is written. It took a lot of energy and hand-holding coaching action before people were ready to give incremental development a try.
Recent experiences in another company proved the same findings. It's very hard to make people leave the tought that big up front design is the only viable option there is. I even discovered that it's even more easy to "sell" them agile practices as TDD or even pair programming, than to change their ideas on how to come to a decent design and architecture. The positive side of it is that it's worth the investment. Once they experienced it's working - even for their projects (as people are always convinced that the things they are working on is the most complex matter one can imagine, and that these practices are not suited to deal with this level of complexity ;-) - they never want to go back to the old paradigm. But it's a hurdle that is not easy to take. It requires courage of the involved people and coaching from someone who's been there to make it happen.

"Agile" certification

2007-08-27T16:16:00.001+02:00

Well, I guess it's the normal thing to happen, when things get mainstream, the temptation for people to "milk the cow until it drops" is stronger than the principles they used to defend. When I see what is happening around the "certification tracks" that are developed around Scrum, I must say I get mixed feelings about it.
More or less 10 years ago, when Scrum went public next to Crystal Clear, ASD, DSDM all in the shadow of the extreme XP, to me it was one of the more pragmatic flavours of the agile movement that was taking off. In contradiction to the black-and-white take-it-our-leave-it gospels of XP, it was bringing a clear message with the focus on the project management aspects of running a software development project. When looking at what is happening today, XP practices like TDD, pair programming, refactoring, continual integration, ... have become a commodity to modern software teams that take their job serious. The "extreme" aspects have disappeared (although there will always people who love to go for religious wars). I have the impression that the Scrum guys just go the opposite way. They try to score by shocking the people they should try to convince. You can discuss about style, and when looking at the effect XP had on the software engineering community, why wouldn't is work once again for the project management community?
It brings me back to the point I want to raise here. Is commerciallizing these agile ideas embedded in methodologies like Scrum the best way to bring the intended change. From what I hear from peers in my network, they are not really happy about it. Although we do not deny that Mike and Ken earn some return on investment on what they brought to the SE community. Still many people get the feeling, that money has become a bigger driver than the principles of the Agile manifesto.
What was fundamentally different between the agilists and the previous generation of methodologists is the fact that although these gurus all came with their personal flavour of implementation, they all subscribed the same basic priciples. But do the current practices of expensive certification tracks match with the open-source philosophy that turned the agile movement into a success? Eventually, what will be the difference between the more rigid methodology tracks like RUP & PMI which live on commercialization versus the agile practices and Scrum.
I do see the advantage of this commercialization as it will help agile practices entering into the more concervative type of software organizations, as to them something only has street credibility when expensive training and certification programs are required. But will it change them into agile organizations ... I'm pretty sceptic about it. Going agile is a paradigm shift, it's not something you do by following a training or passing an exam. It's something between the ears of people and no certificate will help making that switch ... it only helps upgrading your CV.

Root Cause: design smells

2007-06-26T19:37:00.001+02:00

While auditing a software team, I ran into a maintenance project where the estimation of a modification had been underestimated. Looking into the details, the project manager stated that he underestimated the testing effort required. While testing they run into the typical case of "collateral damage" ... you change something here and it goes wrong elsewhere. Digging a bit deeper, showed that this was mainly caused by a software design where tightly coupling was key. "yes we know, as design is evolving, we need to refactor every few years ..."

Refactoring ... every few years ?!? ... How does this fit into one sentence? The weird thing was that even after pointing out the need for a more loosely coupled design and layered architecture, the team was still not convinced that they should focus on refactoring instead of modifying their estimation capabilities. When it came to refactoring, they did not really knew how to sell this to the customer ... make it part of your definition of "done" and just like continuous integration, do it on a daily/frequent basis that will lower the "pain".

Who am I to blow against the wind

2007-06-20T21:08:00.002+02:00

In a recent discussion on the implementation of agile techniques, I ran into the aspect of "courage" - one of the cornerstones promoted by the eXtreme Programming evangelists. In most of the organizations I rolled out agile techniques so far, there was always some flavour of "courage" required to get things done. But I never really saw it as an explicit requirement. People needed to be convinced of Test First principles, refactoring versus big-design-up-front or pair-programming, but I never had to "stand up and fight" ... eventually these things "sell" themselves if you're willing to muddy your boots. But in a recent implementation, the need for "courage" became key. The tention fields that determined the projectcontext were so strong - we would typically call it a "political" heavy loaded project - that the "common sense" aspects typical for the agile toolbox came to a halt.
Convincing the project team to have the guts to deal with these tention fields instead of going for work arounds was a tough thing to do. Getting people out of their trenches and make them couragous enough to give up the "who am I to blow against the wind" mind-set ... as far as I know, there's no open source toolset yet that can help us on this.

Agile banana box

2007-04-01T11:49:00.000+02:00

Well, in July we 're moving to our new house. To avoid packing rush-hours, from time to time we already fill boxes with things we don't use regularly. Our neighbour works in a supermarket providing us with piles of empty banana boxes which have the right size and strength to avoid overload.

Last week Martine started with emptying our "library". Most of the books can be taken off-line for a few months, no problem. But my books on change management, methodology and software engineering ... that's my territory. So we agreed that I would take care of boxing these in.

Filling the boxes is not really a problem, piles of interesting books, but nothing I can't do without the next couple of months. From time to time I put a book aside "this one I have to keep at hand" ... after half an hour, the pile of books "I have to keep at hand" was enough to fill a box. That's good, this proves I've invested in the right books - sometimes Martine questions my "sponsoring" of Amazon.com;-)

Although it was not the intention, the vast majority of books "to keep at hand" are related to agile techniques. An Agile banana box. The idea of "just enough" methodologies filling up a banana box ... a strange thought isn't it. Is this a sign that these methodologies aren't that documentation averse after all. Or is it a sign of acceptance. Is our "industry" finally buying into getting things done.

Organizational ADHD

2007-03-07T15:13:00.000+01:00

Have you ever worked in an organization that is a typical case of organizational ADHD? Organizations that change their structure all the time - partially or completely - without respecting or even being aware of the laws of change.Once something does not seem to work (or does not fit the taste or ego of a manager), it's changed . Not by refactoring but in many cases by implementing patch after fix after patch. The first organizational "bug" that pops up is enough to go throught the motions again without worrying about the collateral damage that is created. Things never get the time to stabilize. Before people more or less understand what has changed, the organization has changed again.

A first side effects of this continual cascade of organizational changes is the fact that people get into the mode of "wait a bit, it will change anyway".

Another derivative of organizational ADHD is an organizational structure with a complexity that is not in synch with the complexity of the organization's goals set. An hierarchical chrismas tree with loads of managers, all with a very limited span of control and the "right to decide" on a micro piece of the process chain.

Although you find these "bad smells" in all organizations in one way or another, in ADHD organization, you can find them in extreme forms:

"limited span of control": For every "two men and a horse head" (translation of a Flemish saying) there is a manager. This leads to upside down pyramids with more managers than "workers".
"hierarchy over process": due to the fact that managers are all over the place, they need to be recognized and respected in one way or another. Due to that, processes suffer, because they are defined in such a way, that managers and departments get the visibility they "deserve". Resulting in havy processes with endless chains of process steps, and checks, stamps and signatures all over the place ('cause noone can be trusted).
"too many decision makers": for every step in the process, someone else decides on go/no-go
"hidden agendas": The personal "at-stakes" get priority over the end-to-end process or company "at-stakes".
"ego over ratio": Although people know the current way is no good, they don't want to change it as it might damage their position, range of influence, ego.

No change before it hurts

2007-03-07T14:57:00.000+01:00

All in all, our business is doing well. We're selling more products than ever. And if we may believe the analysts, "the best is yet to come".

In the mean time, our organizations get into a comfort zone. Things are going well. We're growing and gaining weight. We know we have "room for improvement", but why worry? We're making money, a lot of money! There is no sense of urgency to anticipate on future change.

But everybody knows that fairytales don't last. Like always, change will come in one way or another, whether we like it or not. Our inovative products will become a comodity (let's hope) and we'll have to come up with the next hot thing. Competitors will emerge. Shareholders will come and go. ... Are we ready for that?

When things go well, organizations fall asleep, and they sleep until a real crisis sets in. In the best case scenario, they "get away with it" by restructuring blindly - and getting the shareholders from their back ... for a while - but for some organizations it's the end of their business.

Stay awake! is the message, not to find your self in a "we knew it but we did not do anything about it" mea culpa situation. Stay alert for the signals, get and keep the sense of urgency alive, make your organization look forward and enjoy the rollercoaster of change. And although rollercoasters are scary - at least for me - they are exciting to ride!

Navi-System syndrome

2007-03-07T13:50:00.000+01:00

The first time I had a car navigation system I was totally excited. It takes you where you've never been before.

Fact 1: It's amazing to see how people tend to follow the instructions given by a machine. Is it the woman's gentle voice that makes the driver obey the guidance instructions - for the women in the audience, male voices are also availabe for guidance. Is it the colourfull map display or the animated arrow icons that provide the necessary "street credibility" and make you follow the indicated route? Or is it simply becouse you don't know your way around?

Fact 2: When you travel in an area new to you, the quality of the calculated route is difficult to judge. But when traveling in an area you know fairly well, you frequently wonder what logic is behind the routing mechanism. Why is this device seldomly calculating the route you would take blindfolded? The system never tends to choose the natural trail choosen by people who commute every day.

Adding Fact 1 and 2 together, cummulated with the increasing congestion of our roads, results in the estonishing conclusion that these devices always get you where you want to go, but you're rarely the first to arrive.

You'll get where you want to go, but when will you arrive?
What has this to do with a learning organization or even with Quality Management?

Many companies build "navigation systems" for their organization. They provide nice process descriptions, policies, procedures, work instructions, guidelines, piles of document templates... all documented and accessible via sophisticated intranets and controlled by state of the art configuration management tools. Quality Management Systems (ISO 9000 series, CMMi, Six Sigma...), with renowned certification programs, stimulate this to increase the capability maturity of your organization

So when you start "driving" around in a new organization, the guidance is only a few mouse clicks or phone calls away. You'll get where you want to go, but again, when will you arrive?

Refactoring Human Resources:
In these well structured and documented organizations, people tend to switch to automatic pilot and follow the guidlines without questioning. I've seen it happening multiple times, the creativity and agility needed for survival in a CMMi level 1 organization, tends to crumble when this organization climbs the ladder of capability maturity. Off course these organizations grow more mature, but what about the agility and creativity of the average worker in these organizations.
As survival is less of an issue in these mature organizations, this agility and creativity could be used for other means. And that's where most organizations tend to fail: refactoring their human resources.

Although I never worked for a CMMi level 5 company yet (lucky me ;-), but I've seen a few acting in the mean time. I've been everywhere between level 1 and 3 in the past years. People stop thinking and lose their imagination, creativity and agility if they are not lead by managers who are aware of these risks and know how to cope with it.
Having process descriptions, procedure for every single task and a job description for every memeber of your staff is fine, but it is not stimulating people to think out-of-the-box and look at things from a "non-documented" perspective. Worse, in some of these organizations, thinking out of the box became a sin once the "certification" is accomplished.

In navigating through an economical climate that changes continuously with an ever increasing speed and frequency, "getting there" is no longer the main requirement. Changing the focus of managment from a purely "operational" perspective to a "change" perspective is the main challenge now. The average manager is not ready for this.

The blue dotted squash ball

2007-03-07T13:42:00.000+01:00

Once a week I go squashing with a friend of mine. There are different types of squash balls. Their properties are indicated by a colored dot. We're used to play with a "Super Slow" yellow dotted one. But this time we ran out of our favorite type, so we had to help ourselves with a "Fast" blue dotted ball.

The blue dotted ball turned the weekly routine into a totally different game. It bounced in all directions, points and sets were lost. Frustration filled the squash court. Until ...until I realized that different situations need a different approach, even when it's caused by a small colored dot.
From that moment in time, the game turned. Ok, it didn't turn into the weekly routine game, but I got the ball more or less under control ... and ... won the game.

The game is yours, focus on the ball.

Silver Bullet Methodologies

2007-03-07T13:19:00.000+01:00

I started working as a software developer in a C, C++ environment back in 1991. At the end of 1998 I made a career move towards the world of Quality Management in software engineering environments. At that time the Agile methodologies went public with XP at its frontline.

I remember Quality Week Europe 1999 where the first signs of this Agile movement appeared. At that time the subject of the day was all about CMM. XP was mainly seen as "extreme" and "not realistic", a brainfart that would soon be gone.

One year later at that same conference there were multiple sessions on XP and although there were still a lot of people sceptic about it, at least some of the XP concepts were accepted as "might bring added-value".

As the maturity of our industry is "rather" low, Quality management is almost automatically linked to "Change". The Agile movement, and Kent Beck's "Embrace Change" theme in particular, has been shaking the tree for the last 10 years.

As the Agile methodologies are rather shocking for the traditional/conservative European ICT community, they form an interesting playground when studying "Change". I've been reading most of the books that are published so far on the Agile methodologies, XP, ASD, SCRUM and their related practices, with as main points of interest "how is change introduced?" and "How to cope with the resistance to change?”

I do not believe in religious advocacy, in my opinion process fundamentalists - whether they are iterative or waterfall, process oriented or Agile driven - risk of being blinded by their faith. And although I feel great sympathy with the Agile movement, there are no silver bullets, a team needs the "processes" - sorry for the ugly word - that suits it fine, neither more nor less. I guess that's what the scrum guys mean with "self organizing".

Getting Started

2007-03-07T12:36:00.000+01:00

It feels a bit strange to kick off a blog, as if I had something to tell the world. What a strange idea.
On the other hand, when discussing agile software engineering practices with many people in my "network", I frequently see a "aha!" reaction. Things that look/sound straight forward or common sense at first sight, are not happening because a number of "only-human" aspects.

Getting into Agile is a paradigm shift that is harder to make than most people expect. I always compare it to the paradigm shift of going from procedural software development towards object oriented development. It all seems straight forward, but when you go through the motions of this change, man it hurts! All those little habits we've built for years, we all have to change them.

Well this blog will dance around this theme, hope you come join - and enjoy - the dance

Lieven