Snehamayee's World Of Agile

Many organizations today are trying to start an agile transformation just for its sake. Its almost like that they are afraid of being left behind. Some stake holders perceive agile as a “compliance” activity that they must do in order to clear some audits.In fact, in one of the projects, one of the senior VPs told me “Ma’m all this agile and stuff is just a new name for the same old thing. It wont solve my problems“…. Many of us have come across this resistance when people don’t perceive any real value to them by going agile. They believe “we were delivering projects before, we will continue to deliver projects … how much difference a mere ‘way of work’ can bring?”

I have had some of my most notable successes, when I shifted the focus away from agile structure -( the events, artefacts and rules) to agile values and principles. I ask the stake holders a simple question “List some of your pain points in current way of project execution” Almost everyone has a long list of items that they claim are painful. I then move along further – In an ideal world – how these painful items would change? After I manage to do chip at the usual reluctance, we get to the meat – people start listing out things that they believe will help. Now we are in business. We then identify items that will bring most value to the organizations. These then become the value objectives for the transformations

Some points to keep in mind are

1. Make sure that the items you identify, are adding real value to stakeholders. Its easy to have items that describe the behavior and not the result. We all are conditioned to track progress based on activities completed not results achieved . For example “code review done” is a behavior – the value can be “zero defect production release”
2. Make sure the items on the list can be quantified and you agree on measurement criterion before hand. “10% improvement in time to market” is a better objective than “reduction in delays”

When the stakeholders see that their problems, the real problems are getting targeted, they are more open to change and having stakeholders who are at least open to ideal of a change is half the battle won…

Its important to keep the interest of the stakeholders, otherwise they lose interest quickly. Short sprints that show at least some measurable results is the best way to keep their interest alive and kicking – more about that in next post. Watch this space!

A lot of organizations these days have a grand plan to for their agile transformations. They hire “change consultants” , do a “OCM analysis” and come up with a detailed, prescriptive plan that they intend to track meticulously to completion. This in itself sounds so very “waterfallish”. To me it sounds like an oxymoron to have a plan driven transformation to make your organization agile…

In my experience as scrum master as well as an agile coach, a plan dictated approach usually does not work for to transform an organization to agile ways of working.This in no way means that agile transformation does not need planning, indeed it does but the plan needs to be flexible and driven by value delivered. In short, its best to drive an agile transformation in an agile manner.

Key aspects to drive the agile transformation in this way are

1. Have the transformation focus on business value – Many organizations are starting the transformations, just to get on agile bandwagon. They have no idea why they want to be agile or what they will gain from being agile. These are the transformations which will fail most likely because there is no clear goal. It is important to have a clear idea about what business objectives will be achieved by being agile.
2. Plan Short “Sprints” – Rome was not built in a day and often the transformation plans are detailed, prescriptive and long term. They do not have a tangible value that gets delivered sooner rather than later . This in itself contradicts the agile principle of ” Early and Continuous Delivery  ” I have found it very helpful to divide the ultimate transformation goal in smaller , more immediately achievable sprint goals that can be demonstrated to stakeholders. This also helps to build consensus and create a positive vibe about the whole initiative
3. Build a Well Planned Product Backlog – While its easily said to have short sprints with sprint goals that are achievable and can be demonstrated, its another story to actually identify those goals. For that it helps to build a prioritized and refined backlog to achieve the business value that is desired. This refinement is ongoing and usually tests the facilitation skills of the scrum master.
4. Form an Agile Team – Like any other project that we do, transforming an organizational way of work to agile is a complex and challenging work. It needs all the 3 roles of a scrum team. A scrum master who is experienced. A product owner who can articulate the value and represent it in the backlog. Last but not least, we need a development team that actually implements the backlog items.

Each of the aspect mentioned above deserves a post of its own – there is a lot be discussed. I intend to do just that and write in detail about my perspective of agile transformation in the time to come. Stay tuned!