Agile Buddha - Page 14 of 23 - Demystifying Agile, Getting to its Core

Agile Contracting: Discovery, Fixed Budget, Variable Scope

We discussed about committing fixed number of story points and swapping any additional scope with existing backlog in our previous post “Agile for Fixed Bid Projects“. This is a great way to maximize value with minimal change in timelines and budget. This works well when there is a trust existing between product and engineering, and client/product team understands this agile approach. Still, fixing size, undermines one major aspect of an agile team – “applying learning back into the project”. Development teams while doing size estimation give higher points where there are uncertainties and risks. Known unknowns, new technology, unclear requirements etc. are few reasons for providing higher story points. As project progresses, teams get more knowledgeable (both technology and business) and hence some tasks now look smaller than before.

Agile for Fixed Price Contracts

by ShriKant Vashishtha 6 Comments

The basic premise of Scrum is to help in developing complex software through an incremental and iterative approach based on regular feedback. The feedback comes from sprint review as part of the Increment inspection. That may translate into adaptation in Product Backlog if needed. Agile manifesto has a key tenet around change, i.e. “Responding to change over following a plan”.

Fixed-price projects are all about fixed scope, money and time. In such a contradictory scenario, the question is, how should we accommodate continual changes in the Product Backlog?

Is it even possible to work in a fixed price Agile mode? If so, how?

This post outlines the most common challenges in executing fixed price Agile projects. It also suggests ways to handle them.

Agile Thinking: Continuous Improvement – ScrumMaster 1.0 to 2.0

by Avienaash Shiralige 7 Comments

Readers, Our “Agile Thinking” series is focussed on bringing agility into our thinking as this helps in moving from Doing-Agile to Being-Agile. You can read our earlier article in this series Agile Thinking: Stop Starting, Start Finishing.

This post talks about continuous improvement and obviously this can be applied everywhere irrespective of it is a process, practice or a role. From my recent experience, I would like to share today, how ScrumMater (SM) role evolved in some of the companies.

In many organizations, ScrumMaster role is defined something similar to what is shown below. For conversation sake let’s call it as SM 1.0 (see pic below)

In service industry projects, SM’s playing the role by book (SM 1.0) and expecting Product Owner(PO) from the client side to write stories, acceptance criteria and prioritization did not work due to some of the reasons stated below.

Agile Thinking : Stop Starting, Start Finishing

by ShriKant Vashishtha 13 Comments

Limiting “Work in Process” (WIP) items is one of key ideas of Kanban. A natural outcome of it, inherently coming from Lean philosophy is to stop starting and start finishing.

By having too many work in process items, it looks like everybody is busy but there is no functional outcome for the end user. So, instead, it’s important to work towards completing the user-story.

From the outset it looks like, “Stop starting, start finishing” philosophy is limited to Lean and Kanban world. Scrum world is either doing it well or doesn’t need it. Right?

Wrong!!!

Let’s take a look at a typical Scrum standup.

Webinar: How to Scale Agile using SAFe Framework

by Avienaash Shiralige Leave a Comment

Scrum and XP have been working well for small teams. That works fabulously for small organizations. However implementing the same for large project portfolios, having teams with 100+ developers has remained very challenging from organization perspective.

There are many challenges while working with large teams like:

Breaking silos/departments in large organizations
Requirements focused on changes in enterprise architecture
Ability to work on highest business value features for program portfolio instead of for a project
Eliminate waste and reduce cycle time for the whole value chain
..and more

They can be mitigated by seeing scrum as organization design framework and using lean principles. In this session Shrikant will share his thoughts on how Scaled Agile Framework (SAFe) is used to solve this problem. We will take references from Spotify Scaling Case Study, SAFe and personal experiences.

Date: Feb 19th, 3:00 – 4:00 PM IST

Register Now!