The Agile School

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

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

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

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

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

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’? 

this is a thought provoking article by   James Grenning Boy Scout Rule Applied to Every Day Coding http://www.renaissancesoftware.net/blog/archives/90