Must have Gmail Labs features and tricks

Thoughtworks email move to Gmail was probably the best thing a TWer could have asked for.

Now having Gmail as your mail client, it is also important to harness its complete potential. If a lot of your work involves emailing people, here is a list of GMail Labs features you would want enabled and a few tricks you must know.

(Thanks to the Official Gmail Blog for sharing this !)

1. Don't Forget Bob

(Enable from Labs)

If you often mail a set of people GMail tries to recognize a pattern and suggests including others to ensure you have not missed anyone in the "regular" list.

2. Undo Send

(Enable from Labs)

A very useful feature if you end up clicking send to soon to realize that you missed adding something important to the email, this gives you the "Undo" option !. Of course the popup above remains for not more than 30-40 seconds :-)

3. Move Icon column to the left

(Enable from Labs)

By default GMail shows all your icons on the right of the subject line which is sometimes quite inconvenient when you are looking for "that one mail from Bob which had an attachment" by scrolling down. You can move the icon column to the left by enabling this feature in the Gmail Labs.

4. Drag and Drop attachments

Most GMail users often don't know this is possible. This best works in Chrome. (Has a file locking issue in FireFox).

5. Missed an attachment

GMail looks for phrases such as "Please find attached" etc... in your email and alerts you about a missing attachment to save you from embarrassment .

6. Finding a long lost attachment

You can use the "has:attachment" tag in the search to search for a specific filename or type of file which had come as an attachment.

7. Going back to inbox while typing an email

Quite often, when you are typing an email you wish to go back the Inbox to lookup something more. Most users using the web interface end up opening the inbox in another new tab. A lesser known feature of Gmail is to click the icon on the right in the above pic which elegantly does the same.

8. Canned Responses

(Enable from Labs)

If you often send the same kind of email with a few variables you can use the "Canned Responses" feature to create such templates and minimize typing such mundane emails each time.

What's next that can go wrong ?

When developers on my team are developing the next priority feature, testers trying to break the application, I am busy looking at what is the next possible thing that can stop the teams progress. There is that one area in the application which can possibly bring up a big performance issue and I have no one looking at it yet. There is a UAT phase coming, and some services have not yet been integrated and we might get a lot of surprises when it is too late to recover.

I have started enjoying this as a project manager. Think , think and try to think of things that no one else is thinking just yet. And I know I cant just get into every bit of detail, I will have to trust the leads from each role to ensure that all aspects are covered. I ask my QA lead atleast once a day about what we should be doing 2 weeks from now. He is currently busy getting QAs to test critical features which developers are churning out, but a peep into the near future helps him reassess his plans and make correction. He tells me he needs a few new test environments which were not planned earlier, and I immediately make a note of it. We quickly catchup on plans for shipping future builds and expectations I as a PM should be setting with our customers.

Looking into the future and managing risks becomes a routine task for me. Getting the team to be ready for the next uphill task becomes a big motivation in itself.

Rescuing Agile projects in distress

With the current trend of large organizations struggling to adopt flavors of Agile, one often encounters Agile teams in distress.These teams find it difficult to work in a sustainable pace and deliver predictable results to their customers. Bringing such teams back on track is an interesting challenge faced by Agile practitioners all over the industry. Being an Agile Coach in such an environment can be quite overwhelming and it is important to iterate through the steps intended to bring the project and team back on track.

Definition of DONE

The team needs to have a clear definition of DONE for stories in the project. A story is DONE and accounted for, in the velocity of an Iteration, only if it is accepted by customer. In teams which are plagued with various issues, this definition of DONE often gets compromised. Teams tend to call "Development Complete" or "QA Accepted" as DONE. Both of these only allow sub optimization of the value stream and it is better for the team to move towards "Customer Acceptance" as DONE, as soon as they can.

Minimize work in progress

An incremental backlog of "In Progress" stories starts getting built, when a team does not achieve the same velocity as what was being planned for. Before you know this backlog becomes huge and unmanageable. A lot of stories often tend to get stuck in the QA phase with a lot of bugs. If stories do not follow INVEST principle, QAs also.find it difficult to test these stories. Stories might get stuck in development for a long time, if developers on the team are busy cleaning technical debt as a part of a functional story.

