My Key Takeaways from the TedxToronto 2011

Anybody uses the Internet probably knows what Ted is, and has probably watched at least a single Ted video that has inspired them.

What’s great is that Ted has now come to our city on several occasions thanks to the Tedx program. The Tedx program allows motivated, self organize teams to run localized Ted conferences. I was fortunate enough to attend TedxToronto 2011, and wanted to share some of the key takeaways that I received.

Your Failures, and Your Vulnerabilities Are Critical to Your Success
Perhaps one of the most important themes that I took away from the conference was that your failures are more important than your achievements. Learning never happens if one is always successful, real learning comes from failing, and for that learning to happen failure needs to be discussed with others, and problems need to be brought out into the open and given the same press and publicity that success does.

While this point was alluded to several times in various video and live presentations during the day, Dr. Brian Goldman’s heart rending talk on his own personal failures during his long career as an emergency room physician really took it home.

Goldman started his talk describing how the expectations of the medical system were completely out of whack with reality. A batting average of 1000 was how he described expected success rates. This translates to a 0% failure rate. Dr. Goldman patiently described how he measured up against these expectations, taking us through a number of his "failures" during the beginning of his career. In several of these occasions patients had either died, or nearly died as a result.

In his experiences with the medical system, each failure was dealt with by sweeping it under the rug and keeping things as quiet as possible. Failure was something that was not officially accepted, and in his experiences not openly discussed. Brian described the dehumanizing effect of combining completely unrealistic and arbitrary targets of success with a culture of zero tolerance for failure. The result was isolation, shame and feelings of unworthiness after each mistake. Each failure resulted in Dr. Goldman questioning his right to even be in his chosen profession, and even his self-worth.

More importantly, Dr. Goldman pointed out the catastrophic effect of this attitude towards mistakes on the medical profession itself. An institution that does not discuss failure cannot learn from those failures, professionals within the institution are at risk of repeating each others’ mistakes, and the cycle of unrealistic expectations marred against human reality continues. Organizational learning takes a long time in these kinds of environments, it’s truly difficult to meet the change necessary to improve, an unfortunate state of affairs for profession as important as this one.

Dr. Goldman alluded to a critical piece of feedback missing in his profession. Learning to accept failure means learning how to minimize the cost of that failure, as well as learning how to minimize repetition of the same failures. What was especially intriguing about Dr. Goldman’s presentation was his admission that his biggest failures happened at the end of his career, not at the beginning, and that according to him this is common with medical professionals. (although most would go to great lengths to deny this)

At the end of his session, Goldman talked about his work in reaching out to other medical professionals to give them a venue to discuss their experiences and discuss their challenges out in the open. Dr. Goldman received a standing ovation from the audience, and I believe his candor, openness, and willingness to be vulnerable in front of such a large audience made him one of the favorites of many the session.

On a side note we were also presented with a powerful video by Byrene Brown on the power of vulnerability. IMHO pointing to a similar meme.
The Network Is the Organizing Metaphor for This Century
In the 1900s the hierarchy was king. Economies of scale were established by gathering groups of individuals under managers who would set direction, enforce rules, and ensured everyone marched to the same drum. Managers were grouped together under senior managers, senior managers reported to executives, and executives reported to the big boss or big bosses. People gave and followed orders.

Certainly the need for hierarchical organizing structures have not gone away, and they probably never will entirely. However, there is another important truth, a new metaphor for thinking of how we really organize to create value in today’s information age, and metaphor that has become especially predominant during the last several decades. This new metaphor is the is the network, and specifically, the Internet.
Community activism, network-based learning, algorithms to find information, social media, service-based delivery, are all based on the concept of the Internet.. The concept that self organizing units who are primarily defined by their interactions with each other is what I’m talking about. Community activism, micro search, nanotechnology, social media, you name it, these are all examples being presented to me at TedxToronto. The ability to map together units to create value using a loosely defined network provides a combination of both flexibility and structural integrity that supports today’s massively changing world.

My favorite example was Nicholas Schiefer, a grade 12 student at holy Trinity school, who is already much smarter than I am. Nicolas came up with an ingenious way to conduct effective searches for really small pieces of text, think micro-blogging or Facebook statuses.
Nicholas’s approach was to map a network of likely associations between words, the stronger two words were associated the closer they would be on the network, he would then traverse the network using a random walk algorithm, which would result in stronger word associations getting higher counts than lower associations.
I love Nicolas’s redefinition of word:
an atomic unit of meaning, with associated semantic baggage.
I think that definition could and should be extended to a whole slew of things, organizational departments, people, job descriptions, etc.
Nicholas’s view of the world is insightful, he’s able to perceive that things aren’t what they are because of their attributes, they are what they are because of their interactions with the things that surround them. This is key to the network view of the world, it’s one of the fundamental principles to consider when thinking about today’s work environment.

