<?xml version='1.0' encoding='UTF-8'?><rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/" xmlns:blogger="http://schemas.google.com/blogger/2008" xmlns:georss="http://www.georss.org/georss" xmlns:gd="http://schemas.google.com/g/2005" xmlns:thr="http://purl.org/syndication/thread/1.0" version="2.0"><channel><atom:id>tag:blogger.com,1999:blog-2327230395630273681</atom:id><lastBuildDate>Mon, 16 Sep 2024 17:13:40 +0000</lastBuildDate><category>scrum</category><category>agile</category><category>scrum master</category><category>enterprise scrum</category><category>ASp.Net</category><category>Agile development</category><category>C#</category><category>product owner</category><category>DevOps</category><category>agile coaching</category><category>.Net</category><category>Dotnet</category><category>Linq</category><category>agile quality</category><category>agile transformation</category><category>sprint</category><category>Product backlog</category><category>XP</category><category>external article</category><category>scrum rules</category><category>scrum team</category><category>wcf</category><category>Anonymous types</category><category>Sql Server 2005</category><category>agile consulting</category><category>quality</category><category>testing</category><category>continuous improvement</category><category>innovation</category><category>scrum testing</category><category>user stories</category><category>HTTP handler</category><category>Thread Synchronization</category><category>Visual Studio</category><category>estimation</category><category>feature team</category><category>technical debts</category><category>threading</category><category>ADO.net</category><category>Abstract Base Class</category><category>Ajax</category><category>DateTime functions</category><category>Extension Methods</category><category>Generic Hander</category><category>HTTP Module</category><category>IIS</category><category>Interface</category><category>NFR</category><category>PDCA</category><category>PMO</category><category>QA</category><category>Refactoring</category><category>SOA</category><category>SQL server error</category><category>Sql Server 2008</category><category>address</category><category>agile conference</category><category>ai</category><category>artificialintelligence</category><category>bug fixing</category><category>bugs</category><category>certification</category><category>computer science</category><category>continuousdelivery</category><category>continuousimprovement</category><category>cross functional team</category><category>datatable</category><category>design pattern</category><category>exception</category><category>kaizen</category><category>kanban</category><category>large teams</category><category>lean</category><category>life</category><category>machinelearning</category><category>message patterns</category><category>oops</category><category>performance appraisal</category><category>productdevelopment</category><category>project planning</category><category>quality. agile</category><category>release planning</category><category>retrospectives</category><category>scaling agile</category><category>scoping</category><category>software</category><category>story points</category><category>variables</category><category>viewstate</category><category>web service</category><title>The Agile School</title><description>The practical &quot;bytes&quot; of Agile And DevOps Transformation </description><link>http://www.theagileschool.com/</link><managingEditor>noreply@blogger.com (Abhilash Chandran)</managingEditor><generator>Blogger</generator><openSearch:totalResults>106</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-6091539672804291763</guid><pubDate>Fri, 14 Jul 2023 17:21:00 +0000</pubDate><atom:updated>2023-07-14T10:21:54.123-07:00</atom:updated><title>Key principles for robust and maintainable software development </title><atom:summary type="text">&amp;nbsp;When it comes to robust and maintainable software development, several key principles can greatly contribute to the quality and longevity of the software. Here are some important principles to keep in mind:1. Modularity: Divide your software into smaller, self-contained modules or components that perform specific tasks. This approach allows for easier development, testing, and maintenance. </atom:summary><link>http://www.theagileschool.com/2023/07/key-principles-for-robust-and.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-5848740932265849954</guid><pubDate>Wed, 21 Jun 2023 01:02:00 +0000</pubDate><atom:updated>2023-06-20T18:02:15.850-07:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">ai</category><category domain="http://www.blogger.com/atom/ns#">artificialintelligence</category><category domain="http://www.blogger.com/atom/ns#">innovation</category><category domain="http://www.blogger.com/atom/ns#">machinelearning</category><title>AI - looking beyond the marketing hype</title><atom:summary type="text">&amp;nbsp;Technology is changing very rapidly. Every few decades we might see disruptive technologies which might have a huge impact on our society. Artificial Intelligence is such a technology which can improve the quality of our lives in a positive way. I am sure that in our lifetime we will see its incredible impact on various areas of our lives.Many months ago everyone was behind crypto, “bit” or</atom:summary><link>http://www.theagileschool.com/2023/06/ai-looking-beyond-marketing-hype.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-4036118376060370951</guid><pubDate>Wed, 21 Jun 2023 01:00:00 +0000</pubDate><atom:updated>2023-06-20T18:00:21.178-07:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">continuousdelivery</category><category domain="http://www.blogger.com/atom/ns#">continuousimprovement</category><category domain="http://www.blogger.com/atom/ns#">productdevelopment</category><title>Embracing Frequent Delivery: The Key to Success with modern product development</title><atom:summary type="text">&amp;nbsp;One of my favorite story is about how Google Chrome surpassed Microsoft&#39;s Internet Explorer by leveraging its rapid release strategy. Without fail I repeat this in almost every training I give to my team.&amp;nbsp;In today&#39;s rapidly evolving digital landscape, the traditional approach of infrequent software releases is being replaced by a more agile and dynamic methodology: frequent delivery. </atom:summary><link>http://www.theagileschool.com/2023/06/embracing-frequent-delivery-key-to.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-465118811960679108</guid><pubDate>Sat, 17 Jun 2023 03:00:00 +0000</pubDate><atom:updated>2023-06-16T20:00:11.122-07:00</atom:updated><title>agile frameworks</title><atom:summary type="text">&amp;nbsp;</atom:summary><link>http://www.theagileschool.com/2023/06/agile-frameworks.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEganSxCiXCqkBW2fP8Yzy8LIvh3Vh5R0WEB6jA-p8V-pndXFKtahNDWnaVHvKK8rmH0jhoNfqzaDGnszFpKafs6_3XA7YRNo9QAma6H-NCxZKqZ0a5BJHjBYRbacEPQP_7X3oclCtHuexa7/s72-w640-h200-c/agileconsulting.jpg" height="72" width="72"/><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-1944598136949498141</guid><pubDate>Mon, 26 Jul 2021 14:19:00 +0000</pubDate><atom:updated>2021-08-03T07:22:25.404-07:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">continuous improvement</category><category domain="http://www.blogger.com/atom/ns#">life</category><title>Failure is an option for software development ( and in life)</title><atom:summary type="text">&amp;nbsp;From childhood we are programmed to fear the failure, the opposite behavior is rewarded. I still see many companies &amp;amp; people trying to recruit people with a “Failure is not an option” requirement. Such practices reinforce this behavior. In many cases the “prevention” causes more problem &amp;amp; costs more than the actual issue.Without failure there is no learning. Any process/framework/</atom:summary><link>http://www.theagileschool.com/2021/07/failure-is-option-for-software.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-1369719075905105121</guid><pubDate>Thu, 05 Mar 2020 17:41:00 +0000</pubDate><atom:updated>2020-03-05T10:03:51.180-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">enterprise scrum</category><category domain="http://www.blogger.com/atom/ns#">Product backlog</category><category domain="http://www.blogger.com/atom/ns#">product owner</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><category domain="http://www.blogger.com/atom/ns#">scrum master</category><category domain="http://www.blogger.com/atom/ns#">scrum rules</category><category domain="http://www.blogger.com/atom/ns#">testing</category><title>Why is potentially shippable product quality important </title><atom:summary type="text">
Agile teams work in iterations. During this period, they are supposed to work on product increments which can be “delivered” at the end of iteration. But how you know that the correct product was delivered? Many teams have different kinds of acceptance criteria and Definition of Done (DoD). But in many cases, this “done” is not the real “done” there might be some testing pending, some </atom:summary><link>http://www.theagileschool.com/2020/03/why-is-potentially-shippable-product.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtoPkokAHEVWAxZxT0oMdc61zVTK5jcduLqQrjZR-Odyoyz4Y0w9XT1gJEyHgz85K6Es3g257kV-x45SNlEzCVvWZHyDIxOXyVzLIRwQ3pt6oRfeOb6_6cA9UQ0S_HJ8Web9lSdmaPwt_Q/s72-c/Potentially+Shippable+Product.png" height="72" width="72"/><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-2811955719704371506</guid><pubDate>Tue, 18 Feb 2020 20:16:00 +0000</pubDate><atom:updated>2020-02-19T08:32:57.938-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile coaching</category><category domain="http://www.blogger.com/atom/ns#">Agile development</category><category domain="http://www.blogger.com/atom/ns#">Product backlog</category><category domain="http://www.blogger.com/atom/ns#">product owner</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><category domain="http://www.blogger.com/atom/ns#">scrum master</category><category domain="http://www.blogger.com/atom/ns#">scrum rules</category><category domain="http://www.blogger.com/atom/ns#">user stories</category><title>Product Backlog: Should you write everything in user story format?</title><atom:summary type="text">



