approach

The meaning of Minimum Viable Product (MVP) as part of the product release cycle

Posted on By Koenraad Seys
The notion of building a MVP or minimum viable product often pops up when planning software implementation or development projects. Although it not an inherent part of agile approaches to software development, it is often cited as a means to come to a quick delivery.
In my opinion the idea is rarely fully embraced or followed, maybe related to connotations related to the word ‘minimal’ and it’s echo of insufficient, crappy or a poor excuse for not wanting to invest sufficient time and means to come to a full featured product. Majority of project owners rather want to consider it as a first release of the product they had originally in mind, being fairly full featured and complete.
Is it possible to apply a MVP approach in all circumstances or should we reconsider the positioning of a MVP as part of a project approach?
A MVP can be produced for any type of product, being it a physical product or a service provided to a customer base. The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time. The minimum viable product lacks many features that may prove essential later on. (Eric Ries in the Lean Startup p. 77) Thus it serves the needs of the users/customers and is the first step in a journey of learning and fine tuning the product. In this way it certainly fits the design thinking approach where it can prove to be of better service than the prototype as the MVP is put to the test in a real productive environment interacting with the intended user/customer.
Based on this description of the MVP it is ideally fit to be applied in a green-field, developing a new product or service. Based on a conceptual understanding of the needs of the intended customer a first basic version of the product can be put to the test, seeking feedback, while already earning some income through the new service or product that is ready for a ramp up based on the feedback provided by user interaction and interaction measurement. The learning based on the first use of the product can and should then be transformed into new product feature, for which the demand is clearly demonstrated, new product ‘behaviour’ or configuration conforming the wishes and needs that have be tracked based on use. Therefor producing MVPs require the courage to put one’s assumptions to the test.
The MVP is often positioned in larger organisations. However, it does not succeed in delivery on expectations. Are there obvious reasons why the MVP approach is not taken up or even met with resistance by project or product owners in organisations?
A MVP is often seen as a phase of the product development and release life cycle, when developing new solutions or replacing existing solutions. The expectation level in this situations and certainly in the latter case is not the same, maybe even not similar to those of a green-field development. In the context of the succesion of an existing product or process, one is often confronted with an extensive set of requirements, and a high level of detail in the requests detailing the needs for the product to be developed. Unless the product to be developed holds a complete change of concept, the set of requirements is often that large and detailed that the initial release can, in my opinion, hardly be considered a MVP.
The cited MVP is not really an MVP in a large number of enterprise projects. In the context of the succession planning of an existing application, the product to be delivered, even though the technology or system basis changes is a new release, not a new product. Current users expect the new product to perform better than the product they are currently using. It should contain all current features, be modern and have increased performance and improved usability compared to the current product. The product to be delivered is not subject of discovery and learning it is expected to be an improvement for features well known and – when lucky – well documented.
It is to be discussed whether providing automated support to a running process can result in the release of an MVP. Although the (software) product may be new and its usage and usability is subject to testing and feedback, process and information support requirements are sufficiently known to be explicitly discussed and documented. It might be that the processes to be supported are fraught with bureaucratic controls and needs to be cut down, the concept as such is not to be tested.
Even when we are talking about a real MVP, there are potential reasons for reluctancy to adopt a MVP as step in the way to the implementation of a solution of product are to be found in relationships, the disruptive nature of the approach where majority of interactions are contractually defined.
Relationship with the IT solution supplier – an external contractor is expected to work for a limited time and should deliver the product as defined initially, when granting the project. Even when working with the internal company or organisation’s own IT department, relations are often not as smooth as they could be. In some cases the department is seen as an enemy, it transpires to know better the needs of the business than business departments do and behave in a similar contractual relationship as the external supplier. Challenged by lack of resources, they tend to block of extra requests or changes in scope or requirements, increasing resentment while taking a reactive stance rather than pro-actively participating in the definition of the product along and together with the business department that is product owner.
We want everything to go to plan attitude is part of the overall culture we live in. This need-to-be-in-control, and to act in a predictable way, leads to a lack of open communication, where mistakes, misunderstandings and planning deviation are tucked away by not communicating or vaguely communicating about progress, results and problems while preceding in the development of the product. An efficiency culture that starts with the premise that all is to be done based on past experience, known facts and on precedents or similar activities executed in the past increases expectations and decreases the perceived need to be explicit and clear when expressing requirements and desires. It has been done before, relax, is the standard (requested) attitude… Focus is not on a discovery of the real need and the real added value as design thinking promotes.
In order to profit fully from agile and lean innovation concepts including the use of MVPs, a cultural turn around is needed for departments and enterprises that will thrive on innovation and adaptability. They should go from a command and control view on things, where the few plan and think out products and the majority execute without question what they are ordered to do, to a learning and improvement attitude where everything is in flux, knowledge is gained and all participants in the organisation participate in creating it and its products. All concerned have to work with the same overall purpose in mind, bringing down the walls between departments and teams introduced with an eye on efficiency and task specialisation.

Positioning Advanced Case Management and Business Process Management

Posted on By Koenraad Seys
Case management is an addition to the stack of business solutions, and is only recently permeating in a growing number of organisations.
Case management is positioned as a knowledge worker enabling tool. It places the knowledge worker at the center of the solution. He decides on the basis of case information on the process to follow. He can interact with the case through the case file or through an inbox presenting tasks generated by the business process underlying the case. Tasks may occur in an unpredictable order in response to evolving situations. At the other side of the process tasks are triggered by either internal or external events.
A well developed case management platform or package should support easy configuration for quick delivery.
With this capability it permits developing solutions for a lower number of cases and for smaller teams.
Compared with BPM solutions which are best suited for well-structure and highly predictable work; there knowledge workers mainly execute tasks that come in high volume and are presented to bigger user groups. Configuration effort is higher as you require to foresee all variants and conditions to be defined in the business process solution. You could compare business process solutions to assembly chains but for administrative work. All actors perform well specified roles fulfilling specific tasks presented to them using the application’s inbox. And like for assembly chains definition (like in the automobile sector), setup and modification or update of the chain requires considerable effort, quality checking and testing so the process does not contain any contradictions.
Functionality and features to look for
First and foremost the software solution supporting knowledgeable case workers should support the overall process for handling a case and give them sufficient freedom to make decisions along the way or to invoke case events that can influence the course of action.
The platform should support administrative procedures and should permit to automate clerical work to a maximum so case worker can focus on the content and the decision to make while handling the case.
This also implies that it is possible to interact with the case both via an inbox confronting case actors with tasks to perform but also with the case overview option from where it should be possible to initiate actions at any moment in time or during any phase in the handling of the case. Actions allowed should be governed by the possible actions allowed through the different phases of the case development.
Taking the example of a legal investigation case, where detectives build the file for prosecution, they don’t necessarily know what the sequencing of actions to be taken will be. They interact with the findings they establish. The result of an action may initiate new initiatives that were not foreseen at the onset of the case. Certain actions are strictly regulated and require specific authorisations. Obtaining these authorisation often goes through a fixed hierarchy. These procedures should be implemented as workflows interacting with the standing organisation and when required generate formal documents to be presented to the investigated parties. This digital interaction will speed up the work. The initiative is taken by the investigator.
In the course of the investigation there should be room to add an extensive set of investigative materials to the case. They can hold a variety of information file formats. While working the material conclusions may trigger new actions.
In more client oriented activities like insurance files or complaints cases, regular or ad hoc communication with clients require direct interaction with communication channels as standard mail, customer interaction portals or e-mail. These hooks should be available at any moment and are chosen by the case handler either at the moment of launching the communication or based on the declaration of the preferred interaction channel for the case/customer.
Pre-conditions for successful use of Case Management as technological component in the company solution stack
On a global level it should be clear for what business processes, organisational units or business cases, Case Management will be deployed. How does the case management solution positions itself with other applications and solutions and what is the nature of cases to be handled. Whether the majority of the work you do is based on data intensive or documentary information, it will have an important impact on your product or case management solution choice.
In order to be able to quickly deliver case management solutions you should have not only a clear view of your infrastructure requirements but als of the generic services providing information to the cases initiated. Think of user and customer directories, messaging services or common databases containing essential business data. The software providing the necessary information needs to be connected, taking into account global policies such as those dictated by legislation such as GDPR and more general principles as ‘store once’ and data integrity.
When to choose for Case Management
Taking into account the setup effort of well developed case management packages, they are candidates for implementing less intensely used business processes or less structured processes requiring knowledge worker initiative and decision taking. One should see them as complementary to BPM, specific or bespoke solutions when they are positioned as supporting exception handling for the main process, on the condition the exception handling is important enough to create an independent case file containing the necessary documentation. Alternatively they are to be used for less structured knowledge intensive work processes requiring longer time to close the case while collecting diverse materials to support the decision process.
When setting up case management a four phase approach is advised:
  • Evaluate the business architecture and identify the potential domains where case management solutions will provide added value. In parallel lay out an overview of the application landscape and identify on the one hand the applications to which case management can be an add-on concentrating on non structured exceptions that cannot be supported in an economic efficient way or for which no software support is available and on the other hand applications that provide standard services providing general information or data with which generic integration is a bonus for knowledge workers’ productivity.
  • Integrate standard components with the platform. When working in an agile framework or using scrum foresee a few sprints to realise these connections.
  • Architect your case management solutions in order to streamline the case types, their domains and storage setup.
  • Develop specific case management solutions with a clear focus on creating added value, fast delivery cycles and standard capabilities of the platform.

LeSS is the Holocracy for IT

Posted on By Koenraad Seys
In the past I wrote about holocracy and self managing teams as a system of balance, stressing mutual interest propagating overall business goals like in feudal society. All teams are driven by a purpose of providing a certain service to some other entity or to the final customer.  Teams specialise in a functional domain. Coordination between teams is done through a team delegate participating in the team meetings of teams for which they have a client or provider relation.
Large Scale Scrum (LeSS) is a methodology for developing products along the lines of SCRUM adapted for scaling. It depends largely on focused teams directed at customer, product or product feature, functioning with minimal or no management overhead. Member teams work together at realising a complex product for a business represented by what is called a Product Owner in SCRUM. Coordinating happens through participation of a team members in each others team. A team is tasked with developing a component or better a feature that fits in the overall product and therefore they have to understand what is needed by the business team/unit that will be using the software product supporting their processes. As such it applies the same philosophy as Holocracy but adapted for software or ICT departments.
As holocracy teams are oriented at certain products or customer groups there should be a match with the product or feature teams identified in the software development LeSS teams. This match will ensure better understanding, efficiency as well as continuity in the development and direction of development.
When applying the logic fully, it means pairs are formed between business and ICT teams. In some cases the product provided by the ICT group might cover different customer channels, customer target groups or products addressing the clientele or at least parts of it. It might lead to priority discussions. However, relations between both sides of the story are clear. The lines of communication are short and priority discussion can be held in a transparent way with all parties involved present. Pairing will improve focus, direction and understanding of needs of both customer and the people providing the necessary services. Integrated working will avoid the need of translating business needs to IT requirements. The Product Owner as linking pin is part of the business team who understands due to proximity better than ever how development of software solutions work. The IT team will understand the needs of the business team better as they have a structural and long term relationship with the business team(s) they support even when stories are rather vague and lack information about the technical implementation of the request.
The functional focus will require a mix of technical skills and requires knowledge sharing on this level. Therefore, the creation of functional/product clusters should not lead to new silos. Technical oriented communities of practice covering the technology used within the organisation should provide a space for sharing knowledge and experiences concerning development practices and infrastructural issues related to deployment and system management. Alternatively people with specialist technical knowledge can be delegated to participate in development of a feature team to bring them up to speed. In this way one can avoid the reflex existing in current organisations to build technology oriented teams focusing on technical components  that tend to live in their world having a hard job understanding business needs.
Pushing the envelope further, a good understanding between business and ICT teams can and will lead to more innovative products and fundamental digitalisation of business processes and customer interaction. The SCRUM methodology stresses the importance of the Product Owner as the person representing the business needs and thus piloting the development team laying out priorities and explaining the underlying reasons for a requested functionality. The relationship is mainly one directional, resulting in smaller incremental changes than what would be able to achieve when ICT potential would be used at its potential. Often scanning incoming documents is positioned as process digitalisation, actually it hardly changes anything more than facilitating the communication of the document through the process. Using a structured data entry form at the start of the process would permit instant data quality controls with the possibility to change and enhance data on the spot. Other examples can be imagined resulting in better use of digital technology. This potential often is not recognised by non tech savvy people concerned mainly with coping with the incoming work volume.
Establishing a tight relationship between ICT and business teams will most certainly enhance business performance when the purpose is clear and bidirectional communication facilitating the creation of added value. Therefore all talents should be used in an environment of mutual willingness to understand participants having different backgrounds.

Knowledge Management in times of Google and the internet

