Kanban Adoption Approach

We have been running large transformation projects for the last several years helping organizations to become more agile in their delivery.

A typical approach one often encounters is to select a pilot project, run the pilot and then move onto another pilot.

Based on our experience, we recognize two major issues with the project pilot oriented approach:

1- People already are participating on multiple projects. This causes multitasking that is not captured by the Kanban system. This makes the pilot very limited in terms of value.

2- Organizations often select a project that is just starting. These projects can take as much as 3-6 months to get out of the conception phase. This makes seeing any real momentum impossible.

As a result, we are trying a different approach, one that takes an organization/ team perspective. We hope to eliminate some of the challenges inherent in a project based approach.

We start with a group of early adopters that are working on inflight projects and visualize all of their work.

We are adopting based on “delivery nodes”. We view the organization as a network of interacting units that provide business value. We select a subset of the organization that uses a single technology solution. We get the team onboard with Kanban and try to stabilize their work.

As we are getting an understanding of other work surrounding this delivery node, we can decide who to adopt next. The adjacent node is determined by looking at both risk and value. We want to promote flow for all work under the current scope of adoption while simultaneously expanding our scope.

This approach will allow adoption to proceed using a continuous approach, maximizing flow throughout the organization connecting customers, suppliers, and peers in each subsequent wave.

Implementing basic Kanban throughout the organization allows further insight into the tools/ skills/ methodologies that can be adopted to improve the teams’ capabilities. Additional capabilities, such as feature decomposition and test driven development can be developed as incremental change units and rolled out through the organization where applicable.

We created a roll out plan to have large adoption waves on-boarding 50-60 FTE's per month. After month 2, the basic Kanban implementation is reduced to half to allow the organization to adapt to the new work systems and to start implementing the incremental units of change.

A Kanban board is created to model the rollout plan. The backlog represents the teams that will be trained on the basic Kanban and the incremental units of change.

The adoption wave is a 9 week effort program. Each of the adoption waves will start with a week of Planning & Kick-off and then followed by an 8 week training and coaching program. During the 8 week period there are 6 major learning, workshop and support activities that are essential for a successful implementation.

A Kanban board is developed to model the training material to track the progress of each of the teams through the training program.

We kicked-off training sessions with multiple teams. In a later blog post we will review our initial approach and share our experience on onboarding the teams to their first Kanban board.

Lean Startup For Change: Bootstrapping an Enterprise Kanban Transformation with Lean Startup Methods

By now many are familiar with the concept of the LeanStartup, and the methods pioneered by Eric Ries and others. In a nutshell the LeanStartup approach helps human institutions create value in a sustainable way in highly volatile/uncertain environments. This technique has become the de facto standard for young, savvy technically minded entrepreneurs working in innovative new organizations.

But thinking that the LeanStartup method just applies to the folks in Silicon Valley misses the point of how powerful these techniques are.

Increasingly all manner of organizations, institutions and enterprises are being forced to compete in highly uncertain markets. This means that LeanStartup applies to a wide variety of domains. One such domain is large-scale enterprise transformations.

I have spent the last several years of my career dedicated to IT transformations, helping clients to improve the performance of knowledge workers dedicated to building business applications. I have specialized in using agile and lean techniques, lately putting a real focus on capital K. Kanban, invented and made famous by David J Anderson.

Recently, our team has elected to enhance our transformation approach with LeanStartup. While this is still an evolving approach, I’d like to share our current progress.


Breaking down Change into Increments of Learning
Most change management approaches rely on making a huge number of assumptions about the organization, and impact of specific changes. Kanban provides a more incremental approach to these changes, but still contains a number of assumptions around how people react to certain components of the framework.



























The LeanStartup approach recommends breaking product delivery into a set of Minimum Viable Products (MVP). Each MVP is built for purpose to support learning. The really interesting part of the MVP approach, is that you often don’t have to build anything to learn something about the viability of your product.

In our approach we are breaking up all of the assumptions in our transformation into a set of Minimum Viable Changes, in effect we have decomposed our transformation into the smallest possible units, laid out our underlying assumptions, and then backed up each assumption with a hypothesis and a set of graduated metrics to support that hypothesis.

Defining Target Behaviors Using Measurable Hypotheses
Components of the transformation have to either lead to improved performance (value hypotheses) or facilitate adoption (growth hypotheses). Again rather than relying on assumptions, the transformation vision is decomposed into specific strategies, and the strategies are further broken up into behavioral hypotheses. These hypotheses are tested through the creation and implementation of various MVCs. This approach is allowing us to gather data around whether to change our tactics, while continuing to pursue our overall strategy, or whether to make a major pivot, and make major changes to our overall strategy.



Measuring Specific Hypotheses
MVCs test specific behavioral hypotheses, in our approach we are using classic cohort testing recommended by the LeanStartup approach. Targeting a single MVC against multiple cohorts, or split testing against different cohorts.


We have structured Kanban, and other lean components into a set of graduated behaviors. And then designed appropriate MVC to test these behaviors. We are also currently in the process of extending this framework to cover other agile process components as well.