I like user stories a lot. They help everyone talk the same
language and results in a better product.

User story alone does not constitute product requirement. User story is supposed to be a place holder for discussion which should happen between the team, Product Owner and the customer. This discussion result in a common understanding which along with the user story content is the product </atom:summary><link>http://www.theagileschool.com/2020/02/product-backlog-should-you-write.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXIyoFtu_ld17dnEbccWeYBh05EhAmkbKlav4miIOzHSfxjbnOWlzB0fqMC4MR4DGz-amNQuCA_ST-yIgjw-8e56cFzN2cUgJ0rPbFXZRh-NfJ7F9AsQwPinsyz9LMEiS4GBAuDQ18p_NG/s72-c/userstory.jpg" height="72" width="72"/><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-1700852207816272533</guid><pubDate>Sat, 15 Feb 2020 23:42:00 +0000</pubDate><atom:updated>2020-02-15T16:44:21.377-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">Agile development</category><category domain="http://www.blogger.com/atom/ns#">enterprise scrum</category><category domain="http://www.blogger.com/atom/ns#">product owner</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><category domain="http://www.blogger.com/atom/ns#">scrum master</category><category domain="http://www.blogger.com/atom/ns#">scrum rules</category><category domain="http://www.blogger.com/atom/ns#">scrum team</category><title>The different types of Daily stand-up for different teams with different maturity; Can product owners and others speak during daily scrum</title><atom:summary type="text">

