Written for :
I was dreading the idea of sitting thru a 2 hour keynote session. To my surprise, I quiet enjoyed the content and the delivery of speakers. I actually enjoyed listening to Amit Chatterjee, Managing Director - Microsoft R&D Pvt Ltd, talk around a flavour of scrum methodology inspired by Eric Ries's The Lean Startup. He talked about how Microsoft R&D has successfully adopted scrum and has become more agile in the last few months. I simply loved the Nordstorm Stores example he presented.
The Nordstorm example set me thinking. Does the next
generation impatience and need for instant gratification and results , need a
completely different model of execution? When business and operations within an
enterprise ideate, they are bound to be assumptions, risks and and unwillingness to entertain any failure on a large scale. Failure is still a
stigma in most enterprises despite claims of nurturing innovation and asking
people to challenge their boundaries without the fear. New ideas are
new, by virtue of being un-thought of before, and hence untested and not yet
proven. They are either hypothesis or a bundle of initiatives designed to achieve an objective laced around a foundation of hypothesis and assumptions. These hypothesis need to be put to test without
building definitively, a system or a solution around that idea. Nordstorm sent a couple of
developers to he floor shop. These guys took the business hypothesis and talked to
Nordstorm's customers. Got inputs from them. Coded on the
spot and got customers to use and experience it. They
built-in the learning by making changes to the code, in front of the customers and got them too try using the application again. By the end of the
exercise there were multiple iterations involving collaborating with shoppers on ideation - coding a solution
- getting shoppers to interact with the applications - build in the learning. By the end of the exercise, they had the true picture of what the success criteria for the application should be and the metrics they should use to measure the success criteria. Sometimes, enterprises guess these on behalf of the customers and hence possibly get it wrong sometimes.
I have seen and experienced scrum models where requirements are broken down into small chunks, after which a traditional approach is followed where business analysts (BAs) write down requirements, effort estimation is done and development happens in isolation. This model again results in user depts accusing BAs of missing out requirements, which in reality was a result of lack of bandwidth with the business users and most of the times, the lack of will to spell out everything to the last T. Why do IT teams ask business requirements as if they are part of a different organisations? Why do we need to carry IT on the payroll if they cant figure out business requirements as an integral part of the business? These frustrating questions and scenarios can be avoided by following scrum they way it should be. Developers get the taste of the real world and the rest of the organisation starts appreciating the value IT brings on the table. Developers help the business users see the issues with their business hypothesis. This results in all-round appreciation for each other's efforts.
What I personally like about this approach is that it gives
an opportunity to take what we have and make it a little better every day. This
method greatly helps drive change management where impact is needed on the behaviour of stake-holders
for the innovation to deliver and be effective. Stakeholders go thru the process of experiential learning
during the build phase, rather than being forced to change behaviour post
build-out; during the end user training phase of the project. This approach
helps in facilitating a more cordial environment during end user testing and
acceptance stages of the project. The biggest outcome of this method will be
reduction in rejection of ideas. Management that is unable to visualize the benefits or finds change management around the idea over whelming typically label such ideas as either bad, ambitious and unpractical. The Build-Measure-Learn model executed with scrum methodology, helps evaluate ideas based on experiential learning rather than on perceptions power point presentations create.
I was dreading the idea of sitting thru a 2 hour keynote session. To my surprise, I quiet enjoyed the content and the delivery of speakers. I actually enjoyed listening to Amit Chatterjee, Managing Director - Microsoft R&D Pvt Ltd, talk around a flavour of scrum methodology inspired by Eric Ries's The Lean Startup. He talked about how Microsoft R&D has successfully adopted scrum and has become more agile in the last few months. I simply loved the Nordstorm Stores example he presented.
The Nordstorm example set me thinking. Does the next
generation impatience and need for instant gratification and results , need a
completely different model of execution? When business and operations within an
enterprise ideate, they are bound to be assumptions, risks and and unwillingness to entertain any failure on a large scale. Failure is still a
stigma in most enterprises despite claims of nurturing innovation and asking
people to challenge their boundaries without the fear. New ideas are
new, by virtue of being un-thought of before, and hence untested and not yet
proven. They are either hypothesis or a bundle of initiatives designed to achieve an objective laced around a foundation of hypothesis and assumptions. These hypothesis need to be put to test without
building definitively, a system or a solution around that idea. Nordstorm sent a couple of
developers to he floor shop. These guys took the business hypothesis and talked to
Nordstorm's customers. Got inputs from them. Coded on the
spot and got customers to use and experience it. They
built-in the learning by making changes to the code, in front of the customers and got them too try using the application again. By the end of the
exercise there were multiple iterations involving collaborating with shoppers on ideation - coding a solution
- getting shoppers to interact with the applications - build in the learning. By the end of the exercise, they had the true picture of what the success criteria for the application should be and the metrics they should use to measure the success criteria. Sometimes, enterprises guess these on behalf of the customers and hence possibly get it wrong sometimes. 
Amit
talks about making the business hypothesis a testable experiment. It makes
sense to get all stake holders whose lives will be impacted by the hypothesis
(employees, partners and customers) around a table for the experiment and digest
their take on the hypothesis. What you then get is a Minimum Viable Product
(MVP). Measurement to calibrate the results need to be included in MVP. Once
MVP is coded and ready, validation against the embedded measures is done as users use the MVP.
Learning is gained, which then find their way back into the MVP. Measures are
re-adjusted and or re-calibrated. The cycle repeats again. The important part
being, that all stake-holders traverse this cycle together.
Somewhere during this cyclic iteration, there will be
enough learning based on which you could choose to persevere with the
hypothesis or pivot to a new hypothesis. Before you guys jump to conclusion,
let me tell you what this process is not. This is not a process to decide
what a end product should be. This is a process to test the business hypothesis by studying
customer behaviour.
User departments and end customers of the enterprise are
very good at articulating their need at a very high level. As devil is always
in the details, The Build-Measure-Learn approach avoids the creation of a wall between IT and the
rest of the organisation and between the organisation and the end customer.
Just as IT is accused of not understanding it's internal customers,
organisations are accused of not understanding the needs of their end
customers.
Coding as a part of structured ideation process, to test hypothesis, helps in avoiding scenarios where IT teams
accuse user departments of not giving detailed requirements in entirety and IT
teams do not have to deal with the frustration of changing requirements. This
approach avoids the Big Bang model around conceptualisation, requirement gathering and delivery.
I have seen and experienced scrum models where requirements are broken down into small chunks, after which a traditional approach is followed where business analysts (BAs) write down requirements, effort estimation is done and development happens in isolation. This model again results in user depts accusing BAs of missing out requirements, which in reality was a result of lack of bandwidth with the business users and most of the times, the lack of will to spell out everything to the last T. Why do IT teams ask business requirements as if they are part of a different organisations? Why do we need to carry IT on the payroll if they cant figure out business requirements as an integral part of the business? These frustrating questions and scenarios can be avoided by following scrum they way it should be. Developers get the taste of the real world and the rest of the organisation starts appreciating the value IT brings on the table. Developers help the business users see the issues with their business hypothesis. This results in all-round appreciation for each other's efforts.
What I personally like about this approach is that it gives
an opportunity to take what we have and make it a little better every day. This
method greatly helps drive change management where impact is needed on the behaviour of stake-holders
for the innovation to deliver and be effective. Stakeholders go thru the process of experiential learning
during the build phase, rather than being forced to change behaviour post
build-out; during the end user training phase of the project. This approach
helps in facilitating a more cordial environment during end user testing and
acceptance stages of the project. The biggest outcome of this method will be
reduction in rejection of ideas. Management that is unable to visualize the benefits or finds change management around the idea over whelming typically label such ideas as either bad, ambitious and unpractical. The Build-Measure-Learn model executed with scrum methodology, helps evaluate ideas based on experiential learning rather than on perceptions power point presentations create.
It's always a good approach to talk about a new idea and
invite stakeholders to test the hypothesis as a collaborative exercise in the build
up of the idea and subsequently on solution creation phase, instead of constructing the idea in
isolation and then hard-sell it to the management. The
challenge is in change management around adoption and not in ideation or executing the system build up. This approach gets people to collaborate to make
change management relatively easier by virtue of collaborating in build up of
the idea.
written for :
written for :
No comments:
Post a Comment