Here is a sampling of hypothesis with some ideas on how we plan to measure  the accuracy of our assumptions. These metrics are refined depending on the MVC we design to test the hypothesis.


We are only a couple of months into the process, but some interesting observations have already come to light...

• we are adapting ALOT faster, no pivots necessary yet, but we are incrementally adjusting our tactics every couple of days
• our MVCs are getting much smaller, and we are just getting ready to rip down our transformation Kanban board to better reflect the MVC approach as we get more comfortable with it
• cohort testing is revealing a competitive streak with our coaches, causing us to really maximize client participation (one of our key metrics), we are in effect gamifying the transformation

Stay tuned, we will continue to share our progress...

..

Lean Thinking Tools for Improving Your Portfolio Planning and Prioritization Process

We just started an IT Transformation for a new client that is looking to fundamentally change the way they deliver IT services and application development. As part of the transformation we are helping the organization improve their portfolio planning and prioritization process to provide greater transparency, flexibility and control (yes control and agile does go together). Whenever we work with clients in this area, the first step we take is help them break down their old mental model of portfolio management and take a fresh perspective. To do this we introduce four thinking tools to help them wrap their heads around the new concepts. The goal of the four thinking tools is to help organizations look at planning and prioritization as an economic bargaining system.

Thinking Tool 1: Three level planning approach controlled by cadences

The first tool is to stop looking at portfolio planning and prioritization as a one time annual budgeting process and instead move towards a frequent multi-level planning system for portfolio management. Each level of planning should have well-defined units of work, cadence, and a form of currency (more on that later). The specific goals of each level are:

Strategic Planning:

• Identify ideas to realize strategic business objectives
• Set allocation based on LOB / Program / Work Type
• Longer Cadence, example quarterly

Project Planning: 

• Idea analysis and project planning
• Define projects in terms of business valued features based on a high-level solution
• Medium Cadence, example monthly

Operational Planning:

• Project work intake with frequent work replenishment for solution delivery
• Dedicated intake channel for emergencies, small enhancements and bug fixes
• Short Cadence, example bi-weekly

Thinking Tool 2: Breaking projects into minimal releases and business valued features

Based on Thinking Tool 1, if the organization is able to establish more frequent strategic planning cycles (e.g. quarterly) than this encourages projects to be broken down into smaller chunks that can fit into those cycles. This allows IT to work more frequently with the business to understand what the high value features are and get to quick wins faster. At the same time this also provides greater transparency of progress into budget spent vs budget realized in terms of real value (i.e. a potentially shippable system).

Thinking Tool 3: Planning informed by capacity in terms of throughput to level demand

One of the challenges with traditional planning approaches is that capacity is not used to inform the planning process. To build an effective planning and prioritization process the organization needs to understand capacity in terms of throughput (how much value can I deliver within x amount of time) and level demand based on available capacity. What we often see broken with traditional processes is budget being the only input into the planning process and that is typically not the "bottleneck" or scare resource in the organization. Money is abundant, time is not which leads to the end of year madness many organizations fire fight their way through.

Thinking Tool 4: Establishing currency to represent scarce resources provides a mechanism to facilitate exchange of value to promote liquidity and flexibility

The final piece to the puzzle is establishing a common unit of currency based on scarcity. Instead of throwing money at the problem, the organization starts looking at their delivery capabilities as system of work that has real constraints (i.e. time). The unit of currency we alluded to earlier in Thinking Tool 3, is throughput which represents work/value in terms of time. The currency is then limited based on scarcity which is represented as work-in-progress (WIP) limit that controls the backlog and queues that work fits into.

By understanding these four thinking tools they provide an organization with the foundations for establishing a fast feedback portfolio system managed by multi-level planning with cadences, defining projects into smaller increments of value, balancing demand based on throughput, and planning and prioritizing based on a common unit of currency that represents scarcity.

In a later post, I'll share a set of planning and prioritization patterns we use to implement these concepts.

Using the Business Model Canvas in an IT Transformation

The Context
Our client is initiating an end to end transformation of both business processes and IT systems used to deliver services to its customers. The goal of this transformation is to enhance the ability of their IT Organization to execute on the delivery of new applications, changes to existing applications, and support/maintenance activities. The organization also requires enhanced capability to better execute on delivery strategy, governance, and standards. This transformation will enable our client to better meet the demands of its clients by increasing throughput and quality, while simultaneously reducing delivery lead time.

As part of our initial discussions with directors and managers we decided that the business model canvas can be effectively applied to describe the client’s current software and services delivery model. Based on insights from Directors and Managers, we filled up a 6 x 8ft canvas with sticky note insights.

What is the Business Model Canvas?

The business model canvas is a tool that helps you describe, design and visualize a business model. The canvas helps an organization describe how they intend to deliver value by focusing on 9 building blocks:

1. Customer Segments
2. Value Proposition
3. Channels
4. Customer Relationships
5. Revenue Streams
6. Key Resources
7. Key Activities
8. Key Partners
9. Cost Structure

