Just Do It - Agile PechaKucha vol.2
Last week I gave a talk about importance of doing what talk about at Agile PechaKucha vol.2 in Kyiv. Here is slidecast from my presentation (in Russian):
Check out the rest of the presentations from that evening. See you on the next event!
Two types of answers
When I'm asked a question, my reply often is "Well, there are two answers to that question: a short one and a long one (or a simple and complex)..." And that is because there are indeed two types of answers to many questions. I would call them definitive and process oriented. For example, "how long will it take to complete this project?". The simple answer might be "we do not know", the complex answer will be "we do not know, but here is how we can control and manage schedule for our project and make it possible to make certain commitments on dates depending on your goals".
Another perspective on these answers is that one of them is like "here it is" and another one is "oh, here is how you get it".Remember that saying that professionals do not always know all the answers, but they always know how to find what they need.
The matter of fact is that process oriented answers are just as important as definitive replies. Of course, we should always starve to simplicity, but if there is no simple solution, we should not abandon looking for complex ones.
CEE-SECR 2010
Official call for papers for CEE-SECR 2010 is now available. Submission deadline is May 24 - a little less than two months from now.
QUOTE: Heroics in the workplace
...People respond with heroic behavior. And when they act heroically, they stop improving. They just act heroically again, again, and again, and they stop learning.
David Anderson in interview for Software Engineering Radio.
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]](http://static.squarespace.com/static/4fe616ffc4aab1f53e914823/501ed2cde4b08661f234eb5f/501ed2d2e4b08661f234ebd6/?format=original "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.