Build Small Bridges

You might care, I might care, but how do we make 'everyone' care? It's impossible. We can't. We can attempt to add one person at a time to our way of believing. But most likely--by the time we reach the last person--our thought process and beliefs will have changed so drastically that our purposes will shift. It's like painting a bridge: by the time you're done, it's time to start over again from the beginning and repaint. Make your bridges small. Build many bridges. And be flexible.

The Role of ScrumMaster / Software Development Lead / Manager

Remove impediments, improve the process. Understand what's being added to the backlog. Understand what kinds of "shortcuts" or workarounds are being taken by the team. Understand the consequences and better solutions to these items.

Plan for the next big problem

The stuff you're doing now will likely amount to something bigger and better once you're done. Keep doing what you're doing and getting better at it but keep in mind that there are consequences of what you are creating. Prepare for the consequences and get ready to tackle the next big problem they create when you get there; but only then.

Make the development process be THE KEY PROCESS

Development speed and efficiency might matter more than anything else. Yes, customer requirement and needs are paramount in general, but sometimes they are unclear and the development team can produce something really good that isn't EXACTLY what was corrected. This discrepancy is fine. If the development team can produce Product X which CLOSELY RESEMBLES the 'perfect product' described by the customer, then that is the product that should be produced. Future iterations can make it perfectly align.

Efficient workflow tradeoffs and cost

Workflow can be seen in two ways: that of the SYSTEM USER and that of the DEVELOPMENT TEAM. The end goal for most projects is to create a "perfect and efficient" workflow for the user. Being efficient may involve trade-offs as there is a cost for realizing perfect workflow. If the development team isn't paid for the realization of every incremental user workflow bit, then there is a problem.

Use the skills you have now to add as much value as you can now

Don't get bogged down doing a bunch of boring repetitive stuff now unless it is required. Follow the Pareto Principle http://en.wikipedia.org/wiki/Pareto_principle and knock out the big stuff. Demonstrate as much value as you can. Solve the problems you know how to but don't solve them throughout the whole system just yet. You can do that later. Yes, you'll develop a backlog of little stuff that has to be fixed; the time will later come when that is urgent.

Computer Programming is a Slow (, Fun?) Learning process for me

Yes, for me it's a very, very slow, tedious, painstaking one requiring much patience but the rewards seem to be many: it's very, very fun to learn so much and build a war-chest of solved problems that you can apply to the next situation. It's never-ending.

You learned it generally now, take the chance of applying it later

Any time you're unsure if adopting a new practice will help or hinder, don't adopt it. Go down the road on this project with the skills you have today and apply what you learned to the next project or iteration. Learning along the way is most of the fun but we don't have to apply everything we learned / are learning to our current project. We can do that later, in a future project! If you add the things you're learning to this project, you'll never finish; the project will grow and grow.

Today I'm working on a software app for my buddy Andrew. I'm having fun but the going's slow at times and I don't know everything. It is a forms application and the technology I've chosen to use is ASP.NET MVC (http://www.asp.net/(S(d35rmemuuono1wvm1gsp2n45))/mvc/) which I think is basically amazing, but I'm still learning it. In trying to solve the problem at hand, I read some VERY neat-sounding techniques from Brad Adams (http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-part-4-custom-object-templates.html) on automating form creation in ASP.NET MVC but I don't want to increase the scope of my project; I've got to finish knowing what I know now. I don't want to go down this rat-hole.

Brad's techniques look awesome and like they could save me a bunch of time later, when I have it. But I'm not going to invest in learning it now. I'll plod forward using the skills I have. I'm not a hacker, I am a software developer trying to produce working software as fast as possible. I'm not going to indulge in research activities right now.

Doing anything by yourself is very hard and there's always a better way to do something. There's always something to learn. The lessons we learn on our current iteration or project can be applied to our next iteration, later, when we have a chance to plan.

What’s a good project / program manager? A stable leader.

Someone who can stay afloat. Someone who is confident in their abilities and methods. Someone who is curious and perceives the world as dynamic and pliable. Someone who likes and trusts people. Someone who things that they and their peers are talented and having fun. Someone who can have tons of stuff thrown at them yet know the way forward and what to do next. Someone who is a planner. Someone with a plan. Someone who can backlog, prioritize and not burn out themselves or their teams. Someone who stresses out infrequently and contains it very well when they are stressed out. Someone who is cool under pressure. Someone with systems, standards and strategies. Somoene you want to work with who will not throw you under the bus or add unnecessary stress to your life.

Sometimes you may want waterfall development; but the luxury will cost you!

Sometimes you simply don't care about the specifics of what comes out the other end of the engineering process. Either because you have high expectations and high trust in what they'll deliver. "High engagement" with the engineering department will cost you time and energy. "Low engagement with engineering will cost you in time and rework, waste, and cost

There are times, like when a business person builds a prototype of a system or clearly defines the product requirements, that they can give that input to engineering to harden and tighten the design. In such a case, the inventor(s) of the prototype or specs may not really care what comes out the other end; their requirements are fundamentally qualitative: 1) Make it look good 2) Make it performant 3) Make it "tight". Managing a project in such a way is possible and sometimes desirable. But there are alternatives.

Not everyone wants to engage with an engineering group in an Agile / High Bandwidth way. They need room and space. They don't want to be an engineer. Weekly check-ins (like in Agile) seem reasonable but maybe some people would prefer monthly, quarterly, or annually. The larger the period between reviews and meetings, the larger the budget, the more the risk, the bigger the problems, the lower the quality.

Technology Things I’ve Learned Recently

Installing and using Eclipse. Installing WordPress and Drupal. Installing Drupal modules. Customizing Drupal. Things about ASP.NET MVC version 2.0. DataAnnotation in .NET. SSIS packages and catching error rows. Silverlight application development techniques. About RIA Services. There's a lot of great stuff out there.

Good Governance is Sitting Down with the Governed

You can write all the rules you want in an attempt to make people comply but the best way to get result and learn from others experiences is to sit down with them. Take the time to do this today!

Modified Version of Alvin Toeffler Saying

Coding is the easy part. The hard part is to discover and apply technologies that can continuously fit the business needs and problems.

The Users Need It Now!

Don't procrastinate. Get the software in their hands ASAP. The business process is the thing that matters and unless the tool or software is in-hand, you won't know what it is and what needs to change. Deliver now.

Hacking vs. Solving Root Cause – Level 1 and Level 2 Problem Solving

Stopping the bleeding and fixing what's in front of you is way different from solving the ACTUAL problem (not surface problem). I'll write more about this soon!

Capabilities Increase Scope

So ultimately it seems that having multiple developers changes the REQUIREMENTS of the solution and for that reason, the velocity. Assuming that all developers are stuck with where they are at with their own personal velocity until they read something great or get help from a peer. So if developer A knows how to do thing M and N and developer B can do thing O, then the total requirements for the solution are likely M, N, and O. For me, I'm operating on M and N now and the solution is "simple". If I could find someone who could do thing O, then it would take longer. Pragmatism is odd.

Individual vs. Team Work Velocity

It'd be very nice to always have a team (or at least a pair) of developers, but sometimes this isn't possible; sometimes we've got to 'go it alone'. I'm doing that right now on an app for my friend. I'm fairly good with the basics of getting things to print on the screen but when it comes to making things elegant and beautiful, I am way weaker. I consider these weaknesses "low pri" but if I had another person looking over my shoulder they may be able to help me. Right now I'm going to punt these things I can't do elegantly and am backlogging them with "TO DO:" statements in my code. This isn't a major concern but it raises the question for me of the difference between an individual and team's velocity. In an idea world, all developers would be able to work by THEMSELVES as fast as they possibly can. But there is overlap often, and people have to help people, and there is a team, so what would the net-net of adding people to a team be? Definitely more communication channels…

Find Ways to Tell Your Story to the People You Want, the Way You Want

If you're ever feeling frustrated, stuck, depressed, etc. don't get too down. Sometimes we feel like we're in a rut or mire that we can't escape and want to isolate ourselves from others, make decisions to protect ourselves and avoid interaction with people so we don't have to tell them a sad story or show them how bad or disappointed we feel on the inside.