It is not enough to look at the building blocks as a checklist – they are assembled in the canvas below to help visualize the relationship and interactions between them:

The building blocks focus on a set of key questions that help collaborators capture their insights and facts about the current or target model. These insights and facts are captured on sticky notes so that they are never permanently fixed to the canvas. We adapted the original canvas from the book, Business Model Generation, to suit our unique need.

If you want to learn more about this tool, you can purchase the book, Business Model Generation. There is a 72 page sampler of the book at http://bit.ly/jXCPHQ.

The Custom Canvas
The client environment is quite different from the examples and cases available in the book so we modified the building blocks to suit our particular needs. After several iterations we landed on the following building blocks:

These building blocks were used to create a 6 x 8 foot canvas on a wall in our war room. We had multiple stakeholders from the client team join our business model canvas workshops to capture their insights on some key questions to help us populate the canvas:

1. Who are your customers? Which customers use which services? How is demand communicated to your department? How does intake work?
2. What vendors do you currently work with- both internal and external to your organization? How do they contribute to delivering value?  How do you coordinate to deliver?
3. How do you measure performance? What does your performance look like for the various kinds of work that your department does?
4. What types of tools, processes, and accelerators do you leverage to add value? Which ones are you thinking of using in the future?
5. What do you believe are the major risks or issues that interfere with delivering business value? What counter measures have been attempted to solve these problems or mitigate these risks?

As we conducted the sessions, we started to identify 3 major types of insight. The sticky notes were tagged with a colour corresponding to the types below:

1. Pain Point (red) – something the client wants to change because it is not working well
2. Target State (blue) – something the client wants to have because it will help to deliver more value to the customer
3. No Change (green) – something that is working well and do not want to change

We not only used sticky notes, but also modeled using blank sheets of paper and affixed it to the canvas with painters tape. After the first wave of workshops, we communicated an open-door policy. Anyone can walk in and start adding things to the canvas with our help. Below is a photo of the results:

We ended up with a canvas that helped us get an understanding of the client’s delivery model, pain points, and things that are working well. We also started to look to the target state with many suggestions for positive change. This canvas is in a constant state of flux and changes daily capturing thoughts and facts as we learn and discover. Finally, right at the top of our canvas, we wrote the client’s vision on a sheet of paper to anchor the discussion overall.

You Can't Trust Your Workers Metrics Unless Your Workers Trust You

It's common to place a lot of faith in the power of what metrics can tell us. I've met more than one executive who romanticized about some kind of super dashboard that could pinpoint all the risks and issues, allowing them to base key decisions largely on the data they are seeing.

This could be a desirable target state, if you are doing something simple, like delivering pizzas.

In today's customer experience economy many of us are involved in something a little bit more complex. We are more likely to engage in tacit activities, activities that require analysis, learning, collaboration and on-the-fly synchronization. Chances are, we are engaged in knowledge work.

A profound truth that many fail to appreciate is that knowledge work is inherently variable. Each request for a service or product is always a little bit (or a lot) different from the last one. And you can't remove this variability from the equation. Doing so will remove the work of its value, the work will no longer be something new. Robots could do it.

This makes getting meaningful metrics somewhat problematic, comparing one unit of work to another will always require some creativity.

What this means is you can't measure knowledge work effectively unless your knowledge workers want you to.

Measuring knowledge work means measuring abstractions of the work your knowledge workers do. A trial and error exercise is required to come up with something meaningful. You need commitment to get to a stable performance baseline.

Even more so you'll need courage. Metrics for knowledge work are extremely easy to game, and being transparent about bad data is something very few organizations do well.

And it's not a one-time thing, the approach you take to measuring whatever it is you want to measure will always be little bit wrong. The context that knowledge work takes place in is always changing.


If your workers don't trust why these metrics are being used, you won't have accurate data. You won't have the insight required to know what to do with that data. And you will make bad decisions in the name of that data.

Metrics can be a good thing. But trust comes first.

Kanban 101

Kanban is a less disruptive path to a higher state of organizational maturity.

Kanban inspires a culture, where everyday staff, focus on incremental improvements. This type of culture ensures that an organization can make changes that are tolerable, both right-sized and at the right pace. Over time, organizational maturity grows, and with it, higher performing teams.

The incremental change approach is vastly different from a “Big Bang” approach. A Big Bang approach typically impacts performance to a level where the change initiative is at significant risk of failure. As performance drops significantly, several challenges arise: low employee morale, loss of trust among executive sponsors, or simply, the organization cuts their losses and resorts to the old way of doing things.

Limit the amount of work entering the system.

By limiting the amount of work that enters an organization’s delivery center (e.g. enterprise software delivery), the organization can focus on continuous improvement through its workflow among teams and value stream overall. A domino effect results:

