Idea to Market: Day 3 - CAFCR+ and Scrum/Agile Development
After the introduction to the main concepts of the workshop that was Monday, Tuesday 13th of February was to be a full day of activity. Monday's session was a quick introduction in the CAFCR+ model and team building dynamics, Tuesday was for delving deeper into the concepts.
I had talked about the CAFCR+ model briefly in the previous post. In a bid to gain an understanding of the model, we were to design a product based on this model. The product that was to be designed was an incubator.
One of the very first exercises we did in the CAFCR+ model, was to figure out who the stakeholders of our test case system, the incubator, were. The stakeholders were defined as people who would affect and be affected by the product. It is an important exercise to go through as it does help put your ideas into perspective.
The exercises of the day where centred around exploring the Customer View, Application View and Functional View of the incubator system of interest. For instance, when looking at the Customer View, we had to look at the Customer in terms of: the hospital administration as they were the ones buying the equipment; the nurses since they were the ones handling the equipment; the baby since they are the ones who would be directly affected by the equipment. Thus, it was necessary to understand all these customer needs to come up with a holistic system.
For the Application View, this was basically what would be in the immediate environment of the incubator; you could have equipment like phototherapy units, vital signs monitoring machines among other things that you'd have to operate with the incubator. You'd also probably also consider how the incubators would be arranged in a ward to give more context to how they'd be used on a day to day basis.
The Functional View dealt with more or less about the inputs that the incubator took and the desired outputs that it gave. You could look at how the incubator was powered, and then how this power could be used to drive a heating element to provide a desired temperature in the incubator. So it's roughly getting to understand the various subsystems of the incubator and how you'd want them to come together.
Later on in the day, there was a discussion on value proposition and business modelling. The importance of taking the customer experience journey into consideration was stressed. This could be achieved by getting to know what annoys the customer versus what the customer likes. In the early stages of product development, it is beneficial to design different models that can be presented to the customer, and choosing the best one after testing them out. An interesting thing that was pointed out when it came to business modelling was that you should aim to disrupt, or you would be disrupted.
This day also marked the introduction to the scrum method of product development. Typically, we would assume that the best way to present a product to a customer is after you have dotted every "i" and crossed every "t", but that's really not the best practice. One thing that customers don't like is surprises. So don't wake up one morning and think I'll make this change in the product and the customers will be like wow; that kind of shock factor only works on TV.
As you develop your product, you have to keep the customer involved at every stage, with every change you make. It is extremely valuable to show a customer a mock up of a change you desire to implement, get their feedback before dedicating time and resources to that particular task.
Also, as you work, it is of great benefit to have a product backlog documenting what the customer wants, what you've done previously, and what you currently are working on.
One way of keeping taps on your progress is as outlined in the table below. Basically, you get what you'd call a customer story, which in essence is your customer telling you what it is that they'd like out of a products design, then you use that to come up with tasks and check the progress of each task.
Team building was explored further too. When forming a team, there are a couple of steps that have to be taken in the teams evolution:
One of the very first exercises we did in the CAFCR+ model, was to figure out who the stakeholders of our test case system, the incubator, were. The stakeholders were defined as people who would affect and be affected by the product. It is an important exercise to go through as it does help put your ideas into perspective.
The exercises of the day where centred around exploring the Customer View, Application View and Functional View of the incubator system of interest. For instance, when looking at the Customer View, we had to look at the Customer in terms of: the hospital administration as they were the ones buying the equipment; the nurses since they were the ones handling the equipment; the baby since they are the ones who would be directly affected by the equipment. Thus, it was necessary to understand all these customer needs to come up with a holistic system.
For the Application View, this was basically what would be in the immediate environment of the incubator; you could have equipment like phototherapy units, vital signs monitoring machines among other things that you'd have to operate with the incubator. You'd also probably also consider how the incubators would be arranged in a ward to give more context to how they'd be used on a day to day basis.
The Functional View dealt with more or less about the inputs that the incubator took and the desired outputs that it gave. You could look at how the incubator was powered, and then how this power could be used to drive a heating element to provide a desired temperature in the incubator. So it's roughly getting to understand the various subsystems of the incubator and how you'd want them to come together.
Later on in the day, there was a discussion on value proposition and business modelling. The importance of taking the customer experience journey into consideration was stressed. This could be achieved by getting to know what annoys the customer versus what the customer likes. In the early stages of product development, it is beneficial to design different models that can be presented to the customer, and choosing the best one after testing them out. An interesting thing that was pointed out when it came to business modelling was that you should aim to disrupt, or you would be disrupted.
This day also marked the introduction to the scrum method of product development. Typically, we would assume that the best way to present a product to a customer is after you have dotted every "i" and crossed every "t", but that's really not the best practice. One thing that customers don't like is surprises. So don't wake up one morning and think I'll make this change in the product and the customers will be like wow; that kind of shock factor only works on TV.
As you develop your product, you have to keep the customer involved at every stage, with every change you make. It is extremely valuable to show a customer a mock up of a change you desire to implement, get their feedback before dedicating time and resources to that particular task.
Also, as you work, it is of great benefit to have a product backlog documenting what the customer wants, what you've done previously, and what you currently are working on.
One way of keeping taps on your progress is as outlined in the table below. Basically, you get what you'd call a customer story, which in essence is your customer telling you what it is that they'd like out of a products design, then you use that to come up with tasks and check the progress of each task.
STORY
|
TO DO
|
IN PROGRESS
|
VERIFY
|
DONE
|
This is the specification of what the customer wants
|
This are the tasks that you need to do to meet the
customers specifications
|
This are the tasks you are currently working on
|
This are tasks that have be completed but must be checked
against the customer’s requirements
|
This are completed tasks that meet the customer’s
requirements
|
Team building was explored further too. When forming a team, there are a couple of steps that have to be taken in the teams evolution:
- Orientation
- Trust Buidling
- Goal Clarification
- Commitment
- Implementation
- High Performance
- Renewal
The orientation was what I had mentioned in the previous post concerning the roles the individuals forming the group are capable of playing.
For the trust building phase, what is of importance is that there should be a free and constructive flow of information. Because if the flow is restricted then there really isn't much than can be done with ease.
What one needs to look out for during the goal clarification phase is to understand whether everyone is on the same page as far as the team is concerned. There has to be an understanding as to why the team was formed in the first place. And you've got to figure out how to translate the company strategies into the team's goals.
That was the gist of the third day of the workshop. Day 4 got a little bit more legal, because we got to explore a little bit on intellectual property with the help of an intellectual property lawyer. That was a highlight of the week that you should check out if your interested in coming up with your own innovations in future.
That was the gist of the third day of the workshop. Day 4 got a little bit more legal, because we got to explore a little bit on intellectual property with the help of an intellectual property lawyer. That was a highlight of the week that you should check out if your interested in coming up with your own innovations in future.
Index
Labels: Fablab, Idea to Market, Makerspace, Philips
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home