159 posts
A few days ago, I came across a Chinese term "Guanxi" for building business relationship, which is very much in practice much the same way in India as well for many years and is termed as "Vyavahar".
My recent paper focuses on e-Health Care. The focus today is not how good a Health Care service is but also how fast and efficiently that service is delivered to the end customer - the patient in this case. This in other terms also means how less of the overhead is the health-care organization is able to keep. Cutting all the jargon puzzle - the bottom line is despite all the complicated forms processing and keeping piles and piles of paper work how the health-care office is managed efficiently and with ease. Where all the information is available on the click of the button to the various departments without getting bombarded with information overload or even lack of sufficient information in other cases.
We all know the value of entrepreneurship, and the benefits it reaps for all of us - be it economical, life-learning, technology advancement, research-wise and academically. Entrepreneurship is not only about job growth, creation of new jobs, or technical innovation, but it also fosters a culture that is forward looking, helps in transforming local & national economies and prepares the local region for tough competitive economic and technology environment.
The promise of DevOps is to provide a basis for collaboration between organizations and IT that produces superior customer value.
Here's the excerpt of my recent article published in Better Software Magazine, :
Measuring velocity is a useful way of determining how long an agile project will take to complete, by providing a rough estimate of the amount of work the team can complete in a sprint. It is necessary to keep in mind, however, that as insightful as knowing your team’s velocity is, velocity is not a true measure of your product’s development. This post will discuss what velocity is and the reason why we measure it, and why management is interested in higher versus lower velocity. Velocity Defined Velocity, in terms of agile product management, is a metric that provides insight into approximately how much work a given team can complete in a sprint. Measuring velocity uses information from a completed sprint, so if your team is approaching its first sprint, you must know how many people will be involved in the project, the maximum amount of work each person can complete, and the total number of workdays in the sprint, in order to calculate the velocity. Calculating velocity involves units of work that can be defined as hours or story points – a metric capturing the complexity of implementing a story – for example, and tasks. Velocity is calculated by adding up the difficulty metric of every backlog task, such as stories, completed by the team in a given sprint with the units of work for those tasks. This provides the velocity in terms of units of work per sprint. Why Measure Velocity? Velocity provides an estimate of how much work your team, specifically, can complete in a given sprint. As velocity is calculated using the work of previous sprints and if everything remains constant – such as the same people are involved and the tasks are relatively of the same nature – then velocity is consistent. If the team had a velocity of 30 story points per sprint for previous software development projects, then it can be expected that, all else constant, the team will have a velocity of 30 story points per sprint in the next software development project. Velocity is useful in estimating the approximate length that a project will take, as well. If the project at hand has 120 story points’ worth of stories, and previous sprints show that the team has a velocity of 30 story points per sprint, then it can be expected that the team will complete the present project in four sprints. Higher Velocity Versus Lower Velocity As velocity signifies an agile team’s productivity – the velocity value indicates that either the team completed fewer high-difficulty stories, or they completed many stories of lower difficulty – it is more desirable for a team to have a higher velocity than a lower one. A higher velocity would indicate that the team is capable of completing more stories or high-difficulty stories, which translate into more progress towards the project. It is worth noting, though, that when teams are measuring their velocity at the start of a project, the velocity value will not be as accurate as it will be for later sprints. An underestimation when initially measuring velocity can result in a higher velocity later on in the project. Similarly, an overestimation in initially measuring the velocity will lead to a lower velocity later on in the project, as the velocity is adjusted with each completed sprint. As such, the velocity value that is calculated later on in a project may not accurately reflect the team’s productivity; their productivity could have remained constant, yet the change in velocity value may be due to an under or overestimation. Velocity Is Not a True Measure of Product Development As useful as measuring velocity is, an agile team should not rely on their velocity to indicate the progress of their product’s development. The velocity is measured based on each sprint, and with each new sprint, new product features’ information is accumulated and added; this changes the stories and story points associated with the next sprint, so the previous sprint’s velocity is not necessarily indicative of the team’s work in the next sprint. Many new features may have to be added or changed in the next sprint, so the nearly completed product of the previous sprint may actually be 40% completed, given the previous sprint’s feedback. Even though the team had a high velocity in the previous sprint, product feedback necessitated even more work before the product can be deemed complete.
Here’s the repost of my recent post on ScrumAlliance.org: As we get into the routine of releases and sprints, over time the Scrum team establishes its work pattern, and the product owner (PO) becomes more familiar with not only the team but with methods for developing the product build with agility. As we move into sprint after sprint, daily stand-ups, planning, review, and retrospective sessions become second nature for the team. During this process, the PO may feel overwhelmed by the demands of involvement with the team, as well as the demands of external priorities. Some POs may lose their focus on the team as those external priorities shift. To address this and a few other factors that can affect the transition from being an average PO to being a stellar PO, I've listed some traits that can help a PO move in that direction.
The Agile Manifesto states:
The article below was originally published on Innovation Insights, part of WIRED!
The agile approach to project management entails constant changes which require a set of tools that are not only resilient to the various changes that will emerge in the development process, but which also suit how your team works. The ideal tool for each organization will be different, but in any case, it will facilitate agile work processes and allow for team structures to be adapted for maximum project results. Read more here.
I keep hearing that networking is a crucial element for any business or consultant to survive and thrive. And then I see a lot of 'invasion' and 'information overload' in the form of pointless and useless updates, who's connected to who, tons of forum posts, etc. etc. And all this makes me think, do I really want all this hassle in order to be able to grow my business or network? Haven't we gone from a 'simplinostic' to a very-nostalgic form of network communication? Who's got the time to skim through all this information floating on the world wide web or the clutter being collected in my inbox every hour? Do I really want to follow someone on Twitter just to find out they landed in Chicago from their nice-weekend getaway trip to Miami? Really? How can we simplify this network exchange? How can we make it so easy for a busy entrepreneur so its easier to live a normal life for him or her? Aren't we concerned where we are headed? Aren't we concerned about this information overload?
Innovation and Social Media. Both have been around for many years. Think about the discovery of the newspaper, or the telephone or just about one of the daily devices or appliance we are so used to now.Hard to believe isn't it. What various newspapers, magazines, SW & MW channels on the radio were to my grandfather the new media including feedreaders, Twitter, and other social media channels are the same for me today. There nodifferent than the newer ones have the ability to cut the time traveled and the agility with fancy delivery. Same thing.
So with Windows 8, Microsoft is pretty much on its way in being a trendsetter quietly while the rest of the markets are going ga-ga over mobile devices and what not. Microsoft, is doing good, and they are being very innovative the experience from Windows 8 as a beta user for six months hasn't been frustrating at all. And it doesn't stop at Windows 8, as we see it in newly launched MSN, Office 360, and apps for Android making Office more accessible and productive than ever before. I now prefer using Windows 8 more than Mac OS X. For many reasons, the latest Mac OS X has sucked out all the energy from my powerful Core i7 running 8 GB of RAM - compare this with my Windows 8 Machine running faster on Centrino vPro 2 with only 3 GB of RAM. Why am I not surprised? Without getting into too much details, just say my Mac has more apps running at the same time than Windows machine, but its a power horse then shouldn't it be able to handle it well?
Here's the excerpt of my recent post on ScrumAlliance.org:
A heart warming story of Caroline Casey shared by herself. Sometimes we're blind, figuratively, when we try to be someone, something, that we're are not and we know we are not but we still try hard. Caroline shares some great examples and lessons she learned throughout her life journey. I particularly like the way she put it how she wants to change the way we see the world, people and challenges. An amazing woman, and loved the talk.
This is interesting from IBM www.lotuslive.com. Another attempt from IBM to bring LotusNotes mainstream.
Very interesting comment from Bill Gates to Steve Jobs "...Macintosh of all the machines that I've seen meets that standard."
When you start to think about Enterprise Management Platform (EMP), few questions pop into the head: