New Tool: The Path of Least Danger [Matt Schlegel]

In the previous blog, I described the step in the problem-solving process of how a team will analyze the various ideas proposed to solve a problem. During that analysis, the team logically thinks through the pros and cons of each idea. The team will also want to consider peoples’ emotional reactions to each idea, as that will impact the overall acceptance of a proposed solution. Having done that, the team has equipped itself to formulate a plan to move forward. In order for the plan to be accepted, the costs must be reasonable and the risks must be balanced. In my experience, I have found that after bringing a team of people through the problem-solving process to this point, there is a remarkable amount of consensus around the solutions to use in order to solve the problems the team faces. Building on that consensus, the team at this point in the process decides on a plan to move forward. This plan I like to call the Path of Least Danger.

Fear is a remarkable thing. Each of us has a different reaction to fear. I will stretch myself here with my lay knowledge of how the brain processes fear. There is a part of the brain, the amygdala, that serves as the information processor that outputs the fear response to the rest of the brain. As with much of our bi-cameral brain, the amygdala has a right part and a left part. My understanding is that one side tells our brain that something is really scary and that we should avoid it if at all possible. The other side tells the brain that you should go and destroy the thing that is making you feel this way. And, just like people can be "right-brained" and "left-brained" or "right-handed" or "left-handed", some people will have a strong reaction to fight and some will have a strong reaction to flee. (Please correct me if I have misrepresented the function of the brain, this is a blog after all.)

Since we are not quite to the point in our problem-solving process where we need to fight (I will talk about that more in the implementation phase), we can tap into the thoughts of the more "run-for-your-life" types, and I put myself in this category, to help the team formulate the path to move forward. Since the team has collectively decided already to do something, they now need a plan to get them to a solution that solves their problem. And, since all the scary pitfalls and landmines have been laid out in the analysis phase, and by this I am referring to the resources that the team would need to implement each idea and the threats that would prevent an idea from being implemented, then it is a matter of finding that optimal path that minimizes both resource utilization and threats to failure. On that path the team can build the reasonable-cost, risk-balanced plan. In other words, we can use our fear response to empower the team to choose the Path of Least Danger.

Now that the team has decided on a path forward, it is time to acquire the resources you will need to take the team down the selected path. In the next blog, we will talk about the important step of advocating the plan not only to get the permission to proceed, but to get the resources, as well.

__________________________
Matt Schlegel categorizes himself as a "fear aware" type. He taps into that characteristic as he finds that it gives him the ability to create project plans, schedules, test plans and manage quality for products. He finds that he is a "natural" at worst-case analysis, and uses that natural ability to help teams avoid pitfalls, create reliable solutions, and build high-quality products.

More...

Zoom with Joomla or Drupal [Steve Mezak]

You can launch your web app faster when using a content management system (CMS) like Drupal or Joomla or other frameworks like CakePHP or CodeIgnitor – all written in PHP. These CMSs and frameworks contain built-in functionality that will accelerate you software development. But using them the wrong way, or in the wrong situation can be a disaster.

It is critical to get a web app launched as quickly as possible. No one wants to wait months (forget years) for a new web application to appear online. The promise of CMSs and Frameworks is they give you a jumpstart with pre-built functionality and an environment that makes your programmers more productive. But like most tools, they can also be misused causing more headaches than help.

These frameworks are open source and available at no cost but they have a steep learning curve. I got excited about using a CMS for a website I was creating last year. I bought a couple Drupal books and downloaded the software from the Acquia website. It installed easily and I had a working site in a day.

Customizing the site was a different matter. I was able to easily add in several contributed modules but I found it difficult to combine modules along with my custom code to create a decent looking functional application. I basically wasted a couple weeks to discover that I really needed experienced professional help.

If you are building a community website then you should consider using a CMS platform. A CMS has these features that community websites need:

• Access statistics and logging
• Advanced search functions
• Comments, forums, and polls
• Multi-level menu system
• Multi-user content create & edit
• OpenID & Facebook Connect
• RSS Feed Aggregator
• and many more . . .