As far as I can tell, people and activities are our best means for getting out of ruts. Find your believers and keep engaging them. Seek new believers, really anyone who will listen or share themselves. Keep talking, keep laughing, keep meeting people. Eventually you'll get to tell your story to the person or people you want in the way you want and you will feel very happy!

Punt the shit you can’t do well now

If you don't know how to do something now, don't do it. Do the bare minimum and put in a placeholder or wedge so you can move onto the next more important thing. If you are truly good at the rest of what you do (your trade) and getting the job (as you can do it, on time), you will attract supporters, followers, and believers. These people will be able to help you later and provide you with the time and support you need to complete the product or project on time, on quality and to your mutual enjoyment. Done is when everyone's happy, not when you're tired.

Incrementalism

Word of the day for me. It matters. Maybe more important than pragmatism? Do things in bites; bite-sized chunks. Remember your goal but focus on the near-term and task ahead. I'd rather do things small and incrementally (take baby steps and solve problems that are "bite-sized") than feel like I was eating an elephant. As long as we have enough time to break and breathe between bites of the elephant of life and our ambitions, we'll be fine. The elephant in fact is really the aggregation of all of the bites we are able to take of it. The elephant is fictitious to us and of a potentially infinite size. But don't make it so. Figure out how you can eat the elephant faster and more tastefully and who knows how many elephants you'll be able to eat!?

Sure, it's also great to have a vision and ambition and an appetite for eating lots of elephants and boiling many oceans, but you need to be able to (regardless of how large your challenge is…thank god you're not President of a nation or something ridiculous like that) do the next thing, take the next step, figure out what you CAN do next, successfully.

“Instrumented Reality”

We seem to want things to throw off data. We want to measure and see our world visually. Not just as they appear but with augmented reality; data overlays. We want to want to measure (in a computer system) what is going on around us.

