Client Reviews: From Waterfall to Agile

We are currently transforming a large organization with 200+ people to adopt new agile behaviors. The transformation started off with identifying 3 pilot projects to be the first adopters of agile skills and techniques.

The 3 projects started their agile journey with creating a story map to organize and visualize their business requirements. The story mapping technique enabled the project teams to decompose their projects into features that can be managed independently. As a start, they used their current business requirements document and transformed it into a story map. The story map was then used as visual tool to drive discussions with business on feature creation and prioritization.

After decomposing the project into features, the teams created their Kanban boards with policies to manage the flow of work through the system. The teams’ set up regular cadence for standup meetings to provide updates on tickets, raise and resolve risks, issues, and blockers.

The new approach received positive feedback from business as a result of engaging them in more frequent discussions. Business is now working closely with project teams to get acquainted with the new tools and processes. Currently they have setup regular meetings with business to address business and IT perspectives on features and how they will be grouped into MMFs. The new processes and Kanban have provided project teams and business a collaborative and transparent approach to manage their projects.

Below are pictures from project Kanban boards and the team’s feedback on the new process and Kanban.

Pilot Project 1

• “The story board has been instrumental in identifying gaps between the requirements and potential solution.”
• "Although our project is still very early in the Kanban process we have found definite value in the visual and collaborative aspects of the model.”
• “Having standups helps to ensure everyone on the team is familiar with the state of the project, what issues are currently open and also creates an opportunity for everyone to brainstorm and provide input when required.”
• "Main challenges that I have seen are firstly trying to learn and pilot the model in a medium/high complexity project (learning curve) as well as adjusting everyone's views to how the project would be approached compared to a standard waterfall model.”
• "Trying to retrofit a project that started as waterfall is challenging e.g. high level requirements doc (updated, revised) in progress when Kanban training started; developing project plan with business partner who had not yet been exposed to Kanban, and moving forward adapting to Kanban technique.”
• "Learning and application happening at the same time (don't feel there is sufficient time allowed in the project timeline to 'practice' techniques/adjust our processes before putting it in front of the client; making mistakes as part of our learning can affect our credibility, especially in a culture that traditionally is not failure/mistake-tolerant.”

Pilot Project 2

• “One could easily understand the work flow and identify the bottleneck to re-distribute the work load.”
• "It makes work more interesting and more transparent.”
• “It also helps me to find where is my position in this project and the relation between my tasks and others, and who will be affected if the task cannot be delivered on time.”
• “The most challenging part is defining meaningful tasks (fine-grained) or feature sets and reduce the coupling (dependency) between tasks, which is the key part to make the whole workflow goes smoothly.”
• “Switching to Kanban in mid project hasn't been easy. some overhead was encountered  getting everyone up to speed but project timelines weren't changed”

Pilot Project 3

• “The daily standups promote communication between my peers.”
• “Helpful to identify road blocks and the opportunity to resolve more quickly.”
• “Using Kanban, we can trace the project activities, and find the bottleneck (blocker) in the different phases.”
• “Business stakeholders wanting to drive Kanban activities before they are fully understood. Often the business PM is not clear and causes confusion.”
• “Clarify the role and responsibilities of the Kanban Champion in relation to the Project, how they interact with business - this is not clear and is causing confusion.”
• “I feel that we have a challenge to get blocker removed quickly and efficiently, and define the delivery timeline/milestone for each MMF.”

Integrating Story Mapping with Kanban

Piloting projects on Kanban requires projects team to re-think the old way of consuming requirements and move towards a more structured approach. As a start, large scale projects must be decomposed into features that can be managed independently. In a lot of organizations we find requirements in the form of a business requirements document. Usually:

•        The requirements are not organized to show the value provided from a user perspective
•       There is no priority assigned to the requirements with respect to the other requirements
•       Endless discussions with business to finalize and “lock” the scope of the project

We have had great experience using story mapping to help teams address the challenges that often find in a typical business requirement document. We have been integrating story mapping with Kanban to enable teams to start thinking in an agile approach from day 1.

1- Creating features is a collaborative exercise where the project team and business stakeholders list and organize the features in a sequence of events that deliver value from a user perspective.

2- For each of the activities, the features are prioritized with respect to each other.

After the features are prioritized, the team can now start creating MMFs by slicing the map horizontally.

3-     The prioritized features and MMFs from the story map can then be used to populate the Kanban board. 

 

The story mapping techniques enables teams to see the bigger picture and the scope of the project. As a result, this technique helps project teams to think about features and releases from a holistic project perspective.

My Definition of a Minimum Viable Change - Lean Startup For Change

I've submitted numerous posts on Lean Startup 4 change. Time to put a stake in the ground and define exactly what I mean by a Minimum Viable Change.

To properly understand how to define a Minimum Viable Change we need to understand what we are trying to measure...

yes you...

Therefore I define a Minimum Viable Change as follows...

Please note that this post does not endorse the use of heroics on projects of any kind...

The Gamification of A Kanban IT Transformation

My last post discussed how I and my team were using a transformation participation engine to provide our change team with metrics necessary to support validated learning for our change effort.  Aside from enabling a Lean Startup approach for our change effort, we also plan to use the data set captured  within our engine to Gamify our transformation.

Different transformation  campaigns (eg Kanban, Agile, Dedicated Quality Office, etc)  have been broken into explicit learning tracks. Each learning track has been further refined into specific skills that we hope our clients acquire as part of the transformation. We are tracking our progress (note NOT progress of folks who are learning) as the number of staff and managers who acquire specific skills.

In order to add an element of Gamification to the transformation, we plan to introduce the notion of behavior / change points. Skills are acquired through completion of explicit behaviors. Each behavior when exhibited provides a specified amount of points. 

The gamification aspect comes in because behaviors can only be acquired from folks who have 

A) already acquired the skill that the behavior belongs to

B) have a point reservoir equal to the behaviour being acquired.

Behaviors are acquired by "transferring points" from on person to another. This has some interesting implications.

1) you must find a mentor to acquire a skill, it's not up to the change team or managers to validate your progress, it's a pure peer system

2) you can only give your points away once, after that the pupil must become a teacher or the system dies

3) giving someone credit prematurely is limited because both you and your mentor will look foolish if you are called out.

Our first Minimum Viable Change using this approach will be to setup a manual Leaderboard outside of a Kanban based standup, and measure wether there is desired change in behavior. Or wether people throw eggs at us...

Depending on success, we also plan to prototype some character sheets, periodically updated manually by our team.

If Gamification proves to be a hit than we will figure out how to automate all this stuff ...