Driving an Agile Transformation in Agile Way :: Build a Well Planned Product Backlog

Like every scrum project, an agile transformation needs to have its own Product backlog. This backlog will list all items that need to be accomplished in order to transform organizational way of work to agile.

Some Key Items to consider

  1. Consider using backlog with parent child structure – Agile transformation is a complex piece of work. In the initial stage all the items identified will be very large in size and each of those then needs to be decomposed in items that are manageable in size. Often the top level items are quite independent in nature and will be executed by different sets of people in your organization . For a recent transformation I was a part of some of the initial items in the backlog were Increase Scrum awareness ,Create a supporting organization structure that enables scrum and Increase automation . Each of these items needed to be implemented by completely different teams. Managing the backlog was becoming a difficult task and we ended up creating a sub backlog for each of the items in the parent backlog
  2. Ensure that each item has a defined/measurable acceptance criterion. For any large initiatives you will have negative stakeholders – Those stakeholders who are skeptical and don’t agree on value brought in by the transformation. It then helps to have measurable success criterion – defined and agreed upon before you start the work.
  3. Deliberate on Business value of each item – With stakeholders and team members being used to a plan driven way of operating, the product backlog transforms into action driven plan rather than a list of items where each item adds a discrete value. It helps to consciously call out the business value attached with each item. Over time this becomes a habit but it needs attention and focus initially while the team is getting used agile way of working

Driving an Agile Transformation in Agile Way :: Plan Short Sprints

As we discussed before, many of agile transformations start with a detailed, prescriptive plan mandating action items…..This a beautiful plan considering a lot of perspectives, it is rarely a short plan! This does not allow stakeholders to realize the value that is delivered. As a result after a while stakeholders, most of whom already have a lot of responsibilities start to get the dejected…

A good to way to conqueror this can be to design the transformation as a series of sprints which together deliver the large enterprise goal, but each sprint individually delivers at least a small, tangible piece of that large goal. These smaller goals allow stakeholders to taste success and retain their enthusiasm. It also helps to spread the word and convince those who are on fence.

I usually suggest that these sprints follow the scrum events and artefacts. It allows the team to collaborate in a structured manner. I have found that often stakeholders who are worried about one more topic for long meetings. They are really happy at the prospect of one short and time boxed meeting everyday. Once they see the benefits of shorter sprints , timeboxes and demonstrated values, they become the biggest supporters. In fact the opposing party stakeholder I mentioned in earlier article, went on to be the biggest agile champion in that organization.

For this short sprints to succeed its really important to have goals that can be measured and have a product backlog that is well refined. More about that in my next post…

Driving an Agile Transformation in Agile Way :: Defining a Concrete Business Value

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!

Agile Transformation in An Agile Manner

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!