Instrumented systems (see New Camera System that Takes the Guesswork Out of Baseball Stats http://www.popsci.com/technology/article/2010-01/taking-guesswork-out-baseball-stats) are our new databases. Many systems are now database information systems. They are organic and constantly changing yet digitized and software-enabled. We can present their data and rethink them however we want.

The world is apparently not good enough. What's up with that!?

What’s an Architect?

The first person on the scene. The solver. The guy who can do it. The guy who can create the solution. The doctor, the lawyer, the dentist. The main man. The most knowledgeable person about a topic. Similar to an analyst but this guy knows how to actually create the thing. An analyst might know how to do this but this is the guy that can actually do it and does it. He probably directs other developers to do stuff. He has the keys to the kingdom and can ride the fence between business needs and requirements and pragmatism / practicality in solution and design.

Chartering Should Primarily Come from the Customer

As I said before, hack around…things don't have to be perfect. Once you have a user, a stakeholder, a second on-looker to your work, integrate their suggestions and turn their needs and requirements into the best product possible. You should be hacking less and working on important stuff more when there are customers and users.

Putter ‘til you find a Project

Putter around, fix stuff, it doesn't have to be pretty or perfect or solve "root cause". Just fix things up, be busy, get tidy and eventually you'll stumble upon an important project that's worth tackling.

Demonstrate a Wealth of Options but Have One in Mind

It's great to show coworkers and customers everything that is possible but if you don't have a clue which one to use, which one is best, what your preference is, etc., you're clueless. Get a clue.

What’s an Analyst?

Someone who can think. Someone who can analyze. They can look at data clearly and solve problems. They don't easily get frustrated. They seek solutions. They can clearly and concisely identify blocking issues and impediments to progress. They know what the current largest problems are. They have a forward direction in mind; they have goals. They are someone who knows that there are usually several next steps that could be taken and are capable of advising you on what the next steps are. They may get distracted easily while swimming in a sea of information. Once a decision is made or action is taken, they create a new world view and context from which they continue to analyze. They seek knowledge above information. They are likely good teachers. They are definitely learners and probably doers. They can observe what is going on and determine opportunities for improvement.

Authorization is Odd

Who is authorized? Who can do this? Who is in charge here? There's a lot of confusion in the world. Sometimes we don't feel authorized to do what we need to do. We perceive many rules and go along with what we think to be the status quo. But is that really the status quo? Maybe the status quo is change, chaos, and disorder. There are rules and there are ways around the rules. Be bold and more forward!

How to feel consistent while searching for work

If you're on a short contract, stay until the end.  In the meanwhile, plan for the end and move onto the next thing but keep doing well at what you're currently doing.  Maybe it'll get better!  Don't be a slacker.  If you're on a longer contract or in a permanent job, it's harder to leave and give notice.  Be strong, give two weeks and move on.  Don't look back.  Be thankful for what you have, your relationships, and the people you've worked with.

The Application Layer is All That Matters

I think that this layer is the only layer that matters.  It is the business process, it is the interaction between the user and the computer.  It is workflow and the movement of data.  It is all about the purpose for which the computer exists in the first place.  It is instrumented, it is intelligent.

How Does Business and Economic Development Work?

It's all about trust in my opinion. You should do your own, it'd be nice if you could have someone to do it for you, but that has a potential cost. How do you think we need to grow the economic pie?

Where does work velocity come from?

Accountability of individuals and between team members.

The Tools of Programming

You need some pretty basic stuff: a data store (place to keep the data also called "model", not to be confused with the overall system model / concept), a transformation / business logic layer (this is the thing that takes user input and converts it to and from the data store (these are also your "controller"), and a UI / front-end. The UI need not be graphical, it could be a phone, text message, whatever, you just have to be aware of the interactions with the system that you create and handle the user input and output of different views / screens to the user. This is also called the "View". Happy programming!

No Really, Show Value as Fast as You Can, Dammit!

I've probably said this before and I'll say it again, but the goal—I think ALWAYS—is to show value as fast as you can. This means that you could have had an agreement and understanding with someone before but it was most likely based on unlimited information and a "gentleman's agreement". Once you get down to doing the work and delivering, the real goal is to indeed (as I'm saying here) SHOW. VALUE. AS FAST. AS YOU CAN (and repeatedly for that matter). This is huge!!

I'm working on a pro-bono project for a friend of mine now and even on this, I'm following this principle. I just got his data loaded into the database and the next thing I am going to do is to spit out a bunch of sample data to the screen to show him that I'm making headway. I want to make sure he's engaged, involved, committed, and excited for what I'm building and the best way to do so is through DEMONSTRATION. This principle applies in most (all?) fields.

Crazy Making

So much for my great ideas about bridging the gap from back end to front-end. I'm now way back in the back end, creating some extremely old school hack because the middle tier wasn't working right. BOOOOOOOOOOOOOOOOOOOOO! Here's how to have an OUTPUT from a Stored Procedure that uses Dynamic SQL.

CREATE
PROCEDURE Myproc

@parm varchar(10),

@parm1OUT varchar(30) OUTPUT,

@parm2OUT varchar(30) OUTPUT

AS

SELECT @parm1OUT='parm 1' + @parm

SELECT @parm2OUT='parm 2' + @parm

GO

 

DECLARE @SQLString NVARCHAR(500)

DECLARE @ParmDefinition NVARCHAR(500)

DECLARE @parmIN VARCHAR(10)

DECLARE @parmRET1 VARCHAR(30)

DECLARE @parmRET2 VARCHAR(30)

 

SET @parmIN=' returned'

SET @SQLString=N'EXEC Myproc @parm,

@parm1OUT OUTPUT, @parm2OUT OUTPUT'

SET @ParmDefinition=N'@parm varchar(10),

@parm1OUT varchar(30) OUTPUT,

@parm2OUT varchar(30) OUTPUT'

 

EXECUTE
sp_executesql

@SQLString,

@ParmDefinition,

@parm=@parmIN,

@parm1OUT=@parmRET1 OUTPUT,@parm2OUT=@parmRET2 OUTPUT

 

SELECT @parmRET1 AS "parameter 1", @parmRET2 AS "parameter 2"

go

drop
procedure Myproc

Close the Gap Between the Database and UI

This is no small feat to overcome and to do it means that you can build an entire software application by yourself; all tiers! Not relying on the DBA, Designer, and Coder roles, but on you as the focus in the role(s) of Architect/Manager/Producer. I wrote years ago about "top heavy" applications that repeat logic in the model, views, and controllers. I'm hoping that today we're closer to having the Model Driven Architecture gap bridged: the holy land of software!

Going with the Flow and Being Flexible

Say you create something really great and people like it. You show it to them and they want more. They want to help you build it and work on it. You may have started as "that guy" who was doing some random thing, but depending on how you play your cards, you could become "THE guy" who is at the center of it all. Follow your products and creations around; see where they take you!

In Software, You Can Harden and Tighten Your Design Later

I said it earlier, but don't be a perfectionist in what you create. Don't make the first product you produce perfectly right and tight the first time. Leave some room for enhancement and improvement. Get a working product in their hands as fast as you can and fix what's broken later.

<Rant> The “Cloud” in Cloud Computing is a Stupid Name

Come up with something new, people! It's like saying "fog". People are foggy and cloudy on the cloud. They don't know what it is. I don't know what it is (in total) and I think I should. That's a problem if you're trying to sell someone something more than snake oil. Let's start offering real value and get clear on what the cloud—or our service in the cloud—is!!!

Refactor Later If Necessary

Don't be a perfectionist about the software you're designing. There's always another time you can come back and fix what you built. That's the beauty in fact about object-oriented or component-oriented programming is that the components are "swappable". If I messed something up this time around, I can always go back and fix it later. Insist, however, that the STRUCTURE you create is very good and that you have a solid, defensible, base architecture to stand on. Be fine with rafactoring later if you have to; you'll probably have to.

Be Cool Under Pressure

Sometimes you have to deliver rapidly and set expectations with people. You could burn yourself out and work 80 hour weeks or you could take it easy. Be cool, confident, calm and don't burn yourself out. Make reasonable commitments with people if at all possible.

Get Refocused

I feel distracted at the moment. My main project at work is out of mothballs and I'm trying to get things done on it. The learning curve on Silverlight, RIA Services, and passing data from SQL Server isn't easy. I must plod forward.

The Librarian Role is Needed

In companies there needs to be a librarian or secretary. Teams are busy and produce a lot of things. Even with good IT systems, things don't get checked in and project results or artifacts stay on local machines. This is a knowledge management problem when the resource moves onto something else and frequently causes rework. I propose the role of LIBRARIAN. This person would make sure that everything is done. This is a hat the project manager or functional manager could manage.

Lots to Learn in Programming User Interfaces

It takes a long time to get good at programming. I still don't feel like my "toolbox" is working very well from the front-end to the back-end. I am stronger on the database side and now I have to bridge the gap up to the UI. The UI technologies are crazy in my opinion. Silverlight and .NET RIA Services are compelling. I like how they're working with data binding. .NET 2010 seems to have some cool data binding "drag and drop" functionality (see http://channel9.msdn.com/posts/kmcgrath/Silverlight-Object-Binding-in-Visual-Studio-2010-Beta-2/). ASP.NET MVC is different. I'm more familiar with HTML as my UI and JQuery is a very nice extension for that… Windows Workflow Foundation (WF) is another that I'd like to use here to figure out how to handle the different activities in the workflow I'm currently designing. Another cool / promising technology is .NET Entity Framework. Looks cool and now there's going to be SQL Server Modeling Services and a language called "M". So much to learn!!

Defer in Order to Manage Multiple Customers and Interruptions

I've had the luxury for about three months now of working on projects that have been generally serial in nature. That's changing a bit as I've finished a few things and they're in peoples' hands.

I'm going to implement a new personal policy that is to start and finish the highest priority thing as soon as I can "reasonably wrap up and mothball" what I'm currently doing. I'm currently working on an app that is due in a few weeks. I'm going to finish any loose ends, write down my next steps and move onto the other more pressing thing now. I'll dredge up the other project when I'm done with the current one.

Ideal Software Development Manager

Listens well, writes code, willing to help, willing to be interrupted, not too busy or randomized by other things, values you, smart.

Plan for a Longer Review When the Next Task is Big or Important

I have a problem that I'd like to share with a coworker to get his input. He's really the customer on this so I don't want to waste his time. I have to get ready to ask the question and engage him. This particular question I want to be reasonably BIG because I want to spend some time with him designing the next mini-sprint or story I'm working on; really the finish of this iteration of the product: the first prototype! I've basically finished my current story "build middle tier" and now I have to work on the next story "enable front end". The new story is pretty complex for me and I don't know much. He doesn't either. I could start in on it and ask him things as I go, bit by bit, but I may ask now, show him what I have so far and step into the next big problem, chartered and re-energized by him.

I'm an idealist and want to have shared mental models and designs between people. I don't want to work alone but sometimes I do and have to. This is the case now where I want to take the risk of engaging the customer so we can co-visualize and plan the last leg of his/her project. I don't want to annoy this person but I want to keep them engaged and involved.

Back-to-Front vs. Front-to-Back Systems Design

We all think in models and our computers allow us to build models, so of course use them, right? It would be ideal to have a model of our system that we instantiate. We draw something or configure something and a system comes into existence. That's the basic practice of development but it's much different and far more iterative going from front to back and back to front. Writing code is a sometimes aggravating process as you validate your coding concepts against your mental model of the ideal (or good enough) solution. The Model-View-Controller pattern is very popular these days with Ruby on Rails and ASP.NET MVC. These solutions allow developers to pass data between the layers and control how things are presented. There's a flow they have in mind and that's a really handy tool! I'm building a Silverlight UI right now and I'm preparing the underlying data model for on-screen display. SOMEHOW I have to sync up the back end with the controls and intended user scenarios in the front end. That's tricky. I've been working from back to front but now I'm having to go from front to back. Somehow these worlds will collide!

Computers will be better when:

When software engineers figure out how to allow a user to drag objects around and relate them to other objects in many flexible ways (not just hierarchies), computers will be way more powerful.

Enjoying the Tranquility of Authorized Research

I was obsessing yesterday over the idea that I didn't know how to do "data binding" in .NET. I wanted get help from my coworker because I thought he knew about it but it turns out he doesn't. I talked to him this morning and he told me to do the reading and research necessary to "get 'er done". Cool! So now I get to become my team's resident expert on data binding in Silverlight on .NET. I'm looking forward to experiencing the tranquility of learning something new and want to learn, at my pace, on a cool project, at least for the moment. Thanks, V!

Refactor Later

Start and finish your design. You may not know exactly how to do it but you need to finish. Surely you can engineer a way to make it work but don't get bogged down in asking too many people for input. Maybe don't ask anyone for input at all. You can get the input later when you finish and at that time, either enhance this creation or the next one.

Some preferences don’t matter; they are for you

Sometimes you may think you want people to offer input on something you're designing but you typically don't need this. Keep steaming ahead and make decisions about the design as you see fit. Be creative.

It’s better to ask for forgiveness than permission

Authorize yourself to do something really good today. Maybe the others won't like it, but finish it and make it tight. Show it to them and gauge their reaction. Without a doubt it will be a learning experience.

Don’t be parochial, get the job done!

I've blogged before about how you have to wear different "hats" to do well in IT. I think the hats are: project manager, program manager, product owner, customer, developer, and tester. That said, as a consultant (or employee for that matter!) the "that's not my role" mentality is completely retarded. Don't do it. Wear many hats and don't develop a not invented here mentality! Make sure you develop skills in all of these disciplines and figure out how you can get the job done if you're given any of these tasks. Learn from the masters of these roles and be the "project manager" to drive toward getting the job done. Don't be parochial!

Training Product Owners Is Challenging

Customers can be difficult of course. I say this because many people might not know what they want or how to get there and your job as a software development consultant or team leader is to communicate with this person as effectively as you can and give them products that they can use in THEIR processes. Some core skills and lessons that you need to teach the product owner (whoever he or she may be are): 1) software development is difficult 2) there is uncertainty in how the solution will be exactly created and knowing what exactly will come out is a minute-by-minute problem for a software developer or leader 3) estimating when you'll be done is difficult 4) there exists a process of continuous improvement and improvement of the customer relationship. That process referenced in #4 is YOU!!!

Waterfall doesn't work a lot of but it's fine to have frameworks and principles that you follow. CMMi, Six Sigma, Agile, PMBOK, MVC, etc. They all matter. In the end, something has to get done and agile is a way of breaking up the problem FROM THE BEGINNING about what needs to be done next. What's the risk? What's the priority? Can we do it? When do you need it? Removing as many of these impediments as is possible as fast as you can is the way!

I Learned a Lot About Software Development and Communications from Scott B.

A former coworker, Scott Brown, knew Agile. He'd lived it on the CodePlex program at Microsoft. I wasn't a current practicing developer at the time I was ScrumMaster of that group but I am now. I probably learned the most from Scott. He was very pro-Agile; a zealout, I'd say, but retrospectively he knew a lot about the process and effective communications. He was all about velocity and getting things done; pragmatism. Our team wasn't probably ready at the time for that level of engagement (I know I wasn't) but I am now.

Thanks to Scott for showing me how software development can be fun and we can reduce randomization through quality communications.

Get to a working demo as fast as you can!

You can potentially be perfectionistic and want what's perfect for your app but in the end you have to release it to users and let them break it. Think through the risks and issues of the scenarios they're going to do and plan for that. What are the scenarios? How will you know that they're working well? Answering those questions should be the input to your sprint and its "definition of done".

Cautiously Demo Your Work to Build Relationships with Customers

Caution is the key word here. You don't want to bore people. Let me explain:

The purpose of the demo (or asking for help, input, etc. from your customer or manager, teammate, etc.) is to impress upon them, and to build your relationship with them as much as you can. The more they like you, the better off you are; the more they'll like your products most likely. The more you waste their time with triviality or demos that suck, questions that are obvious or that you could have answered on your own, the more you'll turn them off, bore them, and generally make them dislike you. Sure, they may care about you as a person but what they really care about AT WORK is the product and its QUALITY. If you demo boring stuff or unfinished things or things that simply confuse them, they'll disengage and possibly dislike you, probably ignore you. They'll avoid your products as well. You don't want that.

In total, THINK HARD before you ask someone for help or look at your work. Be in control of what's being presented and don't welcome scrutiny or doubt in your approach. If the demos are good and you get the kind of feedback you really needed in the first place then you'll be in the good! Avoid "ringing the bell" at any given moment; bang the gong when you're ready to summon them!

BI Happens at the Intersection of Project and Process

You need static structures like policies, processes, roles, artifacts, and departments to be successful. Something must be core. These static structures are the tools that allow you to get things done. They are the platform. Projects on the other hand are the vehicles that do the work. If you do a lot of projects you could see project management as itself a process. But it isn't the only process yet it is a very central one.

Business Intelligence As Feeding the Hungry

The business is hungry for information about their operations and customers. The data that is around the business is not currently very delicious or available. People are picking at scraps all the time but they are definitely not satiated. Business analysts, project, product, and program managers (cooks in my scenario) are hired to prepare data-meals for the very data-hungry executives and managers. The managers are picky eaters and have high expectations of what you put on their plate. The job of the cook/analyst is to gather up the various bits (data-ingredients) and whip them into a lovely broth that the business can enjoyably consume.

What’s the Difference Between a Project and Process

The CEO of Siemens Ultrasound asked me once, "What's the difference between a project and a process?" My answer was, "The process is how and the project is the what." He disagreed and explained to me through an example: "If you have never driven from San Jose to Los Angeles before, that is a project, but if you do it over and over again, then it becomes a process. So a project BECOMES a process over time, with repetition. A project is something you have never done before [or have done infrequently]." I totally disagreed.

What are your thoughts on these differences?

I would say now (and said to him then) that a project is an INSTANCE of a process and that the process is continuously improving and changing (it's the how).

Produce Waste Intentionally in Your System’s Design

As part of the design of a quality system, you will encounter ways to be lean and you will encounter ways to create waste. Part of a you will want to keep everything (hoard) and part of you will want to keep only the things that matter. If you keep only the things that matter to you now, then you are potentially painting yourself into a corner. If, on the other hand, you design such that you have some waste (are not perfectly efficient) such that you can pick up the pieces that you left behind.

The point here is that you have to design systems that have some waste, such that it can be consumed later, by others. Designing perfect systems is impossible and if you were to do it, you'd have others pick and find holes and they'd have a job and you wouldn't. Or you'd be starting over somewhere from scratch. Go agile or go home.

What’s It Take To Be a Senior Developer or Software Leader?

If I were to trumpet my own horn, I would say that I've been building web sites and technology-based human process workflows for the last 13 years. Since I was 19 years old and was using Microsoft FrontPage. At the time my skills were HTML layout, PhotoShop, and CSS. I was mostly a designer. In 1999 I picked up the skill of SQL database development and object-oriented programming. That was a huge leap forward. I was writing server-side scripts in 1999 and did that professionally for about 4 years. Then .NET came out. Then I went back to school and got my Master of Science and MBA in Information Systems. I learned a lot then. In 2002 I learned about and implemented SharePoint and was a CAML developer. I worked with OpenText LiveLink and IDS Scheer ARIS to design enterprise wide SOA and Knowledge Management architecture for Siemens Ultrasound Division. I left there and spent the next few years working with SharePoint Server (MOSS) and did the same: this time for Nordstrom and Microsoft. I became a software development project manager and then started getting back into writing code. The languages of today: C#, SQL Server 2008 (I started on 2000), ASP.NET MVC, SilverLight, JQuery, Drupal, WordPress, and I'm getting into Eclipse.

At any rate, I would say that a senior developer is a person who can:

• Write code
  
• Think of processes and business problems as software systems
  
• Can lead software development teams
  
• Is highly communicative and understand the software development process
  
• Can recruit and is respected by other software developers
  

Thoughts?

I Know About Collaborative Tools

The infrastructure exists now for any small team to form online and connect and build software and create companies and "communities of practice" for very little money. Only corporations had this infrastructure a few years ago. You just need the knowledge and social / networking skill to do it. So do it!!! (Or ask me how to do it, I'd be happy to help you!)

How I’m Going to Change the World

Two ways:
Through consulting with businesses and organizations and having an hourly wage or retainer from them as a "worker" or resource to them.
Through making software products or creative processes/systems for companies or for myself that I monetize somehow.
All while having fun.

How I Update My Blog, Twitter, and Facebook

I generally assume that I'm going to blog everything (since I'm generally a long winded person and you never know how deep and long-winded a thought is!). I open up a new Word doc as my blog and start writing. If I determine it's just a short statement (or better as a short statement/point), I'll Tweet and/or Facebook update it. I generally tweet nerdy things to Twitter and other silly musings to Facebook; this may change over time but my Facebook is "friends" and my Twitter is more business-minded. If what I'm writing is long, I'll try to write it all out. If it's short enough and concise enough, and what I think to be interesting and/or pertinent enough and that I want to publish it, I'll post it to my blog. If it's too long or boring, or in concise or rambling (like this post? J), I save it, possibly to return to it later (write a book?) or simply round-file it.
It's nice to have these different online communities and audiences and communication modalities of micro-Blogging and real blogging for sharing your thoughts.

Facebook IM Scam. Beware. I sure hope this wasn’t Madhu!

4:31pmMadhu






hi?





4:33pmMadhu





u there?





?





?





4:36pmEric





Hi Madhu.





I am.





4:36pmMadhu





am not good Eric.





4:36pmEric





am not good?





what?





4:37pmMadhu





i'm stuck here in london and i need help with flying back home.





4:37pmEric





Okay. Tell me more. How can I help you?





in what way are you stuck?





4:38pmMadhu





i had to visit a resort in london on vacation and i was robbed at the park close to the hotel where i lodged





4:38pmEric





Okay.





I'm sorry to hear that.





Do you have anything? ID, etc.?





Are you safe now?





4:39pmMadhu





i was mugged at a gun point and all cash on me got stolen including my credit cards and phone.





4:39pmEric





Okay.





Do you have any documentation?





4:40pmMadhu





the good thing is i still have my passport with me.





4:40pmEric





(as in ID, passport, etc.?) have you visited the US Embassy or anything like that? Are you a US citizen?





That is a good thing!! :)





Have you been able to call your credit card companies to cancel them?





4:40pmMadhu





all i need now is help in getting a return flight ticket back home from you.





4:41pmEric





I see.





And when could I expect repayment? :)





4:41pmMadhu





I need $500USD for my return ticket fees.





i will pay you back as soon as am back home.





4:42pmEric





Remind me how we know each other. :)





