Skip to main content

Posts

Showing posts with the label DevOps

Some tips for Agile DevOps transformation

Lot of companies start on the Agile transformation and find it very difficult. Some even go back to their old process. I have seen this in lot of "large" companies who have "established" process which they are following for many years. Process control Most of these companies have lots of process, checklists and control to manage the "work" which is then  manged by complex hierarchy of "mangers".  Many feel empowered by this complex multi-layer organizational hierarchy. I always wondered how actual works gets done, if any,  in such environment. Such companies  will be slow and costly and will end up like dinosaurs. An Agile/DevOps transformation for  such companies is very difficult. The people connection In today's knowledge industry people are the most critical and important part of any company. The old process thrives with rigid rule and checklists. They focus on finding tools or solutions to meet the objective usually ignoring...

The cultural aspect of Agile & DevOps transformation

I get a lot of request for “help” for  agile and DevOps transformation. Many sincerely want to do this but many do this because everyone else is doing and they contacted some some consultants who gave them their marketing pitch with all the technical jargon and modern buzzwords.  There is a lot of hype around DevOps and most of the consultant companies I interacted had many nice slide decks with lot of keywords but implementing them was very difficult. Adding "Ops" at the end of any normal technical word doesn't turn it into the next stage of DevOps. The team and company needs many years of practice and rigor before they can master the trade. Until you create a team/company which is interested in reducing the overall cycle time  and who is wiling to take the feedback and act on it don't think about ChatOps, DevSecOps, DataOps and a lot of other xOps. These ops jargon looks good on power point slides but in reality these are just common sense, the next thing you ...

Why Scaling Agile Doesn't Work for large companies

Many large companies make the fundamental mistake of scaling agile without understanding the whole idea behind agile principles. Being large shouldn't prevent you from looking at the fundamentals. I have heard many highly paid "agile" consultants say that the agile principles and process is all theory and the "big" companies should do things in a different way. After many years of "transformation" and pocketing lots of consulting dollars they will still complain about organizational inertia and lack of support. The moment they leave the company the entire "agile journey"  will go in reverse direction.  The objective of transformations shouldn't be to support any tool or any framework or tied to custom "enterprise" agile SDLC.   The transformation should focus on individuals, teams and products. Equip them with modern tools , train them on Agile and DevOps principles and encourage them to learn from their mistakes. Guide th...

How to handle "UAT" in Agile/DevOps delivery

User Acceptance when done properly is very effective.  But in most cases i have seen companies taking this to the extreme especially in companies who were following traditional waterfall process People are used to do certain things in certain way for long. It is difficult for them to change. Moreover there is a trust factor. They don't (or wont) trust the quality of the software unless they verify it. The result is complex long UAT period where someone from "UAT testing" team as to test  and approve before the product can be released to production. They even refuse to share their test cases with others. And in many cases i have seen that this testing might not find real bugs or is even related to user acceptance. This is the remnant of old way of doing things and this should change in modern Agile  DevOps delivery. Ideally the UAT period should be very small and if possible eliminate this stage completely. The Agile Coaches and scrum masters will have to "train...

Why is amazon is so great in everything they do ?

Amazon has one of the best DevOps model and this help them to release their product at a very much faster pace than any of their competitors. They are able to do continuous improvement in a very short cycle which results in a better process and products. It is no surprise that they were able to eliminate competition from all the sectors they venture into. This was from a presentation in year 2011. how many deployments do you do every year? Healthcare companies beware they are coming and they are bringing hell with them for you . If you have to survive there is there is no other option, you will have to leave your old process and methods and embrace the future continuous improvement  

DevOps at Microsoft- a successful transformation story

When Microsoft started our own DevOps journey, we quickly realized that our transformation to DevOps would have broad organizational impact. Every DevOps conversation needs to focus equally on people , processes , and tools to ensure a successful transformation. Our DevOps journey began by gradually changing the way we work. For example, on the people front, we were able to reduce team sizes from over 20 members to 8-12 members, and we also shifted from working in private offices to working in team rooms. The DevOps journey also allowed us to flatten our hierarchy over time. Smaller teams working in a more collaborative environment increased our ability to more effectively present, test, and implement solutions more quickly. From a process perspective, we changed from our established 4-6-month milestones to 3-week sprints with features shipped upon the conclusion of every sprint, instead of annual shipments. With the sprint format established, we also transitioned from l...

How Microsoft Vanquished Bureaucracy With Agile by Steve Denning

Microsoft has rapidly rising revenues and today is the most valuable firm on the planet—worth more than a trillion dollars. In 2004, I would never have predicted this. At the time, I was visiting Microsoft for a short consultancy. I was shocked to find how bureaucratic it was. After working for several decades in another notorious bureaucracy, I knew the problems bureaucracy caused. But Microsoft was worse: it was impossible to get decisions from within a labyrinth of silos and layers that called to mind Kafka’s  The   Castle . What can other big old firms learn from Microsoft’s escape from bureaucratic strangulation? According to  The Economist , the reason for Microsoft’s turnaround is that Satya Nadella, the CEO since 2014, took the bold decisions of a heroic leader. He opted not to rely on the existing business (Windows) and chose not to be “rapacious.” The more important lesson for most big old corporations, though, is not so much the individual decisions o...

Why Great Product Companies Release Software to Production Multiple Times a Day

Software development has been experiencing disruptive innovation over the last few years, and with the rising expectations of customers looking to get a superior experience, they are always searching for ways to release their products with faster time to market. According to a  Forrester study conducted in 2012 , 17% of entrepreneurs need strategic IT services or software products, delivered in less than 3 months from basics to production, and a few expect the same in 3-6 months. In this post, we will try to explain the real reasons behind this shift; both from the business and from a technology perspective, plus we will also cover the tools and processes that leading-edge companies are using to stay ahead of the competition. The Business Need It has become inevitable for all industries to deliver superior customer experience, and deliver it fast, in order to stay competitive. As well, continuous innovation is required to meet customers' expectations and the market needs....

Challenge best practice?

Idea of best practices is a seductive but dangerous trap. … The great danger in “best practices” is that the practice can get disconnected from its intent and its context and may acquire a ritual significance that is unrelated to its original purpose. They also inhibit a “challenge everything” culture and continuous improvement—a pillar of lean thinking. Why would people challenge ‘best’?