Technology Combined with Social Concerns Enhances Our Humanity

During the day there were several prerecorded Ted sessions that the audience viewed. A really intriguing one was about Khan Academy, where conventional thinking around education was turned upside down. Classroom sessions consisted of students watching videos on their own time, and homework was done in class using computerized lessons, but supplemented by teachers who are always on hand to provide answers to questions, and on the spot learning sessions for difficult topics. In this case technology was used to maximize valued teacher to student interactions.
Another prerecorded video showed how Deb Roy recorded his family’s interaction with his newborn son, mapping how he was able to acquire new words, associating it with patterns of both parent and child movements along with their interactions with each other (he called them time worms) as well as how words evolved over time. What was really interesting was that the child’s progress in terms of learning new words to progress at a more or less linear rate until just before the child was about to completely be able to say the word, at which point he would regress back to a very early versions of the word. At this point the child dramatically started to speak the (mostly) proper pronunciation. Again the notion that success comes just before the point of largest failure seems to apply, interesting if this pattern applies to other learning systems, I seem to recognize this pattern in my profession as a coach for knowledge workers.

The Status Quo Simply Isn’t Acceptable Any More
There are so many examples of this theme throughout the day that it would be possible to reference most of them. Some of the more obvious ones are:

• Made Wade and Truth Is great performance on redefinition
• Adame Garone’s story of mashing up two very important concerns, helping prostate cancer research, and getting mustaches back in style
• Brandpn Day’s determination to found the Black Daddies Club (Brandon let me tell you, you are an inspiration to a new father)
• Ted Sargent’s passionate quest for affordable solar heating
• Bilaal Rajan’s refusal to say no, and redefine child activism
• David Miller’s passionate plea for citizens not taxpayers, (although I found his message was diluted by old-school right versus left rhetoric)

Toronto Has the Energy for Constructive Change
the work I do and the people I serve make it necessary for me to work in fairly conservative/traditional environments. It was refreshing both listen to sessions, to listen to and interact with (there were several during several "conversation breaks" as well as at the after party with other like-minded individuals) to a variety of diverse individuals, where innovation, courage and desire to do things differently were things we all had in common.
TedxToronto was an opportunity to reconnect with principles that are important to the work that I do, and it was a welcome chance to talk to other motivated individuals who are passionate about changing the world around them.

And of course what’s probably most interesting about this post is not my comments, but what I left out, if anybody who attended the conference reads this, I’d love to hear what we are the key points that you took away?
..

Kanban adoption-Lessons learned

A client of mine asked for a list of lessons learned while applying kanban, so rather than writing it up and send it off in the mail, I thought it would post it here for everyone to enjoy.

I should add that all these lessons were actually learned, and that we made every one of these mistakes at some point and had to learn the hard way not to do it again :-).

Introducing Kanban at the same time as other major structural changes.
While Kanban is positioned as a change management and change catalyst framework, effectively using Kanban does require a (sometimes extreme) shift in thinking. Our experience has been that Kanban should be adopted on top of a working system already familiar to staff and management.

The introduction of a Kanban toolset could be coupled with other big changes, for instance, institutionalizing brand-new capability. The risk however, is that these "big changes" foster resistance often found with change management initiatives. This can cause staff and management to resist the Kanban is it becomes directly associated with these changes.

Detailed, upfront analysis of process components
There is a tendency for many organizations to engage in detailed design activities to get an understanding of demand, work types, and supporting processes & policies. There is a desire to start with a nearly perfect Kanban system.

Our experience again shows that there is a fairly steep slope in terms of the law of diminishing return when it comes to upfront analysis. Kanban systems can be effectively set up with a minimum amount of upfront work, and progressively refined over the first 1-2 months of adoption. As these systems are easy to refine, it is better to get started sooner with imperfect information.

Ensure that Kanban systems reflect work as it actually is completed by management & staff
There is a desire to try to "fix" processes while modeling them to prepare for a Kanban implementation. This should be avoided; we want to avoid the possibility of "shadow" processes, where the official approach deviates from what is actually going on in the organization. We also want to avoid designing a future state solution unless performance can be measured against the current state, this requires that can then be set up to reflect the current state.