Madhu?





4:43pmMadhu





if i wasnt the one i wont ask you to wire to my name as we both know i will need some kinda of identification before i get the cash at the bank.





4:43pmEric





Please tell me how you know me specifically.





4:44pmMadhu





we are from the same city.





4:44pmEric





Yes, please tell me more, specifically about you know me. Who am I?





What is the nature of our relationship?





4:45pmMadhu





Look Eric,this is not the time for Question.





i need to leave,if you are not helping me





4:45pmEric





Madhu, what is your profession?





4:47pmMadhu





i need to leave now.





bye





4:47pmEric





Tell me anything about how we know each other and your profession or mine and I'll talk.





4:48pmMadhu





if i wasnt the one i wont ask you to wire to my name as we both know i will need some kinda of identification before i get the cash at the bank.





bye





you are my formal friend





4:49pmEric





I know you are not Madhu and this is a scam and "formal friend" is not a good enough answer. You should be ashamed that you are trying to rip people off. You should go look for a job instead.

Emerging from Your Work and Selling Simple Solutions to Complex Problems

I'm argumentative and hard-headed by nature. That's probably an understatement. Really, I'm pretty much a pain in the butt. But I try to be funny and have a sense of humor. I try to have a good time. I try to be thoughtful. It's my hope that some people will like me, listen to me, and be willing to put up with me for long enough to allow me to tell them what I think about a problem I'm solving. In short want them to buy into me and what I'm selling.