Posted on By Koenraad Seys
“Just Google it”. An often heard statement, certainly with the younger and more tech savvy parts of the work force. The most popular of public and free accessible search engines is most certainly a portal to huge amounts of information and of knowledge shared by any wiling person on the internet. With all this information available should we then still organise for collecting, curating and creating knowledge in the confinement of individual organisations?
From a pragmatic and economical point of view one should say no. Why should an organisation bother to document and organise knowledge and information that is already available? This argument may hold for more generally applicable or domain independent knowledge. You may find a lot of IT related ‘how-to’ materials ranging from general information on programming to video presenting technological solutions and how to use them. And more, this information is evolving at a high pace. However it is also the information publishers distribute as paper print books or online materials that lead to the creation of libraries for those who do not want every member of the organisation buying a copy of the book they may need. Digital availability however has virtualised the library and what once was the beginning of knowledge management has been made redundant, certainly when you look at the corporate space.
Another argument not to invest in knowledge management is the quick paced change and innovation in current society. Why would you invest in knowledge that is short lived? Shouldn’t we better invest in capacity and competence to learn and adapt? Most certainly, staff that is capable of learning new skills and techniques will be worth  more and ensure organisational agility and sustainability. Opposite to this argument is of course that innovation can only be generated with sufficient knowledgeable and talented people building further on an already available corpus of knowledge.
In positioning the issue a question comes to mind. Is there something like corporate knowledge? Thus, is there value in governing corporate knowledge?
From a protectionist or legal asset point of view, corporate knowledge is all that  should be protected, that is part of intellectual property (IP) and that sets an organisation a side in the innovation landscape. It builds on a notion of ‘knowledge as property’ that is an asset or tool for building innovation, new products and services. Organisations with a strong research and development wing, would certainly fall in this category of corporate knowledge use. But also here, open innovation initiatives break down barriers and put the property reflex into perspective. Would this then mean that there is a knowledge of practice (as Cook and Brown state in their 1999 article on the epistemologies of knowledge). As they indicate the common knowledge pool is situated on the level of activity domain – such as medicine or mechanical engineering – or more specifically on the level of a company or a group adhering to specific working methods.
The technological asset view strives to the creation of an analytical inventory of knowledge elements. They will be expressed as business rules by business analysts and IT people or derived by learning algorithms to be integrated in business applications automating a maximum of processes and tasks. Knowledge is here seen as a productivity asset increasingly standardising and commoditising knowledge work with a repetitive nature.
Taking a human resource based vantage would see knowledge as the possession or attribute of somebody and reduce knowledge management to recruiting for a context and task at hand, and so a proponent of the resource approach will look for somebody with the required training and/or experience to get a specific job done. Extending the resource view to a social level this would imply that knowledge is shared either through education and training or via professional networks of likewise trained professionals that build a certain experience. As a consequence  organisations are not stable, oriented to short term goals and populated with itinerants renting out their skills.
The culture stance on the issue certainly stresses the existence of organisational knowledge expressed in working methods, specific vocabulary and shared experiences and understanding or historical cases that transmit knowledge. Reasoning in a culture building logic will require strong group building and socialisation for all new comers, embedding them in the group logic.
In a social group logic, discussion is central to transferring knowledge and attaching meaning and applicability to the context of use. Knowledge is contextually requested, explained and adapted to the needs of solving the problem at hand. In this way no stable corpus will be established and thus relates strongly to the human resources approach.
In view of the conclusions that Tsoukas and Vladimirov draw on the fact that “individuals understand generalisations only through connecting the latter to particular circumstances” and as such knowledge is developed by employees while doing their job stable knowledge does not exist. It is a continuous succession of learning experiences. Tuning the wheels of learning efficiency “knowledge management then is primarily the dynamic process of of turning a unreflective practice into a reflective one but elucidating the rules guiding the activities of practice.” In this way one should consider the need for guiding information and knowledge presented on a structured meta level balanced with social sharing of knowledge through discussion initiated by a problem to be solved related to the task at hand at a specific point in time.
In this context knowledge management will focus on
  • education and training, however not necessarily covering only ad hoc needs answering concrete learning needs
  • providing structure, context and finding aids giving access to the materials needed for tackling the task at hand
  • providing (access to) a social infrastructure permitting to contact and interact with knowledgeable people or the ones having experienced a similar challenge
This will give opportunities to address problem solving tactics that differ across generations. The older generations will mainly draw from memory, what they have learned in the past and turn to documentation when the answer is not known. The younger people tend to start googling and in a next resort launching requests in their social network.