Your app vs. GMail

When you work in what I call a "controlled environment" it is kind of easy to be dragged into compromises in different areas of quality of your products. As with many other things it does not necessarily happen because you want to compromise, but simply because you can do that. There are many implicit myths about controlled environments. Here are just a few:

  • In controlled environments users have to use your software and therefore you can compromise on usability and user experience. After all users to not have alternatives to in-house corporate software tools.
  • In controlled environments users have to use your software and therefore you can compromise on performance tuning. After all users to not have alternatives to your software.
  • In controlled environments it is ok to provide something "good enough" software simply because all the other corporate software users have got on their computers is crap.

None of that is actually true nowadays. Every corporate user also uses GMail for his personal e-mail. Every corporate user also uses Mint.com to manage his personal finances. Every corporate user also uses Flickr to organize his photos.

We all know that expectations are set by previous experiences, especially, when it comes to non-functional requirements and qualities, which are hard to quantify, like usability. Users have already seen what is possible in other apps and they want to be able to get to the information managed by your apps in a matter of a few keystrokes, like in GMail. They want your apps to produce relevant and nicely looking reports, like on Mint.com. They want easy access to functions they need while focusing on the main thing they do, like with Flickr.

When developing corporate app you compete with Google, Intuit, Yahoo. In modern world you do not have benefit of controlled environment and you have to compete for users' attention and buy in. These days the best recognition for corporate software engineer would be when user while working with custom corporate software system says "Wow! I wish GMail had this too..."

Metrics that mean

We all know this law coined by Elia Goldratt:

Tell me how you’ll measure me, and I’ll tell you how I’ll behave.

This cause-consequence relationship between incentive and action is very important for managers. As with many other things this can be applied on different levels. Consider the difference of measuring someone by number of oranges sold versus number of happy customers returning to the store to buy oranges.

I came across a great example of metric taken to the next level in post £24m School Can't Get Its WiFi Working by Fraser Speirs:

In my school, we aim to lose no more than five teaching hours per school year to computer failure.

Do you see how this metric not only prompts "correct" behavior, but also sets the goal? Metrics like this are less prone to "local optimum" problem when person compromises on quality and results in some other areas make up for particular target, because they do not control action itself (like, selling oranges), but instead control ultimate outcome of the action (like, happy customers).

Are you and your team starve to get more happy customers or try to sell more oranges?

Webinar: The Business Driven Software Development

Net Objectives conducts a series of webinars on Business Driven Software Development:

This series provides an introduction on how to achieve Business Agility. Business Agility enables an organization to respond quickly to external forces (such as new market opportunities and competitive forces) as well as to respond quickly to new insights attained internally. While many organizations have achieved the local optimizations of more effective teams, few have achieved agility at the organizational level. Even when team agility has been achieved, if improvements to how the business is selecting their product enhancements isn’t done, overall return on investment of software development may not have significantly improved.

First event is tomorrow at 9 AM PST. Register at the event page to attend the webinar.

The world is flat (and small)

Several years ago on one presentation I said that world became really small: to any place where you might be interested in visiting on business you can get within 24 hours. Sometimes you do not even need to get there, because world is not only small it is also flat as Thomas Friedman described in his books. Here is great video of his lecture in Yale:

One simple step to better configuration management

Many say that configuration management is hard. It is. 100% correct, "as the books says" software configuration management is hard. It takes tools, skills, discipline and effort to build and support reliable and effective software configuration management process. It is especially difficult, when there is already some process in place and improvement involves change.

My experience shows that it is particularly challenging when it comes to non-source code items like documentation and release packages. Can you imagine following dialogs with project team members? I can…

Managing source code:

--Is it necessary to follow Configuration Management practices, when you work with the source code? --Yes!

--Do you use source code control system during development? --Sure!

--Would you start coding without SCC in place? --Absolutely not!

Managing release packages:

--Should you manage configurations for you release packages? --Oh, yes!

--The best way to do that is to be able to recreate any version of release package... --Oh, yeah! That's the best way, especially, if you hook this up to automated builds and tests...

--Do you do that? --Well... You know, that requires time to setup. We are so busy with other tasks actually writing software, so we never actually got to that... And, by the way, our existing process is not that bad...

--But still you can get all the previous release packages, right? --Well, I guess so... We have a share where all the releases are uploaded.

--Do you delete files from there? --I think so. When we need to.

Managing documentation:

--Should you keep track of the versions of all the development-related documents that you've got? --Yes, definitely!

--So you do that, right? --Well... Not exactly... You know SharePoint (or another tool, you name it) is somewhat difficult to use (or setup). We just put the file in a shared folder or sync over the e-mail. When the document is final, we put it into SharePoint.

--I see... But you do change version number on the document each time you edit and keep it somewhere, don't you? --No, not really. Do we need to?..

Generally, the further you get from the source code the worse it gets.

There is a simple, not ideal, but simple remedy to this, which lies in mimicking what source code control system does:

Never overwrite or modify files! Always create new!

After all, we all have got 500Gb drives in our laptops - we have to put them to work.

Positives of negative New Year's resolutions

By this time most of us (at least those who care to make our lives better) have made their New Year’s resolutions. From what I hear here and there most of these resolutions are around new things which you are going to do this year:

  • work out regularly
  • read more books
  • spend more time with family
  • improve foreign language skills
  • etc.

As you see all of these resolutions are about new things in your life, they are about doing things you did not do before. However, there is another popular resolution, which is, in a sense, exactly opposite:

  • quitting smoking

