Saturday, January 28, 2012

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.

methodology_innovation

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.

kanbanboard_full

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.

principles-of-radical-management5

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.

Thursday, January 26, 2012

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.

Wednesday, January 25, 2012

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.

Tuesday, January 24, 2012

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.


Monday, January 23, 2012

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.

Sunday, January 22, 2012

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.



Saturday, January 21, 2012

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.

Tuesday, January 17, 2012

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.