Another one of those observations that just rings true on so many levels is that a single system has components that change at different rates. It was identified by Stewart Brand in his book How Buildings Learn…
The concept of pace layering (Brand 1994, Morville 2005) sees a building as a series of layers that have differing life spans. The site itself has an eternal life, whereas the building structure might last 50 to 100 years. Other layers such as the external cladding of the building or the interior walls might have a life of 20 years with internal design, decoration and furniture lasting for 5 to 10 years. In a rapidly moving world it makes sense to locate the capacity for change in those items with the potential shortest life span and avoid, if possible, creating some layers, such as internal dividing walls, that have a medium term life span and are a potential barrier to accommodating changing activities.
Taken from JISC, via Tom Graves’s post.
In architectures of any kind—software, enterprise,or physical—failure to accommodate for this will ultimately tear your system apart. In any case, accommodating different rates of change, as in gears in a machine operating at different speeds, requires careful design of the interfacing points. Another reason that designing good and enduring interfaces is hard.
Before I left my last job, I moved interstate and the company set up a local workplace in a serviced office. We had a room with four desks and a separate meeting room, hosted by one of the dominant providers. Simple and effective, but also spartan and completely soulless. While that certainly wasn’t why I left, the thought of working in that office for the foreseeable future wasn’t uplifting. At best, a spartan office encourages focus by lacking distractions, but, as humans, we like environments that reflect our personalities and perhaps even our imperfections.
Now take cafés. I love a good one. Not coincidentally, I find that 80% of my work meetings, both internal and external, take place over a coffee in a café. It removes some formality, which encourages more open discussion, and can build better relationships. Sometimes there are almost back-to-back coffees with people through a day. Over-caffeination is a real risk. I also find a cafe an excellent place to work solo, away from office interruptions, and I find my best creative or strategic thinking seems to come from such an environment.
So, the idea… a serviced office in a café. You turn up, maybe to a reserved table, and pay cover charge to the café, maybe $20 an hour. For that you get some decent wi-fi, access to a wireless printer, a power outlet for your laptop or phone charger, and a clean bathroom. The music is discreet, you order drinks and food separately, maybe to a minimum spend. Conduct your business, meet associates and customers, do your work, all in a relaxed environment and without the need to consistently pay your way with coffee and sandwiches. It’s not a substitute for a corporate office, but I suspect good enough for many, particularly solo workers or mobile sales reps.
Maybe it exists already, it’s just not here yet. Either way, I see opportunity.
Not long ago, I considered the “Lean Startup”
a bit of a fad, and author Eric Ries a poster boy of the deeply fashionable
IT startup movement. I’m cynically wary of populism and what the majority
wants so I stayed away. But recently facing the job market again has
encouraged me to think (yet again) about what I can and want to do, and the
book needed to be read, if for no other reason than for topical discussion
in networking coffees and interviews.
On a slightly less cynical note, I am indeed a long-standing if sometimes
cautious advocate of agile approaches to delivering software, and
enthusiastic about the extensions to lean, Kanban, and systems theory. But
I’m no spring chicken hotshot developer either, so my skills and experience
are best served in exploring the enterprise–software boundary, using my
diverse if not generalist technology experiences. Still, like many others,
I am intrigued and impressed by the energy and enthusiasm of the (mostly
web 2.0) startup movement, so I made my A$9.99 Kindle purchase of “The Lean
Startup” and began.
The book has been on the one hand a resonant experience. The ideas have
reinforced my agile inclinations, even outside software, my engineering
mindset, and above all confirmed that we live in an uncertain world, where
any dogmatic view or strategy is suspicious until tested. And on the other
hand it has been a surprise because it speaks to me less about startups
than reigniting agility and innovation in existing enterprises of any size.
It’s about taking a more humble approach to markets and customers, and
elevating learning to a primary activity for everyone in an organisation.
For that reason, I’m recommending it to just about everyone I’ve talked to
lately in the IT business, as an approach to engaging both their customers
better, and also their own organisations and their colleagues. Like big-A
agile, it’s a framework of principles and suggestions, not a recipe, so it
needs individual thought and adaptation, but it’s been the most
thought-provoking book I’ve read all year.
Some brief thoughts on Agile KM…
Knowledge in a dynamic context is constantly in flux. It is subject to continuous as people gain new knowledge from observation, experience (and often mistakes) and discard or modify obsolete views. Attempts to consistently harness this rapidly-changing knowledge therefore need to be agile in nature. To this extent, using the word “management” is a red herring in these contexts. A top-down approach is highly unlikely to anticipate the scope, lifespan, or use of the knowledge generated, and will lead to white elephant knowledge management systems: as a result of classic “build it and they will come” thinking.
As Johanna Rothman points out, knowledge generally exists in people’s heads, and the transfer needs to be done through f2f communication on teams, and in collaboration with other people. More generally, knowledge is created by people and only delivers value when successfully used by others, whether this is tacit or implicit knowledge. Fundamentally, knowledge is social in nature, and an Agile approach has something to offer.
The most efficient transfer of tacit knowledge is when person X, who learnt something, explains it to person Y, who immediately has use for it. Anything that reduces the richness of the communication media between those two endpoints, be it a repository, a remote communications link, or even the passing of time, will diminish the value of that knowledge. As Alastair Cockburn has identified, adding a whiteboard will likely optimise the transfer.
Valuable implicit knowledge is more likely to be embodied in the values and practices that the team adopts. Moreover, in an agile environment they will adapt over time to the changing context. True insight, wisdom, or generalist knowledge will endure as a longer-life meme, surviving social combat with alternative memes, and ideally changing its host DNA in the process.
As a necessary proxy for f2f communication, KM systems must not only be as social as possible, but implement effective memory, to ensure the fidelity and durability of the knowledge they store. A whiteboard, checklist, or wiki are examples of lightweight collaborative knowledge sharing systems. No matter how advanced, KM systems need to provide easy authoring and retrieval, often in collaboration with others, and the success of the system can only be measured by how well the someone’s knowledge actually generates value for someone else. If the KM is not doing this, it’s not effective. Taking an agile approach, through a people-oriented, and continuous-improvement process, will generate better results than a big-design-up-front KM system.
While settling into my new city and looking for a job, an amount of my reading lately has been in the field of Agile. That is, of course, with a capital A, because this adjective is way too fashionable to require a noun.<p /> Although Agile (and XP before it) has always resonated with me, I have a history of working, even successfully, in rather un-agile companies. Although I have introduced both XP and Scrum in previous organisations, I'm still wary of buying a one-way ticket on the Agile train, to coin a dodgy metaphor. While it seems pretty clear that Agile — as defined in the motherhood words of the Agile Manifesto — has become the most effective way of delivering quick returns on software development, it is not universally clear that the Agile approach has automatic application to other business activities. Agile evolved out of software development because of most modern software's recognised properties of complexity, market dynamism, requirements uncertainty, and so on. Do these same properties exist in other fields at a level at which Agile will bring the same benefits? Is there indeed a more universal Agile mindset or analytical lens that can be used for other areas of value creation?<p /> Trivially, the answer to the first question is yes if you consider fields like design, advertising, and music, where collaboration and rapid feedback definitely take a front seat to hierarchy and rigid process. I don't know if it's true, but maybe it's possible that some of the Agile concepts were inspired by successful practices from those fields.<p /> To the second question of a broader Agile mindset, there is certainly movement in this direction. Three books on Agile that I've been reading lately are:<br /><ul><li><a href="http://www.amazon.com/Management-3-0-Developers-Developing-Addison-Wesley/dp/0321712471/">Management 3.0</a>, by Jurgen Appelo</li> <li><a href="http://www.amazon.com/Agile-Project-Management-Creating-Innovative/dp/0321658396/">Agile Project Management (2nd Ed)</a>, by Jim Highsmith</li><li><a href="http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364/">Succeeding with Agile: Software Development with Scrum</a>, by Mike Cohn</li> </ul>My crude mental model now is something like this.<p /><div><div class='p_embed p_image_embed'>
Each of the three books essentially focuses on one of the above areas. From a first pass on each, Mike Cohn's book is a very practical manual of insights and best practices in forming and maintaining successful Scrum teams to deliver software. Clearly, a lot of practical experience of success and failure has gone into this, and we can at least avoid falling into some of the same holes. Although, human nature being what it is, we still will.
Jim Highsmith's book is more dense; it embeds a generic Agile implementation approach in a complementary project management framework, appropriate to a pre-existing mature business context. It can therefore be used to interface and buffer hierarchical command-and-control business managers on one side to agile implementation and delivery folk on the other. Electrical impedance matching between the two mindsets, if you will. Importantly, it includes good coverage of agile governance, scaling agile, and portfolio management, which are essential in larger organisations.
Jurgen Appelo's book is more about applied psychology and complexity theory than software as such, and works well as a complement to the other books. He frames Agile as a logical response to managing complex adaptive systems, such as team software development, and dicsusses how Agile values can be expressed at a management level. It's a wide-ranging and very readable text and updates an amount of traditional management and leadership thinking for the Agile Enterprise.
For me, even though I'm less than half way through it, Jurgen's book makes clear that Agile's scope is not limited to software development. Anything sufficiently complex, malleable, and people-centric can benefit from an Agile approach, whether that is delivering consulting services, a marketing campaign, starting a (non-software) business, restructuring a company, launching a product, or, yes, just building a web site. I've even used it in my job hunting.
Speaking of which, I'm currently available, and itching to put more of this into practice. Let's do coffee.