Agile Retrospective is one of the best ways to convert a good team in to a great one. When we say retrospective, here is what we have in mind: A special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole team learning, act as catalysts for change, and generate action. Retrospectives go beyond checklist project audits or perfunctory project closeouts. And, in contrast to traditional postmortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so.

Suppose you are a member of a software development team. You are doing good work, but not great work. You are starting to see signs of interpersonal friction on the team, and some people you would like to retain on the team are dusting off their resumes. You know you need to adapt your practices and ease the interpersonal tension before things get worse. You want to introduce retrospectives to your team.

In internet you will find lots of new ways and new twists of old ways to lead a successful retrospective. But we should always return to the basic structure which we will discuss today. This structure can fit into an hour or expand to three days. You can add variety by adding new activities, but stick to this basic outline—this structure does what a retrospective needs to do. There are five steps which belongs to this structure.

  1. Set the stage.
  2. Gather data.
  3. Generate insights.
  4. Decide what to do.
  5. Close the retrospective.

Here is the timing for each step for a two hours long retrospective:


Percentage (%)

Time (Minutes)

Set The Stage


6 Minutes

Gather Data

30 – 50%

40 Minutes

Generate Insights

20 – 30%

25 Minutes

Decide What To Do

15 – 20%

20 Minutes

Close The Retrospective


12 Minutes

Shuffle Time

10 – 15%

17 Minutes



120 Minutes

Set The Stage

Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective. And, it contributes to creating an atmosphere where people feel comfortable discussing issues. You can start with a simple welcome and appreciation for people’s investment of time. Restate the purpose of the retrospective and the goal for the session. Remind people of how long you will meet. Then ask everyone in the room to speak. When someone does not speak at the beginning of the retrospective, that person has tacit permission to remain silent for the rest of the session. Since the point of the retrospective is to help the group thinks and learns together, you need everyone’s participation. Next, outline the approach for the session. Time is precious, and people want to know that their time will be well spent. Knowing the approach helps establish that this would not be another aimless meeting.

Gather Data

It may seem silly to gather data for an iteration that lasted a week or two. But when someone misses one day in a weeklong iteration, they have missed 20% of the events and interactions. Even when people are present, they do not see everything, and different people have different perspectives on the same event. Gathering data creates a shared picture of what happened. Without a common picture, individuals tend to verify their own opinions and beliefs. Gathering data expands everyone’s perspective. You can start with the hard data: events, metrics, features or stories completed, and so forth. Events can include meetings, decision points, changes in team membership, milestones, celebrations, adopting new technologies—any event that had meaning to someone on the team. Metrics include burndown charts, velocity, defect counts, number of stories completed, amount of code refactored, effort data, and so forth. Encourage people to refer to team calendars and other artifacts—documents, emails, charts—to add to the picture.

Generate Insights

Now is the time to ask “Why?” and begin thinking about what to do differently. When generating insights, the team considers the data to identify strengths and issues from the previous iteration. Lead the team to examine the conditions, interactions, and patterns that contributed to their success. Investigate breakdowns and deficiencies. Look for risks and unexpected events or outcomes. It is easy for people to jump to solutions once problems emerge. First solutions may be correct, but often they are not. The work of this phase is to consider additional possibilities, look at causes and effects, and think about them analytically. It is also a time for the team to think together. These insights help the team see how to work more effectively—which is the ultimate goal of any retrospective. Generating insights allows the team to step back, see the big picture, and delve into root causes. When you skip generating insights, your team may not understand how events, behaviors, and circumstances affect their ability to develop software. Time spent generating insights helps ensure that when your team plans an improvement, it is one that will make a positive difference.

Decide What To Do

At this point, the team has a list of potential experiments and improvements. Now is the time to pick the top items (usually no more than one or two for an iteration) and plan what to do. Your primary job is to provide structure and guidance for your team to plan experiments and actions. Sometimes teams come up with long lists of candidate improvements; but too many initiatives can overwhelm your ability to change. Pick one or two experiments for the next iteration. Help your team choose items that they can commit to and that will have a positive effect. If your team is recovering from a change that was stressful, help them choose something less complex this time. Taking action during the retrospective builds momentum. Whether you finish planning in the retrospective or incorporate actions into iteration plans, be sure that people sign up and commit to tasks. Without individual commitment, people assume that “the team” will do the task, and no one does it.