1. Reduce Work In Progress (WIP) Limits – Lowering the level of work in progress (inventory) has a significant, positive impact on average completion time of individual work items
2. Reduce Task Switching – As an individual item is completed faster, the need for wasteful task switching between work items is reduced
3. Reduce Cycle Time – Lower average cycle time means shorter lead time for individual work items
4. Increase Feedback - Quick turnaround time also means that quality checks are done with a fresh concept”, and the opportunity for error decreases
5. Increase Quality - Increased feedback improves the quality of the final result
6. Increase Team Maturity - Increased Quality leads to an increase in overall team maturity and performance, quicker lead time results, teams are further able to lower the levels of work in progress

Kanban is an approach to visually represent a unit of value.

The Kanban Approach:

• Visualize the work – a visible display of moving work to completion becomes a powerful reward
• Pull work based on WIP limits – to create a predictable workflow
• Empower staff to improve processes – simple, visually represented measurements of progress become intrinsic motivators to do the right thing

How does it work?

• Management and staff have a common understanding
• Bottlenecks, issues, and defects are easy to spot
• Explicit mechanisms for root cause analysis and continual improvement
• Demand is limited, fostering focus, early delivery of value, and making bottlenecks obvious
• Defect correction focuses on the source of the defect, not just the defect itself

Work Policies continually evolve as the organization matures.

Organizations build policies and modify them as they are incrementally changed through improvement discussions. Teams may define policies at different levels of detail such as work policies (at the workflow level) or team policies that apply to the team as a whole. For example, a team policy is conducting a daily stand-up at 10AM every day. A workflow policy may define entry and exit criteria for a given phase in the workflow.

Kanban allows teams, managers, and the organizations as a whole to become better at measuring.

Kanban provides the tools to predict delivery time, reduce risk, and analyze problems using quantitative methods. Tools such as statistical process control charts, and cumulative flow diagrams will provide robust metrics managers yearn to discover.

If you would like to learn more, visit the links below:
Limited WIP Society - http://www.limitedwipsociety.org/
David J Anderson & Associates - http://agilemanagement.net/
NetObjectives - http://www.netobjectives.com/
Lean Software and Systems Conference - http://lssc12.leanssc.org/

Up Front Design Is Not Design

If we don't create a reusable design, we will pay down the road. If we don't properly anticipate requirements, we will incur rework. If we don't get the design right up front we are, for a lack of a better term, royally screwed.

If you disagree with the above, then feel free to stop reading, this post will contain nothing new for you.

If you are of the opinion that the design of any kind of information system is something that is done up front in one big batch, I urge you to keep reading.

Design is an act of pattern matching. You are scanning a range of solutions in an attempt to improve the experience of a particular context. 

Design involves equal parts analysis, building, and perhaps most important, testing. 

The key to good design is iterating. Iterating as fast as possible.

Good design involves searching, mixing, inventing, testing, testing, and more testing. 

Good design doesn't come from a better crystal ball, it comes from feedback. And being able to respond to that feedback.

The act of analyzing requirements, modeling a solution, and handing it to a development team isn't an act of design. 

Its an act of analysis. Its an act of direction. One that is rooted in assumption.

For this to be an act of design, you need to complete the entire cycle.

Not all problems require design to solve them. Maybe you are applying a cookie cutter solution to a commoditized problem. Maybe you just need coordination. 

But even complex coordination requires good design to pull off well.

You don't need take my word for it. 

You could pay attention to the growing bodies knowledge out there that are spreading the same message.

Design thinking, Service Design, Managing to Learn, LeanStartup, Radical Management, OODA, Gamification, and Systems Thinking seem to all touch on the same truths. 

Up front and design are the  antithesis of each other. Let's strike it from our vocabulary.

Three People And Their Feedback Loops That Can Transform RIM

A random thought that occurred to me. When they may have have occurred to other technology knowledge workers in Canada.

RIM used to be a real point of pride for Canadians. Not as much anymore. Too many stories of a bureaucratic and dysfunctional organization, a lack of market insight, pulling people off of work mid-project, and just plain not keeping up with the competition.

Sounds like a dramatic overhaul in direction is required to get these guys back on track. I would love to see these three people talk to the executives over at RIM and see if they could stimulate some fresh thinking.

Eric Ries on LeanStartup

You would pretty much have to be living under a rock to not have heard of Eric Ries and the LeanStartup movement. A common misconception out there is that this movement is for kids in garages over at Silicon Valley. It’s really about dealing with uncertainty, and learning how to build sustainable customer value faster than your competitors. Start turning your erroneous assumptions into validated learning. Start leapfrogging ahead of your competitors.

David J. Anderson on Kanban

Moving your organization into leanstartup mode in one go would be a cultural big bang. One that could potentially disrupt your company to the point of bankruptcy. You may want to try a more incremental, evolutionary approach to changing the way you organize the way you work. This is where "capital K" Kanban comes into play. Visualize your work, and limit what you can do to your capacity, start getting agreements between your different knowledge workers down on paper, and get into flow. Bottlenecks to value will become obvious, and you can steer the organization where you need it to go.

Steve Denning on Radical Management

Let’s take a look at how we can get some healthy feedback into our management culture. Radical management is a way of managing organizations so that they generate high productivity, continuous innovation, deep job satisfaction, and customer delight. Radical management is all about helping leaders adapt their organizations to a world of rapid change and intense global competition.

