Wednesday, September 14, 2011

Game mechanics in the Enterprise software

It boggles my mind how we still tolerate all the incredibly stupid apps (B2B or Enterprise software in general) that we use at our workplace everyday. While consumer apps have shown us what Web apps should look like in the 21st century, enterprise software, even the ones that are currently being built (might I say in the process of re-platforming- from Mainframe to Java / .Net), are still in the dark ages. There are a few reasons for these,

1. Strict adherence to specification, hence no room for innovation,
2. Strict focus on correctness of features rather than usability & user engagement,
3. Fear of challenging status quo,
3. Generational gap (not in literal sense) between the people (developers) who work on enterprise apps vs who work on consumer apps.

Recently I came across a few posts by Brad Feld on the same topic dubbed as Enterprise 2.0. These posts are a bit dated (in 2007/2008). It is now almost the end of 2011. I guess Enterprise is not quite social yet. I would still agree with Brad that the Enterprise software is ripe for disruption more now than ever before. However, I would look at this disruption from a different perspective- usability and engagement than social. In consumer space, apps became social (interaction with friends) first before they became usable and engaging (through game mechanics). While making the enterprise software social (interaction with colleagues; see what I mean here) may seem interesting, I contend that it is not as beneficial as making these apps highly usable and engaging in and of itself using game mechanics.

Here are few trends in usability that enterprise software can easily adopt. Applying game mechanics on the other hand could be tricky and will require analysis of the domain as well as business goals. Nevertheless badges, points, voting,  recommendations, check-ins coupled with clever data visualization can be put together in a way to foster right collaboration and coopetition among employees (in other words encourage right behavior) to achieve business goals faster. In fact, enterprises can tweak these elements in a way to encourage a work culture that is unique, and thereby gain competitive advantage.

Are you using any application at your workplace that has these features already? Or are you currently working on a project where you are going to implement / experiment with some of these features? Or, I would love to hear how you would incorporate game mechanics in the apps you use at your workplace.

Friday, August 19, 2011

A simple guide to effective logging

One of my coding pet peeves is lack of useful log messages. While logging is the simplest, yet effective tool in a developer's arsenal, it is often the most neglected one. We developers do not take the time to think through what and where we should add log messages in our codes.