Close The Retrospective

All good things come to an end, even retrospectives. End the retrospective decisively: do not let people (and their energy) dribble away. Decide how to document the experience and plan for follow-up. Help your team decide how they will retain what they have learned from the retrospective. Track new practices with posters or big visible charts. Use a digital camera or hit the Print button on that printing white board to create a visual record. The learning belongs to the team, and team members: not the coach, not the team lead, and not you as the retrospective leader. The team needs to own them. Close the retrospective with an appreciation for the hard work everyone did both during the iteration and during the retrospective. Before you end, take a few minutes to perform a retrospective on the retrospective. Look at what went well and what you could do differently in the next retrospective. “Inspect and adapt” applies to retrospectives, too.

Though I described five steps here but there is another sixth step which is the most important one. That is called “Follow-up”. You did the retrospective on Friday. Then you went home for the weekend. You came back on Monday and your boss is like we must build the product and deliver by this week. And you forget everything you discussed in the retrospective. Your only focus is to get the job done. So everything goes for a toss. So you must follow-up the decisions taken in the retrospective.

Retrospectives can be a powerful catalyst for change. A major transformation can start from a single retrospective. Incremental improvement is important, too. Celebrate it. It is more than many teams ever achieve.

DevOps is one of the hottest topics in the technical world for some time now. When I tried to dig out the real reason behind it, I came to know that it is because it hurts the most. I always believe that the thing you should fix first is what hurts you the most. Historically, the inability to produce code that our users wanted within budget and in a timely manner was the biggest pain.  Development took months, if not years, and at the end of all that time and effort, what we delivered was not what our users expected. Our development process had to be fixed first because that was what hurt most then. Because the process of software development was so bad, the quality of the code was also in question. So the need for innovation on the system side of technology work was increasing. And then a giant was born: DevOps.

When I tried to search and find out the real definition of DevOps, I found out hundreds of different ones. Some of them are really long. But if you ask me personally, I would go for one of the simplest ones to define DevOps.

DevOps is the union of People, Process, and Products to enable Continuous Delivery of Value to our End Users.”

The writer is very deliberate in the terms used in this definition. He chooses value over software. DevOps is not just automating a pipeline so we can quickly deliver software. Our goal is to deliver value. The term “End Users” was also very carefully chosen. The value we produce must reach our end users. If the value only reaches the Development and QA environments but is held up before reaching production where it can be realized by our end users, we are still failing.

It is very important to realize that DevOps is not a product. You cannot buy DevOps and install it. DevOps is not just automation or infrastructure as code. DevOps is people following a process enabled by products to deliver value to our end users.

The best way to define DevOps in depth is to use a parallel method to the definition of a similarly complex term, agile development.  Agile development, according to the agile manifesto, consists of four different “levels” of concern.

Agile Values: Top level philosophy, usually agreed to be embodied in the Agile Manifesto. These are the core values that inform agile.

Agile Principles: Generally agreed upon strategic approaches that support these values.  The Agile Manifesto cites a dozen of these more specific principles. You do not have to buy into all of them to be Agile, but if you do not subscribe to many of them, you are probably doing something else.

Agile Methods: More specific process implementations of the principles.  XP, Scrum, your own home-brew process – this is where the philosophy gives way to operational playbooks of “how we intend to do this in real life.” None of them are mandatory, just possible implementations.

Agile Practices: Highly specific tactical techniques that tend to be used in conjunction with agile implementations.  None are required to be agile but many agile implementations have seen value from adopting them. Stand-ups, planning poker, backlogs, CI, all the specific artifacts a developer uses to perform their work.

DevOps Values: I believe the fundamental DevOps values are effectively captured in the Agile Manifesto – with perhaps one slight emendation to focus on the overall service or software fully delivered to the customer instead of simply “working software.”

