Managing all your passwords from one place

In April this year, my friend Parimal Nagarnaik died after 2 year battle with cancer. At that time I realized how many things we do online now a days. All these websites have a username and password. Usually these usernames and passwords are stored in memory or in browser (e.g firefox/chrome) or some word document. It creates a mess for the family.

Last few days I am searching for a way to manage all the passwords at one place from multiple devices. Also a way to share the passwords with family in case any mishaps. I have found following somewhat practical way.

Keepass : Opensource application for securely storing passwords

First download http://keepass.info/download.html . Keepass is an open source application for managing your passwords. All the passwords are stored in keypass database in an encrypted format. Keepass uses AES/Twofish (two well known cryptographic algorithms with 256 bit key). The main database is encrypted with a key derived from a master password. You have to give the master password to decrypt the database of all other passwords.

How to share Keepass database across devices ?

Now enter all the passwords in Keeepass and save the password database in Google Drive. All your windows devices can share same keepass database. Any changes in one device will be propagated to another device by Google Drive.

Now install KeepassDroid  from Android playstore.                        

Install Google drive app on your phone from app store. Make the keypass database 'available offline'. And then open it directly from Google drive. Google drive will ask 'which app' to be used for opening the file. Select "Keepass Droid" app. Now same google drive keepass database is available to you on your android phone. Any changes/edits you do on phone will be synced to your desktop apps as well.                        

How to share the Keepass database with family members in case of mishap?

You can share the keepass file with your family using the google drive 'share' feature. This way family will have access to your passwords if required.

Gmail has 'inactive account manager' feature. "Inactive account manager" sends a message to google email accounts that you specific and give them access to your gmail. You can specify the message to be sent to these account. Include your 'keepass' master password in this message.

Keepass apps are ported to iOS/iPhone as well. Search for MyKeePass or SyncPass on iPhone appstore.                        

Keepass plugins are available for Firefox, Chrome, IE for managing all your internet password/logins directly from browser. You can get the links for various plugins from http://keepass.info/plugins.html

SVNPlot Version 0.9.0 Released

Today I am releasing SVNPlot Version 0.9.0.


SVNPlot now works on Python 2.7.x and on Python > 3.5.x. Current release also contains many small bug fixes esp. related to Unicode handling.



You can download the installers from Bitbucket Download Page.

Agile Burn Down Chart

I am guiding a project team on some architecture changes. Its a new product. However, I was not getting any clear picture on the progress. I checked Burn down chart. Even that did not give me clear picture. I checked with project team as well Process team on the burn down chart. AND they successfully confused me. :-)

Process team told me that they track the burn down chart based on the 'remaining effort'. Every day each team member update how much time he/she worked any story. The 'remaining time' is the used to plot the 'burn down chart'. 

Now consider the scenario below

1. Original estimate of Story A is 40 hours.
2. Team member X, worked on Story A on first day for 8 hours. So he logged 8 hours and 'worked' and 32 hours as remaining.
3. 2nd day he worked for 8 hours and updated 24 hours as remaining
4. 3rd day he worked for 8 hours and updated 16 hours as remaining
5. 4th day he worked for 8 hours and realized that many more things are still do be done to actually complete the story. So he updated 36 hours as remaining.

The chart will show that till day 3 you are on track. However, on day 4 you are suddenly 'delayed'. At this point, the graph will shoot upwards (Q: Do I still call it burn 'down' chart ??). In my opinion, this type of burn down chart gives a misleading picture to project team. On top of this,  consider that sprint duration is 1 month and stories are estimated at 40 to 60 hours duration. Now you have completely inaccurate picture of project progress. Many cases, by the time PM or Scrum master realizes something is wrong, team is very near to end of Sprint and has very little time to take any corrective action. Exactly the scenario that you are trying to avoid by implementing Scrum. !!!!

So what a Scrum team should do to get better picture in "burn down chart" ??

This is what I will do

1. I will not use remaining time (or remaining story points) to update the burn down chart.
2. If the story is not done, then entire estimated time is 'shown' as 'remaining' in burn down chart.
3. When the Sprint starts, I will ensure that stories are broken down to level where they can be completed in 2-3 days (irrespective of I am using story points or hours for 'story sizing').
4. I will ask which stories may get delayed during the Daily Huddle, but will not use 'remaining hours' estimate by developer to update the burn down. I will use this info only to decide who may need help and how to give that help.

Now my burn down chart will look like a ladder. 

For the above scenario,  till first 3 days, story will remain open and at 40 hours remaining time. On 4th day, when story is complete, remaining time will go to 0. The burn down chart will now look like this.

 

What do you think ? How do you calculate the burn down chart in your project ?

Why does Agile work ?

Why does Agile work ?  Yesterday I missed a session on 'why Agile' works in Agile Dev (West) conference.  (https://adcwest.techwell.com/program/concurrent-sessions/why-agile-works-and-how-screw-it-0).

Just wanted to share my thoughts on "why Agile works". 

Waterfall Assumes and expects "perfection"

Waterfall model assumes 'perfection'. It expects perfect requirements, then perfect design, then perfect code. Usually that doesn't happen but going back and correcting becomes difficult because of this expectation of 'perfection'.

Agile assumes and expects "mistakes will happen"

Agile assumes that 'mistakes will happen'. So all Agile practices focus on 'detecting mistakes early and fixing them as required'. It assumes that requirements will change. Hence Agile practitioners advise that  "don't spend time on big upfront requirement and design". If requirements change then this big upfront requirement spec and design is a 'waste'. To minimize such waste all Agile practices are use some kind 'fail fast' mechanism. This implementation of 'fail fast' mechanisms reduces waste and hence cost at the same time it improves the quality of outcome. Because of this 'mistakes will happen' mindset, Agile works better than waterfall in practice. Remember Toyota production systems is also based on implementing 'Fail Fast' mechanisms

So what is the 'guaranteed' way of ensuring 'Agile failure' ?  

Bring the 'perfectionist' mindset of Waterfall to Agile. Managers and teams who try to bring this 'perfectionist mindset' to Agile ensure that Agile/Scrum do not work for them.