CMSs and frameworks are extendable and it is common to add code to deliver your desired functionality. For example, Drupal has a list of user-contributed modules available to extend its functionality. And your programmers can create their own modules too using the Content Creation Kit or CCK.

The primary pitfall that inexperienced programmers fall into when using a CMS is adding functionality by changing the framework itself. If your programmers “hack the core” of your CMS directly they create a mess that is difficult if not impossible to fix.

Any new development team is not likely to be able to unwind the hacks. To fix any bugs they will only be hacking the core further. In this case you almost always have to start over.

First you should decide if CMS features are needed. Selecting a CMS may only add complexity if the features you need are simple or different that what the CMS delivers. A framework that enables rapid page creation and supports modern Ajax-based user interface features can be a better choice.

The look and feel of your web application is completely configurable with a CMS. Frameworks and CMSs have a way for you to deploy your design in a consistent way. In Drupal this is called Themes, in Joomla it’s called Templates.

Versions of Frameworks and CMSs change periodically. If you outsource, make sure the development team you hire has experience with the latest version, or at least the version you want to use. For example, Drupal had a major upgrade from version 5 to 6 last year. Many of the user-contributed modules did not work with the new version. It was months before most were development teams were experienced with version 6.

Experience with these modules is critical. Anyone can install a framework or CMS, but the basic functionality is not enough. Ask for examples of web apps your prospective development teams have created for other clients and the kinds of modules and custom development they employed.

Use a development team that has experience building web applications for other clients with the CMS or Framework you decide to use. You can wind up wasting your time attempting to make a sophisticated web application on your own by using one of these platforms right out of the box unless you have already gone up the learning curve. It takes professional help.

The only thing worse than wasting your own time, is wasting time and paying money to an inexperienced development team. Choose carefully and your use of a CMS can shave months off your development time line.

_______________________
Steve Mezak, CEO of Accelerance, Inc. and author of the book, Software without Borders, has dabbled with Drupal. Use his free online Global Partner Network, containing the contact information for 40+ hand-selected and pre-qualified software development partners in over a dozen countries around the world, some of which are experts in Drupal and Joomla. http://www.accelerance.com/

More...

Leading What [Jane Divinski]

When people talk about engineering leadership they often are referring to leading human beings, specifically, engineers, but I think that it’s more accurate to realize that one is actually leading decision making. Some of these decisions are made unilaterally by the “engineering leader” but many are the result of input by multiple people in the organization. Regardless of who’s involved, the leader needs to make sure that decisions ARE made and made in an appropriately timely fashion.

Years ago my then boss informally confronted me with his concern that I might be making decisions too quickly. He pointed out that additional information is usually forthcoming and wondered if I might not be better off awaiting it’s availability before moving forward with a decision. We actually had a lengthy and enjoyable discussion about this topic.

I asked him for specific examples of such instances and he promptly cited three. I then proceeded to spell out all the information I had factored into the decision. In addition, I described other data I would like to have had to factor into my analysis and explained why such information wasn’t yet available and when I could reasonably expect said info.

We then chatted about the impact (aka cost) of delaying the decision; for these three examples he ended up agreeing with me that each involved instances where a timely decision, based on the available data was better than a delayed decision. Obviously this is not always the case.

__________________________________________
Jane Divinski has enjoyed the challenges of engineering management consulting since 1994. Most of her gigs are as interim VPE but Jane's also tackled other interim roles including CTO or program manager. Her background is at www.jadski.com

More...

Be a (Part Time) Rock Star VP of Engineering [Steve Mezak]

The phone rang in the meeting with the CEO. He said, “Sorry, I can’t talk now. I am in a meeting with my new VP of Engineering and he’s a rock star.”

The title “rock star” can mean different things. To this CEO it meant he finally had someone he could rely on to get the software product developed. The CEO had fumbled badly spending over $50,000 with a local web design firm with little to show for it.

Now he had hope.