Avoid enforcing changing work conditions in a desire to create the optimal Kanban system
Associating changes to the work environment (such as co-location where did not exist) to support a Kanban system can foster resistance to the approach, and is counter to the Kanban method. As much as it is practically possible, existing conditions of work should be respected. Rather than trying to change the environments of work to support a Kanban pilot, is recommended to select a pilot where more favorable work conditions already exist.

Start out with Low inventory levels and raise them if you need to
The amount of inventory that a particular system is allowed to consume is inversely correlated with the amount of change you want to introduce to that system of work. Starting with a large inventory level is a natural choice for those who want to follow a conservative approach to change.

That being said or experience suggests that Kanban systems with high amounts of inventory tend to completely obscure early identification of bottlenecks, blocking issues and other problems. Larger inventory systems are also hard to maintain and manage, causing workers to abandon the Kanban approach completely.

An approach that we have found to be more successful is to start with a lower WIP level, such as 1-1.5 unit of inventory per knowledge worker. This causes bottlenecks to form extremely quickly, making it clear where opportunities for improvements exist. Instead of immediately tackling these bottlenecks, which can be challenging for lower maturity organizations, make it clear that the team can raise inventory levels as necessary to avoid immediately tackling these bottlenecks as they form. This will allow the team to take note of every time they have to raise inventory level, this is a potential opportunity to improve when the team has the capacity to do so. This strategy allows more conservative teams to get better visibility into the nature of existing improvement opportunities without having to tackle these issues early on in the Kanban adoption process.

Expand scope of Kanban boards to reflect all work being completed by staff for a specific capability
A typical use case for Kanban adoption is to use Kanban to support the work of one project. Very early on, it is discovered that a significant portion of the work being assigned to various project members are actually not part of the project being represented by the Kanban system. Work is often blocked simply because an individual is doing non-project related work.
Our experience shows that project focused Kanban's have limited usefulness unless the projects are supported by dedicated workers. In most cases we have found that Kanban boards should be used to represent the work of multiple projects and scoped by specific business objectives and/or technical capabilities. One of the main benefits of the Kanban system is to support the allocation of specific workers across numerous priorities in real time, and to dynamically manage risk and value of delivery.

Keep metrics extremely simple until the board stabilizes
A major benefit of the Kanban system is the incredible wealth of data that can be shared across management and staff. There are major pitfalls in starting with the complete gamut of metrics from the start.

Most Kanban systems will undergo major revisions in the first 1-2 months. Supporting a Kanban system with detailed process specific metrics (e.g. cycle time of requirements, throughput of design, etc.) will mean that every time this Kanban system changes the supporting metrics framework will need to changed as well. This causes a lot of rework. Furthermore, as the Kanban system changes the units of measurement need to change as well, new work ticket types are created, and others are modified or removed.

Kanban systems need to be incredibly responsive to change during their first couple of months of use, and performance needs to be stabilized before metrics have any meaningful value. The exception to this would be capturing overall lead time and throughput, as these metrics are largely tolerant of change of the internal system workings.

Supplement operational reviews with retrospectives
Operational reviews provide a wealth of insight on how to improve delivery capability. That being said, they can take time to set up properly. Systems of work need to be stable, and maturity needs to exist to take the time to review system performance, analyze it, and aggregated into one or more meaningful reports.

In the interim, teams needed explicit opportunity to reflect on their own performance, as well as their journey to better productivity using a Kanban approach. We strongly believe that supplementing larger, organizationally oriented operational reviews with more frequent, team oriented retrospectives is critical towards helping teams get into a culture of thoughtfully improving the way they work. We recommend retrospectives be conducted monthly or biweekly, using whatever metrics are available depending on the maturity of the team using Kanban.

Identify an internal champion as soon as possible
Not having a "prime" consumer for any change initiative is risky. We are seeing numerous clients attempt to start Kanban pilots/Kanban initiatives without selecting an appropriate champion to continue the work once external coaches have discontinued their services. Finding an appropriate champion can be very challenging, this person needs to be passionate about improvement, and be able to motivate others to think about things differently.

Don’t over engineer the board
Kanban, like all other systems suffers from the fact that the system is often designed and built by engineers. Engineers are often attracted to complexity, and like to make sure that their work can handle all of the edge cases. Our experience shows that this can result in an over engineered board, with too many swim lanes, work types, three-tier/4 tier work tickets, and overall complexity that makes tracking and maintaining the board extremely challenging.