This resolution is about not doing something, thus creating a room for new things in your life. Indeed, ten 5 minute smoking breaks give you 50 extra minutes each day, when you get rid of this bad habit. Extra bucks that you save on not buying cigarettes give you additional opportunities to do something meaningful to you and those around you. And this is not mentioning your health and wellbeing. At the end this negative resolution creates additional time and resources capacity you need so much to act on your positive resolutions.

4232411010_3e7afe8a4e_m_d[1]

I believe that each positive New Year’s resolution should be complimented by a negative one, which will make it possible to do what you resolved to do.

If last year you spend substantial amount of time fixing and reworking what your subordinates did, you need to resolve to stop doing that and instead focus on improving their skills to avoid those reworks in the first place.

If last year you engaged in many activities simply because somebody asked you and technically you can do that (and, between us, do well), you need to stop doing that and make your own conscious decisions about what you do and what you don’t.

We only have 24 hours a day and we always use them up. Each day. In order to start doing something, you need to take time from something else. Unfortunately, we can not create time out of nowhere.

,

Change requests: In or Out

,

Many junior PMs think that Change Requests (in our company we call them Change Orders) always come to project team from the outer space, whenever the client or other stakeholders want to change something, like increase the scope or tighten the schedule. They think that CRs are there to protect the project team from changes coming outside of the project.

in-n-out

The thing is that CRs are not only about the scope. There are many more controlled project parameters, although the scope is probably the most notorious when it comes to changes. And whenever you need to change any of these parameters you need a Change Request:

  • Scope
  • Budget
  • Schedule
  • Specifications
  • Quality (if you run projects better than others and really control quality)

When the customer wants to add something to the scope of the project, you need to issue a Change Request to adjust other parameters accordingly. When you need to change schedule, you issue a Change Request to communicate  the change and get approval for it. So Change Requests are not only and not always incoming, they can and should be outgoing to communicate important things, which happen to the project.

Change Requests are meant to protect project stakeholders from silent changes in the project. As much as you want to be informed and be able to react appropriately to the additional work coming your way, the same way project customer wants to be informed and be able to do something on his end, if you decide that final delivery date needs to be moved.

Change Requests are means of communication and no wonder that not doing this part of communication properly can put your project at significant risk. Next time not only wait for CRs to come, but be sure to communicate the changes you initiate to other project stakeholders.

Also check out The Top 9 Reasons Why Projects Fail at The PM Podcast. Communication done right is 80% of successful project.

Creating great presentation visuals

I do not remember how many times I used phrase saying "if you are one in a million, in China there 1,300 people like you". I heard it somewhere and did not really know who coined that. Reading through "Prezentation Zen" I saw presentation called "Shift Happens", which uses comparison with China to amplify the changes happening in the world today. I could not resist sharing this great presentation with you:

Shift HappensView more presentations from Jeff Brenman.

Going to checkout winners of various SlideShare Contests for more examples of great  presentations.

,

2 steps to more effective communication

,

I'm reading Garr Reynolds' "Prezentation Zen" and his points about efficiency of presentations, which can naturally be translated into efficiency of communication, resonated with my mind:

The presentation would have been greatly improved if the presenter had simply kept two questions in mind in preparing for the talk: What's my point? And why does it matter?

Now communication is more important than ever for me, since I work on-site with client and do not have luxury of face to face communication with my team. Should I be asked to generalize Garr's statement I would do it this way:

The communication would be greatly improved if the person speaking now would simply keep two questions in mind, when preparing to speak: Why my speech does matter? And what is my point?

I have heard dozens of perfectly made points, which unfortunately were not relevant and simply consumed the bandwidth. Alas bandwidth of communication is more limited than we usually think.

Keep that in mind and be an effective communicator.

,

Zooming in on a design

,

Have you ever worked with, maintained, explored a system which looked and felt really great in one area, but was really awkward and clumsy in another one? That was an instance of an elephant on the crutches. Elephant

This often happens, when design specification was not consistent in the level of detail for different parts of the system. And here is how this may happen.

When you design a system, it is never going to be plain and the same wherever you look at. If you have a database and a user interface - those two parts are already different enough. Such diversity naturally leads to the fact that there are some parts that you enjoy working on more than others (after all we never like doing everything that we do).

What happens next is that you spend much more time thinking about parts you like (because there you use new fancy technology, or neat engineering approach, or who knows why). Therefore you add more details to design of those subsystems that you really like. The outcome of all of this typically would be a specification that is an elephant with crutches instead of hind legs, because elephant's butt was never you favorite part of the system and design of this "subsystem" never was detailed enough to make sure it is consistent with the front.

Ideally, your design should be like Google Maps: you should be able to zoom in and zoom out on any part you need. It does not make sense to have a map, which shows each and every tree in your neighborhood, but gives you only a vague idea about how to get to grocery store 5 miles away.

When developing and documenting design you should gradually and consistently increase level of detail in your specification. Ideally, difference in granularity of descriptions of different parts between any two parts of the system should never be more than one level. One possible way of zooming in would be to describe

  • System + external interfaces, then
  • Services and components, then
  • Add their interfaces, then
  • Add interaction (Sequence diagrams) and edge classes, then
  • Components' structure and internal interactions, then
  • Class-level specification for key requirements (functional and non-functional)

This is not the only possible way to zoom. However, when you have class diagram with methods and their parameters, but do not have stored procedures defined for your database, you are doing something wrong (or, hopefully, your design specification is not complete yet).

Design specification is only useful when it can help you answer questions you get during development. This essentially means that you should be able to navigate it and find things - which is zooming in and out and seeing enough to make the right turn.