Sound familiar? The beginning of the new year is a natural opportunity to reflect on the past and make resolutions for the future. It’s common that such resolutions rarely survive the month of January, much less the entire year. Is it that we’re not disciplined or motivated enough? Not necessarily. I believe the fault lies in resolutions themselves.

Too often on New Year’s Day, we make spur-of-the-moment promises with no clear action plan of how to achieve them. Most of us expect to see a drastic change in just a few weeks when, in reality, a significant and permanent change can take months to realize.

I have personally stopped making annual resolutions; instead, I embrace the power of continuous improvement. Taking a note from my Agile software teams, I’ve taken to making numerous small changes in my life that, combined together, have a big impact. For example, I recently decided to reduce the carbohydrates and glutens in my diet. I still eat them, just less of them. It may not sound as impressive as completely cutting these foods out of my diet, but it’s a change that I can realistically sustain. Similarly, rather than committing to losing 30 pounds in a year, I have started by trying to loose 3 pounds in 30 days. By layering such incremental improvements on top of each other, I create goals I can achieve. Each small success builds momentum and the confidence that I can permanently change my lifestyle for the better.

So whether you are trying to build a great software product or just fit back into your old jeans, take an Agile approach rather than a “big bang” approach. Commit to one or two small goals at a time, measure their impact, and adjust accordingly to make them permanent features in your life. If you repeat this process over the next year, I’m very confident you will amaze yourself.

I look forward to hearing your stories of resolutions either made or broken, as well as what techniques you’ve found make a lasting difference.

Wishing you all a happy, healthy and prosperous new year!

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

T-Shirt sizing is vague technique - get rid of it

Originally I estimated stories as one, two, three, four or as small, medium, large, extra-large. It was always meant to be understood that a medium was twice the size of a small and a large was twice the size of a medium (and so on), but that never seemed to translate well when it came to planning. Then someone recommended to me that I try powers of two. Suddenly we were speaking a language that the business could understand. They knew that an 8 was significantly bigger than a 1. I believe the sizes one, two, four, eight are also much more appropriate. As stories get larger they almost always contain more unknown and risk. A powers of two scale emphasizes the risk associated with large stories.

Use four values - it helps streamlining

I was once on a project that started with 1, 2, 4, 8 as their estimation values. After the first two estimation sessions less than 5% of the stories were ones and about 30% of the stories were twos. The project manager decided to get rid of the one value because it made his life easier. An interesting thing happened at each subsequent estimation meeting, suddenly only 5% of the stories were twos and many more stories had become fours. I don’t think that the developers consciously changed their scale, but developers are conditioned to be skeptical. Few developers are willing to say with certainty that any given story will be as easy as the scale allows. After witnessing this type of behavior on a few different projects, I prefer a minimum of four point values. I also prefer a maximum of 4 point values. After all, it’s nothing more than an estimate. If you try to give too much precision to an estimate you’ll end up having to account for why you missed the mark. The idea is to get a rough idea, not a rigid plan to live off of.

No averages or numbers not on the scale

Four values allow you to get a rough estimate without spending unnecessary time focusing on precision. Sometimes a story feels larger than a two but smaller than a four. The story should not be estimated as a three. There’s really no reason to use a three. The story carries enough risk or unknowns that it is not a two; therefore, it’s very likely that it will actually be a four. Using an average or an off scale number can briefly (and unnecessarily) confuse a team member or stakeholder. Also, in the big picture of the project, the occasional uncommon estimate isn’t likely to make much of a difference. Keep it simple, stick to the scale.

Vote independently- no baising

It’s human nature to be influenced by other people. If a technical leader says a story is a two, it’s likely that the rest of the team will follow his lead. For this reason I prefer an estimation process that lets each team member vote independently. This can be done by using sheets of paper that no one reveals until everyone is ready. Another option (that I prefer) is to give your estimation rock-paper-scissors (RPS) style. In our estimation meetings we talk about a story until we are ready to estimate then we all “throw” our estimations the same as you would “throw” rock, paper, or scissors. What I mean by “throw our estimation” is that if we think it’s a 1 we point 1 finger. Likewise a 2 is two fingers and 4 is four fingers. If you need to throw an 8, you can use both hands.

Take the largest estimate - that’s the safest way

