If we improve a process in a forest, and no one hears it… did it happen?

By |2006-02-27T19:04:00+00:00February 27th, 2006|Enterprise Architecture|

In Six Sigma, from what little I know about Six Sigma, you identify the outputs of your process that are ‘critical to quality.’  You then look to see if you can find the measures that can move those outputs.  You work to drive these measures in a positive direction, quality goes up, and the requisite business benefits occur.  Cool.

All this leads to process improvement. 

Problem is: which process? 

Lean manufacturing and the Theory of Constraints tells us that the process you pick to improve matters… a lot.  If I improve a process that makes a non-key individual more efficient, there may be no effect whatsoever on the overall ability of the company to deliver value, make money, or even reduce cost.  In addition, any time and effort I’ve invested in improving a process can, in some cases, make a person unwilling to change the process later, even if marketplace changes demand it, because “we spent all that time!”

So when you are trying to create a business case for an application, don’t just say “we will make Mary more efficient.”  Tell the story of what Mary does, in relationship to the overall process of providing value to the company.  Then it makes sense to invest in Mary.  Then Mary is critical to quality.  Then, any delay in Mary’s job means money is spent or revenue lost.  Tie it back.

Otherwise, you may spend money making Mary more efficient when a smart move would have been to give Mary a more interesting job.

What standards to enforce, and who are the enforcers

By |2006-02-25T12:56:00+00:00February 25th, 2006|Enterprise Architecture|

I’ve been working on a problem that has to do with standards, enforcement, and the notion of a software development ‘community’ in the workplace.

As you may know, I’m a member of the IT Enterprise Architecture team.  We are responsible for creating a vision of where our IT and Application infrastructure will be in five years, charting a course to get there, and then poking (hard) at the business if they want to take the easy way out and go some other direction.

That last part is called Governance:  How to make sure that we all go in the direction that we all agreed to go.

We do this in our own communities.  I vote for civic leaders, they pass laws (with my consent, hopefully) and I obey them.  That’s a democracy.  Problem is: a business is not a democracy.  At best, it is a benign monarchy.  At worst, it is a dictatorship.  But it is nearly never a democracy.

And that takes two key elements out of the loop.  The folks being governed lose the right to say “who” will govern them, and the list of things they have to agree to, the laws, are not born of their concensus, but rather thrust upon them.  Is it fair to call this governance?

So, in the absense of a pure democracy, how do we put back these elements: control over who and what.

One thing we are working on is creating the concept of IT communities of practice.  In Microsoft IT, there are over a dozen different IT organizations that are almost completely independent of one another.  So an application designer working in one group, supporting the World Wide Licensing program, for example, wouldn’t normally know the name of an application designer working in the IT group that supports Microsoft Consulting Services. 

So, if we group people by what they do, developers, testers, designers, architects, project managers, etc, we begin to form the ‘body politic’ that can become responsible for their own future.

With that body, if we can have them create self-appointed committees to determine what changes in policy that they believe should occur, then we get the beginnings of a notion of legislative power.  (The problem is that a policy change that is good for a developer may be bad for a tester, and the testers won’t get to know about it.)

At the center, instead of an elected administration atop a civil service, you get an appointed executive (the CIO), his appointees, and the civil service (Enterprise Architecture, EPMO, Six Sigma teams, plus others I’m not aware of).  This administration has to take the suggested policy changes from the communities and decide which ones to implement.

So, do we get the voluntary compliance in this structure that we see in a democratic environment?  I’m not sure.  We will get more folks engaged in self-determination.  But, on the other hand, I’ve met very few people, myself included, who think that the suggestion coming from “someone else” to tackle “problem X” is better than the solution “I’m already working on.” 

In other words, if the ‘body politic’ suggests a change, and the administration vetos it, is there an override?  In a democracy, the administration is compelled to perform the will of the people, but not in a corporation.  A legislative body that serves a king is about as effective as the parliment of Kuwait. 

I suggest a way to get around this problem. 

Tell the communities of practice the list of areas that are “off limits” for their suggestions.  Define their scope in the negative, as in “You can touch anything except X, Y, and Z.”  Then make a committment, a real honest committment, from the executive level, that the suggestions created by one community, and accepted by all, shall be implemented in a visible manner as long as it doesn’t rewire X, Y, or Z. 

Effectively, this is the same as allowing municipal democracy in a centrally-controlled state (a model that I hope China will adopt, BTW, so that all those local conflicts over land use can settle down). 

Can a corporation withstand the notion of municipal democracy?  I don’t know.  I do know that the model works from an economic standpoint.  Municipal democracies tend to be the most pragmatic forms of government in a democracy, primarily because they are focused on local issues (schools, trains, roads, polics, and fire, for example).  It is municipal democracy that allows the administration at the federal level to focus on strategic issues, instead of being mired in the tactical. In a corporation, that is the CEO, and strategic is where we want him.

So, as we reinvent the notion of governance, where does that leave Enterprise Architecture?  In the civil service. 



Do we have the courage to take ourselves out of the loop?

