The Agile School

  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 blockchain. It seemed like almost everyone was trying to create all these wonderful products based on blockchain. It is a very good technology but it was overhyped . A lot of people lost their hard earned money due to this hype.  Now it seems AI has become a buzzword in almost every industry. However, it's crucial to understand that simply appending "AI" to a product or service doesn't automatically make it intelligent or truly embody AI capabilities. I have seen the same company doing blockchain a couple of years back ,now jumping into the AI bandwagon without any investment in...

  One of my favorite story is about how Google Chrome surpassed Microsoft's Internet Explorer by leveraging its rapid release strategy. Without fail I repeat this in almost every training I give to my team.  In today's rapidly evolving digital landscape, the traditional approach of infrequent software releases is being replaced by a more agile and dynamic methodology: frequent delivery. Embracing frequent delivery not only enhances user experience but also enables organizations to stay ahead of the competition.  User Experience Frequent delivery empowers organizations to continuously improve their software products based on user feedback and evolving market demands. By rapidly addressing bugs, implementing enhancements, and introducing new features, organizations can provide an exceptional user experience. Many years ago, Internet Explorer(IE) was the most popular browser. There were many other small browsers but none had the reach of IE. Then google entered the market tr...

 

 From childhood we are programmed to fear the failure, the opposite behavior is rewarded. I still see many companies & 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 & costs more than the actual issue. Without failure there is no learning. Any process/framework/companies which needs people to follow the “dotted” lines and where “failure is not an option” will not result in innovation or new ideas ; And eventually they will cease to exist. A lot has changed in the last decade, now we have tools and process to give instantaneous feedback to any changes we can think of. Clean code + Short feedback cycle (CI/CD) + automation + transparent data metrics should be the cornerstone for any software development team  A good software development strategy will have process to review failures and make the changes to ensure that people are learning from their mi...

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 integration or review pending or anything else which prevents the actual use of the product increment. Many of these teams will need additional iterations to finish hardening their products. Many teams will implement different types of “gates” or approval steps to move to next stage. The free flow of product will be interrupted. They might end up doing mini waterfall within their agile process. Many don’t even realize this. This results in poor quality and requires additional effort to “harden” the product. Potentially Shippable Product increment The acceptance criteria and DoD should be modified...

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 requirement. This format captures the essence of requirement without confusing the readers User Story is only one of the many different ways in which requirements can be represented. This is not mandatory in any Agile “process”. But many have made this mandatory. I have seen many spending countless hours trying to write the requirements in user story format when they could have easily written that in simple one-line sentence in few minutes.   I have seen team members refusing to even discuss the requirement until product owner rewrote the requirement in user story format. ...