Even when reminded, developers seem to have a hard time estimating with a team in mind. If a developer thinks they can do the story in 1 day, they throw 1 finger. Unfortunately, that developer may not be available to do the story, and then some other team member is stuck working on a story that they thought was a 2 or even a 4. I prefer to always take the largest estimate thrown by any team member. You may consider this to be sandbagging, but in reality it’s likely that each team member has identified different risks and the team member with the largest estimate has probably correctly identified that there is more risk than the other members have thought of.

Taking the largest estimate has additional benefits. If you must agree on a lower estimate then the team member with the larger estimate will need to discuss why they chose a larger value. This discussion can be uncomfortable for developers who are less senior on the team. They may not know how to do something as quickly, based on limited experience with the language or tools. Their concerns are often justified by their skill level, and it would be unfortunate if they felt uncomfortable giving their true estimate because they were afraid to discuss why it was higher.

Any discussion around taking a higher or lower value may lead to the entire team raising their value, or it may lead to that developer uncomfortably lowering their estimate. Either way, you’ll need to spend more time talking and you wont have gained–in the end it’s consistency that matters. You always know how many stories you expect to get done in an iteration by tracking velocity. Therefore, even if your estimates are “bloated” so will your velocity be, thus it has no effect on planning.

Finally, taking the largest estimate can help save time in an estimation meeting. If any member of the team believes the story is an 8 he can speak up at any time while discussing the story and announce that he is going to throw an eight. Unless someone else believes that there is a large estimation gap among team members, there’s no reason to continue talking about the story since it will ultimately become an eight anyway.

Large estimate gaps - something is not right

When estimating it’s usually the exception that the entire team agrees on the size of a story. Like I previously said, I like to handle the mismatch by always taking the larger estimate. However, sometimes a large gap represents a misunderstanding. For this reason any time there is a two value gap in estimation, additional conversation always occurs (e.g. if a team member throws a 1 and another throws a 4, some clarification needs to occur). Discussing large gaps also ensures that taking the largest estimate has less chance of being abused.

Insufficient information - may lead to inaccurate estimates

On occasion a story may need leave the meeting unestimated. It’s better to ask for more information than to give an estimate that you are uncomfortable with. An estimate of 8 implies that it’s a large story, but you expect it to take twice as long as a 4. Therefore, don’t simply estimate ill-defined stories as eights, because you will likely be expected to get it done in the same amount of time as it takes to get two stories estimated as fours completed. The goal of an estimation meeting isn’t to estimate all the stories, it’s to provide estimates on the stories that provide sufficient information.

Business and Developers - the two different line of thoughts

It’s as simple as this, the business wants to know what functionality they can get in the next iteration. To know what to expect they need estimates. Since the business will not be writing the code, they cannot contribute proper estimates. The more they are involved (in the actual estimation), the less likely it is that they will receive realistic estimates. The best domain experts answer questions in meetings, but never assert in any way the level of effort it will take to complete any given story.

Estimation group size - the right number is the trick

Teams come in many different sizes. On smaller teams (6 or less) I suggest the entire team attend the estimation session. The many points of view are likely to solidify vision and positively contribute to an estimate. However, I believe there is a point of diminishing returns. Not everyone on a large team needs to be part of estimating each story. Additionally, it’s an estimate, 6 people should be just as accurate as 15 people would be. If your team is larger than 6 people I suggest breaking into smaller groups for estimation. In general I like to get at least 3 people to estimate any given story, but no more than 6.

New stories - when should they be estimated

New stories come in two forms: new feature requests and stories that split. I generally wait to estimate new stories based on their priority. If a story needs to be done in the next iteration, it generally requires an immediate estimate. However, if the new stories aren’t going to be played for several iterations it can make sense to hold off until you have enough stories to justify an estimation meeting. I find estimates from estimation meetings to be more reliable, since they come from an environment where everyone is focused solely on estimation. Stories resulting from a split provide an additional complication: they likely already have an estimate. I strongly suggest that the new stories be estimated without taking into consideration the previous estimate. If a story carried enough risk or uncertainty that it required splitting, it’s not likely that the estimate is realistic–ignore the original estimate.

Required participation - this is important

