20
I Use This!
Activity Not Available

News

Posted over 8 years ago by Aaron Seigo
Kolab will once again have a booth at FOSDEM, that fantastic event held in Brussels at the end of January. Several Kolab developers and deployers (and generally fun people) will be there wandering the halls, talking about Kolab and looking to connect ... [More] with and learn from all the other fantastic people and projects who are there. It's going to be a great event! Be sure to find us if you are attending ... and come prepared for awesome :)   [Less]
Posted over 8 years ago by seigo
The Kolab development team uses the agile development methodology called Scrum. This is an iterative development process set out to achieve a predictable, consistent flow of incremental improvements to a software product, and as such is basically ... [More] considered mutually exclusive with the concept of a pre-defined end-result. As I’ve mentioned many times before, Kolab includes multiple software development projects, including third-party components, that we group together and make form a complete collaboration suite. The product as a whole can never really be finished and justifies, not to say implies, using an iterative process for our own development. Agility serves this purpose really well — relatively small increases in value can be achieved provided early feedback cycles to adjust expectations and/or implementation, and be adjusted one way or the other as the landscape changes. However, Agile software development projects are not usually provided guidance and direction to the same tune that waterfall projects are. With waterfall projects, you outline exactly what needs to happen, and every zig and every zag on that pre-distilled roadmap is considered a full-fledged change — to be requested, processed, reviewed and approved. The waterfall project methodology teaches us of three terms of particular significance; milestones, roadmap and horizon. In development processes where teams collaborate to develop software solutions, it is important to point noses in somewhat the same direction. This involves stakeholders such as product managers and sales representatives, architects and developers, customers and consumers. Each with their own discipline may have a very different view of the future ahead, but it is important to, at least, remain connected to the common thread of these views. This becomes even more important when; Stakeholders are geographically distributed and do not regularly collaborate with high bandwidth (face-to-face), The participants native tongue is not the language commonly spoken, as nuance is lost and ambiguity is introduced, The product is made up out of many separate software development projects, The development teams are often a mere participant in third-party software development projects, The software encompasses broad topics and requires relatively high degrees of expertise. In such environment, the use of means to funnel attention on to common, shared end-points aids in establishing scope and focus. Milestones In Agile environments, milestones have little meaning — in some regard, the retrospective at the end of every sprint is a milestone. Milestones can simply function as a limitation on the scope of development to finish first, before additional work can commence. For example, the first milestone for Roundcube Next could be formulated as consisting of “Email, Calendaring and Contacts” — no more detailed than that, and without restricting the ways in which to actually achieve any of it. Such milestone (along a longer roadmap) can be split in to several milestones — requirement engineering, design, prototype, proof of concept, implementation, delivery. Each of the smaller milestones can be treated as stringently or agile as seems appropriate or is desired — the end is still the one milestone, functioning as a protection mechanism against “feature creep” and a providing a commonly shared “end point”. Multiple milestones stack up to a roadmap A roadmap may include enhancements not already a part of any particular existing milestone. For example, we have a desire to be able to hook up more “apps” to Roundcube Next, most of which to be developed in the future. I could put one such “app” for Instant Messaging on the roadmap for Roundcube Next,  but I could not assign it to any one particular milestone. Awareness of items on the roadmap however allows the software development process to achieve the first milestone with a result that allows it to achieve subsequent milestones, by taking in to account what kind of application model design these items may require. A roadmap is a perpetually morphing target It doesn’t stack milestones in order, nor does it establish how many milestones there are, which milestones to achieve when, or in fact which parts of the roadmap are included in any milestone. A roadmap as such is a truckload of desires, that you can, but do not necessarily have to, take in to account when actually implementing forthcoming milestones. A general, shared comprehension of a roadmap protects a project from straying off a path by ad-hoc zig-zagging, and avoids needs to re-factor after passing milestones. A horizon is the end of a roadmap In some regards, it is the same as a vision — a fluid concept not set in stone, and something you’ll likely never actually achieve completely — it should be viewed as to provide guidance in design considerations and decisions throughout the process, but not form the ultimate decision making point for either consideration or decision. Rather, it is important that developers and stakeholders can, along broad lines, agree that somewhere along the possible 360° horizon is that one slice where they can all point their noses. Speaking of pointing noses in the same direction, please note that you can still get where you wanted to get to, no matter how much you zig-zag. Again, these terms are more commonly associated with waterfall development processes, i.e. “plan everything between now and the desired end-result up front”, in direct contrast with the Agile development processes, which rarely articulates anything about the desired end-result beyond a vision statement, and is an iterative process for which the results are not outlined at the beginning. I’m sure you can appreciate though, a shared view on the general direction a project takes, and what road to take to get there should bring a lot more clarity to the project’s future.   [Less]
Posted over 8 years ago by Aaron Seigo
The new year is looming, so this seems like a good time to share some of what we are thinking about at Kolab Systems when it comes to the Kolab ecosystem. As a result of careful examination of the Kolab ecosystem, we put together some priority ... [More] adjustments to make. These include: Kolab release process improvements kolab.org reboot partner enablement Each of these are big, exciting and fundamental improvements in their own right, so I will cover each in its own blog entry in which I will attempt to explain the challenges we see and what we are doing to address them. First up is the Kolab release process. tl;dr Kolab Enterprise as a software product is merging with the Kolab community edition. There will be a single Kolab software product open to all, because everyone needs Kolab, not only "enterprise" customers! Both the version selection and development process around Kolab will be substantially simplified as a direct result. Read on for the details! Kolab Three Ways Kolab currently comes in a few different "flavors": what you find in the source repositories and build servers; the Kolab Community Edition releases; and Kolab Enterprise. What is the difference? Well, the code and raw package repos are essentially "server yourself": you download it, you put it together. Not so easy. The Community Edition releases are easy to install and were being released every six months, but support is left to community members and there is no long term release strategy for them. By contrast, you can purchase commercial support and services for Kolab Enterprise, and those releases are supported for a minimum of 5 years. The operating system platforms supported by each of these variants also varies, and moving between the Community Edition and Enterprise could at times be a bit of effort. Yet they all come from the same source, with features and fixes flowed between them. However, the flow of those fixes and where features landed was not standardized. Sometimes features would land in Enterprise first and then debut in the Community Edition. Often it was the other way around. Where fixes would appear was similarly done on a case-by-case basis. The complex relationship can be seen in the timeline below: This has resulted duplication of effort, confusion over which edition to use when and where, and not enough predictability. We've been thinking about this situation quite deeply over the past months and have devised a plan that we feels improves the situation across the board. A Better Plan Emerges Starting in 2016 we will focus our efforts on a single Kolab product release that combines the Q/A of Kolab Enterprise with the availability of the Kolab community edition. Professional services and support, optimized operating system / platform integration and long term updates will all remain available from Kolab Systems, but everyone will be able to install and use the same Kolab packages. It also means that both fixes and features will land in a consistent fashion. Development will be focused on the master branches of the Kolab source repositories, which have been hosted for a while now with Phabricator sporting open access to sprints and work boards. With our eyes and hands firmly on the main branches of the repositories, we will focus on bringing continuous delivery to them for increased quality. Fixes and features alike will all flow into Kolab releases, bringing long desired predictability to that process, and Kolab Systems will continue to provide a minimum of 5 years of support for Kolab customers. This will also have the nice effect of making it easier for us to bring Kolab improvements live to Kolab Now. These universal Kolab releases will be made available for all supported operating systems, including ones that the broader community elects to build packages for. This opens the way for the "enterprise-grade" Kolab packages on all operating systems, rather than "just" the community editions. You can see how much clarity and simplicity this will bring to Kolab releases by comparing the diagram below with the previous one: You can read more about Kolab release and development at Jeroen van Meeuwen's blog: The Evolution of Kolab Development and Short- vs. Long-term Commitments.   [Less]
Posted over 8 years ago by seigo
It is not commonly understood how software development projects moving forward as fast as they can and sometimes do, can be in direct conflict with their actual rate of adoption, not to mention their commercial delivery to market. This post outlines ... [More] the differences between short- and long-term commitments, and how the distinction can be used to form complementary facets of a project, rather than remain in perpetual conflict. Generically speaking, the result of a single iteration of an agile development methodology should result in two things; A known, established and verified upgrade path from the previous iteration, However slight an increment in product value. In contrast to the moving target as outcome of iterations in projects using the agile methodology with its virtually inherent unpredictability, businesses sign contracts with promises, including but not limited to; A version of the product that is both quality-assured and stable — meaning there are no surprises at the end of consuming a stream, meaning neither pleasant nor unpleasant surprises, Support for that version for a much longer period of time than the original outcome of any one particular (group of) development iterations, Incremental updates to support sustainability of the product, be it bug fixes or incremental enhancements, Service level agreements guaranteeing turn-around time-lines, A competitive value proposition based on the aforementioned parameters, Services including but not limited to development of customizations, training and consultancy, The next version of the product meeting all facets of the current version of the product. There are a few additional aspects I could go in to that need to be omitted for genuine Free Software ISVs, such as licensing and exclusivity, as I consider both to be strong-arming a competitive edge, or bullying. Short-term Commitments A short-term commitment is a predictable time-line with an established amount of investment in which the product value can incrementally be increased with a known value. We can state with a degree of certainty that these commitments are relatively small compared to a contractually obligatory commitment to paying customers, to support their deployment for up to 72 months, or 6 years. We can also state that the goal with short-term commitments is an increase in product value, and that the motivations for development partaking in short-term commitments prioritizes the incremental enhancements sorted by descending value increment. As such, short-term commitments are made with an eye on the future — research & development prototyping something, for example. Long-term Commitments A long-term commitment is a period of time often spanning multiple years, during which promises need to be delivered on. These promises have been made to oneself, a community at large and paying customers. These promises include hard targets (contractually obligatory facets) and soft targets (the next generation of a product stream). They will have to be kept though — as such long-term commitments are made with an eye on the past, including tomorrow, aka. the future past. We can state with certainty that very few developers are interested in, and even fewer capable of, both the development of the next generation of the product and maintaining up to 6 or 7 legacy versions. We can also state an ability to support and troubleshoot a set of often ill-articulated symptoms remotely is quite a different discipline. It is not easy to establish how much costs are to be associated with long-term commitments ahead of time, albeit there are models to estimate such costs. One method to reduce such costs (and therefore better predict real costs within a smaller margin of error) is to ramp up quality assurance. It is, proverbially speaking, making sure your customers do not have to pick up the phone at all and therefore reduce the support cost while demonstratively increasing the value of the KSP. Quality assurance however still spells a certain degree of uncertainty in real cost, and is another long-term commitment — except when it is automated and frequently executed, preferrably as early as possible. Customer, Product or Business Value? If you were to entertain only short-term commitments, the product value would be unjustly biased toward customer value as a means to achieve business value. Customer value however is often perceived rather than real, as customers will think the world of the feature they request be included — an absolute necessity, can’t work without out. Ultimately, it morphs the product toward a collection of complex features that are not generically applicable to most or all consumers of the product. Product value needs to be understood to mean generically applicable functionality, or high-value functionality applicable more selectively. This implies that functionality applicable more generically is multiplied the product value of implicitly, albeit by an indeterminate factor. It would therefore be prioritized accordingly. When a project deliberately pursues the implementation of more specific functionality, this should be considered a matter of strategy, such as opening up entire market segments, target audiences and industries. For the real punchline, let’s look at business value. In a genuinely Free Software ISV business, there’s little distinction between product value and business value. For all considerations development, future and short-term commitments, the business value of the product can only rise if the product value itself rises. In other words, if the product’s business value, so does the product value itself. If the product value rises, so does its business value. To put things in perspective, draw a distinction between the business value of the product, and the value of the business. Linking It All Up The long-term commitments predicate that the result of short-term commitments come with a meaningful degree of certainty and confidence. That is to say, very, very well verified. Provided “very well verified” translates in to actionable items, continuous integration testing is used to establish what score such certainty and confidence may translate into — as early on as possible. Allowing for the different stages of a single iteration in development means that this must be seeded correctly in order to acknowledge or decline the bar to delivery has been surpassed. This strongly suggests the process used for development teams is Test-Driven Development, which would certainly increase the certainty on correct input to the development process earlier than a retrospective-based feedback cycle on having missed the mark, and increases certainty and confidence on the result of an iteration as well. To prevent source code management from containing tests failing as a result, we can bring mandatory code review in to play.   [Less]
Posted over 8 years ago by seigo
It is not commonly understood how software development projects moving forward as fast as they can and sometimes do, can be in direct conflict with their actual rate of adoption, not to mention their commercial delivery to market. This post outlines ... [More] the differences between short- and long-term commitments, and how the distinction can be used to form complementary facets of a project, rather than remain in perpetual conflict. Generically speaking, the result of a single iteration of an agile development methodology should result in two things; A known, established and verified upgrade path from the previous iteration, However slight an increment in product value. In contrast to the moving target as outcome of iterations in projects using the agile methodology with its virtually inherent unpredictability, businesses sign contracts with promises, including but not limited to; A version of the product that is both quality-assured and stable — meaning there are no surprises at the end of consuming a stream, meaning neither pleasant nor unpleasant surprises, Support for that version for a much longer period of time than the original outcome of any one particular (group of) development iterations, Incremental updates to support sustainability of the product, be it bug fixes or incremental enhancements, Service level agreements guaranteeing turn-around time-lines, A competitive value proposition based on the aforementioned parameters, Services including but not limited to development of customizations, training and consultancy, The next version of the product meeting all facets of the current version of the product. There are a few additional aspects I could go in to that need to be omitted for genuine Free Software ISVs, such as licensing and exclusivity, as I consider both to be strong-arming a competitive edge, or bullying. Short-term Commitments A short-term commitment is a predictable time-line with an established amount of investment in which the product value can incrementally be increased with a known value. We can state with a degree of certainty that these commitments are relatively small compared to a contractually obligatory commitment to paying customers, to support their deployment for up to 72 months, or 6 years. We can also state that the goal with short-term commitments is an increase in product value, and that the motivations for development partaking in short-term commitments prioritizes the incremental enhancements sorted by descending value increment. As such, short-term commitments are made with an eye on the future — research & development prototyping something, for example. Long-term Commitments A long-term commitment is a period of time often spanning multiple years, during which promises need to be delivered on. These promises have been made to oneself, a community at large and paying customers. These promises include hard targets (contractually obligatory facets) and soft targets (the next generation of a product stream). They will have to be kept though — as such long-term commitments are made with an eye on the past, including tomorrow, aka. the future past. We can state with certainty that very few developers are interested in, and even fewer capable of, both the development of the next generation of the product and maintaining up to 6 or 7 legacy versions. We can also state an ability to support and troubleshoot a set of often ill-articulated symptoms remotely is quite a different discipline. It is not easy to establish how much costs are to be associated with long-term commitments ahead of time, albeit there are models to estimate such costs. One method to reduce such costs (and therefore better predict real costs within a smaller margin of error) is to ramp up quality assurance. It is, proverbially speaking, making sure your customers do not have to pick up the phone at all and therefore reduce the support cost while demonstratively increasing the value of the KSP. Quality assurance however still spells a certain degree of uncertainty in real cost, and is another long-term commitment — except when it is automated and frequently executed, preferrably as early as possible. Customer, Product or Business Value? If you were to entertain only short-term commitments, the product value would be unjustly biased toward customer value as a means to achieve business value. Customer value however is often perceived rather than real, as customers will think the world of the feature they request be included — an absolute necessity, can’t work without out. Ultimately, it morphs the product toward a collection of complex features that are not generically applicable to most or all consumers of the product. Product value needs to be understood to mean generically applicable functionality, or high-value functionality applicable more selectively. This implies that functionality applicable more generically is multiplied the product value of implicitly, albeit by an indeterminate factor. It would therefore be prioritized accordingly. When a project deliberately pursues the implementation of more specific functionality, this should be considered a matter of strategy, such as opening up entire market segments, target audiences and industries. For the real punchline, let’s look at business value. In a genuinely Free Software ISV business, there’s little distinction between product value and business value. For all considerations development, future and short-term commitments, the business value of the product can only rise if the product value itself rises. In other words, if the product’s business value, so does the product value itself. If the product value rises, so does its business value. To put things in perspective, draw a distinction between the business value of the product, and the value of the business. Linking It All Up The long-term commitments predicate that the result of short-term commitments come with a meaningful degree of certainty and confidence. That is to say, very, very well verified. Provided “very well verified” translates in to actionable items, continuous integration testing is used to establish what score such certainty and confidence may translate into — as early on as possible. Allowing for the different stages of a single iteration in development means that this must be seeded correctly in order to acknowledge or decline the bar to delivery has been surpassed. This strongly suggests the process used for development teams is Test-Driven Development, which would certainly increase the certainty on correct input to the development process earlier than a retrospective-based feedback cycle on having missed the mark, and increases certainty and confidence on the result of an iteration as well. To prevent source code management from containing tests failing as a result, we can bring mandatory code review in to play.   [Less]
Posted over 8 years ago by seigo
It is not commonly understood how software development projects moving forward as fast as they can and sometimes do, can be in direct conflict with their actual rate of adoption, not to mention their commercial delivery to market. This post outlines ... [More] the differences between short- and long-term commitments, and how the distinction can be used to form complementary facets of a project, rather than remain in perpetual conflict. Generically speaking, the result of a single iteration of an agile development methodology should result in two things; A known, established and verified upgrade path from the previous iteration, However slight an increment in product value. In contrast to the moving target as outcome of iterations in projects using the agile methodology with its virtually inherent unpredictability, businesses sign contracts with promises, including but not limited to; A version of the product that is both quality-assured and stable — meaning there are no surprises at the end of consuming a stream, meaning neither pleasant nor unpleasant surprises, Support for that version for a much longer period of time than the original outcome of any one particular (group of) development iterations, Incremental updates to support sustainability of the product, be it bug fixes or incremental enhancements, Service level agreements guaranteeing turn-around time-lines, A competitive value proposition based on the aforementioned parameters, Services including but not limited to development of customizations, training and consultancy, The next version of the product meeting all facets of the current version of the product. There are a few additional aspects I could go in to that need to be omitted for genuine Free Software ISVs, such as licensing and exclusivity, as I consider both to be strong-arming a competitive edge, or bullying. Short-term Commitments A short-term commitment is a predictable time-line with an established amount of investment in which the product value can incrementally be increased with a known value. We can state with a degree of certainty that these commitments are relatively small compared to a contractually obligatory commitment to paying customers, to support their deployment for up to 72 months, or 6 years. We can also state that the goal with short-term commitments is an increase in product value, and that the motivations for development partaking in short-term commitments prioritizes the incremental enhancements sorted by descending value increment. As such, short-term commitments are made with an eye on the future — research & development prototyping something, for example. Long-term Commitments A long-term commitment is a period of time often spanning multiple years, during which promises need to be delivered on. These promises have been made to oneself, a community at large and paying customers. These promises include hard targets (contractually obligatory facets) and soft targets (the next generation of a product stream). They will have to be kept though — as such long-term commitments are made with an eye on the past, including tomorrow, aka. the future past. We can state with certainty that very few developers are interested in, and even fewer capable of, both the development of the next generation of the product and maintaining up to 6 or 7 legacy versions. We can also state an ability to support and troubleshoot a set of often ill-articulated symptoms remotely is quite a different discipline. It is not easy to establish how much costs are to be associated with long-term commitments ahead of time, albeit there are models to estimate such costs. One method to reduce such costs (and therefore better predict real costs within a smaller margin of error) is to ramp up quality assurance. It is, proverbially speaking, making sure your customers do not have to pick up the phone at all and therefore reduce the support cost while demonstratively increasing the value of the KSP. Quality assurance however still spells a certain degree of uncertainty in real cost, and is another long-term commitment — except when it is automated and frequently executed, preferrably as early as possible. Customer, Product or Business Value? If you were to entertain only short-term commitments, the product value would be unjustly biased toward customer value as a means to achieve business value. Customer value however is often perceived rather than real, as customers will think the world of the feature they request be included — an absolute necessity, can’t work without out. Ultimately, it morphs the product toward a collection of complex features that are not generically applicable to most or all consumers of the product. Product value needs to be understood to mean generically applicable functionality, or high-value functionality applicable more selectively. This implies that functionality applicable more generically is multiplied the product value of implicitly, albeit by an indeterminate factor. It would therefore be prioritized accordingly. When a project deliberately pursues the implementation of more specific functionality, this should be considered a matter of strategy, such as opening up entire market segments, target audiences and industries. For the real punchline, let’s look at business value. In a genuinely Free Software ISV business, there’s little distinction between product value and business value. For all considerations development, future and short-term commitments, the business value of the product can only rise if the product value itself rises. In other words, if the product’s business value, so does the product value itself. If the product value rises, so does its business value. To put things in perspective, draw a distinction between the business value of the product, and the value of the business. Linking It All Up The long-term commitments predicate that the result of short-term commitments come with a meaningful degree of certainty and confidence. That is to say, very, very well verified. Provided “very well verified” translates in to actionable items, continuous integration testing is used to establish what score such certainty and confidence may translate into — as early on as possible. Allowing for the different stages of a single iteration in development means that this must be seeded correctly in order to acknowledge or decline the bar to delivery has been surpassed. This strongly suggests the process used for development teams is Test-Driven Development, which would certainly increase the certainty on correct input to the development process earlier than a retrospective-based feedback cycle on having missed the mark, and increases certainty and confidence on the result of an iteration as well. To prevent source code management from containing tests failing as a result, we can bring mandatory code review in to play.   [Less]
Posted over 8 years ago by seigo
It is not commonly understood how software development projects moving forward as fast as they can and sometimes do, can be in direct conflict with their actual rate of adoption, not to mention their commercial delivery to market. This post outlines ... [More] the differences between short- and long-term commitments, and how the distinction can be used to form complementary facets of a project, rather than remain in perpetual conflict. Generically speaking, the result of a single iteration of an agile development methodology should result in two things; A known, established and verified upgrade path from the previous iteration, However slight an increment in product value. In contrast to the moving target as outcome of iterations in projects using the agile methodology with its virtually inherent unpredictability, businesses sign contracts with promises, including but not limited to; A version of the product that is both quality-assured and stable — meaning there are no surprises at the end of consuming a stream, meaning neither pleasant nor unpleasant surprises, Support for that version for a much longer period of time than the original outcome of any one particular (group of) development iterations, Incremental updates to support sustainability of the product, be it bug fixes or incremental enhancements, Service level agreements guaranteeing turn-around time-lines, A competitive value proposition based on the aforementioned parameters, Services including but not limited to development of customizations, training and consultancy, The next version of the product meeting all facets of the current version of the product. There are a few additional aspects I could go in to that need to be omitted for genuine Free Software ISVs, such as licensing and exclusivity, as I consider both to be strong-arming a competitive edge, or bullying. Short-term Commitments A short-term commitment is a predictable time-line with an established amount of investment in which the product value can incrementally be increased with a known value. We can state with a degree of certainty that these commitments are relatively small compared to a contractually obligatory commitment to paying customers, to support their deployment for up to 72 months, or 6 years. We can also state that the goal with short-term commitments is an increase in product value, and that the motivations for development partaking in short-term commitments prioritizes the incremental enhancements sorted by descending value increment. As such, short-term commitments are made with an eye on the future — research & development prototyping something, for example. Long-term Commitments A long-term commitment is a period of time often spanning multiple years, during which promises need to be delivered on. These promises have been made to oneself, a community at large and paying customers. These promises include hard targets (contractually obligatory facets) and soft targets (the next generation of a product stream). They will have to be kept though — as such long-term commitments are made with an eye on the past, including tomorrow, aka. the future past. We can state with certainty that very few developers are interested in, and even fewer capable of, both the development of the next generation of the product and maintaining up to 6 or 7 legacy versions. We can also state an ability to support and troubleshoot a set of often ill-articulated symptoms remotely is quite a different discipline. It is not easy to establish how much costs are to be associated with long-term commitments ahead of time, albeit there are models to estimate such costs. One method to reduce such costs (and therefore better predict real costs within a smaller margin of error) is to ramp up quality assurance. It is, proverbially speaking, making sure your customers do not have to pick up the phone at all and therefore reduce the support cost while demonstratively increasing the value of the KSP. Quality assurance however still spells a certain degree of uncertainty in real cost, and is another long-term commitment — except when it is automated and frequently executed, preferrably as early as possible. Customer, Product or Business Value? If you were to entertain only short-term commitments, the product value would be unjustly biased toward customer value as a means to achieve business value. Customer value however is often perceived rather than real, as customers will think the world of the feature they request be included — an absolute necessity, can’t work without out. Ultimately, it morphs the product toward a collection of complex features that are not generically applicable to most or all consumers of the product. Product value needs to be understood to mean generically applicable functionality, or high-value functionality applicable more selectively. This implies that functionality applicable more generically is multiplied the product value of implicitly, albeit by an indeterminate factor. It would therefore be prioritized accordingly. When a project deliberately pursues the implementation of more specific functionality, this should be considered a matter of strategy, such as opening up entire market segments, target audiences and industries. For the real punchline, let’s look at business value. In a genuinely Free Software ISV business, there’s little distinction between product value and business value. For all considerations development, future and short-term commitments, the business value of the product can only rise if the product value itself rises. In other words, if the product’s business value, so does the product value itself. If the product value rises, so does its business value. To put things in perspective, draw a distinction between the business value of the product, and the value of the business. Linking It All Up The long-term commitments predicate that the result of short-term commitments come with a meaningful degree of certainty and confidence. That is to say, very, very well verified. Provided “very well verified” translates in to actionable items, continuous integration testing is used to establish what score such certainty and confidence may translate into — as early on as possible. Allowing for the different stages of a single iteration in development means that this must be seeded correctly in order to acknowledge or decline the bar to delivery has been surpassed. This strongly suggests the process used for development teams is Test-Driven Development, which would certainly increase the certainty on correct input to the development process earlier than a retrospective-based feedback cycle on having missed the mark, and increases certainty and confidence on the result of an iteration as well. To prevent source code management from containing tests failing as a result, we can bring mandatory code review in to play.   [Less]
Posted over 8 years ago by seigo
It is not commonly understood how software development projects moving forward as fast as they can and sometimes do, can be in direct conflict with their actual rate of adoption, not to mention their commercial delivery to market. This post outlines ... [More] the differences between short- and long-term commitments, and how the distinction can be used to form complementary facets of a project, rather than remain in perpetual conflict. Generically speaking, the result of a single iteration of an agile development methodology should result in two things; A known, established and verified upgrade path from the previous iteration, However slight an increment in product value. In contrast to the moving target as outcome of iterations in projects using the agile methodology with its virtually inherent unpredictability, businesses sign contracts with promises, including but not limited to; A version of the product that is both quality-assured and stable — meaning there are no surprises at the end of consuming a stream, meaning neither pleasant nor unpleasant surprises, Support for that version for a much longer period of time than the original outcome of any one particular (group of) development iterations, Incremental updates to support sustainability of the product, be it bug fixes or incremental enhancements, Service level agreements guaranteeing turn-around time-lines, A competitive value proposition based on the aforementioned parameters, Services including but not limited to development of customizations, training and consultancy, The next version of the product meeting all facets of the current version of the product. There are a few additional aspects I could go in to that need to be omitted for genuine Free Software ISVs, such as licensing and exclusivity, as I consider both to be strong-arming a competitive edge, or bullying. Short-term Commitments A short-term commitment is a predictable time-line with an established amount of investment in which the product value can incrementally be increased with a known value. We can state with a degree of certainty that these commitments are relatively small compared to a contractually obligatory commitment to paying customers, to support their deployment for up to 72 months, or 6 years. We can also state that the goal with short-term commitments is an increase in product value, and that the motivations for development partaking in short-term commitments prioritizes the incremental enhancements sorted by descending value increment. As such, short-term commitments are made with an eye on the future — research & development prototyping something, for example. Long-term Commitments A long-term commitment is a period of time often spanning multiple years, during which promises need to be delivered on. These promises have been made to oneself, a community at large and paying customers. These promises include hard targets (contractually obligatory facets) and soft targets (the next generation of a product stream). They will have to be kept though — as such long-term commitments are made with an eye on the past, including tomorrow, aka. the future past. We can state with certainty that very few developers are interested in, and even fewer capable of, both the development of the next generation of the product and maintaining up to 6 or 7 legacy versions. We can also state an ability to support and troubleshoot a set of often ill-articulated symptoms remotely is quite a different discipline. It is not easy to establish how much costs are to be associated with long-term commitments ahead of time, albeit there are models to estimate such costs. One method to reduce such costs (and therefore better predict real costs within a smaller margin of error) is to ramp up quality assurance. It is, proverbially speaking, making sure your customers do not have to pick up the phone at all and therefore reduce the support cost while demonstratively increasing the value of the KSP. Quality assurance however still spells a certain degree of uncertainty in real cost, and is another long-term commitment — except when it is automated and frequently executed, preferrably as early as possible. Customer, Product or Business Value? If you were to entertain only short-term commitments, the product value would be unjustly biased toward customer value as a means to achieve business value. Customer value however is often perceived rather than real, as customers will think the world of the feature they request be included — an absolute necessity, can’t work without out. Ultimately, it morphs the product toward a collection of complex features that are not generically applicable to most or all consumers of the product. Product value needs to be understood to mean generically applicable functionality, or high-value functionality applicable more selectively. This implies that functionality applicable more generically is multiplied the product value of implicitly, albeit by an indeterminate factor. It would therefore be prioritized accordingly. When a project deliberately pursues the implementation of more specific functionality, this should be considered a matter of strategy, such as opening up entire market segments, target audiences and industries. For the real punchline, let’s look at business value. In a genuinely Free Software ISV business, there’s little distinction between product value and business value. For all considerations development, future and short-term commitments, the business value of the product can only rise if the product value itself rises. In other words, if the product’s business value, so does the product value itself. If the product value rises, so does its business value. To put things in perspective, draw a distinction between the business value of the product, and the value of the business. Linking It All Up The long-term commitments predicate that the result of short-term commitments come with a meaningful degree of certainty and confidence. That is to say, very, very well verified. Provided “very well verified” translates in to actionable items, continuous integration testing is used to establish what score such certainty and confidence may translate into — as early on as possible. Allowing for the different stages of a single iteration in development means that this must be seeded correctly in order to acknowledge or decline the bar to delivery has been surpassed. This strongly suggests the process used for development teams is Test-Driven Development, which would certainly increase the certainty on correct input to the development process earlier than a retrospective-based feedback cycle on having missed the mark, and increases certainty and confidence on the result of an iteration as well. To prevent source code management from containing tests failing as a result, we can bring mandatory code review in to play.   [Less]
Posted over 8 years ago by seigo
It is not commonly understood how software development projects moving forward as fast as they can and sometimes do, can be in direct conflict with their actual rate of adoption, not to mention their commercial delivery to market. This post outlines ... [More] the differences between short- and long-term commitments, and how the distinction can be used to form complementary facets of a project, rather than remain in perpetual conflict. Generically speaking, the result of a single iteration of an agile development methodology should result in two things; A known, established and verified upgrade path from the previous iteration, However slight an increment in product value. In contrast to the moving target as outcome of iterations in projects using the agile methodology with its virtually inherent unpredictability, businesses sign contracts with promises, including but not limited to; A version of the product that is both quality-assured and stable — meaning there are no surprises at the end of consuming a stream, meaning neither pleasant nor unpleasant surprises, Support for that version for a much longer period of time than the original outcome of any one particular (group of) development iterations, Incremental updates to support sustainability of the product, be it bug fixes or incremental enhancements, Service level agreements guaranteeing turn-around time-lines, A competitive value proposition based on the aforementioned parameters, Services including but not limited to development of customizations, training and consultancy, The next version of the product meeting all facets of the current version of the product. There are a few additional aspects I could go in to that need to be omitted for genuine Free Software ISVs, such as licensing and exclusivity, as I consider both to be strong-arming a competitive edge, or bullying. Short-term Commitments A short-term commitment is a predictable time-line with an established amount of investment in which the product value can incrementally be increased with a known value. We can state with a degree of certainty that these commitments are relatively small compared to a contractually obligatory commitment to paying customers, to support their deployment for up to 72 months, or 6 years. We can also state that the goal with short-term commitments is an increase in product value, and that the motivations for development partaking in short-term commitments prioritizes the incremental enhancements sorted by descending value increment. As such, short-term commitments are made with an eye on the future — research & development prototyping something, for example. Long-term Commitments A long-term commitment is a period of time often spanning multiple years, during which promises need to be delivered on. These promises have been made to oneself, a community at large and paying customers. These promises include hard targets (contractually obligatory facets) and soft targets (the next generation of a product stream). They will have to be kept though — as such long-term commitments are made with an eye on the past, including tomorrow, aka. the future past. We can state with certainty that very few developers are interested in, and even fewer capable of, both the development of the next generation of the product and maintaining up to 6 or 7 legacy versions. We can also state an ability to support and troubleshoot a set of often ill-articulated symptoms remotely is quite a different discipline. It is not easy to establish how much costs are to be associated with long-term commitments ahead of time, albeit there are models to estimate such costs. One method to reduce such costs (and therefore better predict real costs within a smaller margin of error) is to ramp up quality assurance. It is, proverbially speaking, making sure your customers do not have to pick up the phone at all and therefore reduce the support cost while demonstratively increasing the value of the KSP. Quality assurance however still spells a certain degree of uncertainty in real cost, and is another long-term commitment — except when it is automated and frequently executed, preferrably as early as possible. Customer, Product or Business Value? If you were to entertain only short-term commitments, the product value would be unjustly biased toward customer value as a means to achieve business value. Customer value however is often perceived rather than real, as customers will think the world of the feature they request be included — an absolute necessity, can’t work without out. Ultimately, it morphs the product toward a collection of complex features that are not generically applicable to most or all consumers of the product. Product value needs to be understood to mean generically applicable functionality, or high-value functionality applicable more selectively. This implies that functionality applicable more generically is multiplied the product value of implicitly, albeit by an indeterminate factor. It would therefore be prioritized accordingly. When a project deliberately pursues the implementation of more specific functionality, this should be considered a matter of strategy, such as opening up entire market segments, target audiences and industries. For the real punchline, let’s look at business value. In a genuinely Free Software ISV business, there’s little distinction between product value and business value. For all considerations development, future and short-term commitments, the business value of the product can only rise if the product value itself rises. In other words, if the product’s business value, so does the product value itself. If the product value rises, so does its business value. To put things in perspective, draw a distinction between the business value of the product, and the value of the business. Linking It All Up The long-term commitments predicate that the result of short-term commitments come with a meaningful degree of certainty and confidence. That is to say, very, very well verified. Provided “very well verified” translates in to actionable items, continuous integration testing is used to establish what score such certainty and confidence may translate into — as early on as possible. Allowing for the different stages of a single iteration in development means that this must be seeded correctly in order to acknowledge or decline the bar to delivery has been surpassed. This strongly suggests the process used for development teams is Test-Driven Development, which would certainly increase the certainty on correct input to the development process earlier than a retrospective-based feedback cycle on having missed the mark, and increases certainty and confidence on the result of an iteration as well. To prevent source code management from containing tests failing as a result, we can bring mandatory code review in to play.   [Less]
Posted over 8 years ago by seigo
It is not commonly understood how software development projects moving forward as fast as they can and sometimes do, can be in direct conflict with their actual rate of adoption, not to mention their commercial delivery to market. This post outlines ... [More] the differences between short- and long-term commitments, and how the distinction can be used to form complementary facets of a project, rather than remain in perpetual conflict. Generically speaking, the result of a single iteration of an agile development methodology should result in two things; A known, established and verified upgrade path from the previous iteration, However slight an increment in product value. In contrast to the moving target as outcome of iterations in projects using the agile methodology with its virtually inherent unpredictability, businesses sign contracts with promises, including but not limited to; A version of the product that is both quality-assured and stable — meaning there are no surprises at the end of consuming a stream, meaning neither pleasant nor unpleasant surprises, Support for that version for a much longer period of time than the original outcome of any one particular (group of) development iterations, Incremental updates to support sustainability of the product, be it bug fixes or incremental enhancements, Service level agreements guaranteeing turn-around time-lines, A competitive value proposition based on the aforementioned parameters, Services including but not limited to development of customizations, training and consultancy, The next version of the product meeting all facets of the current version of the product. There are a few additional aspects I could go in to that need to be omitted for genuine Free Software ISVs, such as licensing and exclusivity, as I consider both to be strong-arming a competitive edge, or bullying. Short-term Commitments A short-term commitment is a predictable time-line with an established amount of investment in which the product value can incrementally be increased with a known value. We can state with a degree of certainty that these commitments are relatively small compared to a contractually obligatory commitment to paying customers, to support their deployment for up to 72 months, or 6 years. We can also state that the goal with short-term commitments is an increase in product value, and that the motivations for development partaking in short-term commitments prioritizes the incremental enhancements sorted by descending value increment. As such, short-term commitments are made with an eye on the future — research & development prototyping something, for example. Long-term Commitments A long-term commitment is a period of time often spanning multiple years, during which promises need to be delivered on. These promises have been made to oneself, a community at large and paying customers. These promises include hard targets (contractually obligatory facets) and soft targets (the next generation of a product stream). They will have to be kept though — as such long-term commitments are made with an eye on the past, including tomorrow, aka. the future past. We can state with certainty that very few developers are interested in, and even fewer capable of, both the development of the next generation of the product and maintaining up to 6 or 7 legacy versions. We can also state an ability to support and troubleshoot a set of often ill-articulated symptoms remotely is quite a different discipline. It is not easy to establish how much costs are to be associated with long-term commitments ahead of time, albeit there are models to estimate such costs. One method to reduce such costs (and therefore better predict real costs within a smaller margin of error) is to ramp up quality assurance. It is, proverbially speaking, making sure your customers do not have to pick up the phone at all and therefore reduce the support cost while demonstratively increasing the value of the KSP. Quality assurance however still spells a certain degree of uncertainty in real cost, and is another long-term commitment — except when it is automated and frequently executed, preferrably as early as possible. Customer, Product or Business Value? If you were to entertain only short-term commitments, the product value would be unjustly biased toward customer value as a means to achieve business value. Customer value however is often perceived rather than real, as customers will think the world of the feature they request be included — an absolute necessity, can’t work without out. Ultimately, it morphs the product toward a collection of complex features that are not generically applicable to most or all consumers of the product. Product value needs to be understood to mean generically applicable functionality, or high-value functionality applicable more selectively. This implies that functionality applicable more generically is multiplied the product value of implicitly, albeit by an indeterminate factor. It would therefore be prioritized accordingly. When a project deliberately pursues the implementation of more specific functionality, this should be considered a matter of strategy, such as opening up entire market segments, target audiences and industries. For the real punchline, let’s look at business value. In a genuinely Free Software ISV business, there’s little distinction between product value and business value. For all considerations development, future and short-term commitments, the business value of the product can only rise if the product value itself rises. In other words, if the product’s business value, so does the product value itself. If the product value rises, so does its business value. To put things in perspective, draw a distinction between the business value of the product, and the value of the business. Linking It All Up The long-term commitments predicate that the result of short-term commitments come with a meaningful degree of certainty and confidence. That is to say, very, very well verified. Provided “very well verified” translates in to actionable items, continuous integration testing is used to establish what score such certainty and confidence may translate into — as early on as possible. Allowing for the different stages of a single iteration in development means that this must be seeded correctly in order to acknowledge or decline the bar to delivery has been surpassed. This strongly suggests the process used for development teams is Test-Driven Development, which would certainly increase the certainty on correct input to the development process earlier than a retrospective-based feedback cycle on having missed the mark, and increases certainty and confidence on the result of an iteration as well. To prevent source code management from containing tests failing as a result, we can bring mandatory code review in to play.   [Less]