Or from whatever you are doing to Agile!!
The below are my notes during my last major Agile implementation. The existing setup was archaic and as a result several of our projects were in a mess. It was tough working with mature professionals and waterfall die-casted individuals. But it turned into a great learning experience when I started using their expertise in the area and convincing them to adopt the Agile ways of working. My motive was always to prove that the ceremonies have not changed but only the objectives and expectations from the ceremonies have changed. Pardon me if the below notes look rough; they are here only to serve as a quick reference for me.
But no harm if you can make any sense out of it. Do connect if you have any doubts
My adventures with Agile implementation has convinced me that even if I am in an engagement as a service provider, it is almost always my and my teams job to provide the guidance to enable the Waterfall to Agile transformation.
Business Analyst converted the Project requirements into EPICS – The platform team converted them into stories and provide feedback if they can be closed . Included into Platform team Backlog.
A technical background of working as datawarehouse DWH Project Manager does help in getting this done.
It took 6-7 months to prove that it can be done and Platform team Model will work and is cheaper than separate projects teams making changes to the same system.
Benefits shown due to consolidated testing and reduced refactoring costs.
Some of the projects were Agile as a program and it was a organisation mandate to move top Agile. That helped push in some of the practises and provided motivation for the clients to learn and adapt to Agile
Estimation . Team Structure were changed to form platform teams. With my platform team being the pilot to try out the new model.
Some of my project’s were already Running as Agile at the program level.
—
PBS with the projects (sessions) were encouraged to educate to write user stories
—
Ideal Days – Estimation technique was used for easy transformation from waterfall to Agile Estimation
After 2 release moved to T-shirt & Affinity estimation Technique. This area is still the biggest challenge because as service provider we require to provide time-bound commitment, which is difficult in an Agile model.
—
Problem of confirming the duration of the project because the velocity of the team could not be defined.
Being a service provider with demand changing every quarter, Ramp Up and Ramp down every quarter, Resource/Skill retention has been a problem. Team Dynamic changes.
The velocity of my platform team for one of the stream/DWH Area, we have reached fare confident Velocity which we are able to sustain ever since.
—
Release planning
There was an attempt to replicate the waterfall release planning method into iterations. I helped interpret the Epics (features from Projects) into our consolidated Platform Team Product backlog. The project/programme Manager decided and approved the target release for the features (Epics)
The Platform team enabled reduction in testing and release management efforts if managed via the Platform Team Backlog.
—
During the course of the transformation a new monthly release model introduced across the organisation.
Some of the projects have matured to be able to size the Epics, Stories, MVPs to fit Monthly Releases.
I have moved out of the role but the challenge of educating the Business to commit to Stories, MVP’s which fit into Monthly release exists.
Two ways demonstrated to mitigate the issue :-
- Go into specific releases and skip intermediate releases.
Many have adopted the method of skipping monthly releases and only go into specific releases.(some every 2 months to accommodate longer Integration Testing window)
This is because of the need to have a testing window E2E from frontend to Target system via the DWH ETL.
- Reduce Story Size by splitting based on Functional and Non-Functional Deliverables
First Functional – with technical go live to Production and supported by Platform Team.
After Business signoff of the functionality the non-functional stories along with regression testing to meet the Support Handover – Operational Acceptance requirements. Post that Warranty Support before handover to Support Teams.
—
Prioritisation, Backlog Review, Iteration planning
Participated in prioritisation meeting for the projects, Introduced MoSCoW method used to help the project teams to identify prioritisation .
Provided complexity inputs using Kano Sessions in programs which were matured in Agile. This helped projects decide on priority.
Represent the platform team along with the client platform team owner in scrum of scrums.
—
Help the team in Iteration planning
—
Being a DWH project challenge of providing visible benefit in early sprints since only the ETL skeleton is built. Workshops with Product Owner and other Project stakeholder to showcase the situation with skeleton or flow diagrams.
Explained the challenge of DWH world and the latency required to build the framework before actual data items can be passed via the ETL/DWH route.
My experience in the DWH and ETL helped me represent the domain/platform team in resolving such situations with the various projects.
We were also very successful due to adequate support from client TQA and enough education towards DWH in AGile
–
Subject: Agile implementation
Transitioning from waterfall to Agile
As service provider we provided the guidance to implements Agile
Estimation
Team Structure were changed to form platform teams. With my platform team being the pilot to try out the new model.
Some of my project’s were already Running as Agile at the program level.
—
PBS with the projects (sessions) were encouraged to educate to write user stories
—
Ideal Days – Estimation technique was used for easy transformation from waterfall to Agile Estimation
After 2 release moved to T-shirt & Affinity estimation Techq
—
Release planning stayed as is with the project/programme Manager. I helped interpret the Epics (features from Projects) into our consolidated Platform Team Product backlog.
The Platform team enabled reduction in testing and release management efforts if managed via the Platform Team Backlog
—
Release Planning , After 1 year new release model introduceed with monthly release.
Soe of the projects have matured to be able to size the Epics, Stories, MVPs to fit Monthly Releases.
I have moved out of the role but the challenge of educating the Business to commit to Stories, MVP’s which fit into Monthly release is still a challenge.
Many have adopted the method of skipping monthly releases and only go into specific releases.(some every 2 months to accommodate longer Integration Testing window)
This is because of the need to have a testing window E2E from frontend to Target system via the DWH ETL
—
Problem of confirming the duration of the project because the velocity of the team could not be defined.
Being a service provider with demand changing every quarter, Ramp Up and Ramp down every quarter, Resource/Skill retention has been a problem. Team Dynamic changes.
The velocity of my platform team for one of the stream/DWH Area, we have reached fare confident Velocity which we are able to sustain ever since.
—
Prioritisation, Backlog Review, Iteration planning
Participated in prioritisation meeting for the projects, MoSCoW method used to help the project teams to identify prioritisation .
Provided complexity inputs while the matured Projects decided priority using Kano Sessions.
—
Represent the platform team along with the client platform team owner in scrum of scrums.
—
Help the team in Iteration planning
—
Being a DWH project challenge of providing visible benefit in early sprints since onlt the TEL skeleton build. Workshops with Product Owner and other Project stakeholder to showcase the situation with skeleton or flow diagrams.
Explained the challenge of DWH world and the latency required to build the frameowrk before actual data items a can be passed via the ETL/DWH route.
My experience in the DWH and ETL helped me represent the domain/platform team in resolving such situations with the various projects.
We were also very successful due to adequate support from client TQA and enough education to the DWH in AGile
—
WaterfAll to Agile
Business Analyst converted the Project requirements into EPICS – The platform team converted them into stories and provide feedback if they can be closed
Included into Platform team Baxcklog
-My technical background of working as offshore DWH Project Manager helped me get that done.
—
It took 6-7 months to prove that it can be done and Platform team Model will work and is cheaper than separate projects teams making changes to the same system.
—
Some of the projects werr Agile as a program and it was a organisation mandate to move top Agile. That helped push in some of the practises and provided motivation fro the clients to learn and adapt to Agile
—
Reduce Story Size by splitting based on Functional and Non-Functional Deliverables
First Functional – with technical go live to Production and supported by Platform Team.
After Business signoff of the functionality the non-functional stories along with regression testing to meet the Support Handover – Operational Acceptance requirements.Post that Warranty Support before handover to Support Teams