This suggestion is a very important one. In theory, no developer from outside the team should be attending an estimation session. That means that every developer that attends an estimation session will potentially be tasked with working on a story that’s being estimated. If a developer is not comfortable estimating a story, then I’m not comfortable with them working on the story. Of course, there are exceptions.

By learning how to gather requirements as user stories, I realized how agile plans are always kept up-to-date, contain only the latest and greatest information, and avoid one of the greatest wastes our industry has ever known—premature up-front analysis.

The key challenges that teams run into when they heavily rely on documentation for their software requirements are that:

• They can’t handle changes effectively
• They build according to specs instead of what the customer wants
• They make bad guess and false assumptions
• They waste a lot of time

So, Is a requirement really a requirement? If I put it in words of Kent Beck, one of the 17 original signatories of the Agile Manifesto, then the term ‘Requirement’ is just plain wrong.

“Software development has been steered wrong by the term requirement, defined in the dictionary as something that is mandatory or obligatory. The word carries a connotation of absolutism and permanence, inhibitors for embracing change. And the word “requirement” is just plain wrong.

Out of the thousands of pages used to describe requirements, if you deliver the right 5, 10 or 20 percent, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80 percent? Not requirements—they weren’t mandatory or obligatory.”

The problem with gathering requirements as documentation isn’t one of volume—it’s one of communication.

• First, you can’t have a conversation with a document
• Second, it’s just really easy to misinterpret what someone wrote

This leads us to one of the most important principles of agile:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

So, what we need is something that enables us to have a conversation about a requirement, captures the essence of what our customer wants, and is small enough for planning yet descriptive enough to remind us what we are talking about …ENTER A USER STORY

Agile user story is a short description of a promise of a conversation. Agile encourages the user stories on index cards to remind teams that the initial goal of the requirements-gathering exercise isn’t to get into all the details. It’s to write down a few key words to capture the spirit of the feature and file it away for a later date.

Why just few key words? To save us the time and energy of going all in it now and having to redo it all later, we defer diving into the low-level details until later.

User stories have to make sense to business. That’s why we always try to write them in simple terms and try to stay away from any technical jargon. It is better if we put the information in terms that business understands.

A really good user story is one that goes from end to end - slicing through all the layers of the architecture and delivers something of value. The good user stories are Independent, Negotiable, Testable, and Concise that can be Estimated easily.

A few short, well-chosen words are usually enough to remind the team about what a particular user story is about: that brings up our User Story Template in existence

AS A <USER> I WANT <GOAL> SO THAT <REASON>

The nice thing about this template is it answers three important questions about the user story: the who, the what, and the why. It gives a little more context and really emphasizes and focuses on the business, which is a good thing.

]]> http://blogs.globallogic.com/simplifying-agile-the-art-of-writing-user-stories/feed http://blogs.globallogic.com/tech-trends-for-2012 http://blogs.globallogic.com/tech-trends-for-2012#comments Thu, 29 Dec 2011 16:39:53 +0000 Peter Harrison http://blogs.globallogic.com/?p=1792 As the CEO of a software R&D services firm that focuses on new and game-changing technology, I’m often asked what technology trends I see dominating the year ahead. I have several predictions for 2012, and I thought it would be fun to share them with you and learn what trends you foresee developing in the upcoming twelve months:

1. Revenge of the Tablet: Just as Android created some serious competition for Apple with smartphones, it’s about to do the same with the tablet. 2012 will be the year when we finally see some serious alternatives to the iPad.
2. Gesture-Based TV: The last few years have seen gesture-based technology come to the phone, the tablet and the game console. Next up will be the TV. Why search for the remote when you can just snap your fingers? And why not run apps directly on your TV?
3. Machine to Machine: Next year we’ll see more and more real-world applications of M2M. Our cars already talks to the cloud; very soon anything and everything of value will.
4. Social Goes Enterprise: I predict that 2012 will be the year when most corporations start to embrace social networks and look for ways to harness their value. Think: “Who in my company knows how to optimize Android for video the best?”
5. Return of Zero Install: With the introduction of HTML5 and 4G/LTE, our tablets and smartphones will no longer be dependent on apps and app stores. We’ll be able to access an app’s functionality without the installation.
6. A Planet’s Worth of Data: With sensors showing up in everything, the amount of data we can gather and keep is exploding. What if all this data found its way back to the cloud? Well soon it will, and we’ll need BI tools that can help us understand not just a company’s worth of data, but a planet’s worth.
7. Consumerization of Healthcare: With government incentives pushing doctors from one side and patients pulling from the other, we’ll soon see an explosion of consumer-to-doctor options. We’re already seeing sites like Zocdoc change the way you schedule an appointment. A patient record that you can actually see can’t be far behind.
8. Political Apps: Technology is having an increasing impact on politics, especially elections. With the 2012 U.S. election less than a year away, you can bet this cycle will see an explosion of political apps for tablets and smartphones.
9. Voice Gets Smart: With the Siri feature on iPhone 4S, you can bet voice apps are about to get a major boost. We’ll see voice interfaces getting built into more and more devices.
10. Agile in Business: This rapid development approach, which favors continuous results over analysis paralysis, is making its way into business. Agile makes sense for companies that want to get into new markets quickly and use learning over planning as the way to “get it right.”