DevOps Principles: There is not a single agreed upon list, but there are several widely accepted attempts. “Infrastructure as code” is a commonly cited DevOps principle. I personally believe that DevOps at the conceptual level is mainly just the widening of Agile’s principles to include systems and operations instead of stopping its concerns at code check-in.

DevOps Methods: Some of the methods here are the same; you can use Scrum with operations, Kanban with operations, etc. (although usually with more focus on integrating ops with dev, QA, and product in the product teams). There are some more distinct methods, like Visible Ops-style change control and using the Incident Command System for incident response. The set of these methodologies are growing; a more thoughtful approach to monitoring is an area where common methodologies have not been well defined, for example.

DevOps Practices: Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration management, metrics and monitoring schemes, a tool chain approach to tooling. Even using virtualization and cloud computing is a common practice used to accelerate change in the modern infrastructure world.

In the end, DevOps is a little tricky to define, just like its older brother Agile. But it is worth doing. “I do what Scrum book says so I am doing Agile” is as erroneous as “I am using Chef so I am DevOps”. To be a successful Agile or DevOps practitioner it is really important to understand all the layers that go into it, and what a given DevOps implementation might contain or not contain. In the end, what DevOps hopes to bring to Agile is the understanding and practice that software is not done until it is successfully delivered to a user and meets their expectations around availability, performance, and pace of change.

In the course of my experience working with several teams in multiple complex projects, two critical truths have become clear to me. First, genuine teamwork in most organizations remains as elusive as it has ever been. Second, organizations fail to achieve teamwork because they unknowingly fall prey to five natural but dangerous pitfalls, which I call the five dysfunctions of a team.

These dysfunctions can be mistakenly interpreted as five distinct issues that can be addressed in isolation of the others. But in reality they form an interrelated model, making susceptibility to even one of them potentially lethal for the success of a team. A cursory overview of each dysfunction, and the model they comprise, should make this clearer.


  1. The first dysfunction is an Absence of Trust among team members. Essentially, this stems from their unwillingness to be vulnerable within the group. Team members who are not genuinely open with one another about their mistakes and weaknesses make it impossible to build a foundation for trust.
  2. This failure to build trust is damaging because it sets the tone for the second dysfunction: Fear of Conflict. Teams that lack trust are incapable of engaging in unfiltered and passionate debate of ideas. Instead, they resort to veiled discussions and guarded comments.
  3. A lack of healthy conflict is a problem because it ensures the third dysfunction of a team: Lack of Commitment. Without having aired their opinions in the course of passionate and open debate, team members rarely, if ever, buy in and commit to decisions, though they may feign agreement during meetings.
  4. Because of this lack of real commitment and buy-in, team members develop an Avoidance of Accountability, the fourth dysfunction. Without committing to a clear plan of action, even the most focused and driven people often hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team.
  5. Failure to hold one another accountable creates an environment where the fifth dysfunction can thrive. Inattention to Results occur when team members put their individual needs (such as ego, career development, or recognition) or even the needs of their divisions above the collective goals of the team.

And so, like a chain with just one link broken, teamwork deteriorates if even a single dysfunction is allowed to flourish.

Another way to understand this model is to take the opposite approach—a positive one—and imagine how members of truly cohesive teams behave:

  1. They trust one another.
  2. They engage in unfiltered conflict around ideas.
  3. They commit to decisions and plans of action.
  4. They hold one another accountable for delivering against those plans.
  5. They focus on the achievement of collective results.

If this sounds simple, it’s because it is simple, at least in theory. In practice, however, it is extremely difficult because it requires levels of discipline and persistence that few teams can muster.

Before diving into each of the dysfunctions and exploring ways to overcome them, it might be helpful to assess your team and identify where the opportunities for improvement lie in your organization.

Not DevOps

I am seeing around me that lots of people have a serious misconception about what is DevOps and what it is actually not. So today let us try to figure out what is not DevOps.

Not NoOps

It is not “They are taking our jobs!”  Some folks think that DevOps means that developers are taking over operations and doing it themselves.  Part of that is true and part of it is not.

