Tuesday, 18 December 2018
Tuesday, 12 June 2018
More thoughts on Business Value
In this highly dynamic and fast paced world, one would tend to think that lead time of features would make sense for business and more so with DevOps and Continuous deployment gaining ground.
Is it so straightforward?
If the application under question is web-based and B2C more likely the case. If it is a product deployed in the customer organization (in a B2B context) it starts getting tricky. The Product house may develop newer features and newer function, but the customer organizations may not have the appetite to upgrade. More so if there is data migration or significant downtime involved. In such contexts it is not uncommon to see many versions being supported and fixing defects and propagating the fixes across different versions makes it a configuration management nightmare. Probably solving this conundrum through a credible software or a business strategy provides more business value than churning out newer features.
At a much different level of an organizational discourse, it is quite possible that responsiveness is valued. Which would mean that cross-functionalism within teams and between teams is encouraged. This would in turn translate into a lesser throughput of new features. Perfectly valid!
My next post on Evidence based management!
Thursday, 24 May 2018
Deciphering Value in an Agile set-up - Business Value, Customer Value and User Value
This post is a sequel to my talk on the same subject in APGI conference in Pune on 18th May, 2018.
Delivering Business Value is something all scrum teams target. Product Owner defines the Product Backlog Items prioritizes with the perspective of maximizing Value. The development team being able to complete them helps deliver Business Value.
The scrum guide talks of it in its definition of Scrum as "A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value."
It further talks of the Product Owner being responsible for maximizing the value of the product and Optimizing the value of the work the Development Team performs.
In case of the Scrum Master the guide talks of helping everyone [stakeholders] change these interactions [with scrum team] to maximize the value created by the Scrum Team.
In the section on Scrum Master Service to the Product Owner, it again talks of
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
In the section on Scrum Master Service to the Development Team
• Helping the Development Team to create high-value products;
There are references to Value in Sprint Review, Scrum Artifacts and Product Backlog.
Beyond these references, the Scrum Guide does not explicitly talk of what Value means.
If this the focus of the Scrum team, let us examine what is meant by Value.
In his book The Art of Business Value, author Mark Schwartz talks of the distinction between three types of Value - Business Value, Customer Value and User Value. Typically customer is the one who pays for the value or service and users are the ones who ultimately work on the software. In a general sense, Business value is treated as equal to revenue or profits. Users represent the end-users. Depending on whether who pays for it is the one who uses it, these 3 roles will differ.
In any Agile system development context, understanding how these three types of Value play out is critical to formulating it for the product / application at hand and translating it into PBIs for translating into working software.
Let us examine how these roles play out in differing contexts.
Case 1: Captive in-house centers
This is where a company has an in-house set-up to develop software for its own use. The customer is internal and hence Business is the same as customer. The users are the internal users of the software.
Case 2: B2C businesses
This is where a company has an business targeting retail customers. The customer is external and hence Customer is same as the user. There may also be users internal to the company and consume functionality related to finance, logistics and retail analytics.
Case 3: B2C businesses with agents or suppliers
This is a variant of Case 2, but there is a significant constituency of suppliers or agents which the company works with. There is significant functionality targeted at these users.
Case 4: Software Product company.
This is where a company has an business targeting corporate customers. Business is represented by the Product house and the customer is the corporate house and users of the software (internal or external to the customer) form the third category.
As Mark Schwartz explains in his book, it is quite possible that what is of value to the customer may not be valuable to Business and vice versa.
Ideal scenario is where Business Value and Customer Value converge.
What when they diverge? There is customer value and little Business Value?
Like a hotel taking a conscious call to discourage low-staying customers or telcos weaning away low-value customers. Legitimate business strategy but but not all customers are happy. Or what I myself have experienced with Ola a cab aggregator in india and a market leader.
I have opted for a Select package paying a rental fee for a month. That means I get cabs on priority, high rated drivers and peak rates are not applied. That applies to just couple of vehicle types and couple of others are out of the rate cap. In evenings when I return from work, when demand is at its peak, I never get vehicles even though vehicles appear to be available. Then I found out why, for Ola it makes better business sense to allocate its vehicles to customers without rate cap - where they have maximum profitability. So even I get vehicles when I opt for two vehicle types outside of Select. And yes, I pay peak rates. More business value, but they are losing trust big time.
As this article in Bieberlabs argues, over reliance on Business value reduces the customer connect in the longer run and reduce the revenue and profitability in longer run.
Alternately, there are many cases where there is a clear case of customer value but little business value. I use the Indian Railway booking site IRCTC. Tickets are booked well in advance and many a time its a long wait list which greets the customers. What if IRCTC, based on the historical data pile it sits on, gives an indication of a particular wait-listed position to get confirmed? Prior to a customer / user booking a ticket. Great customer value but poor business value. IRCTC will lose out holding cash for so many tickets for a quite a few days - which adds to its working capital. In addition it loses out on ticket booking fee and likes.
Tough choice really.
Now where user is a customer as in a B2C case, the voice gets heard. In case of internal users or internal users of a customer using a software product, there is a certain lag before the voices could be heard. As Mark Schwartz illustrates in his book, user value may be in divergence with customer / Business value. For instance, the management may go in for optimized processes through the new software implementation but users may not be for it. May be a huge change for them.
No easy options!
Delivering Business Value is something all scrum teams target. Product Owner defines the Product Backlog Items prioritizes with the perspective of maximizing Value. The development team being able to complete them helps deliver Business Value.
The scrum guide talks of it in its definition of Scrum as "A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value."
It further talks of the Product Owner being responsible for maximizing the value of the product and Optimizing the value of the work the Development Team performs.
In case of the Scrum Master the guide talks of helping everyone [stakeholders] change these interactions [with scrum team] to maximize the value created by the Scrum Team.
In the section on Scrum Master Service to the Product Owner, it again talks of
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
In the section on Scrum Master Service to the Development Team
• Helping the Development Team to create high-value products;
There are references to Value in Sprint Review, Scrum Artifacts and Product Backlog.
Beyond these references, the Scrum Guide does not explicitly talk of what Value means.
If this the focus of the Scrum team, let us examine what is meant by Value.
In his book The Art of Business Value, author Mark Schwartz talks of the distinction between three types of Value - Business Value, Customer Value and User Value. Typically customer is the one who pays for the value or service and users are the ones who ultimately work on the software. In a general sense, Business value is treated as equal to revenue or profits. Users represent the end-users. Depending on whether who pays for it is the one who uses it, these 3 roles will differ.
In any Agile system development context, understanding how these three types of Value play out is critical to formulating it for the product / application at hand and translating it into PBIs for translating into working software.
Let us examine how these roles play out in differing contexts.
Case 1: Captive in-house centers
This is where a company has an in-house set-up to develop software for its own use. The customer is internal and hence Business is the same as customer. The users are the internal users of the software.
Case 2: B2C businesses
This is where a company has an business targeting retail customers. The customer is external and hence Customer is same as the user. There may also be users internal to the company and consume functionality related to finance, logistics and retail analytics.
Case 3: B2C businesses with agents or suppliers
This is a variant of Case 2, but there is a significant constituency of suppliers or agents which the company works with. There is significant functionality targeted at these users.
This is where a company has an business targeting corporate customers. Business is represented by the Product house and the customer is the corporate house and users of the software (internal or external to the customer) form the third category.
As Mark Schwartz explains in his book, it is quite possible that what is of value to the customer may not be valuable to Business and vice versa.
Ideal scenario is where Business Value and Customer Value converge.
What when they diverge? There is customer value and little Business Value?
Like a hotel taking a conscious call to discourage low-staying customers or telcos weaning away low-value customers. Legitimate business strategy but but not all customers are happy. Or what I myself have experienced with Ola a cab aggregator in india and a market leader.
I have opted for a Select package paying a rental fee for a month. That means I get cabs on priority, high rated drivers and peak rates are not applied. That applies to just couple of vehicle types and couple of others are out of the rate cap. In evenings when I return from work, when demand is at its peak, I never get vehicles even though vehicles appear to be available. Then I found out why, for Ola it makes better business sense to allocate its vehicles to customers without rate cap - where they have maximum profitability. So even I get vehicles when I opt for two vehicle types outside of Select. And yes, I pay peak rates. More business value, but they are losing trust big time.
As this article in Bieberlabs argues, over reliance on Business value reduces the customer connect in the longer run and reduce the revenue and profitability in longer run.
Alternately, there are many cases where there is a clear case of customer value but little business value. I use the Indian Railway booking site IRCTC. Tickets are booked well in advance and many a time its a long wait list which greets the customers. What if IRCTC, based on the historical data pile it sits on, gives an indication of a particular wait-listed position to get confirmed? Prior to a customer / user booking a ticket. Great customer value but poor business value. IRCTC will lose out holding cash for so many tickets for a quite a few days - which adds to its working capital. In addition it loses out on ticket booking fee and likes.
Tough choice really.
Now where user is a customer as in a B2C case, the voice gets heard. In case of internal users or internal users of a customer using a software product, there is a certain lag before the voices could be heard. As Mark Schwartz illustrates in his book, user value may be in divergence with customer / Business value. For instance, the management may go in for optimized processes through the new software implementation but users may not be for it. May be a huge change for them.
No easy options!
Saturday, 24 June 2017
Factors affecting user story cycle time
Importance of user story cycle time cannot be over emphasised within Scrum.
Why is it so important?
It gives us useful insights into several aspects of how the team practices scrum. In fact it can be the one single indicator for agile maturity of the team (?)
Cycle time in the context of a user story would be days between team starts implementing a story and when it is "done". Is it OK to complete most or all of the stories in last 1-2 days of the sprint?
Lesser the cycle time, the better it is.
What are the factors impacting it:
1. Well groomed story
A story well groomed means it adheres to INVEST principles - appropriately sized and "ready" to be taken up for development. This means there is less likelihood of serious queries / dependencies impeding the story completion within the sprint.
2. Story WIP is limited within a sprint
The team starts with few stories when the sprint starts and as and when the stories close the other story (ies) from the sprint backlog are taken up for implementation. Team has consciously worked on how many stories it wants to be "ongoing" at any point with a sprint. Thus the team works on a few stories and completes them within a few days. What this implies is that more than one developer works on a story and collaborate actively to complete the story - which leads to our next point.
3. Team swarm to complete stories
4. Sound CI infrastructure
Ability to build and deploy builds across environments is the key to smooth flow of stories towards completion. "Merge discipline" of the developers will avoid late integration challenges.
5. Team builds "quality in"
Story does not spend time going back and froth between testing and development.
A line graph of how the cycle time is evolving across the sprints will throw interesting insights into team's maturity.
Why is it so important?
It gives us useful insights into several aspects of how the team practices scrum. In fact it can be the one single indicator for agile maturity of the team (?)
Cycle time in the context of a user story would be days between team starts implementing a story and when it is "done". Is it OK to complete most or all of the stories in last 1-2 days of the sprint?
Lesser the cycle time, the better it is.
What are the factors impacting it:
1. Well groomed story
A story well groomed means it adheres to INVEST principles - appropriately sized and "ready" to be taken up for development. This means there is less likelihood of serious queries / dependencies impeding the story completion within the sprint.
2. Story WIP is limited within a sprint
The team starts with few stories when the sprint starts and as and when the stories close the other story (ies) from the sprint backlog are taken up for implementation. Team has consciously worked on how many stories it wants to be "ongoing" at any point with a sprint. Thus the team works on a few stories and completes them within a few days. What this implies is that more than one developer works on a story and collaborate actively to complete the story - which leads to our next point.
3. Team swarm to complete stories
4. Sound CI infrastructure
Ability to build and deploy builds across environments is the key to smooth flow of stories towards completion. "Merge discipline" of the developers will avoid late integration challenges.
5. Team builds "quality in"
Story does not spend time going back and froth between testing and development.
A line graph of how the cycle time is evolving across the sprints will throw interesting insights into team's maturity.
Thursday, 10 March 2016
Limiting WIP for Crowd Control
Couple of weeks back, I had a chance to attend the Mahamaham festival on 22nd Feb. 2016 in Kumbakonam town in Tamilnadu state, India.
It is one of the great Indian bathing festivals which happens typically once in 12 years. As against the other ones like Kumbh Mela or Godavari Pushkaram, which happen on a river this one happens in a huge tank.
This tank has multiple approaches and unlike with a bathing festival in a river, a tank offers limited space for devotees to take a dip. There is the auspicious day and within that day - the suitable time. Around the "holy hour" there is a huge rush and a huge possibility of a stampede. In 1992 event had a history of stampede related deaths. Typically half a million to one million devotees converge on the given day.
Now, to what stood out in terms of crowd management that day:
- There was one entry and one exit - a practice widely followed in most events. Entry through the eastern side and exit through the western side.
- There were 14 gates in the streets leading to the entry. These gates spatially well positioned, with the intent of curtailing peak crowding in the vicinity of the tank. During the peak bathing day, crowds were held in these different gates and released in batches. So at any point in time, the number people taking dip within the tank was well regulated.
The public authorities were clearly thinking in terms of how many people could take a dip at any point in time and entry into the tank area was based on that - clearly WIP limit in action.
I am actually reminded of the practice in a Tokyo Park about the token system to keep a tab on the number of visitors narrated by David Anderson in his Kanban "Blue Book".
Good showcasing of Lean Principles in Public domain.
Photo Credit: The Hindu / Web Edition / Feb. 22, 2016
It is one of the great Indian bathing festivals which happens typically once in 12 years. As against the other ones like Kumbh Mela or Godavari Pushkaram, which happen on a river this one happens in a huge tank.
This tank has multiple approaches and unlike with a bathing festival in a river, a tank offers limited space for devotees to take a dip. There is the auspicious day and within that day - the suitable time. Around the "holy hour" there is a huge rush and a huge possibility of a stampede. In 1992 event had a history of stampede related deaths. Typically half a million to one million devotees converge on the given day.
Now, to what stood out in terms of crowd management that day:
- There was one entry and one exit - a practice widely followed in most events. Entry through the eastern side and exit through the western side.
- There were 14 gates in the streets leading to the entry. These gates spatially well positioned, with the intent of curtailing peak crowding in the vicinity of the tank. During the peak bathing day, crowds were held in these different gates and released in batches. So at any point in time, the number people taking dip within the tank was well regulated.
The public authorities were clearly thinking in terms of how many people could take a dip at any point in time and entry into the tank area was based on that - clearly WIP limit in action.
I am actually reminded of the practice in a Tokyo Park about the token system to keep a tab on the number of visitors narrated by David Anderson in his Kanban "Blue Book".
Good showcasing of Lean Principles in Public domain.
Photo Credit: The Hindu / Web Edition / Feb. 22, 2016
Thursday, 11 February 2016
Is Scrum Master a full-time role?
This is a typical question which arises not just when agile teams are formulated but even as teams mature.
While debating whether it is a full-time role, I am certainly not suggesting or for that matter, even considering a situation where Scrum Master is shared between teams. That is a certain No.
The question is should a Scrum Master should do his role full-time or should take other tasks within the Sprint commensurate to his/her skill areas.
One can certainly argue that core tasks within the role - like conducting the agile ceremonies, removing impediments, facilitation & enabling, conflict resolution, promoting cross-functional and self-organizing behaviors and so on in that direction - demand a full-time role. Like how this scrum alliance article argues.
In my experience working in & coaching scrum teams, I have observed that in the initial days of agile and scrumming, there is a lot of work - setting up the agile ceremonies, sorting out bottlenecks, stakeholder coordination, improving team collaboration and helping the teams to get cleared of any "starting troubles".
As things start settling down, typically teams start displaying more cross-functional and self-organizing behavior. Sprint moves on its own, with the Scrum Master as a care-taker, intervening when needed.
In this situation, I suppose the Scrum Master should be free to take up delivery related tasks. May be for a limited fraction of his time. Thus a contributing Scrum Master remains in touch with his core skill, enabling him to pitch in for the team when needed and understands - on the ground, how user stories get done. Through this, Scrum Master in a very subtle way displays that he is also another team member taking up team's tasks, when there is an opportunity to do so.
I am against this idea of having a person dedicated for a leadership / management function - especially when adopting a methodology which emphasizes on delegation, team work and collaboration. That too when the team size is around 7-8 people.
Mike Cohn, in this article, though did not explicitly rule this option out, said that Scrum Master should be readily available for supporting the team. Should a Scrum Master just be waiting for situations where he needs to intervene? I would rather prefer he/she takes up some tasks in the meanwhile.
While debating whether it is a full-time role, I am certainly not suggesting or for that matter, even considering a situation where Scrum Master is shared between teams. That is a certain No.
The question is should a Scrum Master should do his role full-time or should take other tasks within the Sprint commensurate to his/her skill areas.
One can certainly argue that core tasks within the role - like conducting the agile ceremonies, removing impediments, facilitation & enabling, conflict resolution, promoting cross-functional and self-organizing behaviors and so on in that direction - demand a full-time role. Like how this scrum alliance article argues.
In my experience working in & coaching scrum teams, I have observed that in the initial days of agile and scrumming, there is a lot of work - setting up the agile ceremonies, sorting out bottlenecks, stakeholder coordination, improving team collaboration and helping the teams to get cleared of any "starting troubles".
As things start settling down, typically teams start displaying more cross-functional and self-organizing behavior. Sprint moves on its own, with the Scrum Master as a care-taker, intervening when needed.
In this situation, I suppose the Scrum Master should be free to take up delivery related tasks. May be for a limited fraction of his time. Thus a contributing Scrum Master remains in touch with his core skill, enabling him to pitch in for the team when needed and understands - on the ground, how user stories get done. Through this, Scrum Master in a very subtle way displays that he is also another team member taking up team's tasks, when there is an opportunity to do so.
I am against this idea of having a person dedicated for a leadership / management function - especially when adopting a methodology which emphasizes on delegation, team work and collaboration. That too when the team size is around 7-8 people.
Mike Cohn, in this article, though did not explicitly rule this option out, said that Scrum Master should be readily available for supporting the team. Should a Scrum Master just be waiting for situations where he needs to intervene? I would rather prefer he/she takes up some tasks in the meanwhile.
Monday, 4 January 2016
Cross-functionalism in agile teams - to what extent?
I was reading a Linkedin post by Steve Bockman about Siloing versus Specialization a couple of days back and it triggered this blog.
We have a team built from people of various specializations, typically we may not be able to deliver as a team and Cross-functionalism is seen as a desirable attribute within agile teams. Stretching the arguments for cross-functionalism do we imply that specialization is undesirable within a team?
Specialization in the Industrial age meant that the person focuses on one area of the Production process and because of the skill and felicity built over practice, the productivity is enhanced. So to enhance the overall output we need to have specialists and the specialists were grouped into horizontal groups and so on. As we could imagine in a production set-up the work items were homogeneous and work was repetitive in nature.
This same word takes a different meaning when we apply it in the Product development space. Specialists provide technical or domain excellence needed to develop products. They are not there because they can do things merely faster but because of the skills and expertise they bring to the product development set-up. So to succeed in the product development game we need specialists who can help implement cutting edge features which provide competitive advantage.
But specialists being specialists often confine themselves to their own areas and have a narrow view. It is tackling this that I see cross-functionalism coming in. They still retain their specialization but build up skills in related areas,
So in the end we want to have a team with complementing specialist skills so that as a team it has all the relevant skills suitably distributed that it has all the ingredients to develop a world class product. So somewhere there is an "adequate" or "sufficient enough" clause coming in for cross-functionalism.
Cross-functionalism cannot become an objective by itself. It has its value when it is placed over a team which has sufficient specialization with complementing skills. If we were to interpret it as "anyone on the team can perform any needed function" then ultimately we will turn a team of 'complementing specialists' into 'generalizing specialists' that they will lose their domain or technical edge and move the product towards mediocrity.
This is the point emphasized by the T shaped skills as well - they specialize in one area but have basic skills in other areas as well.
We have a team built from people of various specializations, typically we may not be able to deliver as a team and Cross-functionalism is seen as a desirable attribute within agile teams. Stretching the arguments for cross-functionalism do we imply that specialization is undesirable within a team?
Specialization in the Industrial age meant that the person focuses on one area of the Production process and because of the skill and felicity built over practice, the productivity is enhanced. So to enhance the overall output we need to have specialists and the specialists were grouped into horizontal groups and so on. As we could imagine in a production set-up the work items were homogeneous and work was repetitive in nature.
This same word takes a different meaning when we apply it in the Product development space. Specialists provide technical or domain excellence needed to develop products. They are not there because they can do things merely faster but because of the skills and expertise they bring to the product development set-up. So to succeed in the product development game we need specialists who can help implement cutting edge features which provide competitive advantage.
But specialists being specialists often confine themselves to their own areas and have a narrow view. It is tackling this that I see cross-functionalism coming in. They still retain their specialization but build up skills in related areas,
- to collaborate
- to reduce handovers
- to able to see the big picture
- to understand the different dimensions so that suitable trade-offs can be made and so on.
So in the end we want to have a team with complementing specialist skills so that as a team it has all the relevant skills suitably distributed that it has all the ingredients to develop a world class product. So somewhere there is an "adequate" or "sufficient enough" clause coming in for cross-functionalism.
Cross-functionalism cannot become an objective by itself. It has its value when it is placed over a team which has sufficient specialization with complementing skills. If we were to interpret it as "anyone on the team can perform any needed function" then ultimately we will turn a team of 'complementing specialists' into 'generalizing specialists' that they will lose their domain or technical edge and move the product towards mediocrity.
This is the point emphasized by the T shaped skills as well - they specialize in one area but have basic skills in other areas as well.
Subscribe to:
Posts (Atom)