Daily stand up meeting serves a very important role in agile teams. In a way they are the risk 


mitigation meeting. Team members talk about the risk for the iteration and overall product delivery.

The need of a daily stand up for a new team and a matured team is different and hence the need for different rules for different teams. Teams who are starting the agile/scrum journey needs a lot of</atom:summary><link>http://www.theagileschool.com/2020/02/the-different-types-of-daily-stand-up.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHtaymtBccc4tKEV9v8DyXpRbcJXDuWXvmruukVvqJQBIb11wZvPnQifldhf9Y77SQUQzXs8vRGBJBwmGk-Zahi0kFuhukOvzsrQw7hsu3EU6OLhmG10wnUTZbfpb-qJSyPSPCT9hiXlS8/s72-c/dailystandup.jpeg" height="72" width="72"/><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-5123917775064068856</guid><pubDate>Thu, 13 Feb 2020 06:59:00 +0000</pubDate><atom:updated>2020-02-15T20:15:00.097-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile transformation</category><category domain="http://www.blogger.com/atom/ns#">DevOps</category><category domain="http://www.blogger.com/atom/ns#">enterprise scrum</category><category domain="http://www.blogger.com/atom/ns#">kanban</category><category domain="http://www.blogger.com/atom/ns#">scaling agile</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><title>Some tips for  Agile DevOps transformation </title><atom:summary type="text">


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 &quot;large&quot; companies who have &quot;established&quot; process which they are following for many years.


Process control

Most of these companies have lots of process, checklists and control to manage the &quot;work&quot; which is then&amp;nbsp; manged by complex hierarchy of </atom:summary><link>http://www.theagileschool.com/2020/02/why-agile-devops-transformation-is-hard.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9Juja0Z_WhuSfnSR-PQN8Zot63ougGj_Ua8AsZ7dFYmSNS_hxVXtVS9flOhv3orkW0OWsySja9apfYy7r5W2LTTIEhJCT-62TZQdj9NPS2r1JQrucNUJcmXxTFCPs4BKMXBrzcqq_rOEo/s72-c/transformation-3753440_960_720.jpg" height="72" width="72"/><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-497611052683363394</guid><pubDate>Mon, 10 Feb 2020 20:28:00 +0000</pubDate><atom:updated>2020-02-10T12:28:35.823-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile transformation</category><category domain="http://www.blogger.com/atom/ns#">DevOps</category><title>The cultural aspect of Agile &amp; DevOps transformation </title><atom:summary type="text">

I get a lot of request for “help” for&amp;nbsp; 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.&amp;nbsp;

