Agile and Knowledge Management, part 2

A couple of days ago I posted about Agile and KM, this is a part 2 to that post and is a result of a discussion I had at a meeting the day after the presentation.

In the meeting we were talking about the business case for KM and how to best get started once you have some basic level of approval and support, which is to move on to a pilot stage.

Being successful in KM is continually doing this agile cycle: business case, pilot, business case, pilot, each one builds on the success of the previous one, each one is a small, manageable piece of the KM puzzle. Each one matures the people, process, and technology a little bit more. You keep going until the whole organization has adopted KM as a regular and necessary part of its activities and operations and then you continue to evolve and improve your KM activities. While you’re doing all those business cases and pilots, you’re integrating those 10 lessons into the organization’s behaviour.


Agile and Knowledge Management, part 1

At our Knowledge Worker Toronto event on January 23, 2013 our speaker, Gil Broza, spoke about the human side of Agile. Now, Agile, for those of you who don’t regularly interact with software developers, which I imagine are many of you who read this blog, is about iterative and incremental design and development of software applications. Gil was speaking about lessons that could be learned from the experience of software developers in this area and transferred to other areas of the organization. That activity in itself is a knowledge management activity: knowledge transfer of lessons learned, but I digress.

Gil spoke about 10 lessons that the rest of the organization could learn and apply:

  1. People are not resources
  2. Focus
  3. Nurture the joy of delivering value
  4. Take small, safe feedback-rich steps
  5. Mind the physical environment
  6. The social environment matters too
  7. Want high-performance teams? Be ready to invest
  8. Manage less, lead more
  9. Collaboration rocks
  10. Human conduct trumps “best practices”

There was a discussion after the presentation and Q&A ended about how this talk fit in with Knowledge Workers/Knowledge Management, this is what I contributed to the discussion: these 10 lessons are about how knowledge workers like to work. In the KM consulting that I do, I often have a section in the report about knowledge workers, especially when I’m working with an organization that is hierarchical. Knowledge work and knowledge management thrives in a flatter organization model, one where sharing and working together is expected, and the silos of a hierarchy are detrimental to achieving the goals of the organization.

Anyone else have any thoughts?