I could imagine a series of webinars, once a week, which featured these folks presenting. What happens next of course is open to speculation.

You Owe It to Yourself to Find a Mentor

In today's fast changing, knowledge economy, traditional management structures will not provide you the guidance you need to advance your professional career. Something a little bit more intimate is required. You owe it to yourself to find a mentor.

Your chosen mentor is a couple of steps ahead of you along the path that you are walking. You share common passions, similar ethics, and hold like values. You also disagree enough to challenge each others' perception of the universe.

Your mentor is someone that you trust. Someone who will help you bury the bodies if you really screw up.
Your mentor is a lot like a friend. Eventually, he will become your friend.

Your mentor is something more, you have an innate confidence in the advice that he provides. You trust his instincts, even when they conflict with yours. A good mentor is not your peer, a little bit of awe is healthy.

A good mentor is temporary, his job is to bring you up to his level. When that happens, your relationship has now evolved, you are now trusted comrades in arms.

Finally, a good mentor will learn as much from you as you will from him. You are inherently better at some things than your mentor. Your mentor learns by watching you in action. He is constantly challenged by your questions, and has to stretch himself to provide the right advice.

Is there anyone where you work who fits the bill of a good mentor? If the answer is no, you have some important work to do.

Executives, for those of you trying to think about how to start down the road of self organization, begin with fostering a mentorship culture.

Encourage the mentorship/mentee relationship amongst your staff, preferably outside of the official chain of command.

Start with you.

Nothing In Your Professional Life Is Insurmountable

Trust me. Nothing. Whatever it is, you can evolve, you can adapt.

I'm hoping a personal story will provide some inspiration.

About 5 years ago, I was an experienced software developer in his prime. I was doing a reasonably good job at playing technical top dog for about 15+ developers.

I coded, I drew UML on whiteboards, I set standards, and took responsibility for the technical direction of the solution. I was on the keyboard. A lot.

Then my wrists and hands started suffering severe pain. First the left, then a week later the right. I couldn't type, and I couldn't use a mouse, not without inducing searing agony that would last for hours, and eventually days.

I went on disability, I tried to get better, and I tried to figure out what was wrong with me, for many months. With absolutely no success. One day I was an aspiring professional, the next I had no clear future.

But one thought kept reoccurring to me. When I was still working, I provided the most value when I was designing with others, and communicating those designs with others. No software was involved for either of these activities, just whiteboards, and the English language.

It was with this thought that cemented the decision to return back to work. I still couldn't type, and I still couldn't use a mouse. But I knew I could still add value. And I was sick of being on disability.

The firm I work for provided me with the best technical support they could, in that day that meant a laptop equipped with some very slow and inaccurate voice recognition. If I really tried, I could send e-mails, and even a section of a Word document or two. But I could use a whiteboard (painfully) and I could speak.

I'm still at that firm 5 years later, and I have been promoted twice since I returned. At times it's been an uphill battle, I've often felt like a blind art critic, one that could make judgments based solely on the perception of others. I also worked in a consultancy, which meant constantly having to explain to superiors why I couldn't create a PowerPoint by myself. And then explain it again. And again.

The most interesting part of this story, is how it forced me to grow. I had to learn how to rely on others to get anything done. I would constantly trade my knowledge mentorship for the use of a more junior person's fingers. I'm pretty sure I'm a better professional as a result.

Eventually, I also stumbled on some cool agile tools like CRC cards and agile card walls that didn't require the use of a computer to get stuff done.

I still can't type or use a mouse, and my hand still occasionally flare up. The tools I use now are way better than the ones I started with. Some I found along the way, some I programmed myself. I easily spent many a hundred hours on customizing accessibility software to fit my needs. One of those was the ability to program with my voice.

Hopefully, if you're facing an insurmountable barrier, you'll find your way to this post. I hope it inspires you. Whatever is in your way, take it down.

Adopting Retrospectives? Start by learning to learn

Retrospectives is a great practice that is widely adopted by agile teams. I've worked with a large number of teams across different organizations and one of the first lessons you learn after you coached a number of teams is that while improving team performance to deliver faster and better is important, what's even more important is the team learning to learn. Continuous improvement is a big commitment, and not easy to do especially for knowledge work. That's why I tend to take a different approach for teams new to retrospectives and instead of setting improvement as the goal for them, I focus them into learning how to discuss problems in a structured way and coming up with simple tactical fixes that can be implemented fast. 

Structured - many teams struggle to discuss problems effectively, the first goal is to find a simple framework to structure the problem discussion. A simple one I use often is setting a simple matrix on a big whiteboard, the top row I place the discussion topics, divide them with vertical lines and then divide the verticals horizontally into 4 buckets, challenges, causes ("why"), easy fix, harder fix. This is a simplified 5 whys approach to root case analysis. I then get the team to brainstorm and start mapping stickies into these buckets. This provides a simple structure to the conversation.