At work, I'm producing a complex analysis of what happens when people log out of Hotmail and use other Microsoft properties. I'm trying to find out some patterns. There are dozens of parameters and variations of the process. I need a simple way to measure it so I can explain it clearly. I've spent about a month working on this now and have been improving my methodology on it. I think I'm getting close to having a robust solution to the problem I've been given.

The next step for me will be to teach people what I did and how they can use it; to promote myself and the product. I want the interested persons to BUY INTO me, my methodology, and product. Only if I've made an elegant solution can I accomplish this. It's not all about personal power, it's about QUALITY. If things appear to be complex or unfinished, people will look the other way.

I'm still in development mode at the moment but I hope to emerge from this state soon in a highly effective and communicative way that allows me to advocate the greatness of my solution.

Separate Your Concerns

Build to the bare minimum part that will serve as an input or foundation to some other component. Don't build 'one-size-fits-all' systems that do everything or serve too many functions or purposes. Componentize!!!!!!!!!!!!!!!!!!!

Dividing Up the Work

An important part of being Agile and enjoying your team is efficiently and effectively dividing up the work. This includes figuring out the roles of each team member (as a function of the current work load) and also how they will collaborate with one another and their stakeholders in general. It is also the responsibility of each individual team member to determine how they can best impact and support the team's overall quality and acceleration (velocity over time) ie performance. People need to have autonomy so they can achieve things and learn on their own, but also need to be provided incentives to collaborate and interact with their team for the team to grow stronger over time.

I’d Like to Find the Perfect Work Partners

I want to work, play, and collaborate with people who are:

• Inquisitive
  
• Playful
  
• Fun
  
• Intelligent
  
• Funny
  
• Available and willing to give time
  
• Thoughtful
  
• Curious
  
• Courageous and strong
  
• Supportive
  
• Good coaches
  
• Good listeners
  
• Creative
  

It's hard, sometimes, when you're stuck working alone. Our best work is rarely done—if done at all—when we're alone. We have to band together and find others who complement us or lift us up somehow; motivate us, change us. I think there are people out there who can help us with most of our needs, regardless of the task. They are generally playful and fun. We need to seek these people out and create with them.

Sprinting at a Sustainable Pace Seems Oxymoronic

I had my primary customer tell me today that my current project should be done by next Friday. I'm fine with that but I have no idea how long it will take. I'm not stressing, either. I told him that I'd sprint on it and give him daily updates, letting him know how it was going. He said, "Don't kill yourself, it's okay [if it slips]." (I have a very kind customer, mind you). The customer must have thought that if I'm sprinting daily, I'm wearing myself out. This isn't true. I'm still having fun and I'm still putting in my standard 8-hour work day. I'm head's down on the project and moving forward as fast and reasonably can. If I determine at some point soon (as fast as possible) that this assignment is mission impossible, I'll tell him, he'll know. My customer's not trying to burn me out and I'm not trying to burn myself out but I'm still trying to dig into the project as it's described as fast as I can and start to move forward so I can determine the velocity of this sprint and if it's tracking with our 1/29 due date. Let's hope it is!

Things I’ve Learned Since November

• How to attach to a process in Visual Studio
  
• Source Code control with Source Depot
  
• Integrating source control with Visual Studio
  
• Hosting SVN online
  
• The SCOPE Language
  
• Running database jobs on a Cluster
  
• Processing usage logs
  
• Coding through SIPOC logic (Supplier, Input, Process, Output, Consumer)

Code for the Retrospective

Your goal as a developer is to get the job done as fast as you can—to the requirements—and have your retrospective with your developer buddies and the customer. You'll want to bring a few things to the retrospective and be prepared to get the most out of it:

1. What went well
   
2. What didn't go so well
   
3. What you'd like to change
   
4. Your code base and what you produced as far as diagrams, lessons learned, tips, tricks, etc.
   

The retrospective may be your only chance to complain a bit, kick up your heals, be thankful that you're finished, learn something, and re-energize yourself for you next task. Enjoy it and plan for it.

Code for the retrospective.

It’s Not About You. Keep a Sense of Urgency.

When you're working on a project, you can decide to do things the smart, elegant, research-based way, or you can do them in whichever way is necessary to get the job done. To me, a project is and should be a "forward pass" sprint through the requirements. A project isn't the process. A project isn't fair. It is a single iteration. There will always? be time for more improvement and change later. Maybe you won't get to change what you want to on this project, or learn what you want to, but you can do this next time you have the opportunity. In a project you solve the problem as fast you can and backlog the opportunities for future consideration. You deliver. Maybe the things you didn't do won't be considered, maybe they'll never be done. But you will still always have the idea to apply that thing some other time. Nothing is lost.

I recently ran into a scenario like this at work while trying to "lookup" something against a file. The way the existing code was written, it only worked on one file, but I had two files. And I needed a solution. We determined that since I had just two (and not 300, for example) files, that we could copy the code and make it work. This was the fastest way of doing it and we know we'll try to do something better in the future.

Engineers have to make things work. There is urgency, there are customers, the project is held down every minute you're not solving the key requirements. The world is not about you and your learning, nor is it about an elegant system. Those things are for you, your values, and in your long term, maybe you can achieve them. But for now, it is about getting the job done. The system will take care of innovation, not you now.

My Business Areas of Focus for 2010

I'm going to focus on four main (business related) things in 2010:

1.  Network
I'll network because I have to meet new people and develop a support system of people who know me and what I am doing as well as what my needs are. I am going to do this during the days.

2.  Engineer and Build products in my free time and work with people online
I'll engineer and build new products in my free time because I have to. I want to develop my skills and I want to create new products and services. I want to stay current on the new technologies and be a builder. I want to run the risk / opportunity of making something that is cool, will grow, and is a business. I want to get traffic and make a buck. I won't do much in my free time that is not for business (besides the necessary R&D required to accomplish business objectives).