It is a misconception that DevOps is coming from the development side of the house to wipe out operations – DevOps, and its antecedents in agile operations, are being initiated out of operations teams more often than not.  This is because operations folks have realized that our existing principles, processes, and practices have not kept pace with what is needed for success.  As businesses and development teams need more agility as the business climate becomes more fast paced, we have often been providing less as we try to solve our problems with more rigidity, and we need a fundamental reorientation to be able to provide systems infrastructure in an effective manner.

Now, as we realize some parts of operations need to be automated, that means that either we ops people do some automation development, or developers are writing “operations” code, or both.  That is scary to some but is part of the value of the overall collaborative approach. All the successful teams I have come across have both people with deep dev skill sets and deep ops skill sets working together to create a better overall product. And I have yet to see anyone automate themselves out of a job in high tech – as lower level concerns become more automated, technically skilled staff start solving the higher value problems up one level.

Not (Just) Tools

DevOps is also not simply implementing a set of tools.  One reason why I feel that a more commonly accepted definition of DevOps is needed is that having various confusing and poorly structured definitions increases the risk that people will pass by the “theory” and implement the processes or tools of DevOps without the principles in mind, which is definitely an anti-pattern. Automation is just the exercise of power, and unwise automation can do as much damage as wise automation can bring benefit.

Similarly, Agile practitioners would tell you that just starting to work in iterations or adopting other specific practices without initiating meaningful collaboration is likely to not work out real well. Sure, a tool can be useful in Agile (or DevOps), but if you do not know how to use it then it is like giving an assault weapon to an untrained person.

But in the end, fretting about “Tools should not be called DevOps” is misplaced. Is poker planning “Agile” in the sense that doing it magically gets you Agile?  No.  But it is a common tool used in various agile methodologies, so calling it an “Agile Tool” is appropriate. Similarly, just because DevOps is not just a sum of the tools does not mean that tools specifically designed to run systems in accordance with a DevOps mindset are not valuable.

Not (Just) Culture

Many people insist that DevOps “Is just Culture” and you cannot apply the word to a given principle or practice, but I feel like this is overblown and incorrect. Agile has not helped thousands of dev shops because the work on it stopped at “Culture,” with admonitions to hug coworkers and the lead practitioners that identified the best practices simply declaring it was all self-evident and refusing to be any more prescriptive. We might be able to figure out all those best practices ourselves given the cultural direction and lots of time to experiment, but sharing information is why we have the Internet.

Not (Just) Devs and Ops

In the end, it’s not exclusionary.  Some people have complained “What about security people!  And network admins!  Why leave us out!?!”  The point is that all the participants in creating a product or system should collaborate from the beginning – business folks of various stripes, developers of various stripes, and operations folks of various stripes, and all this includes security, network, and whoever else.  There are a lot of different kinds of business and developer stakeholders as well; just because everyone does not get a specific call-out (“Don’t forget the icon designers!”) does not mean that they are not included. The original agile development guys were mostly thinking about “biz + dev” collaboration, and DevOps is pointing out issues and solutions around “dev + ops” collaboration, but the mature result of all this is “Everyone Collaborating”. In that sense, DevOps is just a major step for one discipline to join in on the overall culture of agile collaboration that should involve all disciplines in an organization. So whoever is participating in the delivery of the software or service is part of DevOps.

Not (Just) A Job Title

Simply taking an existing ops team and calling them “The DevOps Team” does not actually help anything by itself; neither does changing a job title to “DevOps Engineer.” If you do not adopt the values and principles above, which require change at an overall system level not simply within a given team, you would not get all the benefits.

However, I am not in the camp that rails that you cannot have DevOps in a job title. It is often used in a job title as a way to distinguish “New style DevOps-thinking, Automation-first, Dev-collaborating, CI-running, System Admin etc.” from “grouchy back room person who aggressively does not care what your company does for a living.” Some people find value in that, others do not, and that is fine.

Not Everything

