https://www.mountaingoatsoftware.com/blog/how-to-ensure-youre-working-on-the-most-important-items-each-iteration Continue reading “Mike Cohn’s Latest – How to Ensure you are Working the Most Important Items”
Knowledge and Knowledge Management
There is a lot of talk about Communities of Practice (CoP). You may have already heard about something called a Center of Excellence (CoE).
While the 2 entities have common goals and objectives and generally support improvement throughout the organization, they are targeted towards different groups and ways of interacting.
As background, it is important to look at how knowledge is gained, and how organization knowledge is gained and ultimately shared and managed. For the individual, a sample knowledge model might look as follows:
The DIKW model:
In this model, there is a representation of how an individual gains knowledge through a process of acquiring data and maturing it. This is a common model and provides a good basis for the value of Training and Continual Learning. Noting that application of Data and Information is critical to acquiring the Knowledge/Wisdom Level.
If you want to learn all about the DIKW model, there is an excellent paper in the Journal of Information Science, entitled ‘The wisdom hierarchy: representations of the DIKW hierarchy’ (PDF) and written by Jennifer Rowley of the Bangor Business School.
Organizations acquire knowledge differently. Typically through the acquisition of people or expansion of the existing workforce’s knowledge bands.
This brings us back to an earlier discussion about Autonomy, Mastery and Purpose. In order to facilitate the knowledge growth in an organization the following CoP’s might be established:
-
- Product Owner CoP
- ScrumMaster CoP
- Leadership CoP
Some background on CoP vs CoE:
Centers of Excellence (CoE)
SUPPORT: For their area of focus, CoE’s should offer support to the business lines. This may be through services needed, or providing subject matter experts.
GUIDANCE: Standards, methodologies, tools and knowledge repositories are typical approaches to filling this need.
SHARED LEARNING: Training and certifications, skill assessments, team building and formalized roles are all ways to encourage shared learning.
MEASUREMENTS: CoEs should be able to demonstrate they are delivering the valued results that justified their creation through the use of output metrics.
GOVERNANCE: Allocating limited resources (money, people, etc.) across all their possible use is an important function of CoEs. They should ensure organizations invest in the most valuable projects and create economies of scale for their service offering. In addition, coordination across other corporate interests is needed to enable the CoE to deliver value.
Communities of Practice (CoP)
SUPPORT – provision of a network of experts from both inside the organization and from outside
GUIDANCE – a CoP can be entrusted to devise and document best practices, standards, methodologies, tools, bodies of knowledge
SHARED LEARNING – Except for actually creating formalized roles in a company hierarchy, a CoP does all the same things as a CoE under this heading, plus provides mentorship, apprenticeships, and access to external informal and formal trade groups.
MEASUREMENTS – besides providing measurements of efficacy, a CoP typically describes what measures are appropriate for the proper execution of the domain of expertise or trade
GOVERNANCE – in this one dimension a CoP differs greatly from a CoE and instead of managing resources, a CoP strives to refine and improve the domain of expertise itself. A central function of the CoP is to improve the domain itself rather than simply managing its deployment. A CoE for project management seeks to improve the deployment of project managers and the like in furtherance of operational targets, whereas a CoP would seek to improve the entire field and practice of project management itself.
These distinctions will serve you well as you plan to improve and harness your organization, and leading transformations into a future of unleashed talent to build your solutions.
In a future article, I will add some additional information to help you further these ideas.
What makes agile, Agile?
The early founders of the ‘agile movement’ we’re just people who had been involved in solution development and just spent time thinking about how they could do their jobs better. They spoke plainly and tried to use basic concepts that could guide their decision making and be repeatable.
Often in our daily lives we will tend to try to make ourselves look ‘smart’, ‘sophisticated’, ‘technical’, ‘innovative’ and so on. usually to do this, we end up sounding like a lawyer or a professor from university.
On a recent trip, I had a chance to speak to farmers from another country. In the US, we tend to see farming as a science now. We use chemicals and computers and computer modeling.
As I spoke with these farmers they told me of how important weather was to them, and their planning. The weather, or bad weather, could risk crops, animals and harvests as well as have negative and ripple effects on other planning. In fact, they spent so much time telling me about the weather it was easy to see this information was extremely important to them and they would not risk getting it from a trusted source.
Interestingly, as the weather report came on the radio in the shop I was in, I noticed no one paid attention to the radio broadcast. I found this really odd, as a tourist I was very interested in the weather too, and while I strained to hear and understand what was being said, they went about their business.
I asked the shop operator if he could help me by explaining some of the terms used in describing the weather better. The operator, in a heavy accent, said ‘Nye’, if you want the weather accurately don’t listen to that ‘Uni’ TV guy, call up the postman.
Without a translator, I felt lost. Why would I ask the man who delivered the mail about the weather? Did he get some special piece of information possibly controlled by the government to ensure mail delivery? Was this kept secret from people who’s lives and livelihoods depended on it? Why weren’t these farmers annoyed and alarmed? It was very confusing.
As I returned to the tour bus I asked the local guide about this odd conversation. The following is how it was explained to me, without the heavy accents and as little folklore as I can use!!
The local farmers had for years complained about the weather reports in the area. They had become so frustrated with the accuracy that they even tried to remove the weatherman on the ‘telly’. He used to ouch science and words to make simple things complex and accuracy and precision were lost as he tried to impress with his explanation of ‘how’ weather was forming rather than getting the predictions correct and timely. This problem lead to the ‘need’ for someone to step in and solve this problem. Enter the ‘Postman’
Every day, after dropping the mail, a local man would go home and consult several pieces of information and create a file for the next day. The file predicted sunrise and sunset, chances of rain, El Niña, La Niña etc, winds and interestingly the tides, and predicted time times, as well as previously reported reports for the dates and accuracy of the reports. Lastly of course was the high and low temps.
This man was not university educated, but rather spent time improving his craft through basic plan, do, check and adjust cycles. Over time, he had become a local celebrity. His passion for accurate weather reports, and experimentation with his own beliefs about what impacted weather lead him to form his own set of experiences and learnings. He didn’t allow what he had been taught to always direct his reports, but instead spent time continuing to learn and adapt this thinking. The goal was not the report, the goal was improving his own accuracy, incrementally, over time.
As I listened to the story I thought how agile of this man. He took his simple principles and followed them, and then applied the data he had to make his next set of predictions about the outcomes. He then recorded the outcomes, made notes about how his predictions had come out, then add any adjustments he felt necessary, repeated the process. Maybe that is really Agile, not agile.
What is your experience? Are you being asked and are you doing, the right thing, right?
Discipline vs. Process
In many organization when they decide to do an agile transformation it is typically to do either a process swap or ‘agile’ or scrum for waterfall. Usually this is done with the noble goal of producing ‘business agility’. The transformation should not be about the business, it should be about the people.
This misrepresentation is part of the common fallacy that causes many organizations to fail in their efforts or to get outcomes that do not measure up to their original business objectives. This false objective causes organizations to focus their efforts on the wrong things. The transformation should not be about the business, it should be about the people. In the end, businesses are not agile, they can only employ people that embrace and exhibit agility. These false objectives stem from some common misconception that process and discipline are the same thing and that discipline and agility are at odds with each other.
Webster’s dictionary defines these notions as follows:
Discipline:
- Control gained by enforcing obedience or order
- Orderly or prescribed conduct or pattern of behavior; self-control
- Training that corrects, molds, or perfects the mental faculties or moral character
- A rule or system of rules governing conduct or activity
Process:
-
- A natural phenomenon marked by gradual changes that lead toward a result: process of growth
- A continuing natural or biological activity or function such life processes as breathing
- A series of actions or operations conducing to an end; especially : a continuous operation or treatment especially in manufacture
Agility:
-
- The quality or state of being agile : nimbleness, dexterity
Clearly business cannot be nimble. It is a collection of people and processes, nothing more. However, the people can exhibit agility and cause the direction of the business and the activities of the business to exhibit the dexterity we associate with people. To achieve that, we must concentrate on the discipline of the people, not the processes that control the business.
Agile is about people and unleashing their creativity and passions to drive outcomes. Processes deliver consistent outcomes, agility drives unexpected outcomes that are directed to the objectives that are desired. Discipline allows agility to learn in a consistent fashion that creates incremental and sometimes extraordinary increases on outcomes.
For a long time in IT we have sought to gain efficiency improvements in a very consistent way. This approach fueled IT growth for a long time, but produced minor year over year gains but never really unleashed the significant efficiencies that can be delivered by the discipline associated with minor adjustments to how outcomes are achieved usually individual creativity and passion.
The connection between agile and discipline is very strong and the very best agile teams consistently use very disciplined approaches to their work so when outcomes deviate, they can trace the deviation, good or bad, to the trigger and can maintain very high confidence in how those outcomes were achieved, and repeat them or improve them.
Ultimately discipline, not process, is what allows agility, in people and in turn, businesses. Your focus on doing the right things right is what will enable and unleash your agility.