3.  Make personal income
I'll make personal income and keep a day job. I am going to work for someone. Networking and doing well at my day job will help me accomplish this. My side projects will hopefully help me be good at what I do during the day. Whether I am a 1099 contractor, a W2 employee, a consultant, contractor, or employee, I am going to do well.

4.  Volunteer
I'll volunteer and work on some things for free. Not out of the "kindness of my heart" but out of the desire to learn and connect with people. If I offer things for free, I will learn, I will feel good and I will develop a more flourishing network.

In addition to this stuff, I'll exercise, hang with friends, watch my budget, have fun, read, be outdoors, travel some, relax, spend time with family, and enjoy myself.

That's the plan! Let's get it on.

3 Ways to Value Nothing

Sometimes you want to calculate usage growth rates for people who are brand new. There are three options for doing this. They are:

1. Throw out these ones and keep the ones where there was previous growth.
   
2. Set a standard denominator based on the bottom. (say 1 or 0.1 or 0.8 or something)
   
3. Set a dynamic denominator based on the top. (Say new value – 2 or new value – ½ of new value)
   

These options show that there is ambiguity in how you value new users with possible small amounts of usage.

I'd recommend that you do this in all three ways; changing parameters in the second two and see what you like, given your risks and business purposes.

List of Data Visualization Tools

Just got "Now You See It" by Stephen Few.  Here's a  list of the tools he's using to generate good-looking visualizations of data in the book:


Panopticon Explorer


Time Searcher 2

Tableau Software

Inxight's Table Lens

Spotfire

Vizster

JMP Profiler

Trixie Tracker

Google Motion Charts

Red Balloon Winning Method

Really found this contest interesting and exciting.  MIT won it.  Their technique: divide the total pool equally between the outcomes.  Give 1/2 to the winner, 1/4 to the person that referred the winner, 1/8 to the next, 1/16 to the next, and 1/16th to charity. 

That to me is  kicking positive butt but they didn't keep any money for themselves.  But they're rolling in the acclaim and accolades, so I'm sure it didn't do them any harm!

Don't Just Kick Butt...Kick Positive Butt

In this post, I explain my two core business principles: Kicking Butt and more importantly Kicking Positive Butt.  Briefly, the point is to do good work for the communities you care about but in order to do that, you have to get out there first.  I hope that me sharing my principles with you will help you better understand what your principles might be. 

My overall philosophy is pretty simple: Kick Positive Booty.  But this has a sub-part to it and is really TWO steps: Kick Positive Booty (principle 1) requies that you first Kick Booty (principle 2).  Together these principles focus and balance me toward getting things done.

1. Kick Booty - First you have to get out there and connect with people.  This means getting off your butt and taking charge of your life.  You have to be hungry, aggressive, and focused and ready to change things and take them as they come.
   
2. Kick Positive Booty - For me, I don't want to just "kick butt", I want to kick good butt.  A specific type of butt.  I want to do good for mankind and society first, and myself second.  I care fundamentally about myself and my situation but if I don't put others in front of myself and their needs in front of mine I will not be successful.  This is like having good customer service and not being too self-serving.

In summary, you learned that I'm not just about kicking butt but I want to kick positive butt and make a change to things that matter.  I hope that knowing this will help you think about what POSITIVE butts you are going to kick!

An Easy-To-Follow, Scalable, Agile Process for Anything

In this article, I outline a quick and easy-to-follow process for getting lots of things done (the agile way).  I think you'll find it useful and informative.  It doesn't matter if you're scheduling improvements to your home, hometown, or business, you can follow this process on any and get results. 

1. Note the request(s) (high level) in the backlog…you don’t have to understand what it is fully…just the gist of what’s being requested.  Make sure you include who its from and anything else.  Make sure it's fluid, too, and always be willing to go all of the way to the end of the process if the rules allow.  Don't let yourself or the process be the bottleneck!
   
2. Backlog and prioritize this work.  Figure out where the request should sit in the queue.  Use a method like FIFO or LIFO as a reference.  You could also create a "value index" to score the cost/benefit of the request.  Sometimes you may choose to do ANYTHING you can just to demonstrate value and show the customer that you are doing SOMETHING toward their objectives.
   
3. Define the request in concrete terms including the problem, required output and success criteria.  This may also include the specific implementation method and input required to get the job done.  Be clear what the customer needs and make sure there's a clear agreement and understanding of output at this time.
   
4. Optionally train the person(s) performing the work—even if it’s yourself—how to do the tasks necessary.  Remember the goals and make sure there is no "loss" in the communication process. 
   
5. Assign the work and start executing.
6. When the work is reported to be completed to spec by the person, verify.  Repeat this step until you accept the quality. Note: you could see all changes you make here as backlog items as well, so beware of "churn" and be fair to the people and process (team!).
   
7. You may queue or hold the result at this time as to efficiently deliver a collection of things to your customers or you may deliver it as well.  Queuing your results will promote longer, larger cycle times but could be more efficient for your business.  Delivering now will shorten the cycle and create for much higher customer interaction, which can be good, especially for very small teams (even teams of one).
   
8. Deliver the result to the end customer.  This is a similar verification (validation?) process but is facilitated by you, the process owner; that way expectations and feedback can be set and the overall process and deliver method improved.

I hope you found this process for getting things done useful and are able to apply it to things in your life.  Please offer any feedback or questions to me through the blog or to eric.veal@efficitrends.com.  Thanks!

Be Versatile or Be Gone

One of the keys to being a high-functioning technology consultant is to be versatile in your role.  You have to be able to do a lot of things well to make the client happy.  Common roles you (should) have to play well are Analyst, Builder, and Project Manager.  Here’s a quick description of each:

Analyst - Understand and define the problem using your skills of interviewing, math, statistics, process flow, data and information analysis.
Builder - put the necessary pieces together to create the solution.
Project manager – Integrate and communicate what’s necessary about the related parts of the project such that the involved parties understand what’s going on and continue to want what's being produced.  

In total, you have to be willing to do whichever job is necessary to get the job done and make the customer happy.  This requires experience, risk-taking, research, and networking.

6 Ways I'll Make a Better Professional Blog

I recently wrote a blog post (here) that I shared with several people.  Some liked it and were "with me" yet others wrote somewhat lengthy feedback about how I needed to improve my delivery method.  They were commenting more on my style more than the content.  So I guess I'll focus on style for the moment. 

Here's what I'm going to do about it.  I hope you'll take what I'm  learning and apply it to your own experiences writing, blogging, and career management. 

Thanks to Don L. and John S. for their feedback and insight.

How I'll Offer More Quality Content to My Audience:

1. I'll get to know my audience better and understand their needs and desires in order to offer more relevant information and conversation about the topics that interest me most. 
2. I'll be more clear about my point and ramble less.  I'll try to capture the audience's attention ASAP, get to the point and get out the information that I'm trying to convey as compactly and rapidly as possible.  Maybe I'll use more graphics (see this post).
3. I'll be more precise and specific and cite references more. I'll read more as an input.
   
4. I'll have a call to action if possible, directing my audience to next steps, further reading, engagement, etc.
   
5. I'll build a community and drum up input from them on my delivery and content (effectiveness).  
6. I'll tell more people how to sign up for my blog and think of other methods of reaching my audience (podcast, email, speaking engagements, etc.)
   

My overall goal online here and professionally is to create a dialog and debate with my audience about topics that matter a great deal to me.  I'm trying to learn and help my audience as much as I can with insight that matters to them.  I'm seeking insight from them on the topics that matter most to me and also looking for feedback on delivering the best way possible.  Thanks for your patience and participation in this process.

8 Ways to Be Agile with All Customers and Grow Your Business

1. Say yes to all work being requested, regardless of your ability to deliver on it now
   
2. Seek to define all work completely with success criteria, method, etc. and add it to your backlog
3. Make your backlog/pipeline visible and available to your customers
   
4. Make it clear to your customers what you're working on now and next
   
