Basketball ... wasn't that team sports?

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

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

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

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!

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

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

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.