There is a lot of hype around DevOps and most of the consultant companies I interacted had many nice </atom:summary><link>http://www.theagileschool.com/2020/02/the-cultural-aspect-of-agile-devops.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjN9ZK652ia3UullE-1rVfTZR7qxDt_TJE9gIpom9JJFfTYCWWE-9b2X1LmAl3lXSm7fknxvbDRpTuiF7_PCLlvlP_Y5WvhT5w-FNAeLEKrWygZA8ziiAksXAB25kjjEaIHu93YuS6u4aeL/s72-c/Picture1.png" height="72" width="72"/><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-2494370536090117814</guid><pubDate>Mon, 10 Feb 2020 05:04:00 +0000</pubDate><atom:updated>2020-02-15T21:20:51.222-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile coaching</category><category domain="http://www.blogger.com/atom/ns#">Agile development</category><category domain="http://www.blogger.com/atom/ns#">agile transformation</category><category domain="http://www.blogger.com/atom/ns#">DevOps</category><category domain="http://www.blogger.com/atom/ns#">enterprise scrum</category><title>Why Scaling Agile Doesn&#39;t Work for large companies </title><atom:summary type="text">

Many large companies make the fundamental mistake of scaling agile without understanding the whole idea behind agile principles. Being large shouldn&#39;t prevent you from looking at the fundamentals. I have heard many highly paid &quot;agile&quot; consultants say that the agile principles and process is all theory and the &quot;big&quot; companies should do things in a different way. After many years of &quot;</atom:summary><link>http://www.theagileschool.com/2020/02/why-scaling-agile-doesnt-work-for-large.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://img.youtube.com/vi/2zYxWEZ0gYg/default.jpg" height="72" width="72"/><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-1922277678363920836</guid><pubDate>Mon, 10 Feb 2020 01:46:00 +0000</pubDate><atom:updated>2020-02-15T21:22:55.906-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile coaching</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><category domain="http://www.blogger.com/atom/ns#">scrum team</category><title>What to do if your SCRUM team finishes early?</title><atom:summary type="text">
This is a good place to be. But if this happens a lot then you may have to look into commitments you are making. You may be committing less.

Work on the next priority items in the backlog. Inform the Product owner. He/she may have some ideas also. You don&#39;t have to complete the additional &quot;stories&quot; you pull into the sprint&amp;nbsp; but if there are stories which you can complete then do it.

Work </atom:summary><link>http://www.theagileschool.com/2020/02/what-to-do-if-your-scrum-team-finishes.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-5337168711571058828</guid><pubDate>Sat, 08 Feb 2020 19:18:00 +0000</pubDate><atom:updated>2020-02-15T21:24:50.332-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile coaching</category><category domain="http://www.blogger.com/atom/ns#">agile consulting</category><category domain="http://www.blogger.com/atom/ns#">Agile development</category><category domain="http://www.blogger.com/atom/ns#">DevOps</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><category domain="http://www.blogger.com/atom/ns#">scrum testing</category><category domain="http://www.blogger.com/atom/ns#">testing</category><title>How to handle  &quot;UAT&quot; in Agile/DevOps delivery </title><atom:summary type="text">
User Acceptance when done properly is very effective.&amp;nbsp; 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&#39;t (or wont) trust the quality of the software unless </atom:summary><link>http://www.theagileschool.com/2020/02/how-to-handle-uat-in-agiledevops.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-6629283316006082163</guid><pubDate>Fri, 07 Feb 2020 08:30:00 +0000</pubDate><atom:updated>2020-02-08T14:41:43.422-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile coaching</category><category domain="http://www.blogger.com/atom/ns#">Agile development</category><category domain="http://www.blogger.com/atom/ns#">agile quality</category><category domain="http://www.blogger.com/atom/ns#">continuous improvement</category><category domain="http://www.blogger.com/atom/ns#">DevOps</category><title>Why is amazon is so great in everything they do ?  </title><atom:summary type="text">
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 </atom:summary><link>http://www.theagileschool.com/2020/02/why-is-amazon-is-so-great-in-everything.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-6523160461781064351</guid><pubDate>Thu, 06 Feb 2020 17:45:00 +0000</pubDate><atom:updated>2020-02-15T21:18:35.505-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">Agile development</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><title>Why are scrum teams hung up on Velocities ?</title><atom:summary type="text">