A non-technical or business-oriented CEO must hire a competent VP of Engineering to take responsibility for on-time delivery of a high quality product. But what kind of person should our CEO hire? Should the VP be hands-on and contributing to the code? Or should the VP be a people manager and stay above the details of the daily builds?

Either way, you want to hire a rock star. But what is a rock star VP of Engineering?

Rock Star as a Technical Achiever. The CEO of a startup I spoke to recently wanted to hire a VP of Engineering to jump in and start doing hands-on work with Microsoft .NET. His rock star will have his or her own MSDN subscription and personally built several ASP.NET web applications.

Rock Star as a Mature Leader. Another company already had 20 software developers (and a small outsourced QA team in South America) all lead by a young but very smart programmer. He worked directly with his team to create the software.

The CEO wanted to add an experienced VP of Engineering that could harness the existing technical leadership and get some control over the software development process. With business growing, the programming team could increase to 40 people.

His rock star will be able to impose a predictable process, command the respect of a strong technical team while hiring more programmers.

Rock Star as a Global Leader. Some companies will have no internal programmers and rely completely on their offshore software development team. One Accelerance client had their own development team in Ukraine. It was a remnant of an outsourcing arrangement gone bad, which is another story.

But things were still not going smoothly. The CEO needs a rock star leader that keep a global team productive and can hop on a plane to Kiev once in a while to do so. A technical achiever with little concern for cultural issues, or a technical leader that is a good face-to-face manager will not manage a global software development team well.

It is important to understand your situation and hire a full time VPE rock star with the kind of experience that will meet your needs.

But there is an alternative.

The Part Time Rock Star. Instead of putting all your eggs in one basket with a full time VPE, a CEO can hire a part time or interim VP of Engineering to get things started. Part of the interim VP of Engineering role is to find their own replacement.

The CEO benefits by moving the programming work forward and extra experienced help with the recruiting process for a full time VP of Engineering. Otherwise a great deal of time and money can be wasted waiting for the right person to come along, or worse, if the wrong type of VPE is hired for the situation.

On the flip side, if you are looking for a full time VP of Engineering job then decide what kind of “rock star” you are. Consider only the kind of opportunities for which you are a fit. Don’t feel bad if a prospective employer is looking for a rock star of a different stripe. Focus on what you do best and the right job will come along.

But the economy being what it is, consider offering to be a part time VPE if you can’t close a full time opportunity with an employer that looks like a good fit. Working part time is a good way to get some cash flow and for both you and the employer to get started on a trial basis.

Be a part time rock star until a full time gig comes along.

____________________________________
Steve Mezak, CEO of Accelerance, Inc. and author of the book, Software without Borders, is a global software development rock star. Use his free online World Region Outsourcing Guide containing the contact information for 40+ hand-selected and pre-qualified software development partners in over a dozen countries around the world. http://www.Accelerance.com

More...

IT Dilemmas [John Levy]

As an organization grows, it has to increase the scale of IT activities, including software development. As a result, it faces these dilemmas:

1. Software development is engineering, but IT is an expense.

If your only management metric is level of expense, rather than return on investment, then you won’t be able to differentiate between winners and losers in software development. Some organizations have the CIO reporting to the CFO, because they are completely oriented to control of expenses, and IT is a large expense. But this misses the fact that investment in software, whether for internal use or for sale as a product, should be managed the way that R&D (Engineering) is managed – as an investment in development that must ultimately produce a return.

Engineering is not purely execution. R&D/Engineering involves a degree of creativity along with a professional sense of discipline about implementation. That’s why recruiting and retaining people who can balance innovation with execution is as important in Engineering as in, say, Marketing.

2. Outsourcing and offshoring work when the activities of software development can be broken into component parts and split across multiple organizations without loss of innovation or relevance of the product.

In forward-looking organizations, IT-implemented tools provide a strategic advantage to the business. To achieve this, IT strategy and architecture must be very close to the top decision makers. In this context, the question of outsourcing becomes, “can we succeed by having people we have not hired directly execute some part of our implementation?” To the extent that the impact of software or IT on the organization’s strategic goals is not considered, the decision to outsource can lead to failure in many ways.

