No, remote access should not mean less control. It admins need to examine the problem as quickly as possible but conflicting to user expectations, it's not possible always. Remote access tools are the solution to these problems. Tools like GoToMyPC, LogMeIn, TeamViewer are the quite popular which provides remote access, control and support. But apart from this, remote IT administration is also needed i.e., capability to diagnose the system even before connecting to the server. Microsoft provides such ‘manual’ remote control tools. Goverlan is also one such tool which provides remote troubleshooting. Read more here: http://www.infoworld.com/article/3021938/systems-management/it-admins-remote-doesnt-have-to-mean-less-control.html

Cloud is the new buzz word. Nowadays, more and more people are willing to shift to the cloud. There are too many paths available for this journey and each path which does appear to be good, might not result in a successful decision. So people need to consider more details than they actually thought. The first step is to categorize types of workload that one wishes to migrate. These are not the applications, but the patterns of processing the applications. Some of the patterns may be - Database-intensive; Compute intensive or; User interface- intensive. If you have, say 200 applications, then, place each application in one of these categories and you will end up dealing with 3 categories rather than 200 applications. Doing so, you will be able to select proper cloud configuration to service your applications. This approach will help you in saving time and money. Read more at: http://www.infoworld.com/article/3016559/cloud-computing/the-right-way-to-migrate-to-the-cloud.html

There is a prediction that by 2017, 33% of Fortune 100 companies will experience information crises due to lack of adequate testing measures. To prevent this, the robust testing approach must be used. Developing a well-planned data warehousing, testing process will help in minimizing such risks. And while moving to agile, we can do more testing in comparison to traditional projects. The testing being done during development in parallel aids to agile development, because development and testing can be completed in a single sprint. The roadmap for building agile data warehouse will consist of following steps-

·         Build business conceptual model

·         Grass roots Data governance

·         High-level architecture with repeatable design patterns

·         Strong testing tools

·         Robust data quality program

·          Self-managing teams.

Read the full article here http://www.cio.com/article/3012097/data-warehousing/take-testing-seriously.html

We all have heard Time is money. Speed is one of the most important factors which determines cost in IT industry. So here are the five actions which will increase speed and productivity and will result in great potential success.

1. Integrated service play.

2. Establish a new strategic intent driven by business rather than function.

3. Reorganize the computer structure by making cross functional teams that work across different disciplines.

4. Invest in the appropriate and technologies.

5. Consider options for renting with technologies like cloud. Read the full article here: http://www.cio.com/article/3022757/it-strategy/5-moves-to-make-your-it-group-more-responsive-to-business-demands.html

A research was done in 2015 where purchase decisions of 20,000 European citizens, across 30 product areas and more than 100 brands in the year 2013 and 201 were examined. They were asked how social media influenced their purchasing decisions.  It was observed that social media recommendations induced an average of 26% of sales. It was found that consumers made 10% more purchases on 2014 in comparison to 2013. Moreover, the choice of product also played a vital role. For example, 40 to 50% of consumers look for social recommendations for categories like travel, investment services, etc., whereas only 15% recommendations were looking for low end utility services. So we can see that Social media does play a vital role in brand awareness and hence end up converting to the sales. Read the full article here: http://www.mckinsey.com/insights/marketing_sales/getting_a_sharper_picture_of_social_medias_influence

In today's world Data Scientist is the most- desired workers in IT industries. Since the demand for such skills is high, this has become a desired job for the potential candidates as well. So here are some skills which will increase your chances of hiring, if you want to become a Data scientist - SQL, Hadoop, Python, Java, and R. Not only these, but MapReduce, Hive and Pig skills which will increase your desirability as a data scientist. So, gear yourself up and start working and learning these skills to become a data scientist. Read more at: https://adtmag.com/articles/2016/01/08/data-science-skills.aspx

I found this interesting article which described transformation to Agile using a metaphor of the train's journey. Source and destination points are described as process initiation phase and successful completion of the process. An agile coach is the driver of the train which leads the transition. This approach made sure that Agile coaches were available at the right time and helped coaches transforming 800-900 individuals per year with the help of 10 agile coaches. There were certain steps followed by each team- Agile introduction workshop, Management Start-up, Training and Start-up, Warm-up, Ongoing support, and evaluation. But this metaphor was used in the starting days of Agile. In the present time, we need something faster than a train. So, how about a racing car? Why? Because, it’s fast and will help the team in understanding the need to respond rapidly to changes. Read more at: : https://www.scrumalliance.org/community/articles/2016/january/travelling-without-moving

Yes! Agile is for everyone, not just for IT industry, though it has become a misconception because it is majorly implemented in IT world only. Let's just understand what is agile. Agile is a framework which helps in problem solving with use of teamwork, with main focus and priority for delivery and a constant effort on finding ways to improve the quality of work and the product.  So this can apply whether you are building software, a toothpaste, a dam, or managing a restaurant. There are some things which surely must be kept in mind while considering a shift to agile. Like, what am I really trying to build or achieve? How do I create a creative environment where the right people on the team? How to keep focused on the agenda? How do I measure progress? How to increase feedback and learning cycle? If you can answer these questions considering your business, then, welcome to the agile world! Read more at - https://adtmag.com/articles/2015/07/06/does-agile-apply-to-you.aspx

We often get placed or appointed for roles which we don’t want to pursue after few years but it’s not so easy to change the line of course. For example, if you are part of the technical team, it is not easy for you to switch to the managerial team. But the organizations must understand that rather than appointing people to work or designating work, they sometimes should create vacuum holes. By vacuum holes, I mean an opportunity which is open to all to work on. But then this might create a problem that everyone would want to work in some profile which they love and the actual work which is to be done will lose its priority. So the company should make policies to balance the two things. For example in Google, an employee can invest 20% of his/her work hours to do something he/she likes to do. So rather than appointing work, companies should create a vacuum and should see who steps up to fill it in.  Read the complete article by Mike Cohn (Founder of Mountain Goat Software) at: https://www.mountaingoatsoftware.com/blog/leave-work-unassigned-and-see-who-steps-forward

Interviewing a ScrumMaster is pretty much similar to interviewing any other employee but there are certain attributes which must not be neglected. They are :

• ·         Responsible: Its Scrummaster’s responsibility to bring the best out of each team member.
• ·         Humble: ScrumMaster must work with “we” ideology rather than “I”
• ·         Collaborative: SrumMaster must ensure a collaborative environment where anybody can raise questions.
• ·         Committed: ScumMaster must be committed to success of the project
• ·         Influential: ScrumMaster leads the team without direct authority, so they must be influential.
• ·         Knowledgeable: having the knowledge of the domain or the project is a big plus

To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/advice-for-interviewing-scrummasters

Two main goals of Agile Sprint are building new functionality and building new knowledge. Building new functionality seems obvious for sprints, but teams also need to focus on building knowledge.  Each sprint should end smartly from its inception.  A UI designer should focus on both of these goals. Within a sprint, a UI designer helps in coding and testing of his/her design while simultaneously, he/she focuses on the next design feature to be built. A UI designer's top priority should be working in the current sprint. If a developer or tester needs any clarification regarding the design than he/ she should immediately halt the work and attend to their queries. But then one might say that every member of the team does so. Be its analysts, architects, database designers. The difference lies in the amount. Designers spend majority of time in building knowledge. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/incorporating-ui-design-in-scrum-sprints

Generally, product owners' role is to tell WHAT TO BUILD instead of HOW TO BUILD it. But there are some situations when product owner must specify some architectural decisions. Let's consider a scenario, years ago; when Sun was looking for the ways to promote Java, they paid companies who made certain applications using Java. But, such decisions should not be taken regularly. Product owner can decide what hardware pieces to be used to make the product economically viable. So product owner can dictate architectural decisions, but they should take good care and should make decisions sparingly, wisely and ideally. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/can-a-product-owner-dictate-the-architecture

Agile teams must embrace change. After all, that is what agile means, right? Accommodating changing customer's requirement… But the stakeholders or customers must also understand that nothing comes for free in the world. So are changes. They have a cost related to them. Scrum works on a rule that once the required changes are fully stated, a sprint begins. And no changes are allowed into a sprint. Once a sprint is started, it’s not disturbed and the team’s entire focus is on selected work. This is good and works efficiently, but can sometimes backfire. The customer can question that the foundation of being agile is to welcome changing requirements. Well, yes, but they aren’t free. Customers must understand that changes introduced beyond a certain point have a cost related to them. And both the customers and organization should work together to optimize results with the minimum cost.To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/change-isnt-free

Every project starts with a Software requirement Specification (SRS) document, but somewhere in the middle a decision to adopt agile methods is made. So the question arises whether an SRS can serve as agile's product backlog? Let's find out. An SRS is a document with all the direct or indirect requirements of the system are listed. It generally has statements like "The system shall.."

Whereas product backlog serves two purposes: 1. It lists the work that is to be done and 2. It prioritizes the work to be done. It is different with the SRS in the sense that SRS only tells about what work which is to be done, not the priorities. So just for the sake of adopting agile, SRS should not be mixed with user stories, instead a product backlog should be created which will serve the purpose well. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/can-a-traditional-srs-be-converted-into-user-stories#

There is a misconception about agile model with teams across the world. They create an iterative waterfall model and call it agile. In a traditional waterfall development, analysis of the entire project is done first, followed by design for the entire project, followed by coding and testing. In iterative waterfall, the same approach is followed, but each story is treated as a mini project. They do the analysis for one story followed by design, coding, and testing. This is not agile. They confuse both the model because they thrive to build an agile model without exactly considering its meaning. The incorporation of user stories, or treating it as short placeholders for future conversations; each story becomes a mini-specification document. Ideally, in an agile model, all types of work would finish exactly at the same time, be it analysis, design, coding or testing. It is not always possible to achieve this, but it should become team's goal. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile