Natural Leaders

Did I intend for this space to be used for discussions about leadership? No. However, the natural risks and pace of change that are inherent with software engineering makes leadership incredibly vital and high quality leadership hard to come by. When I came across an article written by Gary Hamel called How to Tell If You're a Natural Leader I immediately thought that it was important to share it here.

What made it most thought provoking are these paragraphs:

• "Think about your role at work. Now assume for a moment that you no longer have any positional authority—you’re not a project leader, a department head or vice president. There’s no title on your business card and you have no direct reports. Assume further that you have no way of penalizing those who refuse to do your bidding—you can’t fire them or cut their pay. Given this, how much could you get done in your organization? How much of a leader would you be if you no longer held even a tiny, tarnished scepter of bureaucratic power?".
• "... how much of your power comes from what you are (the VP for HR, for example), and how much comes from who you are ..."

In my mind, that's powerful stuff. Of course leadership is enhanced by title and power - perceived or otherwise. Who isn't going to follow someone, at least temporarily, who can dump your ass into the cold winter of this recession.

Yeah, Gary Hamel's article could be useful as an exercise in self-examination by existing leaders but I think a lot of that internal dialog has already happened. At most, this discussion could be a catalyst for calibrating oneself or possibly a reminder of some of those leadership principles. That's not what I find most interesting about this article.

I think this article is most useful for those that are not currently in an officially sanctioned leadership role. It's for self-examination of whether one is acting like the leader one thinks they are, or thinks they want to be, or possibly reluctant to be, or even in denial of being.

Another valuable aspect is to identify the natural leaders on your team and within your organization. Who is being followed without a title? Who on your team and organization tends to be at the center of things? Who do people go to for questions and advice? Those are the people that will build the teams for the future who are entrepreneurial, innovative, and mission oriented. You will need them because today's workforce is transient - and this is especially true in software engineering.

I recommend reading Gary Hamel's article How to Tell If You're a Natural Leader as well as subscribing to his Management 2.0 blog.

I'm interested in your thoughts.

Kanban Development Methodology

I was introduced this week to a development methodology called Kanban. For those of you who don't know the origin of the word Kanban, it's manifestation is as a physical card as part of the Toyota Production System (TPS) that signals the moving and production of parts in a "pull" system; a system where parts are made available as others are pulled into use downstream. The objective in a manufacturing setting is to control inventory based on the speed of production. The concept is applied to software development through controlling the development of tasks. In Agile, tasks could be user stories (the parts) which are subsequently developed into software features (downstream production).

The control of requirements, design, and development inventory is important to maximize project efficiency. A main focus of Agile is to gather requirements, design solutions, develop objects, and test working code at the moment they are needed. If any of these areas are far ahead or behind the others then a critical principle of Agile is being violated. Implementing Kanban helps to keep production of objects at each stage of the project at the appropriate levels.

Here is how it works. The team has a board that looks very similar to a Scrum board. It has columns for stages of development. The stages can look quite different. The images contained in this article are a few examples courtesy of InfoQ. Some look eerily like Scrum boards, don't they?

Regardless of the column names, cards start out in the far left column and move their way to the far right column. The inventory of cards at any one category is controled by open slots within a category. For example, using the image with the multi-colored postIts, when a card is pulled from the To Do column and placed in the Doing column, it leaves an open slot in the To Do column thus a need for more To Do items to work on. Unlike Agile, Kanban does not bundle work into sprints. The flow is constant.

In my opinion, where Kanban is most effective is on larger projects where there are teams that make up "columns" of work. The image with the Waterfall style stages illustrates this best. A large project will likely have teams that make up Basic Design, Detailed Design, Development, and Validation. With Kanban, each team can set their capacity of work by the number of slots they make available. If the Basic Design team has 10 slots available then they are saying they can work on 10 basic designs at one time. Detailed Design may have only 7 slots, thus their capacity is 7 Detailed Designs at a time.

It isn't hard to imagine Agile teams using Kanban techniques to control the flow of work. A simplistic view is to wrap Kanban into iterations and you now have Kanban Agile. There are additional difference between Agile and Kanban and I provided a couple of links at the bottom of the page if you are interested in learning more.

In a previous article, The Convergence of Continuous Integration and Continuous Release, I discuss the merits of deploying to production immediately after code is checked in and all test are run and are successful. Kanban would work exceptionally well in this type of environment.

Whether it's Agile based on Kanban or another style of Agile, there is a consistent attribute of Agile teams; the Agile team needs to be composed of multi-faceted team members who are adaptive. As production velocity shifts across any or all categories of the project, team members should be able to shift into different roles accordingly, i.e. gathering requirements, designing solutions, developing software, and/or testing working code (or coding automated tests). Personally, I think this makes being a software development professional more interesting but it isn't for everyone.

Click here and here to read two good articles on Kanban as it relates to Agile software development.

I'm interested in your thoughts.

The Emergence of Enterprise Social Computing

It’s exciting to think that true social computing at the enterprise level is right around the corner. That in the near future, the pretense of living intranet sites will be replaced by open, transparent, and constantly evolving intranet sites that grow organically through the contributions of the organizations workforce.

Picture, if you will, an environment where organizational leaders blog to their workforce on a regular basis and readers comment freely. Where those same organizational leaders query their workforce and their answers shape the company’s roadmap.

Add to that the ability of each member of the workforce having the ability to customize their own corporate page; blog on their respective expertise; create communities of like-minded people with whom they work regardless of proximity; search the organization for specific skills, work product, like-projects, structured and unstructured data; where they search for people with specific past experiences related to companies, industries, and expertise. All this with the ability for spontaneous contact through IM, email, VoIP, and web conferencing.

Lastly, this environment is shaped via email postings, blog articles, project and organizational processes, discussion boards, forums, wikis, profiles, and virtually any other type of medium where information is shared.

Today I attended a seminar at Microsoft in Waltham, MA where my colleague, Mauro Cardarelli, as well as other professionals in the SharePoint world, demonstrated real-life implementations of the environment described above. It was clear evidence that this type of environment is ready for prime-time and available to any organization with the vision and discipline to implement it.

The organization that is looking for a fully quantifiable ROI will be late adopters. But I’m certain they will be adopters. There are many aspects of this that are quantifiable but there are many more benefits that are not. One has to know that a fully collaborative organization is a fundamentally more productive one.