business architecture

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.

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.

Arrange sites & spaces High level structuring of content & information sharing platforms

Posted on By Koenraad Seys
Information platforms are increasingly structured along the lines of sites or spaces at top level.
The available functional/technical capability alone however, does not guarantee a good organisation appealing to your users. The structure has to take into account their working and social context.
Coming from the image created by web sites and made popular for corporate internal use of content and information by Microsoft SharePoint, there is little thought given to the logical structuring of sites and spaces. Often they are created on request and the environment becomes an ad hoc loose collection.  Current platforms have a wide variety of functionality which make them suitable for a broader use than sharing information on projects or structures along the lines of the formal organisation of the company. More so, in current organisations, there are more dimensions to be discerned. Not only do we need to be more efficient and work cross-departmental with a stronger focus on customer and consumer needs, our work place is also a social construct in which we interact and have a richer experience than the one strictly confined to the execution of tasks. Therefore an information platform has to be more than an intranet on which static content is to be made available. Social interaction and cross functional and hierarchical conversation is increasingly expected by colleagues and employees. In ages where innovation and creativity are perceived as the most important success factor of an organisation. Information sharing and conversation should foster engagement and belongness as profound as possible. The platform should also be able to quickly engage new comers and temps.
It is while thinking along these lines we come with a meta-structure or a number of dimensions along which one can organise these information intense platforms while fostering conversation and providing direct usefulness for corporate users.
The Home space or site is the starting point when accessing the intranet.
The content of this space reflects:
• global information of and on the company
• what you should know about the company as a newcomer
• press relations (both outgoing and incoming – comments made in the global press)
• global management information and announcements of the direction/general management
• references to practical information on how to find your way on the campus or the buildings
Per organisational unit or department a space or site gives the frame for specific organisational exchanges. As such it has a more operational character than the home space.
The content of this space reflects:
• information on and about the unit
• organisation of work
• notes periodic meetings
• person related notices about department members
• departmental announcements of practical nature
• references to practical information on the workings of the department
• operational announcement
This personalised space contains everything you need. It focuses on the tasks you need to perform, the information that is addressed to you as a member of the organisation or has specific pertinence (e.g. positing in discussions you follow) and can be enhanced with information or reference that are of particular use.
These (social) group spaces are free subscription based getting togethers where information and thoughts are exchanged. They may concern professional or practical topics relating to company life, logistics or amenities that can make life agreeable. It is here that communities of interest or practice would thrive. They contain discussions, documentation, postings, polls, … Topical interest may obviously also relate to products or services of a company or group.
For each recognised project a space grouping related information is accessible for the project participants. It is here they will report on progress, post information and documents related to the project. It is also here the planning is to be found.
For project and line management specific progress dashboards are made available.
The Geographical site is similar or a sub set of the overall company home space. It contains specificities related to a specific location, campus or building group.
The HR site is common for all staff of the company provides information on global HR policy and personalised services regarding holiday planning, compensation and benefits, career planning and evaluation, training …
The Governance space is a restricted area for the actors concerned with maintenance and extension of the intranet environment. Here administrators will find tools and documentation for enhancing and managing the intranet platform.
Relating to these space types, templates or models can be devised to structure the setup of requested environments referring to each of these types.
They are documented in the specific governance space.
A personalised global navigation instrument will give an overall user experience permitting to go directly to the information one needs, without having to recall individual destination addresses.
See also the related slide doc published on slideshare.

The feudal organisation