Simple and Fast - Once the team identifies a number of improvements or fixes they believe can improve their problems, I encourage them to start by selecting the simple ones. Within their span of control, limited analysis needed, and easy to implement. Finally, the fixes should be fast to do, 1-2 days max in effort and duration.

It's not initially important whether the fixes actually provide sustainable improvement or not. That will come with time once the team learns how to learn by tackling smaller changes often. This approach allows them to move at their own pace, is sustainable and will likely provide a positive reinforcement as they can finish what they started. Stop starting and start finishing also applies to continuous improvement.

How to Architect An Agile (or any other) Software System

Apparently you can't.

Architecture is a noun, not a verb. At least according to a cousin of mine, who is an architect in the non virtual sense, at Rios Clementi Hale Studios.

According to him architects don't architect. True, they are responsible for architecture. But they fulfill this responsibility by ensuring the building fulfills the purpose for which it was intended. That there is a consistent design, and that the building has flow. They make sure the building will be safe, and will survive the test of time and use. An Architect also is responsible for the beauty of his creation.

Architects do this through a combination of engineering and design, a mix of science and art. The Architect performs a divers range of tasks. Gathering requirements, performing impact assessments, conducting environmental analysis, and performing QA site visits, amongst other things.

But he doesn't architect, architecture is a result of all those other things.

IT seems to have absconded the architecture word without really understanding what it means. Ask ten different people what an IT architect is/does and you will get twenty different answers. (just ask them twice)

It seems to me that architects above all need to be real leaders who have serious (and current) technical chops. They also need to know their customers business better than they do. We could use more architects.

Agile Methods Require Highly Sophisticated Teams to Be Successful

Bet you knew I was baiting with that one.

I've always felt that this was utter nonsense. I now know first hand that it is utter nonsense.

I've just spent the last year helping a public sector IT organization transform the way they think and execute. That means I have plenty of stories to tell debunking this myth.

Here's one story, about the first team we introduced to agile methods (Kanban in particular) during this transformation.

Unionized staff, legacy technology, a fluctuating team size, and little practical experience in modern development practices. Picture an environment where one expects agile to wither and die.

What the team had going for it was a couple of folks who embraced the chance to do something different when they were given one. It wasn't the entire team, just a couple of them.

That was enough. Courage and passion are infectious, and a team used to command and control is now experiencing self organization, and continuous improvement.

It's not perfect, it's not like in the text book. There are easily a couple of dozen things that could be better, and would make many an agile expert cringe. But that's the point, this team is continually trying to get better. Sometime they take a step forward, sometimes they take a step backwards, either way they keep trying.

They have quantifiable results too. Metrics, love them or hate them, are one way to communicate progress. Over a 9 month period lead times are 30% better, throughput is up 100%.

Every environment can be changed for the better. You just need to take a risk.

Comparing Kanban and Scrum

Is pointless.

Yes everyone has an opinion, and a strong opinion at that.

Including me, especially me.

Everyone has an opinion except the people that really matter. I'm talking about the executives in charge of those multi hundred million dollar IT transformations going on right now. The ones responsible for integrating all those legacy systems to support that latest M and A.

The folks responsible for determining the who, the what, and the how for the technology landscape that will support corporate America (and in my case Canada) into the next century are almost all completely ignorant of what agile is, and what agile means. They still think waterfall is the way to go. They think agile is a toy to be used by post graduates to create cute applications that play on teenagers' iPhones.

I see this every day where I work, and I see a lot of big IT programs here. I have have seen some very large scale IT transformations started recently based entirely on more command and control, more governance, and more standardization.

This is the big killer whale that we all need to face. A prevalence of a mindset that is hostile to agile principles, and sees self organization as a threat.

Yes, the tide is slowly turning, but its also going backwards in lots of places. There is a ton of work for us to do. Best we do it together.

The Best Way To Become A Developer In A Self Managed Team

Start acting like one.

There are many tech shops out there that place developers in the center of their universe. The developers in those places deserve that respect. They have the trust to do what ever it takes to build sustainable value end to end.

But they earned it.

For those of you in IT land who would like to be in a similar situation, I have one question.

Are you ready?

Is your code largely bug free by the time it gets to QA? Are you willing to stick around long to support the code you write? Do you take the time to learn from your mistakes and make sure you don't repeat them? Do you know what business you are in and why you are writing the code you do? Are you able to listen to your customers and respond to their feedback at a pace that keeps them happy? Do you take that collaboration, experimentation, and communication form the core of your job?

In stead of waiting for your culture to change from on high, bootstrap yourself with the skills it takes to deserve being part of that culture. Don't wait to long to start mentoring some peers into fast followers. I've never seen more local and free resources available to those who want to escape software mediocrity.

Before you know it you will be working in the environment you want to be, it just might not be the same place you are at now.

You're to Technical For An Executive or Business Facing Role

Hard to believe how often I still hear this.

John Doe shouldn't be put in a client facing role. Jane isn't the best candidate to be promoted to upper management.

Jane and John are much to deep on the technical side. That expertise in java, that passion for patterns, and that incessant blogging about closures delegates these folk to the basement.