3. If no one in top management understands how IT works, then all the IT decisions will be made based on financial reports. As organizations get big, they become more and more finance oriented. When someone at the VP level or higher has enough technical background to understand IT implementation, then IT strategy has a much better chance of being realistic. Of course, the CIO should have a basic knowledge of technology as well, because vendors will attempt to sell things which may not be appropriate to the organization. The main problem, however, goes back to item 1 above: managing Engineering is different from simply controlling expenses.

4. Traditional Project Management doesn’t fit well with Agile software development.

When we do software development in an Agile framework, we have fixed time & budget and variable functionality. Almost no one who has been doing traditional Project Management intuitively understands how to manage a project this way. Short Agile iteration cycles confound traditional PM tools and measurements. We need the PM world to come up with a new division: Agile Project Management, with a focus on projects that are not characterized by large sets of requirements up front, and have rapid fixed cycles with variable functionality.

5. It is difficult to overcome an addiction to short-term metrics.

IT managers prefer short-term pain-reduction (ship it!) over longer-term goals (is it what the users want?) every time. This leads to the never-ending cycle of code debt (code that needs to be cleaned up and/or re-written). To overcome this phenomenon we need to understand the psychology of addiction and to get top management to support a change to proper metrics. For further discussion of this, I recommend reading Gerry Weinberg’s Quality Software Management, Volume 3: Congruent Action (New York: Dorset House, 1994).

All 5 of these items also apply to software development in Engineering departments. But the effects are most widespread in IT organizations. How is your IT organization doing?

__________________________________________
John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on managing development, Get Out of the Way, is due out in 2009. More info is at http://johnlevyconsulting.com/

More...

New Tool: Analysis, no Paralysis [Matt Schlegel]

In my previous blog I described how the problem-solving team generated a rich set of ideas from which to draw candidate solutions to the challenges it faces. But, how does the team go about deciding which idea is the best one? Should they fight, bicker and argue about each?

Well, sure, in a controlled way. I call this phase the Analysis Phase of the problem-solving process, and it is part of a two step process, the second step being the Proposal Phase, in which the team arrives at a consensus regarding the path they will take going forward. In this phase, the analytical folks shine.

Every idea has its good points and bad points, its pros and cons. During this Analysis Phase, I present the problem-solving team with the list of the big ideas that have been generated. I will have taken the many ideas that were generated in the Idea Brainstorm and grouped them into a number of big ideas for the team to explore. Each big idea is allotted time for discussion and for generation of the strong points and the weak points.

It is important to move quickly through the collection of the pros and cons. For instance, if you have 100 minutes and 12 big ideas, keep the pro/con analysis of each idea down to 8 minutes apiece. You will find that you are able to collect the important points in those 8 minutes. And, you can avoid getting caught up in minutiae and falling into the proverbial rat hole. Remember, some folks will excel during the Analysis Phase and want to explore the nuances of each idea. On the other hand, some folks will find this detailed analysis a bore. You will want to strike a balance to ensure the analytical folks have a chance to show off their stuff, while keeping up the pace to get through all the ideas and, at the same time, keeping the entire team engaged.

During the Idea Brainstorming phase, you asked the team to set aside their negative reactions to the ideas aired. During the Analysis Phase, you take the opportunity to revisit those negative reactions. You will want to encourage those that feel strongly about each idea to voice their thoughts and feelings. What has happened in the roughly 7 days since they first had their reaction is that the emotional level will often have subsided and the person who feels strongly will be in a better state to explain calmly to the team the reaction that they had and why they think they had it. I have found that letting some time pass is an effective way to explore the emotional side of each idea without letting emotions rule the process.