Since that date, I have been part of multiple teams with a wide variety of experienced team members (in one project I’ve worked with the punch card developers of the ages of 1960s). One particular project with a very small group of developers was at Liebert,Ohio. My colleagues at Liebert, and many others around the world, treated  integration as a non-event. Any individual developer’s work is only a few hours away from a shared project state and can be integrated back into that state in minutes. Any integration errors are found rapidly and can be fixed rapidly.

This contrast is not the result of an expensive or for that matter any complex tool. The essence of all of this lies in a very simple practice of everyone on the team integrating frequently, usually daily, against a controlled source code repository or any source code configuration management tool like SVN, CVS, VSS, Git, Mercurial, Perforce etc. to name a few.

This practice becomes all the more very important when teams are Agile or practice XP (extreme programming) or any such other method of development like TDD etc. Creating continuous builds for every change that’s committed into the repository becomes a matter of seconds and it also eases the troubleshooting any broken feature. There are multiple tools available in the market. The most commonly used and heard is the CruiseControl.

The story is, however, very different when it comes to mobile projects especially iOS based projects. We had a tough time initially having to come up with something that builds continuously and communicates any issue(s) found as soon as they happen. I am going to describe here in as detailed way as possible for setting up an automated process for building the apps for iOS based projects. But before we do that I think it will be wise to consider the following: Integration is primarily about communication. Integration allows developers to tell other developers about the changes they have made. Frequent communication allows people to know quickly as changes develop. The one prerequisite for a developer committing to the mainline is that they can correctly build their code. This, of course, includes passing the build tests. As with any commit cycle the developer first updates their working copy to match the mainline, resolves any conflicts with the mainline, then builds on their local machine. If the build passes, then they are free to commit to the mainline. By doing this regularly and frequently, developers quickly find out if there’s a conflict between two developers. The key to fixing problems quickly is finding them quickly. With developers committing every few hours a conflict can be detected within a few hours of it occurring, at that point not much has happened and it’s easy to resolve. Conflicts that stay undetected for weeks can be very hard to resolve. So if your team is not accustomed for this practice yet, this process is going to be more of a headache for you rather than an ease. If your developers keep their code changes for weeks for fear of losing them, it won’t work for your team.

The general rule of thumb is that every developer should commit to the repository every day. Practically it’s often more useful if developers commit more frequently than that. The more frequently you commit, the less places you have to look for conflict errors, and the more rapidly you fix conflicts. Besides it also an excellent advantage. And that is that frequent commits encourage developers to break down their work into smaller chunks of a few hours each. This helps track progress and provides a sense of progress for the entire team. Often people initially feel they can’t do something meaningful in just a few hours, but I’ve found that mentoring and practice helps them learn. This way team becomes more Agile and aligned to achievement.

Having said that we have come to the first necessity of setting up the process and that is:

1. Everyone commits to the mainline everyday.

As I make travel plans over the holiday season, I’m reminded of the technology behind Global Positioning Systems (GPS) and how it has made a huge impact on the way we interact with the world. From satellite street views to real-time functioning, GPS software has dramatically increased our ability to navigate new cities — and even new countries — with the ease of a native. Interestingly, GPS-based apps embody the Agile principles of adaptability, real-time reports and a focus on forward momentum. Let’s consider a few of the things they have in common:

Adaptability. GPS-based products work on the principle that plans are important, but continuous planning is more important. It’s not just about determining the appropriate deadline or schedule. Planning, especially in an environment where change is the only constant, is about adapting quickly to the situation. Just as GPS apps adapt to detours and other factors by quickly providing an alternate route that minimally impacts a traveler’s time and distance, so do Agile teams employ iterative planning to work around changes while still delivering high-quality products that maximize a client’s ROI.

Real-Time Reports. Kids are infamous for asking “Are we there yet?” when driving on a long trip — or even short ones, for that matter. But with GPS, they can see exactly how much longer and farther the trip will take. Similarly, I had a senior developer recently tell me at an Agile event that as soon as she transitioned to Agile principles, she no longer had people asking her “Are we done yet?” The iterative and incremental approach helped her entire team — including management — see in real-time which user stories were developed, which were in-progress, etc.

Forward Focus. GPS also takes an entirely different approach to how you view a progress report. Instead of focusing on how far you’re already gone, GPS instead keeps you updated on the distance and time you have left. Agile teams also learn to focus on how much work is left by keeping a close eye on sprint and release burn down charts. This enables them to identify how many more sprints are required to deliver the entire backlog of a product based on the team’s average velocity.

When people ask me how Agile teams work, I tell them to think about how they interact with their GPS device. Used wisely, you will spend less time planning a trip and more time actually enjoying your journey and getting towards your goal. Agile principles in turn will lead your team to a more predictable outcome; help them quickly respond to change; bring a higher level of innovation; reduce waste and minimize risk; and help you arrive at the correct destination on time and less stressed.

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

Maintenance Projects are little different than development project in the nature. They are more volatile than typical development projects. All the activities planned may or may not get executed during the sprint and there may be possibility of sudden change in priorities in the plan.

Planning for Maintenance Projects

Looking at the nature of execution, we make take few things into account while planning for maintenance projects.

• Sprint Iteration should be planned for shorter duration (ex: 1 week) to minimize the impact of unplanned movement.
• Activities can be planned into following categories:
  • Features pulled from Product backlog
  • Daily activities required during maintenance (like daily system health check-up, back up, clean up)
  • Issue fixing for known open issues identified in earlier sprints maintained in issue backlog.
  • Time planned for issue fixing which may be newly identified in this sprint (aka placeholder).  This is buffer time for fixing high issues which may be induces during the sprint. The exact time may not be planned as no. of issues is unknown but time planned is on historical data on earlier Sprints by the team.
  • Hot fix release. This needs to be derived from historical data on how much time needs to be spending if team needs to give hot fix and number of hot fixes coming up.
  • Buffer time (around 15%), Product backlog grooming (around 10%) (for upcoming sprints) and issue backlog grooming (around 10%) (for current sprint) should be considered to come up for available time.
• Definition of done should be very clear and crisp for planned activities and issues.
• Maintain a separate backlog for issues apart from normal product backlog.
• Priorities of planned activities as well as issues should be strictly prioritized by Product Owner.
• Product Owner should earlier decide on what priority issues should be picked from issue backlog.
• 50% of assigned time from placeholder time should be considered for assigning planned activities (But this should be good to have items). In case issue fixing time is consumed, there will be no harm in moving these items in next sprint.
• Daily quick meeting apart from daily stand up to absorb new issues cropped up
• Retrospective Meeting can be more focused on analysing the refinement required for grey areas for issue backlog apart from normal retrospection.

Challenges in Maintenance Projects

Usual Challenges seen in maintenance Project are:

• New issues come on the fly and can’t be completely planned.
• There can be possibility of hot fix release. Although hot fix needs to be avoided for same sprint and see if this hot fix can be planned in upcoming sprint.

Benefits of Scrum

Benefits that come along with following scrum are:

• Self-organized team having complete domain knowledge of the product
• Less management efforts in maintenance
• Reactive to high priority issues but having an eye on product backlog as well resulting into quick deliveries.
• Accommodating unknown factors of issues in maintenance.
• Good visibility for everyone and hence helping in better planning of upcoming sprints

Lastly but not least, there is no perfect way to handle the maintenance projects, but team has to evolve and together refine the processes to get the best out of them. Moreover as Scrum has always said “If you don’t know the way, try it out for one sprint and either adapt it or refine it”.