Kanban systems do not need to visualize everything, they are meant to be abstractions of knowledge work that allow instant recognition of how well work is flowing through the system. Understandability is much more important than exact precision.
Don’t treat the Kanban board as a command-and-control system

Project managers familiar with more traditional management approaches often fall into familiar behaviors when interacting with a Kanban system. Work tickets are all affixed with scheduled completion dates, and individual FTEs are held to the fire for any work not making those dates.
This reliance on individual workers accountable for individual activities will foster resistance and interfere with a culture of continual improvement. There will be little motivation to be transparent and visualize the state of all work if any defect or late work is used as an excuse to criticize or punish. Product managers and other leaders need to focus on systemic issues, and how to improve the overall system of work.

Familiarize executives and other stakeholders with the Kanban board and use that to visualize performance
There is often a desire to represent information provided by Kanban system and other simpler forms to make it more consumable to an executive audience. To some extent this is perfectly valid and we recommend working on executive reports. This needs to be balanced with the fact that a Kanban system provides a vast wealth of information that display system health without any need for interpretation. Time should be spent educating executives on how to understand what Kanban systems have to say. Bottlenecks are easy to identify, as are the number of defects blockers and other impediments to productivity

Maximizing the Benefits of Kanban as an Accelerator for Lean/Agile Transformations

One of the common approaches to many Lean/Agile Transformations is to start off with a set of "pilots". Typically these are selected based on the likelihood of success, priority and business risk. Often six months or so down the line after a few successful pilots the organization is eager to accelerate the process and attempts a larger scaling initiative to spread adoption. At this point the organization typically hits a wall as they run into a new set of challenges with the new teams/units being "transformed":

• These teams/units are typically less enthusiastic about the change - pilots are typically "cherry-picked" and are often the most capable and enthusiastic of the change while the rest of the organization is not
• Larger and more legacy systems/teams bring about different challenges the pilots did not face
• Limited capacity and budget within the organization to support the larger scale adoption resulting in less time spent with the team/units
• Executive deadline for the transformation looms closer, typically organizations are looking for organization wide results within a year or two

As a result, the transformation typically starts switching to a "big-bang" type of change as patience starts running out and new challenges to the transformation starts slowing down progress. This where organizations often get into trouble.

As an alternative to the piloting approach is a Kanban change management approach to transformations. The great thing about Kanban is that it allows an organization going through a transformation to adjust the pace of change from fast to slow depending on the tolerance of change within the organization. The only requirement is to ask each team/unit to follow a subset of the Kanban properties:

1. Visualize what you do today
2. Limit the amount of work in progress
3. Improve flow
   

With the Kanban approach to transformations, the organization can start "transforming" the entire organization on Day 1 without significantly disrupting business as usual while gaining the benefits of scaling out change to a larger group of teams/units. Another way to look at this is from the J-Curve model:




The J-Curve is the amount of disruption/pain an organization goes through when change happens. If you are starting/going through a Lean/Agile Transformation today, this approach is worth considering if you are facing a few of the challenges I discussed.


I'll blog more about the specifics for how we are applying the Kanban change approach in a current large-scale transformation in a later blog post.

A Map of Lean Agile Accelerators I Use

When ever the Deloitte LEAN crew helps our clients delivery business applications we typically reach out for a familiar set of practices, principles and thinking tools.

As a first step towards explaining how Deloitte LEAN approaches delivery I mapped out some of the concepts we tend to fall back on.

Explaining why Limiting WIP is so important

According to Kanban limiting Work In Progress is a foundational component that enables knowledge workers to engage in continuous improvement. But why? And how do I explain the need to limit WIP to execs and other decision makers that need to be convinced?

Here's the arguments I've been presenting..



Limiting WIP leads to a virtuous cycle of improvement. Multi tasking goes down, feedback goes up, errors are easier to catch, work becomes easier to break up into smaller prices, which makes it easier to limit WIP, which mean multi tasking goes down, etc, etc,etc



Limiting WIP is extremely important to ensuring maximum throughput in any systems that face variability. This has been proven in relatively stable systems like manufacturing assembly lines. It's exponentially more true in dynamic systems like software delivery and integration. Think of a highway, when WIP is to high you get a traffic jam, at the same time ifthe highway is empty you get no throughput, there is an optimization at play here. But this is a bell curve, 100 full WIP is never the answer