Many teams are measured on the velocity numbers. There are scrum masters who forces the team to &quot;achieve&quot; the numbers without understating the science behind it. Sometime such people even ask team to put numbers against the &quot;research and learning&amp;nbsp; &quot; work which the team has to do. And because of this velocity focus sometime they don&#39;t allow the team to learn or invest the time to reduce the</atom:summary><link>http://www.theagileschool.com/2020/02/why-are-scrum-teams-hung-up-on.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-8818505533062880745</guid><pubDate>Tue, 04 Feb 2020 03:18:00 +0000</pubDate><atom:updated>2020-02-09T19:19:52.369-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile transformation</category><category domain="http://www.blogger.com/atom/ns#">DevOps</category><category domain="http://www.blogger.com/atom/ns#">external article</category><title>DevOps at Microsoft- a successful transformation story</title><atom:summary type="text">

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 </atom:summary><link>http://www.theagileschool.com/2020/02/devops-at-microsoft-successful.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://img.youtube.com/vi/X4uziBlC728/default.jpg" height="72" width="72"/><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-3643935721895498324</guid><pubDate>Mon, 03 Feb 2020 02:14:00 +0000</pubDate><atom:updated>2020-02-15T21:27:11.799-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile coaching</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><title>Are there any  benefit of working in longer sprints </title><atom:summary type="text">
The best benefits of scrum or agile is in shorter iterations. There are no major advantage of doing longer sprints for most of the teams/products. If teams can do shorter iterations/sprints then they should definitely do it.

Longer sprints might be good for teams

1) who were doing waterfall for long and being transitioned to Agile. A longer sprint will be more suitable for them until they can </atom:summary><link>http://www.theagileschool.com/2020/02/are-there-any-benefit-of-working-in.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-4732055441419922318</guid><pubDate>Sat, 18 Jan 2020 03:11:00 +0000</pubDate><atom:updated>2020-02-09T19:12:43.172-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile transformation</category><category domain="http://www.blogger.com/atom/ns#">DevOps</category><category domain="http://www.blogger.com/atom/ns#">enterprise scrum</category><category domain="http://www.blogger.com/atom/ns#">external article</category><title>How Microsoft Vanquished Bureaucracy With Agile by Steve Denning</title><atom:summary type="text">

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 </atom:summary><link>http://www.theagileschool.com/2020/01/how-microsoft-vanquished-bureaucracy.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-3304813717841241155</guid><pubDate>Fri, 17 Jan 2020 09:00:00 +0000</pubDate><atom:updated>2020-02-15T21:30:15.720-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile consulting</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><category domain="http://www.blogger.com/atom/ns#">scrum master</category><title> Advice for two retrospectives in one sprint(without and with product owner)</title><atom:summary type="text">
I have done that !!!!
Many years ago i inherited a team which had lot of issues . The PO and team didn&#39;t trust each other.


I had my first retrospective with Product Owner (PO) alone and my second retrospective&amp;nbsp;with team but without PO. Usually followed by a third retro meeting with PO and team . During the first two meetings PO and team talked about the issues they had with each other. I </atom:summary><link>http://www.theagileschool.com/2018/08/advice-for-two-retrospectives-in-one.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-4476287918322887690</guid><pubDate>Fri, 17 Jan 2020 00:02:00 +0000</pubDate><atom:updated>2020-02-07T16:03:10.578-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">certification</category><title>Some recommended Agile certifications </title><atom:summary type="text">


Agile has many different process . For the certifications I
will limit the scope to Kanban &amp;amp; Scrum because these are the most popular
agile practices



There are many companies providing these certifications so
the cost will vary. I am listing few companies which provides these. They are
leaders/pioneers in this space &amp;amp; I have undergone/reviewed their training.



Kanban – 

