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

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  

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

We all know about definition of done. It defines a set of conditions which should be satisfied by the feature team during the sprint execution for each Product Backlog Item worked by them. Unless all the conditions are met, the Product Backlog Item (PBI) or User Story cannot be marked as done. This can be called as the exit criteria for each PBI or user story. Usually apart from the team & Product Owner, the organization and other stakeholders also play a big part in creating them. A well-defined Definition of Done ensures that all the PBI delivered meets the standards. As team maturity improves this definition also evolves. For every exit criteria there should be an entry criteria. I have seen many lazy Product Owners (& scrum Teams) who don’t do a proper job of backlog grooming.  Because of this there will be lot of ambiguity about the upcoming PBI’s. There will be constant churn producing a lot of waste.  Sprint planning will end up in failure. A poorly pl...