The Law of Diminishing Returns has broader implications than just economics. Imagine an engineering team is preparing to scope a project. In theory, the more time and effort the team invests in outlining the project’s tasks and timelines, the more accurate the results will be. However, in reality, the team only needs to spend a fraction of this effort to achieve adequate results. The relationship between estimate accuracy and effort look like this:

Predictive “plan-driven” teams often put so much effort into their plans that they become convinced these plans are absolute. They often fail to account for business viability and cannot respond to necessary changes, leading to increasingly elaborate and rigid controls, waste, inflexibility, misalignment, low levels of innovation, lower business value and lost ROI. Agile teams address this issue by applying two simple strategies:

1.  “80/20 Rule” or “Pareto’s Principle”: Italian economist Vilfredo Pareto observed that the distribution of wealth is predictably unbalanced, with 80% of the land being owned by 20% of the population. This observation eventually became known as the 80/20 principle and can be applied to multiple fields. For example, roughly 80% of an organization’s sales come from 20% of its clients. Similarly, 80% of the value in a software product comes from 20% of its functions. So nearly two-thirds of a product’s features are unused, which is obviously a problem. Not only is it very expensive to develop these extra features, but it adds unnecessary complexity to the code base and makes it both more difficult and costly to maintain. The outcome is often a reduced life for the software.

An Agile team, on the other hand, will apply the 80/20 principle to identify the features that are in the top 20% of the product backlog. By developing the most important features first, an Agile team delivers maximum value to the client. This method helps establish a highly collaborative environment that enables feedback, gives the team a chance to inspect their work and make the right decisions, and ensures the delivery of high-quality, incremental software releases in quicker cycles.

2.  ”Planning Poker”: Agile teams employ two levels of planning: iteration planning and release planning. Iteration planning, which is very short-term and detailed, is when a team discusses how to implement a specific feature. During release planning, a team takes a less precise and longer-term view of the project. The objective is two-fold: (1) make a ballpark estimate of the time and effort required to build the product and (2) split the product backlog into the desired set of releases. The whole team participates in this exercise and spends just enough time on estimates, all while considering inevitable uncertainties. Even if the initial estimates aren’t completely accurate, an Agile team’s plans are still more reliable because it frequently delivers small increments of fully working, tested and integrated code.

As an Agile team moves from iteration to iteration, it measures its productivity through the Agile/Scrum metric “Velocity,” which has units of story points per sprint. As a standard, team Velocity should not decrease from sprint to sprint on a rolling average basis. The idea is not necessarily delivering at a faster rate, but maintaining a sustainable pace and making reasonable commitments to clients. Planning Poker is by no means a silver bullet, but it does optimize the estimation process by reducing waste and, more importantly, relying on the collective wisdom of the team.

By employing strategies that focus on what clients value most along with plenty of collaboration, empirical Agile teams are able to quickly respond to change. This approach leads to more predictable outcomes, higher levels of innovation, reduced risks and greatly reduces the risk of either over investing or investing in the wrong plans/features thereby greatly reducing the impact of the Diminishing Return and nearly eliminating the risk of the Negative Return.

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

]]> http://blogs.globallogic.com/overcoming-the-law-of-diminishing-returns/feed http://blogs.globallogic.com/creating-the-right-environment-to-get-the-right-results http://blogs.globallogic.com/creating-the-right-environment-to-get-the-right-results#comments Mon, 03 Oct 2011 15:23:47 +0000 Peter Harrison http://blogs.globallogic.com/?p=1624 I recently read a blog entry by business consultant Peter Bregman, who talked about visiting Disneyland’s Animal Kingdom Park. He saw a lion sitting on a rock, where apparently he sat every day. When he asked the ranger how they trained the lion to sit there every day, the ranger laughed and said, “We don’t train the lion; that rock is temperature-controlled. We make it a place where he wants to be.”

Just like that theme park, corporations must focus on creating the right environment to get the results they want. When applied to software R&D companies with geographically distributed teams, this means leveraging the right tools and processes to overcome challenges such as limited real-time collaboration, unclear communication or general misalignment, location-based silos and delays caused by a lag between development and testing cycles.

Here at GlobalLogic, we must juggle these challenges every day with thousands of R&D professionals distributed across four continents and eight time zones. Creating a solution to address these issues was not easy, and it certainly did not happen overnight, but the results have been impressive. Primarily, we leverage tools and processes to create an environment where our distributed teams can connect, collaborate and innovate with each.