https://</atom:summary><link>http://www.theagileschool.com/2019/12/some-recommend-agile-certifications.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-7707354212026895861</guid><pubDate>Thu, 16 Jan 2020 08:00:00 +0000</pubDate><atom:updated>2020-02-09T19:10:09.760-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">Agile development</category><category domain="http://www.blogger.com/atom/ns#">DevOps</category><category domain="http://www.blogger.com/atom/ns#">enterprise scrum</category><category domain="http://www.blogger.com/atom/ns#">external article</category><title>Why Great Product Companies Release Software to Production Multiple Times a Day</title><atom:summary type="text">

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&amp;nbsp;Forrester study conducted in 2012, 17% of entrepreneurs need strategic IT services or software products, </atom:summary><link>http://www.theagileschool.com/2020/01/why-great-product-companies-release.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-4404584175990012683</guid><pubDate>Thu, 16 Jan 2020 02:57:00 +0000</pubDate><atom:updated>2020-02-09T19:10:29.272-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">continuous improvement</category><category domain="http://www.blogger.com/atom/ns#">enterprise scrum</category><category domain="http://www.blogger.com/atom/ns#">external article</category><category domain="http://www.blogger.com/atom/ns#">innovation</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><title>Embracing Agile by Darrell K. Rigby,Jeff Sutherland and Hirotaka Takeuchi</title><atom:summary type="text">

Agile innovation methods have revolutionized information technology. Over the past 25 to 30 years they have greatly increased success rates in software development, improved quality and speed to market, and boosted the motivation and productivity of IT teams.

Now agile methodologies—which involve new values, principles, practices, and benefits and are a radical alternative to </atom:summary><link>http://www.theagileschool.com/2020/01/embracing-agile-by-darrell-k-rigbyjeff.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-1798475057412900802</guid><pubDate>Sat, 11 Jan 2020 03:24:00 +0000</pubDate><atom:updated>2020-02-09T21:17:14.850-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">agile transformation</category><category domain="http://www.blogger.com/atom/ns#">enterprise scrum</category><title>Why Budgeting Kills Agile And Innovation by Steve Denning</title><atom:summary type="text">


Budgeting, as most corporations practice it, should be abolished.”


—Jeremy Hope and Robin Fraser,&amp;nbsp;Harvard Business Review, 2003


The budget often constitutes one of the last—and largest—stumbling blocks to creating a truly Agile organization.

Budgeting as practiced in most large organizations today is cumbersome, expensive, time-consuming and wasteful. It often cripples innovation. It</atom:summary><link>http://www.theagileschool.com/2020/01/why-budgeting-kills-agile-and.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-2621101634730705456</guid><pubDate>Sat, 04 Jan 2020 06:27:00 +0000</pubDate><atom:updated>2020-02-09T22:34:32.408-08:00</atom:updated><category domain="http://www.blogger.com/atom/ns#">agile</category><category domain="http://www.blogger.com/atom/ns#">Agile development</category><category domain="http://www.blogger.com/atom/ns#">external article</category><category domain="http://www.blogger.com/atom/ns#">Product backlog</category><category domain="http://www.blogger.com/atom/ns#">scrum</category><title>Welcome to the not knowing  ( we need to embrace uncertainty ) - Mike Cohn</title><atom:summary type="text">

In one scene of the TV show Mad Men, a young advertising copywriter (Peggy Olson) asks her boss (Don Draper) how to know which of her advertising ideas will work best.


He tells her she can’t know in advance, which frustrates her. He then adds that part of her job is “living in the not knowing.”




Part of our job, too, is living in the not knowing.




To survive--perhaps even thrive--here </atom:summary><link>http://www.theagileschool.com/2020/01/welcome-to-not-knowing-we-need-to.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item><item><guid isPermaLink="false">tag:blogger.com,1999:blog-2327230395630273681.post-8979711642187251437</guid><pubDate>Thu, 29 Sep 2016 18:13:00 +0000</pubDate><atom:updated>2020-02-07T09:45:52.925-08:00</atom:updated><title>The scaled Scrum Framework from Ken  Schwaber</title><atom:summary type="text">


Last many months i am hearing a lot about scaling agile. We have a lot of&amp;nbsp;certifications and&amp;nbsp;&amp;nbsp;new &quot;frameworks&quot; for scaling.&amp;nbsp;Personally&amp;nbsp;i&amp;nbsp;don&#39;t&amp;nbsp;like&amp;nbsp;the&amp;nbsp;idea of the frameworks i have seen till now.&amp;nbsp;&amp;nbsp;For companies this will soon become another checklist for them&amp;nbsp;

https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf

Purpose of the </atom:summary><link>http://www.theagileschool.com/2016/09/the-scaled-scrum-framework-from-ken.html</link><author>noreply@blogger.com (Abhilash Chandran)</author><thr:total>0</thr:total></item></channel></rss>