5. Have your customers prioritize your backlog and "fight" amongst each other (you should probably facilitate this so you're not purely randomized) for your time, driving up demand
6. Work on and complete the well-defined problems and learn from the experiences.  Feed lessons learned and changes back into the backlog.
7. Make customer after customer happy and make sure the the prioritization method is fair and best for your business and total customer satisfaction.
   
8. Try to delegate as much work as you can to your team but make sure that the process documents all work, regardless of who does it.  

Your value is how much you are getting done in total, though your system.  This means that you should be developing more business, working less, defining more.  You should focus on the demand AND supply side and grow this business.

Refusing to Use the Tie-Breaker Role

My friend Bruce today told me about a book called The Seven-Day Weekend: Changing the Way Work Works http://www.amazon.com/Seven-Day-Weekend-Changing-Work-Works/dp/1591840260 and brought up an interesting point about systems that are "open" but also have a "tie-breaker" role (manager or authoritarian).  In the system that Bruce described in the book, although this role existed, the manager never used his power as tie-breaker and would always put it back onto the group.  I thought that was interesting.

The Ideal Dev Process Parts

What parts do you think must be included in the ideal, high-scale web and software development process today?  (As judged by such factors as most Secure, Scalable, Stable, Collaborative, Clear, Easy to Use, Powerful, etc.)

I'd say it needs to have:

• For a web site / CMS:
• .NET Nuke, Ning, or WordPress
• .NET 4.0
• For code:
• TDD, unit testing
• Asp.net MVC 2.0
• Subversion, TFS, or CodePlex for code sharing
• OnTime for backlog, requirements, bug tracking, and communication
• SeleniumRC for test automation
• Team City
• For a team:
• A Digital Whiteboard

Forming a Consulting Group (that is World-Changing, Profitable, Enjoyable, Sustainable, Continuously-Improving, etc.)

The world is full today with people in business who are doing good things and making compelling change to our organizations.  These people are not generally organized as a collective.  It's likely the goal for many of these individuals to find other like-minded people and establish "guilds" around their particular part of the technology and change delivery puzzle, be it sales, product definition, development, delivery, or support.  In total, our system today requires many quality professionals to deliver the services that it has; and the quality of these services and their density is highly variable and in some cases poor, some cases excellent.  The goal is to make high-quality products that the world needs and for which the market will be willing to pay.  "It takes a village" but this village that we will need for this change is smart, involved, well-organized, and planned.  This is not a government, it is an uprising.

What are the attributes of this village we require to bring about the quality products and services of tomorrow?  From where does this village come?  The crowd, I say!  From our networks; current and future.  In my opinion, it is possible to find and support--with the appropriate tools, incentives, practices, and resources--people willing to capably contribute to our current firms and to the firms that we need to bring about.  The goal for the support organization and consulting group would be to offer the training, staffing, and project/program/product services necessary to allow the resources we have today to turn out the products we need tomorrow as fast and at as high of a quality and leading to the greatest economic value possible. The technologies we have today are mature enough to support and sustain such a group.

Today's organizations are either A) antiquated B) outdated C) unprepared or D) non-existing.  Let's fix this!


Critical Components of the Consulting Organization (EfficiTrends):

• Sales & Marketing -- responsibilities are to build the network, filter associates/partners/relationships, educate and train our stakeholders and members.
• Operations & Delivery -- responsible for getting the job done as it's defined and communicating to others when things aren't going according to plan.
• Product Definition and Contracting -- responsible for strategic planning, fine-grained management of relationships, project/program/product management, and contracting.
• Product Support and Operations, Sustainability -- responsible for the ongoing "care and feeding" of completed products and services as well as the definition of new, more streamlined ways of providing those products and services at a lower cost.

Critical Inputs to the Process:

• People in jobs
• Make the most out of the person's role and support them with a great staff and "back office"
• Provide personal marketing, coaching, and resume services about what they're doing, how to market their strengths, develop their weaknesses, and work toward demonstrable results and efficient engagement
• On-site staff augmentation and support services to fill gaps within client team.
• Project and program management definition and sales -- how to "stealthily" grow the scope of the consulting group's influence at the client.
• Replacement services when the individual isn't the best fit
• "Graceful exit" services when the client or engagement should not be the focus of the consulting organization
• Leads, hiring managers, entrepreneurs
• Assist in the definition of programs and offerings
• Put consultants and partners in place
• Seek to define measurable results and a consistent, visible practice, and knowledge base
• Partner via Master Service Agreement (MSA), Joint Venture (JV), etc.
  

My Personal and Company's Mission Statement

"To provide the best ways for people to create the most productive communities and networks about their most critical interests using the most current communications technologies."

That's it.  Any thoughts?

Eric

Developing the Right Metrics Matters the Most

There are several ways a person could view an organization:

• As a collection of business processes (activities) that the business has to perform to meet its strategic objectives
• As a collection of IT applications that support the processes
• As a collection of people and suppliers who provide the resources necessary to achieve the organizational objectives
• As a collection of metrics or measures that describe the performance of the organization

Although each of these perspectives is equally real, only one is RIGHT in my opinion. Which one? METRICS, I say. Unless we boil our organizations into numbers and shared things that people can understand -- not complex and changing things like systems, processes, tools, and people -- can we really manage our organization as a program. I'm not making an argument for ACCOUNTING, per se, I'm talking about those facts and figures that tell us whether or not our business is being successful at achieving its objectives.

Therefore, it's my contention that a key part of the strategic planning and communications processes is to define and communicate about the key performance indicators (KPIs) of your business. KPIs are a bit of a cliche term but they're critical. The fundamental question we have to agree upon is, "How will we know that we are doing well?".

The more we develop this language of numbers and measurement, the more clear we will be together on our perception of what matters and how to allocate our resources and attention.

Replacing Problems with Solutions -- More thoughts on Pragmatism

After I published my last article “15 ways to be more pragmatic at work” I started to wonder if I’d overdone it by citing fifteen points about being pragmatic. Maybe I personally wasn’t very pragmatic since it took me fifteen points to make my case!

When I wrote my 15 points, the problem that I was trying to solve for was that for me the idea of pragmatism seemed very complex and I felt that I had to create an equally complex solution (one that required a fifteen-point process) to solve for it. The basic point here is that pragmatism has a lot to do with efficiency and perception.

If the input requirement I'm given is “build a box” and I create something wildly complex like a computer, you may say that I wasn't being very pragmatic. Whereas if I instead drew a box with paper and pencil and you liked it, you may say that I'm rather pragmatic. It all depends on how we define the problem, who's the audience or judge, and what's really at stake.

When it comes to making new things and getting the most out of life, all of us probably want to know what to expect before we take something on so we are prepared to advocate or defend what we’ve done once we get to the end. We don’t want to do anything without a purpose or to have a story to tell! We know that we won’t be able to mitigate all of the risks involved in doing what we want to do decide to choose the most important risks to mitigate and go down the road to fixing them. Along the way we may have to defend our actions and tell others that what we’re doing is the right thing and the step we’re taking is the right one. In others eyes, we want to be seen as capable, confident, and intelligent; independent.

A pragmatic solution to me is one that includes only as much complexity as is required to be deemed by the people who defined and/or are defining the immediate problem at hand as acceptable. To provide for this we have to know what expectations others will have once we’re finished. This is why we have to inquire and wonder and include others on our journey. This is why planning matters and this is why it’s nearly impossible to create solutions in a vacuum.

Let’s set our sights on replacing problems we have with solutions we like.

Top 15 Tips for Becoming a More Pragmatic Worker

I recently completed an engagement leading several software development projects for Microsoft and learned quite a bit from the experience. Times are tough right now in our economy and I want to express to you how I think we all can be more pragmatic in our work styles and rise to the occasion of these tough times.

Answers.com defines pragmatism as, “having or indicating an awareness of things as they really are.” Well, how are things REALLY? I’d say—given our down-economy and business in general—the world is “really”:

• Competitive. There’s a lot of people out there competing for the same resources and business that you are.


• Impatient. Due to the competition customers may have very high expectations for what is possible and what “value” they think you can deliver to them. They want it all now, perfect.


• At Times Cut-Throat. Managers in today’s environment may be threatened by the realities of competition or the complexities of their tasks. This may cause in them agitation and desire to force workers to realize the inherent risks of today’s environment.

If we see and accept the world as competitive as described above, then we next have to figure out how we can best operate in such a context. Below is my list of top recommendations for becoming more pragmatic—and successful—in our work today. I hope you find this list useful to your situation. Please feel free to comment and augment based on your thoughts!

1. Use induction. Induction is defined as “the process of deriving general principles from particular facts or instances.” What this means to me is that we must learn by demonstrating things to our customers, ie “get real data and feedback”. Turn that real data and feedback into something real.


2. Identify and appropriately manage all assumptions. Assumptions will kill you and your organization can’t afford to run on them. Make sure you identify all of them, understand them and determine how to manage them. Some possible strategyies: a) document them and look the other way b) validate them with the customer either by asking a question or demonstrating your interpretation of the assumption in your work or c) (not recommended but sometimes necessary) cover them up.