It is extremely important to stop the line and fix some of these problems, by doing all it takes to get the stories "In progress" to "Customer Acceptance" before signing up for new work. If you have a huge QA backlog, try and understand the root cause of it. Is it because QAs are not getting good builds to test on ? Or is it really a capacity issue ?

Bring in Scope Control

Controlling changes in scope at all times is important to ensure that the team is working on stories which provide the maximum business value to customers. Sometimes teams struggle with this because they are dealing with product owners who defer any commitment, either for signing off story narratives, or accepting a story in a build. Product Owners (Customers) should be made to understand the scope of each and every user story during release and iteration planning.

In a situation where there is lot of change in requirements, introduce a release level baseline of stories. Create a light weight change control with a group of people who approve any changes to the release baseline. This board should include at least one stakeholder who is responsible for the cost/budget of the project, along with a lead business analyst from the team. This ensures changes are well accommodated into the release plan before they are developed.


Prioritize bug fixes

A common smell with too many bugs is prioritization. Almost every bugs ends up being critical, and hence triaging bugs with customers on a regular basis becomes essential. This ensures that the team is fixing only bugs which add maximum business value considering limited development capacity. It is also important that enhancements are explicitly called out and not buried as bugs. This should also happen during the daily triage of bugs.

(Fixing the Criticals and Highs is more important)

There is a good chance that if a team is running behind schedule then there might be a lot of bugs being introduced in the system. Analysis of these bugs more closely should yield patterns such as fragile areas in the codebase, lack of unit tests, tricky UI issues etc. which could be primary causes of these bugs. It is important that these causes are talked about regularly in standups and unit tests written to cover the issues wherever necessary. Fragile areas also highlight technical debt in the codebase which should be prioritized and cleaned up.



Prioritizing technical debt in the codebase

Technical debt slowly starts getting accumulated when refactoring areas of the code is deferred due to project pressure to deliver functional stories. If this continues for longer, it begins to hurt the team by manifesting itself in the form of bugs and longer development times for stories. It is essential to start prioritizing technical debt and playing the higher value tasks every iteration. Technical leads within the team can help with this prioritization and bring to the table technical stories that can be played during the Iteration planning meeting. Awareness about this technical debt needs to be created by writing on big visible charts, talking about it in standups, and by even conducting group refactoring sessions.


Regular Status Reporting

When a project is in distress, everyone is concerned and wants to know where the project stands almost everyday. It is vital to provide this level of visibility to customers, especially when they are paying for it. One needs to constantly provide information of the risks and issues impeding the project and the way the team proposes to deal with it. If the team's velocity is low for an iteration, it is important for the customers also to understand the reasons behind it. This ensures that the customers and the delivery team work together as a unit towards a common goal,and eliminates any uncecessary friction.


Continous Integration and Automation

It becomes all the more important to keep the Continuous Integration system stable and running when a project is struggling to be on schedule. Discipline around not checking in on a broken build and periodically cleaning up the build files to improve build times go a long way in eliminating delays for the team.

It is also important to run a suite of Automated functional tests that ensure that the application is not broken with any checkin. A small set of Smoke tests can be identified by the team that can cover the breadth of the application. An exhaustive suite of regression tests can also be run periodically to minimize manual regression efforts.



It is always the people

It is always the people in the team who make it work. You always need a highly motivated set of individuals with a strong resolve to pull things through difficult times. If you are a PM/Coach, it is important to constantly talk to people in various roles in the team and continuously set expectations for the near term. It is also key that people in all roles work together as one team. The mythical man month still holds good in an Agile project and adding more people later in the release will only delay it even further.

Don't let sustainable pace stop you from further improvements

The classical XP/Agile view of velocity relies on a graph which indicates that the velocity of a team stabilizes over Iterations as the team goes through the cycle of Forming,Storming,Norming and Performing It is also an indicator of team achieving sustainable pace.

A lot of Agile project managers/coaches/leads fall into the trap of sustainable pace, and stop thinking about ways to improve efficiency, one the velocity graph shows signs of stabilization. This also gets complemented by the fact that customers are reasonably happy with the velocity the team is currently achieving.

This often stops Agile practitioners from innovating and coming up with even better means to increase throughput of the team.

