Recently I have been to a conference, dealing with organizational change. One of the sessions there was about human resources (HR). This is the department of an organization that is supposed to support individuals within the organization. Here people were talking about how to evaluate the skills of employees, how to train them and the role of leadership in all this. At one point during this session a young woman from the audience got up and confronted a high-ranked HR manager from a large German energy provider, also female, with an interesting subject.
The young woman said that she was at the very beginning of her career. She recently read that a study, which shows that the careers of women are often hindered by other women, not so much by men. This sounded counter intuitive to her, as she thought women would support each other.
Or: The Difference between Pre-Launch and Post-Launch of an E-Commerce Project
Every e-commerce project has this one moment that changes everything: The launch. From that magical moment on your efforts are made available to real users and are due to earn real money. The whole organization faces a major shift. The parts of an organization external from the development team change their modus operandi. In their perspective, what used to be an abstract future suddenly becomes an active system facing customers.
It’s a known fact that in any e-commerce project, the development never stops. Throughout the whole project there will be bugs to be fixed and new features to be implemented, no matter on which side of the cut-over you are. What changes is the attention brought to the project from the organization as well as the emergence of topics. Thus, the development of the e-commerce project faces its biggest struggle when switching from implementation to in-life-support mode. This struggle cannot be ignored by the development process.
We live in a world of digital full service agencies and companies that deliver the full brand experience, from a complex technical backend to a fancy frontend. This requires specialists of opposing fields with very contradicting backgrounds to closely collaborate in order to achieve great goals.
Impressive success stories of cross functional teams, where UX designers and software engineers cooperate happily are widely spread [3, 4]. Just as descriptions on how to organize this way [1, 2]. However, these success stories rather document the exception. Truth is that most agencies are struggling with this organization of team collaboration. In order to understand this problem, let’s have a look where the two professions came from.
Large parts of my PhD thesis are based on a theory by Morten T. Hansen, Nitin Nohria, and Thomas Tierney . In their article the authors analyze different consulting companies and define two basic strategies for knowledge management: The codification and the personalization. An organization has to follow one of those, the one that fits to the competitive strategy best.
Note: Most of the text from this post is directly taken from my PhD thesis. That is also the reason why this text is so long and detailed…
Sorry for that. 🙂
I introduced this little Christmas series the other day, explaining that I compare scrum to modern soccer. Yesterday then, I focused the efficiency in both disciplines. Today I discuss cross-functional teams.
As I described yesterday, this is the second part of my little Christmas series, in which I compare scrum to modern soccer. Today I focus on the efficiency in either discipline and tomorrow I will discuss cross-functional teams.
Recently, I became certified by the Scrum Alliance as a Scrum Product Owner. During the course, Craig Larman gave many analogies of scrum behavior to different sport disciplines, like relay races. After all, scrum is a method in rugby.