3. Demonstrate as quickly as possible that you understand customer requests via the end product. Build as many of your unchecked assumptions and thinking into the end product so you can get feedback from the customer as soon as possible. Make sure that you are flexible in listening to the feedback integrate those changes into the next iteration.


4. Have your work process be the way that you continuously demonstrate your understanding of the customer’s requests. Be flexible. It’s okay to be wrong. Listen hard and show them that you understand through demonstration.


5. Your work backlog will grow and you need to manage it. Develop a way that you manage the things that are requested but you’re not currently doing. Expose the work backlog to your customer and work with them to set aside chunks of work that you’ll get to. Prioritize the work between what’s immediate and what’s future. Understand what’s future but don’t spend any time working toward it. Limit feedback until the next demo with the customer if at all possible.


6. Don’t over-engineer. Building too much “value” into the product will kill you. Only put in “hooks” architecturally for future possibilities but never spend too much time engineering toward them until the customer decides they are in scope. When it’s time, you’ll have a platform that makes you ready.


7. Ensure you have the right contract type setup. Using an iterative process like that which I’m suggesting is difficult. Be prepared for the rigor an negotiation required to engage with someone in such a structured and regimented manner. Make sure that the contract terms align with your goals.


8. Be clear with everyone about what the process is and isn’t. Listening, demonstrating, and responding sounds like a simple process to follow but you have to make sure that everyone gets it. Teach and coach everyone on this repetitive process so they understand their role in supporting the next increment and improvement overall.


9. Advocate less and inquire more with the customer. Your goal with the customer is to listen to their needs more and uncover more and more work that they want you to do; open up a realm of business opportunity.


10. Keep some things secret. Don’t share all of your best ideas with the customer. You may want to keep some things secret for when the time is right for a surprise.


11. Advocate more and inquire less with your team. Your team is there to support you. They need to be listened to and understood. So much innovation can come from your team if you can figure out how to integrate it and suggest it to the customer in a fair way.


12. Building products is a partnership and shouldn’t be a dictatorship. Seek to bridge the gap between all parties involved but let the product owner (customer) be the ultimate decider.


13. (Removed as it was a duplicate of a point made above. Was: "Build “hooks for the future” into your current solution")


14. Elaborate on assumptions but only when the customer thinks it’s time. Your job is to build to the “immediate core” of what the customer is stating as their need but also to add “hooks” (not total solutions, rather starting points) for what you think they could mean.


15. Use the Kano Model to think through a balanced approach with your customer. The Kano Model is a handy tool for considering customer satisfaction. Make sure you’re always doing what qualifies in the customer’s eyes but keep them excited and engaged with performance and excitement features at the same time. If you can keep them engaged enough, then not too many features should be “qualifying”.

I hope you found these tips helpful. Please offer your comments.

3 Keys to Making Your Product Development Effort Successful

Through Six Hour Startup--where a new web-based product is developed and launched by a team of 20+ strangers in six hours--I learned what it takes to lead in chaotic situations. At BluWater Consulting I was Scrum Master to three concurrent software development projects and learned that there are a few key principles required to succeed: strength, (team) commitment, systems thinking, and creativity. Based on this I define agility as “a willingness to seek, accept and integrate feedback as frequently and rapidly as possible”.

In my opinion, there are “3 Keys to Making Your Product Development Effort Successful”:

1. Develop relationships with key suppliers. Rely on your suppliers to coach you on the best tools and methods for your organization and situation. Invest the time and resources necessary to procure what’s required to lead the change you seek! At a minimum, put up a whiteboard to track each project and use “stickies” to track the work as it flows through the process. Ensure that there’s shared accountability within the team and the roles of shepherd, pairing partner, and QA are clear. Synchronize your stickie-note process with a powerful information system so you can get real-time statistics, detect, and analyze process variances.


2. Identify and establish the leadership required. The program will only succeed if you have the support and understanding of the right people. This requires persistence and a strong will! Seek to continuously understand who is in charge (the team) and govern as required. Make the roles of Scrum Master, Product Owner, etc. clear but don’t be surprised when they change.


3. Make sure that your team gets it. There are some critical things that your team has to understand before they’ll do well in an agile process. One example is understanding the difference between burning time “up” (tracking actual hours in the case of work that involves uncertainty or risk) and burning time “down” (tracking how much time is left against work that can be reasonably estimated). Make sure that your team has the training it needs to succeed, move forward, and communicate with each other effectively.

If you would like help getting your project or practice off the ground, I'm happy to quickly assess where you're at and help you get get to where you’d like to be!

Managing Schedule Risk in an Agile Scrum Process

Managing time and the team in an agile scrum project is difficult but it's gotta get done. In all projects, we have to estimate what we're going to do and try to get it done. If we aren't getting it done, we have to either work more and meet our deadline or communicate to our sponsors how things are going to be different at the deadline or move the deadline out. It's all about delivery and customer service in the end. At any rate, typical software projects have two distinct parts, each requiring their own management techniques:

1. New feature development



2. Bug fix, customer service and support

Since we have to manage both of these types of work, and they behave very differently, we need to develop a language around getting things done to support effective communications within the delivery team and to our customer community. The choice we use at my company is Agile/Scrum, where we plan and deliver our work in 2-week increments called sprints. By doing this we're able to execute and significantly re-tweak our process every two weeks. We are given a quote-unquote new lease on life every two weeks; it should be a refreshing way to work and partner.

In our methodology, new feature development is handled by the Agile/Scrum methodology burndown method to track work. The burndown method is the typical agile/scrum way of tracking work: we create a definition of done in terms of scope and features, then estimate how many hours we think it will take to do it. Between the ScrumMaster and the team, we track how the hours are burning (up or down since maybe your last estimate wasn't great and there was unseen work) on a recurring basis and if we think our velocity is what it needs to be. If the velocity starts to slow down, the team addresses how to remove impediments and get the velocity up to such a degree that the project is scheduled to finish on time. If things don't go well, we figure out how to mitigate the risk with the customer.

Burnup is a different but important concept to understand and use to manage our work. Our example of using burnup here is a 50-hour max promise to the customer to deliver customer service. We don't have to provide all 50 hours in our example but we do want to know how much of this time we're spending because it's a distraction to the other part of the project since we can share resources and sharing resources is efficient. This method requires tracking ACTUAL hours spent, which is different from the burndown method. Note that this is a key difference from burndown, where we really only care about how many hours are left. We can see how many hours are left on a burndown type of project but what's potentially left on it is certain, whereas what's left in burndown is only estimated.

These two methods of burnup and burndown are two very different ways to think about work: the former is a picture of what's necessarily remaining and the latter is a guess of what's left. The latter is best mitigated by good planning and knowledge of what tasks and how much time is required to get to "done". Together, we use these two techniques to manage risk and communicate effectively.

Conclusion: We Can Now Manage Projects That Burn Time Up and Burn Time Down

By understanding how these types of work are different and how we can manage each, we're able to develop and speak a language about risk and progress making our velocity increase and our projects more fun.