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
- 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”
- 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
- 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.
- 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
- 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.
- 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!
Agile Transformation is the process of transforming an organization’s culture and nature to one of agility. Transformation is about a fundamental change in the way people think and feel. Some people distinguish this from adoption by calling agile adoption “doing agile” and agile transformation “being agile”.
The group of articles which I would be publishing in this category is about my experience in managing Agile Transformations.
I am Snehamayee!!!
Who Am I? A rather philosophical question. I am a mom …Am a passionate coder.. also a wild life enthusiast…I am in love with software assurance… I live my life with agile values and Principles … Really? I am a glass that shows a different color depending upon the angle you see it from… There are so many sides of me that I usually restrict my introduction to this one line – “I am Snehamayee”
With over 19 years of experience in Software Industry , I have worked across all phases of SDLC. I have wide experience over all phases of SDLC , I have worked across geographies and project types. My Niche Skills Include
- Opening New Logos for TCS using Assurance As A Lever
- Organizational coaching to drive quick and consistent ROI during their agile/DevOps transformation
- Creating Customer focused Assurance Strategies that enable QA function to be a transformation lever that will drive technology excellence
- Creating Assurance /Testing strategy for projects in AGILE and DevOps Models
I am a passionate career tester and always strive to increase mind share and “assurance” brand recognition within the region. I believe that for modern sofware ecosystem,Assurance will bring value rather than mere testing….My objective is to enable QA to be a value centre rather than a cost centre.
Over the years, I have seen it exceedingly useful to apply Agile values and principles to all aspects of my life. It really excites me to share this experience with others who want to start their journey on the agile road.
Certifications That I hold
1 – PSM-2 by scrum.org
2 – PSM-1 by scrum.org
3 – CSP by Scrum Alliance
4 – CSM by Scrum AlliancePSM -I by scrum.org
5 – CSPO by Scrum Alliance
6- PMI ACP
7 -Exin DevOps Master
Welcome to my world! This blog is meant to be a “slice in my day” .. I plan to write about many things that interest me … to start with I plan to write about agile , devops, testing – things that interest me professionally