So, after spending a few minutes on each idea, would you feel like you have done a proper analysis on the idea? Of course not! What will often happen is that the team will not have all the information that they need to adequately analyze a specific idea. In that case, I ask for volunteers, generally the biggest proponent and opponent of a given idea, to collect the information the team feels it needs to analyze the idea. If the need arises, I may call a separate meeting to review any new information, so the team has the chance to develop the pros and cons for the idea to the team’s satisfaction.
Your Problem-Solving team now has a rich set of ideas with the pros and cons for each idea. The analytical folks on the team have chimed in and provided the data and assessment that the team needs to move forward. That brings us to the topic for the next blog, the Proposal Phase, which I affectionately call, “The path of least danger.”
_______________________________________
Matt Schlegel enjoys data. During a recent presentation to a client, Matt noted that he had to pare back the amount of data in the presentation, saying that there was simply too much data. The client quickly quipped, “I never thought I would hear Matt Schlegel say the words ‘too much data.’”

More...

Reviewing Up - Revenge? [Philippe Habib]

At my first job, when the VP of engineering asked me if I could come to his office for a few minutes, I felt like I was 10 years old and called to the principal’s office. Things did not improve when he asked that I shut the door. This was my first job; I was trying my best to do good work. I mentally searched for what I could have done to be in this much trouble.

Instead, he asked for my opinion of my boss. In my previous work experience , sweeping an airplane hangar, or working in a factory, my opinion of my boss was neither important or solicited. I just had to do what the boss said, and do it quickly enough and well enough to keep my job. I had no idea of how the boss was evaluated, but I was sure that what I thought of the boss never entered the equation in any way.

I don’t remember exactly what I said. Probably something lame like “She’s fine.” or some such. This really wasn’t enough to satisfy him, so he asked me more detailed questions.

• Did my manager make it clear to me what I was expected to do?
• Did she provide me with relevant and useful feedback along the way?
• When I needed help, did she provide it?
• Did she give me too much guidance and try to control my every step?
• Did she have adequate technical skills to give me the help I needed?
• Did she act in a way that made me uncomfortable or afraid to ask for help?
• In areas where another person in the department had more knowledge, was she willing to defer to that person, or did she always need to act as the expert?
• When I did something wrong, did she tell me what I did wrong and explain what I should have done instead? Was this delivered in a constructive way that helped me learn and do a better job the next time?
• Did she give me guidance about what I could be doing to get myself ready for more responsibility in the future?

Once I got over shock of having the tables turned and being asked to evaluate the boss, I answered the questions as best I could.

After we were done, I had my own question. Since she was the manager of 6 or 8 engineers and I was the newly hired, zero-experience, source control person, what did it really matter what I thought of her? I would do what she said and get my work done, whether I liked her or not.

The VP explained to me that the manager’s job went beyond making sure that I had current listings of all software and that I could build the same executable each time. Her job was to make sure that I did my job in an efficient and effective way and that I was happy doing it, so that I would not look for another job. She was also to help me grow into a more skilled role. She wanted me to succeed and be able to relay my knowledge of the company's products and processes, so that they would not be lost when I was ready to do something else.

He explained that all he could evaluate from his position was that the work was getting done, (dust on the floor, finished machines on the rack). He also cared about the stuff that would keep people happy and productive long term, so that he wouldn’t have to hire a replacement for me or have schedules jeopardized by turnover. In order to get that kind of information, he had to solicit it from the people who report to the manager.

Looking back on it after more than 20 years in the work world I now see benefits for all involved in this kind of a review. The VP knew if productivity was the result of fear and intimidation and would vanish, when his people did, at the first upturn of the job market. My manager could be alerted to good and bad habits and become a better and more effective leader. As an individual contributor I was able to influence my work environment and to learn about the bigger picture of how a department is run.

I'm sorry to say that in over 20 years of industry experience I have never worked at another company that did that kind of a review. Lacking the explicit interest from upper management, most people don't take the risk and trouble to review their manager. They just vote with their feet.

______________________
Philippe Habib consults on embedded device design and firmware. Prior to consulting he has worked for Oracle, IBM (lotus/cc:Mail), Apple, and several startups. More information can be found at www.phenomasoft.com.

More...