By |2006-02-18T16:39:00+00:00February 18th, 2006|Enterprise Architecture|

Workflow tools only fulfill their real promise if the business users can not only see the workflow, but can modify it without calling a software developer on the phone.  It has to be simple, easy to learn, and something that is difficult to add bugs.  (Think Excel Spreadsheet).

Of course, the tools have to be available… something that is “safe” to put on the desk of a business user (e.g. Not Frontpage or Visual Studio)… and training has to be available.  It has to be usable.

We aren’t there yet… and the competition is getting close.  There’s a race here.  Let’s see who wins…

Would a six-sigma business architect support Agile methods?

By |2006-02-15T01:53:00+00:00February 15th, 2006|Enterprise Architecture|

A few weeks ago, I spent a few days with “six sigma” folks.  I was reminded of that experience when my manager asked me for “measurable results” and I thought back to what my six-sigma friends would say is a ‘Measurable result.’ 
In one team at Microsoft, I had a long chat with a software process person who was very interested in measuring the productivity of the development team in “average lines of code per hour.”  At the time, I felt, in my bones, that this was a poor measurement of “productivity” but I had a hard time putting my finger onto why.  So all this came together when my manager asked for measurements.
If we, as developers, are going to deliver value, that value will pay off when we deliver a feature that an end-user will use.  Owning the software isn’t enough. It must be used.  More so, they have to not only use the feature, but feel that the feature is valuable.  Therefore, of all the lines of code that I write, if that line of code is not in direct support of a “valuable feature,” then the time I spent writing it should NOT count towards my productivity. 
So take an application spec, deliver only the features that a user will find valuable, and I will deliver a small increment of value to that user.  Call that V.  Multiply V times the number of users who find it and you get a measure of “accumulated value” for that feature (FV).  Now, subtract the cost to develop the feature.  (Net FV).  Pray it is not a negative number. On a feature-by-feature basis, that is how to know if I am productive.
Of course, we’d all like to think we are delivering valuable features.  So why did I find myself in an argument today with a business analyst who was insisting that a segment of the market for one little tool would NEED “expensive feature X,” when that same analyst couldn’t answer the question “what business process will that user be performing when they use feature X, and how will that feature add value to that process?”  He didn’t even try.  Yet, he still insists that the feature MUST be delivered.  His project is waterfall.
And that is why Agile works, and why Waterfall doesn’t.  Because he is typical.  Because developers and analysts think they know what users want, but they are nearly always wrong.  Because we need to have users IN the team, and working WITH the team, and not the victims OF the team.  Because users discover their needs on every iteration… so giving them as many as you can, in a short period, is the best way to “grow” your application from an idea to a useful solution.
Because, in the end, instead of measuring developers’ productivity by lines of code, we should be measuring teams by their Net Feature-Value (NetFV). 
That would be a ‘measurable result.’

No one will read it

By |2006-02-11T04:25:00+00:00February 11th, 2006|Enterprise Architecture|

I’ve thought about writing a book on workflow.  I have a lot to say (more below).  The problem is, no one wants to read a blinkin’ book on workflow.  So, I’m thinking about a business novel (like Goldratt’s The Goal or Who Moved My Cheese by Johnson and Blanchard).  Problem is: I’ve never published fiction. 

This is an odd space, really… business stories.  Taking a dry topic and wrapping it an story makes it much easier to grasp.  Normal people, who don’t spend their time in geeky pursuits, may even be able to benefit (or at least, enjoy). 

How else would I get someone to read a book on the notion of multiple levels of abstraction?  I’m certain that a person, any person, can apply the principles of abstraction to workflow, and can create models for appropriate audiences that can be both useful and possible to automate.  I’m pretty sure I can teach my 12-year-old son how to model a workflow at different levels of abstraction, and how the best way to find the “big themes” is often to reduce, not increase, the amount of detail.

It’s counter-intuitive, until you do it about a hundred times. 

The thing is, instead of describing workflow and abstraction and models, I’ll be telling a story.  And that is much harder to do.

Better software cost estimation tools are needed

By |2006-02-02T03:18:00+00:00February 2nd, 2006|Enterprise Architecture|

Geeky topic: Why has there been so little investment in software cost estimation?

I know that Boehm at USC created the Cocomo model and a really cheesy and unusable tool for cost estimation.  No one can understand it, and it is impossible to train a project manager on how to use it.  Some products are based on this tool and they do a good job of making the interface less ugly, but the overhead for understanding the measurements is still high.  (Plus I question the basic premise… that you can take measurements about things like the development team’s level of experience with the code and come up with a useful estimate, when less than one third of the time on a project is spent writing code.) 

Let’s face it: COCOMO is a failure.  It is open design (if not open source) but no one can use it.

Capers Jones suggests a different way to measure software productivity.  You measure the time spent on a bunch of software development projects, across a long list of activities (things like coding, integration testing, requirements gathering, deployment, etc), and you attribute those measurements by some information about the project (like language, platform familiarity, etc. Some of the same things that COCOMO tries to turn into cost factors).  You then have actual measurements.  When you want to figure the cost of a project, you take the measurements for similar projects and you figure the same average productivity will exist for the new one.  It’s amazing effective, and quite versatile. 