This mentality is just a sampling from a luggage department store sized selection of cultural baggage that condemn many IT shops to a mediocre existence.

Truly excellent places to work recognize, reward, and promote the technically awesome. Every day we hear about the next business success story; lead by a geek with a passion, supported by a team of passionate geeks.

Maybe if we nurtured an environment where the brightest techies actually wanted to work, some of that success could be ours.

For sure technical skills aren't the only keys to the kingdom. Business savvy, interpersonal skills, networking, and being able to speak in a language that doesn't alienate our customers are just a couple of other slots needed in the utility belt.

What some don't realize is that today's techies are of a very different stock from the engineers bred in the 70s, and 80s.

The modern professional geek is locked into a rapid cycle of continuous learning and accelerated networking. They study and collaborate towards success, and move at a speed that make conventional thinkers appear to be at a standstill.

Perhaps the word chosen for those barred from the decision making crew should be socially inept, offensive, or don't understand your business.

If that describes the majority of technical folk in your organization, think about how to grow, attract, and retain a different breed.

No One Is Following Your Waterfall Process

A note to executives. Waterfall is anything but.

I have yet to experience a sincere account of a project where work actually moved in one monolithic chunk.

Development is done during requirements, design decision are being made (and remade) during UAT, and requirement changes keep happening right up until the end.

You might think the solution is to get better at waterfall.

You would be wrong. Think about dumping a delivery approach based on century old managment theory.

Your staff will thank you.

Your customers will thank you.

You will thank yourself.

Waterfall processes might seem like a nice way to mitigate risk, or raise efficiency. A simple way to track progress.

In reality they create a dangerous illusion of safety.

They turn executives into ostriches, providing them with a convenient place to hide their heads.

They force your staff into a game of pretense, avoidance, and circumvention.

Spend more time with your workers on the ground, talk to some of your best bees.

They are ignoring your stage gates, they need to get work done.

Advice on Successful Organizational Transformation

Every transformation has a unique set of challenges based on its particular context. We have noted the following top issues below, along with remediation activities. All issues noted below are based on our real experience on similar transformation engagements:

Leveraging a One-Size-Fits-All Solution

Many leaders within our client organizations are challenged by the fact that there is no commonality in the way that different teams and programs deliver and maintain software application systems. They justifiably see this lack of standardization as a symptom of an ad hoc organization that lacks the maturity to perform similar work in a similar manner. This lack of standardization increases risk, raises cost, slows down delivery, and makes it impossible to get to a higher state of performance. 

A natural reaction to this state of affairs is to create a process framework that covers all possible circumstances, often using a standardization approach based on a one size fits all process. Customization is typically done at the project size/cost level, if done at all. Elaborate processes are drawn up to cover the SDLC, along with detailed templates. Staff is then trained on the new method. Feedback is gained on the new method, and (eventually) that method is updated.

Unfortunately all too often this approach results in a delivery process that looks good on paper, but does not meet the diverse requirements of different teams, different programs, and different levels of delivery risk within the organization. The process is often adapted to the group of knowledge professionals that have the most influence, with the requirements of other staff and managers having less impact on the framework. Typical reactions from project staff range from ignoring the process framework to following it to the minimum level possible to avoid punishment from compliance watchdogs. In neither case is the desired behavior accomplished, knowledge workers leveraging the process framework to add value and reduce risk. 

Our approach is to take a different perspective on standardization. While it is critical is to define a common process architecture required for an organization to be successful, it is equally critical to ensure that those processes have unique policies based on the type of work being processed for particular types of work. A fundamental difference to our perspective is that we believe that standardization efforts should focus on the work itself, and that processes can only be a standardized to the extent that the problem domain and associated work can be standardized. 

We recommend starting the standardization effort with gaining an understanding of the different work types the organization must process. Work types can be thought of as a definition profile identifying delivery risk, size, technical skills required, and effort for particular category of work. Work types can then be associated with the exact policies required to facilitate maximum quality and better throughput/leadtime. This approach facilitates the development of a policy framework that is right sized to the work, and is flexible enough to change to meet the requirements of different categories of work.

Following a Big Design Upfront Approach

Stakeholders and managers tasked with running large-scale transformations face a great deal of risk. ROI might not be as high as anticipated, processes may not support certain scenarios, staff may resist change, and process components may be too lightweight or too heavyweight. A natural reaction to managing this risk is to try to come up with the perfect design. There is a desire to try to take into account every possible scenario, and develop the perfect target state solution. There's often a tendency totry to design any anticipated risks out of the solution. 

Unfortunately, the impact of locking down decisions before the right kind of information is available is just as risky as making a decision too late in the process. When a decision is made to early, it is largely based on assumptions. When the assumption proves to be false, it can be very challenging for a program to admit the error, and it can take many months to reverse the design decision. A program that has to much upfront design will be weighed down by unvalidated assumptions, these unfounded assumptions can cause the program to go completely off track. While it is important to do some upfront design, the key is to focus upfront design on decisions that are very expensive to reverse. Examples include overall organizational structure, process architecture, tool technology platform, and executive level processes. Even for these components, it is important to examine the underlying strategy, and separate fact from assumption.