For example, we use a specialized collaboration platform called GlobalLogic Velocity™ to build software products in a distributed environment. This platform is invaluable because it facilitates effective communication across distributed teams and provides complete transparency into project health monitoring, risk management and progress tracking. It also reduces lags between testing and development by taking an Agile approach and running quality assurance and development cycles as parallel as possible.

We also deploy a rich, contextual social network called GLO that connects people across teams and time zones to easily find each other and share their knowledge to accelerate innovation. With GLO, people think “community” rather than “hierarchy.” It aims to promote a culture of collaboration, participation and openness that helps increase their productivity, foster new ideas and increase employee satisfaction. GLO also creates awareness of in-house capabilities, increases agility and responsiveness, accelerates communication and increases innovation.

Finally, we recently developed an innovation-focused platform and rewards system called GLIDE that encourages new ideas. This “ideation platform” collects, validates, sustains and implements ideas in a crowd-sourced environment for new businesses, products, processes and improvements on existing products and processes. GLIDE is an open innovation model, where the community decides what is valuable, encouraging individuals at all locations and positions to really think outside the box.

GlobalLogic has experienced a positive track record of success in both delivering quality technology products and providing clients with a high degree of innovation. I wholeheartedly believe this success is in part a result of creating a connected infrastructure where our global teams are constantly communicating and collaborating with each other and have real-time visibility into each other’s work. In short, we’ve created the right environment to get the results we need to be in the right place at the right time.

To read more about how to create a global culture of innovation within your own organization, I encourage you read my colleague Shashank Samant’s recent article on SandHill.com:

http://sandhill.com/article/practical-steps-for-building-a-global-culture-of-innovation/

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

Directions
Before your meeting, draw a 2×2 matrix on a large white board or poster. Label the axes as followed:

• 2 left cells – Urgent
• 2 right cells – Not urgent
• 2 top cells – Important
• 2 bottom cells– Not important

After describing the matrix to your participants, hand out pens and plenty of sticky notes. Allow 5 – 10 minutes for participants to write to-do items on the post-its: one per note. Once everyone is finished, have players present their tasks to the group. Collaborate as a team to identify where each to-do item should be placed on the matrix.

Keep in mind the value of each cell:

• Cell 1: Urgent, important – these tasks should be at the top of your to-do list
• Cell 2: Not urgent, important – these items are likely to be neglected, but are necessary for long-term success. Set aside time each week to focus on these in order to be more productive. We suggest making this cell a different color so you will remember its significance.
• Cell 3: Urgent, not important – these tasks suck your time and are often the result of poor-planning. They should be minimized or eliminated.
• Cell 4: Not urgent, not important – these items are trivial time-wasters that should be eliminated

Write down the new order of your to-do list, but make sure to take a picture of the chart or leave it up so you can refer back to it. Avoid creating a long, intimidating to-do list by breaking it down into smaller lists. For example, consider creating a task sheet for each person or a group list for each day or week.

Collaborate to clarify the value of the items and to identify which team members will be responsible for each task. Delegation is an integral part of time management. Rather than assuming everyone will work together on each item, you must assign tasks in order to prevent social loafing. This way, people will feel more responsible for certain items and will accomplish them more efficiently.

Play Merrill Covey Matrix Online

Now you can play Merrill Covey Matrix instantly online! Clicking on the picture to the right will start an “instant play” game at innovationgames.com. Here, this image will be used as the “game board.” The chart is organized the same way as the in-person version, and the second cell is highlighted yellow to remind you of its importance. However, instead of post-it notes, there will be two different icons that players can drag onto the chart and describe to represent the tasks:

• Green squares – priority tasks that require attention
• Red squares – tasks to minimize/eliminate

All moves can be seen in real time by each participant, so everyone can edit the positions and descriptions of the icons. Also, the integrated chat facility allows you and your players to collaborate to form the most efficient to-do list.

Bottom Line
While we are all busy working through our to-do lists, we may not be doing so as efficiently as we think. Play Merrill Covey Matrix to identify the purpose and value of your tasks and to minimize or eliminate time-wasters. Plan ahead to avoid unproductive busy work and to accomplish your goal in a productive manner.