We tend to use only "error" and "debug" level log messages. We use "debug" messages to help test our codes during development stage. But we add these debug messages on an ad hoc basis. And, our applications usually do not have debug level turned on in production (and we don't want to). The only other time we log messages is when there is an error or exception. This is partly because traditionally developers are not required to provide operational support for the software they write. They are usually removed from production support by 1 or 2 levels- a support team in the client's organization and then another in their own organization. With SaaS model, this separation is going away to some extent, but the issue persists. Well thought out log messages can save a lot of time & frustration with debuging production issues.

Here is a set of rules I use when I write codes,
  1. Use a good mix of 4 levels of log messages- error, warn, info, and debug.
  2. Usually "info" to "debug" ratio is 30%.
  3. "Info" is the most important log level from operations perspective, yet the most neglected and misunderstood one. Systems should run at info level. I see it as the "system's heart beat." At any point in time, anyone should be able to say how the system is doing by reviewing info messages. The trick is to achieve that using the minimum number of messages with just enough useful information.
  4. Use "info" message to trace high level application flow.
  5. Use "debug" message to trace detailed level application flow. Never use "system.out" messages.
  6. Use "warn" level messages when system can recover from a failure. Also use warn when a user is doing anything unusual, i.e. multiple attempt to login, or trying to access functions that they are not supposed to etc. This is specifically useful in the SaaS systems. "Warn" messages can serve as an early warning signal.
  7. Send email when an "error" message is logged. Do not use "error" level if you do not want to receive an email about it.
  8. Be vigilant about what data you write out in a log message. Only enough data to help track activities, but never any security sensitive data (in the context of the domain).
  9. Add context to the log messages. For example, date & time, line#, class name, method name, session id, user id etc. Logging frameworks available in most languages now-a-days are designed after "log4j," one of the most well-designed framework by Ceki Gülcü. Log4j and similar frameworks make it easy to automatically add this context to all messages. 
  10. Format log messages in a way so that it is easy to plop them into a tool like Excel for easier analysis. Here is an example of a good formatted log message,
[ DEBUG] | 110817 21:28:58 | pid-609 | user 2 | session 12345 | controller | effective_logging.rb:17:in `descope_multiple' | wi 12 descoped
Here is an example code showing a good mix of log messages used:

What guideline do you follow for logging?

Wednesday, August 10, 2011

7 usability guidelines for developers

Over last year, as we worked on improving the usability of ScrumPad, we learned a few things that are not so obvious to us "Developers." The conventional wisdom is that usability is something developers don't understand, or should defer to interaction designers. Some aspects of interaction design probably require specialist skills. But, here are seven things that we developers could easily do to improve usability by an order of magnitude.
1) Choose an appropriate default behavior.
Most applications have a default use case. This is usually implemented through some parameters with some default values. But, we do not take time to carefully analyze and understand this default use case. It is an after-thought or an ad hoc decision most of the times. Worse, we defer this to users by making them go through an elaborate setup process to pick the default values. We feel that users would feel empowered if we make them explicitly set these values themselves. As it turns out, most users want to get up and running right away and expect the application to just work. Customization, if necessary, should be "as and when" needed, and should be presented to the users in the context of their actions (and not as a separate action). We call it "on-demand incremental context-sensitive customization." For example, in ScrumPad, users can create a project with 2 weeks sprint as a default (they don't have to do anything extra). When they define sprints, the system would set the end date 2 weeks apart from a given start date. We even help pick the start date based on the last sprint / current date. We also pick the name of the sprint as "Sprint#count." However, users can change the length of a particular sprint by changing the pre-populated dates, or they can change the name of the sprint, if they want to, when creating the sprint. It may seem trivial, and it is, but this little thought about default behavior can greatly enhances the user experience.

2) Minimize required information.
Most applications have forms to collect different data. Some of the elements on these forms are required and some are not. We tend to make more data required than we ought to. What we found is that most of the time we over think what we should make mandatory when we collect data from users. We should really question our assumptions about what we think are really necessary. We need to allow users to move forward with the minimum information and let them provide rest of the information "as and when" necessary.  We call it "on-demand incremental context-sensitive data collection." Amazon does it really well. You can start shopping without needing to login. You are prompted for login at the last possible moment. We see this also in signup process for most of the new breed of Web applications. In ScrumPad, we used to force users to pick tags when adding stories. We thought we were helping the users by forcing them to think about themes / grouping for their stories at the time of creation. Our users did not see it that way, instead they found it annoying / limiting. We changed our mind and now it is an optional element, and the users are happy!

3) Trust users, not constrain them.
We tend to design our applications around the idea that our users, if allowed, would do things that they are not supposed to. If somehow we prevent them from doing "not allowed" things through different roles, we would help them. This Also gives us a false sense of satisfaction that our applications would become more secured. This was the case with ScrumPad when we initially designed it. Scrum promotes three roles- Scrum Master, Product Owner, and the team members. As any purist would do, we segregated these roles very strictly. As a result, we were forcing our users to fit into these straight jackets and made their lives difficult. As we faced with different real world situations, we started to relax some of these constraints by allowing users to be in multiple roles. Still with that, it felt like it was a work-around rather than natural. We started to question our assumption that we need to prevent one role from doing things that usually is expected of from another role. We came up with two reasons why we do this. One, we are afraid that we won't be able to track who did what. We could easily address this concern by implementing tracking "change history." Second, we are afraid that people will be confused about what a role entails. If this is the case, then we have a bigger issue than what a tool allows us to do. However, we are certainly not suggesting that we should allow everyone to do everything. Of course, we need to draw some lines among different roles, but we should minimize them to improve user experience with our system.

4) Mange the context.
All user actions have contexts. The context depends on what action was taken just before, what role a user is in, the location a user is coming from, what time of the day it is now, etc. etc. among many other things. Most applications don't do a good job of taking all these into account and making it easier for users to perform the action. For example, if you go to "Groupon" site for the first time, it forces you to choose a city or login/signup before you can see the current deals, whereas if you go to "Livingsocial" site, it recognizes your location, and allows you to go the current deals page for that location. Which one do you think is more user-friendly? Manging the context is becoming easier and richer (with location and other contextual inputs from other connected apps- i.e. social networks) now-a-days. It is in fact expected of applications to manage the context more intelligently.

5) Personalize interactions.
Personalization has become popular among applications now-a-days. We see this commonly implemented as "My page/data/tasks," popularized by "iGoogle" type personal Web portal sites. However, it is more static in nature, and requires the users to set it up. We can harness the power of personalization even more by making this more dynamic in nature. For example, what it means in ScrumPad is keeping track of report / search queries recently run, or the projects/stories recently viewed, or discussions recently participated in, or even better, organizing menus based on the usage pattern.

6) Don't interrupt, allow "undo".
Traditionally we have designed applications with many little interruptions in the form our pop-up prompts. This form of interaction design has been popularized by Microsoft. Here is a good illustration of this by Joel Spolsky in his Business of Software conference talk. The most common and popular of such interruptions is a "delete prompt"- asking user to confirm their intent to delete something. The thought behind it is users might accidentally clicked "delete," when he did not mean to. We know these situations are rare. We are interrupting all users most of the time for those rare occasions. Google has shown how we could avoid these type of interruptions by implementing "undo." We don't have to implement/support "undo" for all users actions. Given the context and domain of the applications, we could pick and choose actions that could benefit from "undo."

7) Learn and accommodate.
We are just starting to see more and more applications are designed to learn user behaviors and adjust accordingly. An example of this is Gmail. Gmail recently introduced tracking important emails. It tries to determine whether an email is important based on the context and the past actions by the users- whether the user opens an email from a certain user or with certain subject line for example. Also the users can explicitly tell Gmail which emails are important. Overtime, Gmail gets better at isolating important emails from regular. Recommendation engine (i.e., friend recommendation, content recommendation etc.) is another example where "learning" is applied. I'll use Zynga as an example to illustrate where an application could implement "learning mechanics." We all played Zynga's one of many popular games. One thing they encourage is to post status messages from time to time to Facebook. While I understand the motivation behind this, but it provides poor experiences to users who always choose to skip posting such messages. A better thing to do would be to learn the behavior of individual users and stop prompting for posting messages for the users that always/most of the time skip such actions. Instead, Zynga could provide a visible action button to post a message, just in case these users do feel to brag once in a while.

We can summarize these 7 usability rules into just one as Jared Spool would put it- "increase goal time, reduce tool time." In other words, we should do everything we could to not require users spend time in learning & using the tool (tool time) so that they can have more time doing things that they actually want to do (goal time).

The ultimate test of usability lies in how much training users need (in-person training, or help screen casts, or help FAQs) to start using a product. "A perfectly usable product" would not need any user manual, or training, or FAQs.

Do you have any insights for improving user experience?

Monday, July 18, 2011

Using Scrum of Scrum (SoS) as an early warning system

Typically we use Scrum of Scrum (SoS) as a platform to address issues between teams on a multi-team agile projects. Mike Cohen has a good post on the basics of SoS. SoS (as the acronym aptly captures this intent) is a good way to synchronize teams and resolve issues as they arise. However, it is a reactive approach. A better approach would be to turn SoS into an early warning platform so that teams can be proactive about imminent issues and prevent them from becoming real issues. In the process save everyone "valuable" times, and probably frustrations.

With that intent in mind, I suggested the teams of a distributed Agile project that I'm coaching now to use these questions:
                         1.  Is anything slowing my team down or getting in my team's way?
                         2. Is my team about to put something in another team’s way (DB changes, interface changes, UI changes etc.)?
                         3. What stories or bugs have been completed by my team since we last met?

Question 2 primarily, and question 3 to some extent serve as the sources of early warning. However, I quickly realized that teams would not knowingly report that they are putting anything that would impede other teams. So, I changed the question to be more explicit about the intent:

                  2. Is my team going to make changes to any shared resources (DB changes, interface changes, UI changes etc.), or checking in significant codes by the end of today?

This seemed to have helped. The Scrum Masters now need to listen in their daily scrum meeting more carefully to understand and be able to answer questions 2 and 3. Additionally, the teams are also tracking any inter-team requests at the SoS meetings.

How do you use SoS on your project?

Friday, July 15, 2011

Remote team building on distributed Agile projects

Team camaraderie is important on any projects, but it is critical on Agile projects because Agile process requires close interactions. If you have distributed teams, it becomes challenging. It is important that you spend some time to make sure the teams gel together to get the best result for your Agile project.
Ideally, you would want to bring the teams together at one location for a sprint at the start of the project. The team members will get an opportunity to know each other while they start working on the project. You may want to do some explicit team building activities. Then you want to bring the teams together every so many sprints, maybe rotating the locations where they come together. Here is a nice case study on this.
Yes, it increases the cost of your project. Given how the economy is, you may not get the budget approved for the travel and associated costs. This is what happened to the project I'm working on as an Agile coach. As an alternative, we came up with a remote team building activity, which truned out to be very helpful.
Some backgorund on the teams
We wanted to faciliate a team building activity between two teams- one located in the West coast, and another in the East coast. The two teams did not know each other. This is the first time they are working together. One team was staffed by people from the client, and the other was by the vendor. As a result, there were some work culture differences. The teams were communicating through Scrum Masters and Proxy Product owners. Developers did not know each other and shyed away from communicating directly. Also getting in the way was the 3-hour time differences between the two teams. Overall, annonimity resulted in lack of trust and was contributing to the overall frustration between the teams.
Remote team building
We decided to faciliate a remote team buidling session using a vedio conferencing session. Prior to the event, we did the following:
1. We created a team profile for each team. It included some intro info about each person with a picture.
2. We paired each member of one team with another from the other team.
3. We sent them a list of questions and asked each pair to interview each other over the phone prior to the team event. A sample set of questions that we used to help prime the conversation:
                  1) What is your role on the project?
                  2) What is (are) your domain(s) of expertise?
                  3) What new capabilities are you learning on the project?
                  4) What are your pet peeves at workplace?
                 5) Tell us one interesting thing about you that no one knows.
                6) What is your favorite hobby? Why do you like it?
               Additonally we asked everyone to pick a question to ask their buddies.
4. The team event was divided into two parts. In the first part, we asked each pair to introduce their buddies to the whole team. In the second part, we made it free form (quizzed the team on what they learned about each other) with a deliberate effort to instigate conversations about things that the teams are struggling with.
Overall, everybody found the team building activity helpful. At the least, it broke the ice between the two teams, got them talking about issues (as you would expect in "storming stage" of a team/goup development), and opened up the communication. Some norms are starting to form from the storming.
I do not expect the trust to be built overnight. Still we need to continue to make deliberate efforts in making that happen. But, it was a good start. We plan to do this on a regular interval.
Some of the fun facts about these two teams
  •  One team is a all-women team.
  •  Eleven languages are spoken between the two teams.
  •  Six countries represented based on birth places.
Do you have a similar experience of team building?

Wednesday, April 20, 2011

Product backlog sedimentation pattern

Are some of your stories in your backlog moving down in priority when new stories are getting added daily and getting scheduled for implementation? Are you worried that you will never get to finish the original scope of your project? Worry no more. It is, in fact, a good sign of a healthy project.

"Backlog sedimentation" is a pattern seen on an healthy agile project where some of the high priority stories get pushed down by new stories and or lower priority stories bubble up.  As the project progresses, you start to collect these original stories at the bottom and hence the sedimentation. This is a result of active feedback at the end of every sprint from users and customers as well as the progressive learning of the team about the domain & technology, and the project.

If you are happy that your team is making a great progress towards the original scope because they are diligently working down the list of stories you originally put on the backlog, I have a bad news for you. You are most like not delivering what your customers actually want.

A great sign of a healthy Agile project is an active engagement of the users and customers. The most important sign of actively engaged customer is the quality of feedback that comes out of every review session at the end of each sprint. The outcome of a quality feedback is "new stories" that get prioritized over "existing stories".

Now the flip side of feedback is that you may find yourself only working on feedback and never get to make any progress towards the original goal (not scope, mind you). At least, it may feel like so.  I would argue that it is a sign of either "the project is not well conceived" or "the priorities are not well understood." Either way, it is a time to take a step back and have a conversation with your customers and users.

Ideally the project should reach a harmony between work done based on feedback and work done from the original scope of the project such that the project is moving towards the intended goal. That is the most important job of a successful product owner.

Have you experienced this on your project? Would love to hear how you are coping with this?