Limiting WIP exposes bottlenecks in your process, when inventory is low, and a particular process becomes blocked or produces defective work, it causes downstream processes to become starved of work. This is a good thing, it's a signal to fix your system of work. Yes, work will be delayed in the short term, but only long enough to improve the system of work, which will accelerate throughput over time.

The Three Feedback Loops of eXtreme Programming

With all my talk about Kanban, people might think thats all I use to help clients be successful.

Nothing could be farther from the truth, whenever I run delivery projects I whip out the technical practices in full force.

eXtreme Programming becomes my reference in these cases. I certainly dont think I'm doing anything to move eXtreme programming into new places, but thought Id share some visuals I use to communicate XP to unfamiliar audiences (yes they do exist).

The Three Feedback Loops of eXtreme Programming

For me eXtreme Programming is all about feedback. When done well, everyone on an XP team knows when something is broken, and they can immediately fix it.





Pair Programming
Feedback loop one is accommodated by pair programming, and by switching pairs. As a team lead I've never had more confidence of good technical quality then when I saw my entire team using this practice, its just so much easier to keep the style of the code consistent, the metaphors aligned, and to spot code cruft.

As a program lead, I am much more comfortable leaving daily decisions to teams that use this practice, I know my product is getting the benefit of the wisdom of the crowd. Critics point out that Pair Programming takes longer. I tried it for myself three years back. I conducted an experiment where The Observer had to ring a bell every time the Observer helped the Doer overcome a hurdle or make a decision faster than the Doer could have done on his own. The Observer was ringing the bell every 10 - 30 seconds. while not exactly science, it convinced me.

Test Driven Development

TDD is another agile practice that took me years to appreciate. While I started my agile journey with agile tools like JUnit and Cruise Control way back in 2001, I really was not following the TDD mantra.

I built lots of tests, after I coded, I often abandoned the tests half way through the project, and then started agian on the next project hoping to do better.

It took me years to evolve from Plain Old Unit Testing (POUT) to appreciating Test Driven Development (TDD). Once I got immersed I could never imagine going back



What makes TDD not just another test automation approach is a few key innovations:

1. Write the Tests first, they are your design spec and fine grained requirements all in one
2. They work because they are small, and match the design of well factored code, in fact TDD demands it or you wont keep up with your tests
3. You need to code, good tests demand SOLID OO engineering, not WYSIWG generated tests
4. Test, Code, then Design. TDD backed code is truly faster to redesign than most up front design work, code becomes like clay in the hands of a good TDDer.

TDD works becaus the majority of testing effort is applied at the micro level. Like all good architecture, reuse is enabled by creating fined grained tests that test fined grained code. When something breaks, you know what and where.

While high level tests have a purpose, they should be thought of as extra insurance, most errors are caught well before a macro test could fail.


Higher level tests can take advantage of Behaviour Driven Development, and extension to TDD that focuses on expressing requirements in a testable and automatable format.


Continuous Integration


Continuous Integrations helps synchronize across team members. Provided that TDD is working well, CI ensures that when code is checked in it is tested against the entire code base, packaged, deployed,etc. Any errors are sent to interested parties so that the team can swarm on the issue and fix it right away. Setting this up can take some doing, but i have always found it to be worth the effort.


In order to be successful with things like TDD and CI i found it necessary to focus on a parallel testing and build architecture. One that focuses on what tools to use, what level of tests will be built, how mocking and stubbing will occur, where automated runs occur, and other critical details. A good testing architecture is one that promotes the building of fine grained tests that can be executed quickly.

Balancing Global & Local Authority within the Organization

Organizations frequently have difficulty managing diversity as they scale to larger number of programs/projects. A balancing act is required to determine how much freedom to give versus how much control to take when determining how to manage and govern. Most clients I have spoken to describe the pendulum as having swung in a specific direction.

Many organizations I have worked in or what appeared to be laden with a top-down, restrictive, and prescriptive governance approach, or conversely, are not properly engaged with what's going on, suffering from ad hoc, siloed initiatives that appear out of control.

Many folks I talk to have a very partisan/polarized view around which state is better. The agile community tend to bristle at any oversight and governance that comes from outside of the team, many rightly point out that governing from afar isn't particularly effective, and the people doing the work have the best context and knowledge around what decisions are necessary to manage their work.