As an example, imagine a team merrily churning 20 points of stories in an Iteration on an average and the customers are quite happy with the progress. The team probably has an average build time of 20 mins with SVN as a source control, and most often, if this team is in this happy rhythm , it wont bother about the build time, even though there is scope for improvement there. In my previous project, we moved from SVN to GIT as a source control and it reduced our build time by 70% approx. If someone started doing this in the imaginary team with a velocity of 20 points, they can surely speedup by 5 points atleast, considering the huge number of continuous builds in a day.

Another example which I see quite often is teams getting stuck on to sweet release schedules and not striving to improve further. Sometimes a team starts of with a 6 month release cycle, takes a lot of pain and then moves to a 3 month release cycle. When moving to a 3 month cycle this team, tries to improve their processes quite a bit which can involve things like bumping up the functional test suite coverage to 80%, reducing build times etc... But very soon, the 3 month cycle becomes a sweet spot, if the customer is not demanding any further. The point here is not to reduce the release cycle even further, but do more of the optimizations you did to the build times and functional tests and maybe even more things, which will continue to cut down waste. Unfortunately once the sustainable pace is achieved, inherently the motivation to think out of the box to reduce waste goes away.

There is always scope for improvement in a team. Agile practitioners/leads should always have the hunger to make their team better. Think of building teams iteratively. The Forming, Storming, Norming model itself is an iteration at each stage where the team is getting better. But dont stop at performing. Always be hungry for more and don't stop yourself at sustainable pace.

Why is a Story narrative signoff and Showcase acceptance from a Product Owner important every iteration ?

A proper development iteration will involve the development team working on a user story, and towards the end of it, showcasing what the team has completed. This is not only critical to get feedback from the product owner, but also from a scope management standpoint, which most teams tend to neglect.

It is the responsibility of a Product Owner to sign-off on a User Story narrative before the beginning of the iteration, and see the working software during the showcase. Sometimes Product Owners do not end up doing this because of various reasons, and this can result in the following smells

Story requirements keep changing constantly within an Iteration

A narrative signoff is an agreement between the Product Owner and the Development team around the Acceptance Criteria of the story mentioned in the narrative. Sometimes Product Owners shy away from doing the same because they are not sure what they exactly want in the given story. They also want to work in a mode where they can propose changes to the same story within an iteration, since in their mind, as the team is doing agile , it is supposed to embrace changes at any point in time.

This setup results in story changes leaking into a development iteration and causing a lot of churn, and hence wait in the form of code and testing effort. This also results in a team not achieving sustainable pace with every iteration, because of constant changes in user stories,

A fix to this problem,is to coach the product owner on writing/signing-off User Story narratives well before the Iteration starts. What is also required is to make him/her understand that a change made later in the iteration will come at extra cost. One also needs to highlight the amount of waste generated because of changes being made, and the hidden costs associated with thrown away code etc...The team should ideally work in a mode, where if a story narrative is not signed off within an iteration, it should not be played at all. And once development has kicked off for the story, any change to it, should come in as additional scope request which is up for negotiation.


Stories do not get accepted at the end of an Iteration, and the team does not have a clear definition of "Done" for stories.


If Iterations are planned correctly then towards the end of every iteration, stories developed in that time frame should be showcased to the Product Owner and accepted. Sometimes Product Owners are averse to the idea of "Acceptance of a User Story" and insist on a feature being complete to sign-off. Taking such a stand results in many stories within a release pending acceptance till the very end of a feature. Some Product Owners lean towards this claiming a complete feature is much more testable and makes logical sense than a single user story. If this is happening, then it is either a case of your User Stories not following the INVEST principle or the product owner wanting to delay commitment for various reasons.

Again this very problem should be fixed as early as possible in a project. The practice of acceptance of stories every iteration ensures that the product owner has validated the working software as per his spec every iteration. The feedback cycle is cut short and any change beyond this point on requirement is a new story altogether. More importantly, this builds a lot more confidence in the development team that they are on the right path. Ideally, "Customer Accepted" should be the definition of "Done" of a User story, and only when a story is "Customer Accepted" should it be counted in velocity of the team,

The Product Owner role is critical for an Agile team to work smoothly. A good product owner should not only have an excellent view of the product and domain, but also understand the importance of some of his responsibilities towards the delivery team.