Author Archives: Andre - Page 4

Knowledge Management

As Peter Drucker wrote – knowledge is about increasing capability of individuals to do something different or being able to do something more effectively. Knowledge is not limited to individuals, it  also exist  on organization level. However this is the area where it becomes more esoteric.  Although there are different models trying to define and put knowledge into some kind of a structure – I do not think that anybody got it right so far. There are many reasons for this although I think that it is primarily related to complexity of individual mind, and at the same time influences of human interactions as well as factor introduced by environment or context. It exists not only in physical or electronic format but primarily in human mind, expressed by speech, gestures, motions or thoughts. Knowledge management can be positioned on one of the higher levels of continuum starting from data, information, knowledge and ending with wisdom. The complexity of the definition increases along this continuum. Data refers to facts, information is data put into a context, but knowledge is much more difficult to define, not to mention definition of wisdom which increases the challenge even more.

I think that organization’s position within this continuum is indirectly related to information management maturity model.

CMMKMM

 

For most of organizations data and information management, with all their challenges, come much easier to be put on the information management roadmap, rather  than explicit expanding of capabilities through knowledge.

I like Nonaka’s spiral model with knowledge process with intertwined tacit and explicit knowledge (externalization, combination, internalization and socialization), although it has its own limitations. One of the biggest problems that mature organizations face today is to try to codify the knowledge so it could be shared or used collectively. Great example is project’s lessons learned. All project managers know that this should be produced at least at certain stage of the  project lifecycle. And what happens? PMO collects them but very few project managers make any use of them. Lack of standard codification of lessons learned, and related lack of context, make them of little use. The knowledge transfer process breaks.

 

Better approach is to use access to experts to provide coaching for such transfer. The human interaction allows for better alignment with the needs.

 

Big push for knowledge management comes nowadays  from introduction of social networking. It became already part of our lives, however organizations still struggle with the concept and how to tap into this enormous knowledge repository. This is quite interesting topic and I am working on a paper addressing this. Coming soon….

The Mythical Product Owner

(This article was originally published on Pragmatic Marketing.com)

Product Managers must quickly adapt to the Agile methodology, or face becoming sidelined. It is critical to understand the relationship between traditional and new roles within a delivery organization, particularly between the Product Manager and the Product Owner. By Andre Kaminski

Background

Barbara Nelson said in The Politics of Agile, “When product managers weren’t looking, the developers went agile.” Indeed, many Product Managers were taken by surprise at the speed of Agile’s adoption. And with the introduction of a new Product Owner role and its perceived overlap with the traditional Product Manager function, Product Managers have expressed some anxiety about the future of their role.

Agile was borne from frustrated development teams who were constantly blamed for non-delivery and missed business goals. Nothing in life is black and white, and objectively speaking, problems could be found on both sides. Nevertheless, Agile was a response from tactical teams that wanted to control the rules of the game and redefine the criteria for success.

Since the Agile process was created by tactical teams, it concentrates on development practices. At times, Agile may seem inattentive to the environment in which projects are delivered, and to hold idealistic views of reality. However, Agile has many merits, and for organizations to be fully successful, the changes of Agile need to happen not only on the tactical level of delivery, but across the whole organization. It is not enough to have a fully functional and efficient development team that delivers, if it does not translate into success of the company. As product managers, we bear the responsibility for bridging the two worlds – technical and business, and need to influence both. Ultimately, we are responsible for the success of the product and, thus, the company. We cannot point fingers anymore and say, “It was the developers who did not deliver,” or, “It was the business unit that did not have a coherent strategy.” Although there may be some truth to these statements, the art of product management is to influence strategies and plans even if we do not have direct authority over them.

Change must happen on two levels across the organization:

  • Technical – Roles and responsibilities must be understood, accepted, and adopted.
  • Cultural – Attitudes, expectations, political ambitions, and how we collaborate must change.

Obviously, Agile should not be introduced with a ‘big-bang’ approach. Instead, by demonstrating that the new process works on a tactical level, and building confidence within the organization, we can show the way forward for the rest.

In this article I concentrate on the role of the Product Owner. This role is critical to the success of any initiative, and yet it is not widely understood. For tactical teams, the Product Owner represents the business, yet there is no clear definition of who that person should be. Articles or books by technical Agile authors almost always present the Product Owner as a jack of all trades—whatever information a team needs, the Product Owner delivers. Posts on the website of Scrum Alliance (the professional organization of Scrum practitioners) call for more training of Product Owners so they understand what it means to be ‘good’ Product Owners. Clearly they are not getting what they need from this role.

Since Scrum describes what this role should do, but does not say who specifically from the traditional world should play this role, Product Managers are put in an ambiguous position. According to Scrum, the Product Owner can be anybody – the Business Manager, an internal or external client, or the Product Manager—as long as this person is part of the team and can devote enough time to the role. The simplistic assumption is that the Product Owner contributes to the success of the company by performing whatever business-side functions are possible. This assumption may be true as long as this person sees the big picture, understands the market or client problems, sees the market opportunities and trends, and is able to quantify them. In other words, the expectation is that the Product Owner is, at least partly, also the Product Manager, regardless of title.

So there is overlap between what teams expect from the Product Owner and the traditional role of Product Manager, but is this the same person?

Read more »