Sometimes, DevOps people get carried away and make grandiose claims that DevOps is about “Everything Everywhere!” Since DevOps plugs into the overall structure of a lot of lean and agile thinking, and there are opportunities for that kind of collaboration throughout an organization, it is nice to see all the parallels, but going and reengineering your business processes is not really DevOps per se.  It is part of an overall, hopefully collaborative and agile corporate culture, but DevOps is specifically about how operations plugs into that.  Some folks overreach and end up turning DevOps into a super watered down version of Lean, Agile, or just love for everyone. Which is great at the vision level, but as you march down the hierarchy of granularity, you end up mostly dealing with operational integration – other efforts are worrying about the other parts. But there are still a lot of unsolved problems around the delivery of software and maintenance of services and making it fast, reliable, secure, et al. – if someone wants to use what they have learned from DevOps to go be a larger scope corporate consultant that is fine, but most people involved in DevOps are technical practitioners who are looking for better ways to do their job, not someone else’s.  In Agile there is “Agile Software Development” and then there is the larger Agile organization work. I think DevOps is best defined as “Agile Software Delivery and Operations,” which should similarly work in concert with others working on larger organizational initiatives, but without losing sight of its primary value proposition for the organization.

We all .Net developers use Microsoft Visual Studio 2005/2008/2010. We do lots of operation/action in the visual studio by clicking mouse on the icon though Microsoft provides us shortcut keys for those actions. Now a general question may raise that why we need those shortcuts when I have the mouse and I can easily click on the icon within a second. Believe me, as a .Net developer I am telling you if you use some common shortcut regularly your development time will be decreased by at least 10% – 12%. I am not expressing this information from my imagination. I myself experimented this situation several times. So guys start using shortcuts from today.

  1. CTRL + M, L (Toggle all outlining): Toggles all previously collapsed outlining regions between collapsed and expanded states.
  2. CTRL + M, P (Stop outlining): Removes all outlining information from the whole document.
  3. CTRL + K, C (Comment selection): Inserts // at the beginning of the current line or every line of the current selection.
  4. CTRL + K, U (Uncomment selection): Removes the // at the beginning of the current line or every line of the current selection.
  5. CTRL + K, D (Format document): Formats the current document according to the indentation and code formatting settings specified on the Formatting pane under Tools | Options | Text Editor | C#.
  6. CTRL + SHIFT + N (New project): Displays the New Project dialog box.
  7. CTRL + SHIFT + 0 (Open project): Displays the Open Project dialog box, where existing projects can be added to the solution.
  8. SHIFT + ALT + C (Add class): Displays the Add New Item dialog box and selects Class template as default.
  9. SHIFT + ALT + A (Add existing item): Displays the Add Existing Item dialog box, where existing files can be added to the current project.
  10. CTRL + SHIFT + A (Add new item): Displays the Add New Item dialog box, where a new file can be added to the current project.
  11. CTRL + K, W (Complete Work Intelligence): Completes the current word in the completion list.
  12. CTRL + K, I (Quick info): Displays the complete declaration for the specified identifier in your code in a Quick Info tooltip.
  13. CTRL + K, P (Parameter info): Displays the name, number, and type of parameters required for the specified method.
  14. CTRL + K, R (Find all references): Displays a list of all references for the symbol selected.
  15. F12 (Go to definition): Navigates to the declaration for the selected symbol in code.
  16. F7 (View Code): Displays the selected item in Code view of the editor.
  17. SHIFT + F7 (View designer, View markup): Switches between Design and Source views for the current document
  18. CTRL + W, C (Class view): Displays the Class View window.
  19. CTRL + W, D (Definition window): Displays the Code Definition window.
  20. CTRL + W, E (Error list): Displays the Error List window.
  21. CTRL + W, O (Output): Displays the Output window, where status messages can be viewed at run time.
  22. CTRL + W, P (Properties window): Displays the Properties window, which lists the design-time properties and events for the currently selected item.
  23. CTRL + W, S (Solution explorer): Displays Solution Explorer, which lists the projects and files in the current solution.
  24. CTRL + W, X (Toolbox): Displays the Toolbox, which contains controls that can be included or used with your code.
  25. CTRL + W, L (Server explorer): Displays Server Explorer, which lets you view and manipulate database servers, event logs, message queues, Web services, and other operating system services.
  26. CTRL + TAB (Next document window navigation): Displays the IDE Navigator, with the first document window selected.
  27. CTRL + D, C (Debug callstack): Displays the Call Stack window, which displays a list of all active methods or stack frames for the current thread of execution.
  28. CTRL + D, I (Debug immediate): Displays the Immediate window, where expressions can be evaluated.
  29. CTRL + D, Q (Debug quickwatch): Displays the QuickWatch dialog box that has the current value of the selected expression.
  30. F5 (Debug start): Launches the application under the debugger based on the settings from the startup project. When in Break mode, invoking this command will run the application until the next breakpoint.
  31. SHIFT + F5 (Stop debugging): Stops running the current application under the debugger.
  32. F9 (Toggle breakpoint): Sets or removes a breakpoint at the current line.
  33. F10 (Debug step into specific): Executes the next line of code, but does not follow execution through any method calls.
  34. F11 (Debug step into): Executes code one statement at a time, following execution into method calls.
  35. CTRL + D, W (Watch): Displays the Watch window, which displays the values of selected variables or watch expressions.
  36. CTRL + F9 (Enable breakpoint): Toggles the breakpoint between disabled and enabled.
  37. CTRL + R, E (Encapsulate field): Displays the Encapsulate Field dialog box, which allows creation of a property from an existing field and updates all references to use the new property.
  38. CTRL + R, I (Extract interface): Displays the Extract Interface dialog box, which allows creation of a new interface with members derived from an existing class, struct, or interface.
  39. CTRL + R, M (Extract method): Displays the Extract Method dialog box, which allows creation of a new method from the selected code.
  40. F6 (Build solution): Builds all the projects in the solution.

Search Engine Optimization is a very interesting and important topic in the World Wide Web. After all, everybody wants to rank higher and come up on the first page of Google search and get more traffic. I have identified some SEO practices. These simple SEO techniques if practiced properly can make a significant difference as to how your pages are ranked in the Search Engine Queries.

  1. Use rel=”nofollow” tag on low value links to not pass the page rank juice. For example ‘Read the rest of the entry’, ‘About’, ‘Contact’ etc.
  2. Use proper anchor text for interlinks. Don’t use ‘here’ or ‘there’.
  3. Optimize the images, always create alt tags and write description in the alt tag.
  4. Use search engine friendly permalinks. Make sure the URLs do not have ‘&’, ‘?’, ‘!’ etc characters.
  5. Use hyphens (-) between words to improve readability.
  6. Do not use underscores (_), use hyphens (-) instead.
  7. Do not use session id in URLs.
  8. Use sticky posts.
  9. Use tag clouds.
  10. Have a category description paragraph.
  11. Let the visitors subscribe to category specific RSS feed.
  12. Use internal linking when possible and appropriate.
  13. Use sub-directories rather than sub-domains when possible. Sub-domains do not share link love from the main domain as it is treated as a different domain.
  14. Research the target audience and aim the site content appropriately.
  15. Keep the content up to date. Visitors don’t like outdated content. Updating the content frequently also attracts the Search engines spiders to index the web pages frequently.

Here is something worth knowing if you have a mobile phone.

Have you ever wondered why phone companies don’t seem interested in trying to prevent the theft of mobile phones? If you have ever lost, or had one stolen, and if you are on a plan, you still have to pay the plan approximately up to 24 months, and you have to buy another handset and/or enter into another contract. This is more revenue for the phone company. There is a simple way of making lost or stolen mobiles useless to thieves and the phone companies know about it, but keep it quiet.

To check your mobile phone’s serial number, key in the following on your phone:

star-pound-zero-six-pound ( * # 0 6 # ) and a fifteen digit code will appear on the screen.

This is unique to your handset. Write it down and keep it in a safe place. If your mobile phone get stolen, you can phone your service provider and give them this code. They will then be able to block your handset, so even if the thief changes the sim card, your phone will be totally useless.

You probably won’t get your phone back, but at least you know that whoever stole it can’t use/sell it either. If everybody do this, then all the thieves will also come to know that there would be no point in stealing mobile phones as they can’t use/sell those stolen mobile phones. So start it now and spread the news.