More traditional mindsets advocate that enterprise initiatives run through strong governance, typically by some kind of counsel that reviews spending priorities,make sure that projects are being run according to appropriate quality, budget, etc. these folks point out that extra work and control is required to make sure that all the pieces in an organization are moving in the same direction, share common standards, and that work is aligned with strategic objectives of the organization.

I strongly advocate that both of these perspectives have something to offer...


A global perspective and strategic thinking is required to get you where you need to go, however, it won’t get you all the way to your destination


A good metaphor for global governance and global authority is a cruise line. A cruise line is a great vehicle for moving a large number of people in the same direction. The cost of moving each person is relatively low, and it's easy to drive efficiency when using such a large vehicle.

In other words, global authority is great for setting direction, driving uniformity of purpose, and increasing efficiency.







Unfortunately, a cruise ship is not very agile, if you try to turn too quickly using a cruise ship you will most likely fall over.

Organizations that rely exclusively on top-down, command driven approaches, and standardized/commoditized processes we'll never have the flexibility required for today's fast changing business environments. While costs might be contained, this type of organization is unresponsive to the market, and takes a long time to deliver.


No one would ever think that you could take somebody all the way to their destination by using a cruise ship. Left unchecked, relying solely on the global authority will cause your organization to crash.

Optimizing based solely a global perspective can interfere with organizational agility, causing a stall, or even a crash

Local autonomy is required to be flexible and responsive to change, but can be expensive, and makes coordination and alignment difficult

Likewise a good metaphor for local authority is a motor boat. Motorboats allow you to travel fast,and they can get a small number of passengers exactly where they want to go with precision in a very short period of time.

Also, motor boats are more fun to ride than cruise ships :-)

In other words providing local authority/empowerment enables workers to make decisions as they need to to create value, less time is spent focusing on the organization and the organization's way of doing things, and more time is spent looking outwards, and what the market is demanding.

Motorboats are not just fast, they are agile. Organizations with a high level of local authority can react to, and even anticipate change, delivering quickly and being responsive to their customers.












Motorboats however, are not fuel-efficient, and are not the best choice for long-distance travel. I don't know anybody who would consider taking a motor boat all the way across the ocean. Local authority and team empowerment allows you to be fast, but it can be expensive(per passenger) and a lot of resources can be consumed in order to accomplish something.

it's hard for organizations to get any kind of efficiency through common approaches if there is no centralized authority or centralized governments, too much localized authority creates a suite of many organizational silos, all operating independently from each other.

local authority can make it hard to optimize and react to global market trends, and bigger issues that are hard to see from a local perspective.

This can cause smaller initiatives (and even larger ones) to be completely upended, and marked as failure because of forces much larger than within an individual units control.

When left unchecked local decision-making can erode organizational value, creating independent silos that conflict with each other

Use global authority to set global priorities, enterprise policies and align capacity to objectives, use local authority to come up with the tactics on how to respond

Since I'm talking about ships, the Coast Guard provides an excellent example of how global authority and local authority both play an important role in meeting both strategic and tactical objectives.









Overall objectives and strategic directions are made at the highest levels of authority. Policies, solutions, and tactics vary greatly depending on the exact situation, and context.

organizations should not be overly focused on one-size-fits-all solution/processes/standards, there are a huge variety of problems to be solved, there are a large number of solution sets, and approaches handling these problems.


What's even more important to ensuring a successful mission is that units on the ground are empowered to make decisions just in time based on information gathered using tight feedback loops like OODA(Observe Orient Decide Act).

Higher-level authority figures trust localized units because of the deep level of training that they have received, very detailed policies and instruction sets around how to handle work have been provided for a large number of situations.

Localized authority is empowered to respond to needs that they recognize because troops on the ground have been giving the tools and training to do so. Tight feedback loops between localized units and global command centers ensure that adjustments can incur should individuals strayfrom strategic objectives.

How does this apply to organizational governance and authority?

Create “containers” made up of policies, decision rules, and explicit boundaries that empower workers to make decisions independently ,but constrained by the needs of the organization

In this model senior-level authority figures in organizations switch from trying to govern all decisions to actually creating a governance framework that is based on clearly understood policies. These policies allow managers and staff to operate and respond to their individual context while ensuring that they still align to the greater objectives of the overall enterprise. Behavior can be codified into decision rules that dictate the value of making a certain decision. For example if the goal of the program is to create a lightweight product, a decision rules could be configured allowing engineers to spend a certain amount of design time per pound of weight shaved from the product.