Unfortunately, this model requires a good bit of data about your environment.  That data is hard to capture and the tools are light at best.  You can make your own tool, and use published national averages, but the numbers will be suspect.  Once again, there are a few niche tools, but they are expensive.

There are a couple of proprietary apps that try to bridge the gap between complexity and producing useful information.  They are interesting, but REALLY expensive.

This really isn’t that hard to get right… why has no one done it?  A software app that is under $300 (one time fee) that can get basic information from a user, in a simple paradigm, and can construct a useful and valid software development cost estimate… is that so difficult?

If I can choose from between five different tax programs to fill out my taxes, and they all have wizards that allow me to answer simple questions, and they result in correctly filling out some REALLY complicated forms, there is no reason why software cost estimation should be as hard to do and as complicated as it is.

No wonder this area of research never took off.  Mathematicians make lousy usability designers (I can say that… I’m a math geek).

Paying to get to the new Enterprise Architecture

By |2006-02-01T20:33:00+00:00February 1st, 2006|Enterprise Architecture|

I need to rant.  I ran across an article on the IASA web site that provides tips for knowing if your Enterprise Architecture is mature.  One of the tips asks “If you have a bunch of architecture projects defined, do you have a process for getting them funded…”

Huh?  Since when is Architecture a “bunch of projects?”  Yes, you need a project to collect the strategic requirements and to create the high-level systems architecture, future-state application portfolio, and migration plans.  However, after that, is it really a “string of architecture projects” to move to the new plan? 

Yes, there are projects needed to change code to more to a new structure.  Yes, those changes cost money.  Yes, someone has to pony up that cash.  However, if your architecture doesn’t actually deliver any value, on a project by project basis, why are you doing it? 

If your architectural change delivers value, then you can justify that value as ‘changing the app to reduce the cost of owning it.’ 

If the cost of the change exceeds the value in the short term, perhaps your migration plans show that the app doesn’t adopt the new architecture until a business-driven change is actually required.

It is not wrong to migate to an architecture slowly, over time.  Time can be your friend.  You get better at delivering value on the architecture, and the team gets better at using the architecture, and risks associated with adopting the architecture are minimized. 

And you don’t need to go to the CIO and beg for millions… honest.

Patterns and the Peter Principle – The positive effects of recognizing good application design

By |2006-02-01T18:56:00+00:00February 1st, 2006|Enterprise Architecture|

Old developers don’t die… Sometimes they move up.  Think about it.  Have you ever met a manager who was a stellar Assembly developer once.  How about RPG?  (When I first entered management, the team could point to one time in my past when I wrote EasyTrieve code… if you can call EasyTrieve “code”).  I can’t count the number of dev managers or dev leads that I know who once wrote code in Visual Basic 3.0.

The problem is that design moves on, even if a dev manager doesn’t.  This isn’t wrong.  In fact, it is perfectly normal.  Our managers rely on smart teams to keep up, and they do their best.  No, the lack of advanced design skills in management is not a problem.

The lack of design skills in the design team… that’s a problem, and the fact that most managers can’t tell that their design teams stink because their design skills are not exactly “cutting edge”… That’s the flip side of the same problem.

The Peter Principle says “A person will be promoted through the ranks of a corporation until they reach a position where they are utterly incompetent, and there they will stay.”  In some corporations, this means that nearly all of management is essentially incompetent.  (At Microsoft, we reorganize management so frequently that incompetence tends to show up and filter out… but sometimes good ones leave as well.  That’s another blog post altogether).

The Peter Principle in design says that excellent application design will go unrecognized, and poor application design will go unpunished as long as the manager was promoted before he or she learned how to design anything.  In some IT shops where I worked in the past, this was the primary rule.

Design was delegated to the ranks of the hero.  The system could not support the building of excellent design skills, or require excellent design artifacts, or even reward excellent design expressions, because the group manager was utterly incompetent in the skill of “recognizing and rewarding good design.”

Therefore, developers who cared would first learn good design, then try to force their team mates to use good design, and then, after mountains of frustration, would leave.

If this is you, I have good news: you do not have to simply suffer in silence.  You can get off the merry-go-round.  Your first task is to learn how to EVALUATE good design, and then teach others (especially your manager) how to do the same. 

If you have a hard time convincing your manager to learn good design, then set up a competition in your company, with open submissions and a judging panel (made up of good designers) who will evaluate submissions and give a quarterly prize.  Hang a poster next to the elevator or the water cooler announcing the winner.  Pitch in $20 for a ‘desk trophy’ that the winner gets.  (I spend more than that schmoozing with internal customers on a monthly basis).

Once your team begins to recognize what good design looks like, it will be much easier to convince people to spend time and effort on improving the overall process so that good design becomes normal, and not the product of heros.

Everybody wins.  And who knows… maybe you will be the one they recognize next…