Big Design up Front (BDUF) is also the antithesis of a Lean approach. Fundamental to Lean thinking is the notion that large amounts of inventory (unfinished work) causes waste. This waste materializes in the form of quality problems, unpredictable delivery lead times, and lowered throughput. When thinking about knowledge work, there is no physical inventory to remind us of how much unfinished work we have. In this case our unfinished work are all the requirements, plans, strategies, and design artifacts that represent a unit of change that has not yet materialized.

The more we try to create the perfect design the more we increase our inventory of unfinished work. Larger inventory delay potential downstream business benefits. More importantly, they reduce the feedback into the transformation process. Transformations are inherently variable, many things will not proceed according to plan. When dealing with something as ambiguous as the way people work, it is inevitable that designs will contain a large amount of assumptions. Our experience has shown that assumptions are only correct a small portion of the time. It essential that we test our assumptions as quickly as we can. This will tell us when we need to pursue a strategy, and when we need to pivot.

We recommend building the transformation vision and strategy in such a way that known facts are separated from ( well-intentioned) assumptions. A good transformation plan will contain explicit activities to validate each assumption through incremental adoption of specific process components using the piloting process. This approach forces working in smaller batches, allowing completion of smaller units of change more frequently. After each unit of change is completed, progress can be assessed, feedback can be gathered, and the overall approach and plan can be adjusted based on the latest information. We recommend running the transformation using a Just Good Enough Design approach. This implies implementing the design in small units using a testable approach, validating the results of specific tests, and then finally determining if any adjustments to the design needs to be made.

Centralizing All Design Decisions

Creating the perfect, standardized solution using a big upfront design approach is typically accompanied by the desire to centralize design decisions for the transformation program. In an understandable desire to gain the highest possible quality, many transformations assemble a dedicated group of very experienced experts, tasked with creating the perfect design. All design decisions are passed through a centralized stakeholder committee, where design elements are carefully reviewed, and the future target state is built.

Unfortunately, this approach does not scale to meet the diverse requirements of different groups. Centralizing design decision-making doesn't work for the same reason that a one-size-fits-all solution doesn't work, IT work is inherently variable, a unique mixture of technology, consumers, internal experience, and delivery risk exist across different IT departments, and even within different projects. Furthermore, IT work is not manufacturing, something slightly new is always being built. The above has two implications, for processes to be effective, they need to vary by context, and they need to continually adapt to changes in those contexts.

We have had great success following an approach that organizes processes and other design components as a hierarchical set of design elements. Centralized design decision-making focuses on the top of the hierarchy, on areas that truly need to be standardized across the organization. This includes the overall process architecture, overall organizational structure, role descriptions, and performance metrics. Lower levels of the hierarchy contain design elements that have a smaller span of scope. An example of the next level may be decisions and policies that affect individual departments. The next level down our elements that affect individual programs, and the bottom are elements that affect individual teams.

Policies and processes that only impact the individual teams can be designed, and followed by those individual teams. This also means that those teams are free to adjust those policies when they are nao longer supporting a high quality approach to delivery. Policies and processes that are project or departmental wide requirements appropriate manager intervention to modify, likewise design decisions at the top of the hierarchy require executive oversight to change. This approach, supported by a measurable and testable framework, insures that the organization is able to successfully adopt a continuous improvement approach while still providing a stable framework for the enterprise..

 

Transformation Demand Outstripping Organizational Capacity to process change

We have seen clients commit to transformation roadmaps without adequately considering the level of engagement required to successfully complete the plan. While a roadmap can look good on paper, it is important to assess the order and sequence of all activities against the capacity of internal staff to complete those activities and absorbed the change being asked of them..

Starting too many things at once will also lead to too much work in progress, which as stated previously is a primary source of waste for knowledge workers. We recommend putting a hard limit around the number of transformation activities that go on in parallel, and reducing that number if there is evidence that activities are not being completed in A timely fashion.

One solution is to operationalize the transformation engagement using Lean & Kanban techniques. This approach ensures that the organization will not start more work than they can finish, ensuring that the transformation team stops starting, and starts finishing.

Not Providing Adequate Support for Staff to Adapt to Big C Change Elements

Not all changes will be done in an incremental fashion. The targets may call for some larger, big bang structural changes to the organization and the way people work. This kind of change must take into account impacts to affected staff. This includes the time required for staff to acquire new skills, create new capabilities, bond with new departments, and otherwise absorb the change. Major changes to organizational capability, changes in job descriptions, and movements to new departments are tough on all involved. Is important to properly assess the impact of any of these changes on all staff and management before starting.

Focused, full-time expertise is required to provide communication and change management support to pull off these kinds of change. This includes appropriate communication, skills assessments, training, and organizational readiness. Dedicated professionals are required to take the time to ensure that the vision is communicated to all levels of the organization, areas of resistance are understood, enabling teams are identified, and that the change management approach follows a deliberate change management strategy.