I've been working with a number of clients on extending the Kanban approach to address concerns like governance, portfolio/strategic prioritization, and other enterprise concerns, I believe Kanban, and many of the concepts described in "The Principles of Product Development Flow" by Don Reinersten, provide the basis for creating a localized/global authority mechanism. This mechanism would leverage explicit capacity and demand allocation, decision rules for prioritizing work, and ensuring that enough feedback exists across multiple levels of the organization.

In another post I'll describe this kind of framework in more detail.

Agile belongs in a Kanban, not Tables

Alistair Cockburn put together a fine article on using various tables to track value, risk, and quality in a agile project.

I countered on twitter that a Kanban board would be a better a way to visualize this information. Alistair didn't quite grok what i was getting at and asked for a picture, now being such a boig fan of Alistair, I couldn't refuse...

:)

A Macro View of Agile

Despite the fact that the agile manifesto was signed over ten years ago agile adoption remains uneven.

One manifestation of this is how often I have clients ask me for even a simple overview of what I mean by agile.

I decided to put together this simple map that shows how the pieces fit together.






IMHO lean thinking and tools like A3 and Kanban tie all of the agile pieces together, and help organizations think and behave with agile principles in mind.


Supplementary agile practices like BDD and DDD integrate modeling with agile practices to help core agile team based approaches.

Core agile methods like XP are just that, and create the foundation for delivery excellence.

Technology focused movements like DevOps focus on upping the quality of from a technical perspective.

And while some will groan, RUP or UP provides some good lifecycle stages, roles etc,etc that can help scale agile.

The Hockey Maturity Model

IT Departments often fond themselves in a state of "low" maturity, typified by radically inconsistent processes, total lack of standardization, and a lack of transparent accountability.

Management frequently points to a lack of specialized skill sets as a contributing cause to lack of efficiency and delivery expertise. A typical reaction to this state of the nation is implement highly prescriptive process alongside very explicit (and rigid) roles and responsibilities. I've found it to be less than helpful to debate any of these assumptions head one. What I have found to resonate with some clients is what I call the "Hockey Maturity Model".

IT Departments often find themselves in a state of "low" maturity, typified by radically inconsistent processes, total lack of standardization, and a lack of transparent accountability.

Management frequently points to a lack of specialized skill sets as a contributing cause to lack of efficiency and delivery expertise. A typical reaction to this state of the nation is implement highly prescriptive process alongside very explicit (and rigid) roles and responsibilities. I've found it to be less than helpful to debate any of these assumptions head one. What I have found to resonate with some clients is what I call the "Hockey Maturity Model".


--The Little Leaguer-

The first stage of maturity is what I call the little leaguer, imagine this is the frost year your child is playing hockey with others equally new to the game. gameplay is typified by both teams swarming the puck in a chaotic fashion, lots of chopping and whacking at the puck, very little passing, and no teamwork. This is your ad-hoc, uber generalist organization, occasionally a goal is scored, but heroics are required and effort is extraordinary.





--The Table Top--





The second stage is what I call table top hockey. Now picture you are playing hockey using one of those table top games, you know the ones where different player positions located in specific slots that allow movement pre described ways so that you can simulate the typical movement of a specific position.

Now this a better way to play hockey than the little league approach, passing is now encouraged, and individual players in the game have clear accountabilities creating a more professional atmosphere. But closer examination reveals flaws, individuals are restricted from working out of pre set boundaries making it sometime impossible to get at the puck, and truly magnificent plays are impossible to pull off. Performance peaks quickly, and play satisfaction is low. This feeling of mediocracy and dare say stagnation is one that I've felt in organizations that have become to focus on process, and putting boxes around their employees. Look for symptoms like a developer refusing to test code because it's not his job.


--The Integrated Team--




Now let's think about how hockey is played when professionals, or even experienced amateurs do it. In this case all players are allocated to a particular position and have differentiated skills and responsibilities necessary to help them excel as an integrated team. What makes this type of hockey different is that it would be unthinkable for a defensemen to not try to score if he circumstances give him a shot. Likewise you'd never hear anyone committed to playing hockey refuse to deflect a shot on his goal. Key here is that explicit roles don't get in the way with what's more important, and that's winning the game.

Truly effective organizations deliver software this way, specialization, and clear roles don't get in the way of the need to pinch hit, and step out side of job descriptions. Net net, teamworks trump all other concerns.