Posted on By Koenraad Seys
Most of us know feudality from school, being the predominant way of organising a state during the Middle Ages. Although embedded in a traditional society based on a stable order imposed by god, some elements may still be of value in current contexts.
Discarding the basis for legitimising the position of nobility as the leaders in the Middle Ages, feudality is mainly a method for distributing power and a way for the king or emperor to exert control over his realm while having a sustainable community.
Looking at the material context of medieval society, feudality was a logical organisational format. Traveling even over short distance was difficult and took time. Roads were rarely paved so using them was mainly restricted to summertime when it was dry and days were long. As it easily took a day to travel to the next village, it was hardly feasible for the lord to enforce strict control on regions further away. Giving instructions and receiving feedback on them easily took weeks. On matters not involving the overall structure, fiefs were alone in their decision process. Although set in a rigid and strictly hierarchical context, legitimised by god, fiefs were largely independent, autarchic units. They had to decide on their operational besognes.
A fief had to be able to subsist independently of others. It could and should survive on its own, provide in its victuals, producing enough agricultural produce for its own inhabitants, be able to construct housing, furniture and tools to get necessary production going. Specialisation was limited. They were also self policing on the level of internal peace keeping and justice. They also produced enough surplus to support nobility and clergy. Their focus was on their purpose: subsist.
They were only called to help when neighbouring or when fiefs of which they were part of were under attack of an external source. On the other hand they presented enough force to ascertain the equilibrium with neighbouring fiefs.
In the ceremony, where a lord got ordained, tokens of trust were exchanged delegating full control to the lord while promising the lord eternal support and assistance. As such the local lord was also representing his higher master to which he had sworn obedience, while assuring representation of his domain with higher authorities when it came to engagements of a broader nature. Other interlinking was extremely limited, thus evolution was slow.
This is the basic setup of feudal society without distortions incurred by powerplay or unbalancing privileges.
Considering current organisations and societal evolutions a new type of distance could be identified. Increasing specialisation, either technical or functional, makes communication across the board more difficult. Vocabulary and practices often differ between groups and they have different support, infrastructure and tooling needs. Competition requires light, flexible and adjustable setups, quick on their feet to respond to changing contexts under their own responsibility not needing to go long ways through the overall organisation to obtain feedback or authorisation. This would take too long.
The medieval principles of autarchic units existing in balance with neighbouring units are also found in new organisation types heralded in modern management literature.
The Connected company defines it a podular organisation where “you divide labor into “businesses within the business”” fully oriented at its customer. An infrastructural platform sees to it that the necessary information and knowledge can be shared and common support activities are mutualised.
In holacracy work is organised in holons, “a whole that is part of a larger whole”. These holons or circles are organised along the lines of business functions and processes and fundamentally autonomous for their internal organisation of work, however constrained by the need of other circles and anchored in the context of the organisation. “The “Lead Link” is appointed by the super-circle to represent its needs in the sub-circle. A lead link holds the perspective and functions needed to align the sub-circle with the purpose, strategy and needs of its broader context. The other link, called a “Representative Link” (…) is elected by the members of the sub-circle, and represents the sub-circle within its super-circle.”
Different to the past, management or leadership overhead is out of the question. Each unit should be self steering based on a set of basic governing principles, mutual member negotiation and unit democracy.
Although recurring in other contexts mechanisms from the past re-appear, ideas are recycled and depend on similar conditions for their success and sustainability.
Each member of the organisation should be taking up responsibilities for the role (holacracy) or tasks assigned to or taken up by him/her, he should act as an engaged adult
Have a clear view on the organisational purpose and vision
Share the common vision or purpose declared or grown in the organisation
Avoid powerplay, created when units see possibilities to lift the equilibrium instated in the initial organisation
When providing a governance framework keep it crisp and stick to general widely applicable rules. Avoid to let it become an elaborate set of detailed rules and procedures.
In this context it is also tempting to retreat in the own autarchic circle, not sharing any knowledge or learning and to focus on the internals of the working of the circle. The businesses in the business not contributing to the whole will eventually lose efficiency by not sharing experience across the board, merely being a franchise or an independent organisation. The potential for corporate learning is clearly available based on the platform services on global level.
Keep connected to your customer (in a broad definition) and continue to observe how needs and behaviour are evolving while capitalising on your talents, knowledge, competences and experience.