The Agile School

  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. ...

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 help. They might be new to agile or might be working together with each other for the first time. A structured well-defined set of rules will help them grow. For such teams the following rules are more than enough Daily Scrum Meeting Rules - http://www.theagileschool.com/2012/03/daily-scrum-meeting-rules.html   Daily scrum misconception, scrum meeting objectives and different stages of meeting http://www.theagileschool.com/2012/03/daily-scrum-misconception-scrum-meeting.html Only team members are “allowed” to speak and scrum master should be present to help the team. This rule im...

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 ...

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...

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't have to complete the additional "stories" you pull into the sprint  but if there are stories which you can complete then do it. Work on those Technical debts which you were pushing out- bug fixes, automation, performance enhancement, CI,CD etc. If needed , based on the input from Product owner, do some backlog refinement for upcoming sprints. Maybe its a good idea to learn something new which you might use in upcoming sprints. Do some cross team learning or work on some "new ideas". If there are multiple teams working on same product go and help other teams. They might do the same for your team in future when you need help and when you are behind in your schedule. 

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...

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  

Many teams are measured on the velocity numbers. There are scrum masters who forces the team to "achieve" the numbers without understating the science behind it. Sometime such people even ask team to put numbers against the "research and learning  " work which the team has to do. And because of this velocity focus sometime they don't allow the team to learn or invest the time to reduce the technical debt. Velocity is only a forecast - that x amount of work can be done. This might change. I usually take an average of sprints to get this value so any change in one Sprint doesn't impact much. Overall the pluses and minuses balances themselves out. But I do keep track of changes like people resigning, long vacation, long sick leaves , holiday season , new product /domain or technology , new members joining team. Such events will impact the velocity (and sometimes the story points) . Based on the change sometime I will ask my team to revisit the story point...

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...

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 transition to shorter sprints 2) Products/Teams which doesn't need frequent feedback and can run smoothly . Most of such products/team will have stable backlogs which doesn't change much but then then should have other XP practices ( if they are delivering software products) 3) certain infrastructure /manufacturing projects which needs longer duration to get all the parts working together and other approvals. But even in manufacturing the final product may take many sprints but it doesn't prevent  the team from running small sprints to product the internal components. even...

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...

I have done that !!!! Many years ago i inherited a team which had lot of issues . The PO and team didn't trust each other. I had my first retrospective with Product Owner (PO) alone and my second retrospective 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 shared the feedback to each other along with my coaching and mentoring. During the third meeting we focused on the product and common issues which we could solve together. The focus was to create trust and transparency.  I have seen this in many other teams also because of many reasons. Team members were not willing to talk about all the issues in front of PO because they don't trust the PO. In my case after lot of coaching and mentoring both groups agreed to have a common retrospective. Soon we became one of the best teams in our group. Retrospective is the meeting where everyone...

Agile has many different process . For the certifications I will limit the scope to Kanban & 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 & I have undergone/reviewed their training. Kanban – https://www.kanban.university/#certifiedkanban Foundation – Kanban Practitioner , System, design, Management ( scaling) Trainer – Kanban trainer Advanced – Coaching & advanced Kanban Strategic  - enterprise services planning Scrum Jeff Sutherland & Ken Schwaber together created scrum process. They maintain the scrum guide which is the “Bible” for all scrum based training, coaching and the actual work done across the planet. Scrum.org ( started by Ken Schwaber the co-founder of Scrum process)  - https://www.scrum.org/professional-scrum-certifica...

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....

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 command-and-control-style management—are spreading across a broad range of industries and functions and even into the C-suite. National Public Radio employs agile methods to create new programming. John Deere uses them to develop new machines, and Saab to produce new fighter jets. Intronis, a leader in cloud backup services, uses them in marketing. C.H. Robinson, a global third-party logistics provider, applies them in human resources. Mission Bell Winery uses them for everything from wine production to warehousing to running its senior leadership group. And GE relies on them to speed a much-publicized transit...

Budgeting, as most corporations practice it, should be abolished.” —Jeremy Hope and Robin Fraser,  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 is riddled with gaming-the-system. It encourages unnecessary spending and fosters sub-optimal targets. It hides accountability. It is demoralizing to the participants, inefficient, ineffective, built on fictions, and fundamentally at odds with the dynamic of business agility. None of this is new. Way back in 2003, Jeremy Hope and Robin Fraser wrote as much in  Harvard Business Review . Yet traditional budgeting remains entrenched in big organizations, even those implementing Agile. Why? A key reason is that budgeting interlocks with other aspects of the internal bureaucracy. R...

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 in the not knowing, we need to become comfortable with uncertainty. That means we can’t: Know six months in advance exactly what will be delivered on what date and at what cost Know exactly how much more productive one team is than another Know how users will respond to a feature before they see it Similarly, we can’t even really know things such as that velocity will go up when a good, new member is added to the team. It should, but it’s not guaranteed. I can think of at least a couple of situations in which adding a good person to the team reduced velocity for more than the first f...