archive-nl.com » NL » I » IMPROVEMENT-SERVICES.NL

Total: 128

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • October | 2014 | ImprovemenT
    idea is to stay in control while doing Agile Anyway this attempt to merge the two mindsets is the recipe for fiasco To translate an old Dutch proverb Between two religions on one pillow lies the devil Posted in Agile Mindset A Scrum Team as Dissipative Structure Posted on October 21 2014 by erikphilippus A fundamental aspect of the Agile mindset is the encouragement of self organization in teams The team has a collective responsibility for the results by making trade off decisions together adjusting roles dynamically and discover the best solutions on the fly Especially the traditional manager will have to get used to the idea that an Agile team will do all the work in a merely autonomous fashion including organizing themselves as a team It is a public secret that management is the largest impediment for the implementation of the Agile way of working 1 The concept of self organization Self organization in teams is a spontaneous phenomenon bring a number of people together in a room give them a goal that must be achieved within certain boundary conditions and wait Of course there are many ways that lead to Rome and most managers will not sit and wait until the self organizing team has found by itself the most suitable line of march Indeed self organization does not mean letting people do whatever they want to do Correctly applied self organization is a very powerful instrument to build a high performance team so the question is how to use it wisely and effectively After all an important Agile principle is to regards people as the most important asset in the organization which supports the idea of self organization in teams The concept of self organization has a strong scientific fundament provided by the Belgian Nobel laureate Ilya Prigogine 2 During his groundbreaking analysis of non equilibrium thermodynamics this physical chemist of Russian origine encountered an apparent contradiction According to the second law of thermodynamics any thermodynamic work process will show an increases in entropy due to dissipation of energy for instance in the form of frictional heat Hence every closed system will show an increasing amount of disorder unless external energy is supplied Escaping the trend toward chaos This would imply that the universe irreversibly moves to a situation of increasing chaos Nevertheless we see numerous processes in our environment leading to an increasing order which seems to contradict the law of increasing entropy Most striking example is the evolution from atoms to molecules amino acids proteins cells micro organisms etc This is undoubtedly a proces of increasing order against the stream of increasing disorder This paradox has puzzled scientists for a long time until Prigogine found the key open systems will not only exchange energy with the environment but are also capable of discharging an excess of entropy to their surrounding It is exactly this characteristic that enables systems to escape the trend of steadily increasing disorder There is an upper limit to the amount

    Original URL path: http://www.improvement-services.nl/blog/?m=201410 (2015-12-05)
    Open archived version from archive


  • August | 2014 | ImprovemenT
    must have the flexibility to assign user stories to Scrum teams at random e g if collaboration of teams or re allocation of work is needed to meet the next deadline In other words when more teams work together to deliver functionality for the same release there is a need for a project wide estimation scale This would make the velocity of the individual Scrum teams the only parameter for release planning not the scale each Scrum team is using for the estimation of user stories Therefore I always advise to install a separate estimation team comprising representatives of each Scrum team plus a few experts to arrive at a realistic estimations of user stories requiring specific expertise or knowledge This estimation team will do all the estimation of user stories using a single relative scale during each estimation session Product Owners are able to convene an estimation meeting at any time when new user stories need to be estimated by the estimation team As a result the Scrum teams will never do estimations of user stories anymore During the Sprint Planning meeting the only thing a Scrum team will have do is to identify the tasks needed to realize the user story possibly providing an hour based estimation of the identified tasks In that case it is even beneficial that they don t have story points as reference their commitment to deliver the user stories at the end of the sprint will be solely based on their appraisal of the work to be done Since a team knows its own velocity there would otherwise be the temptation to fill the sprint backlog accordingly The previous estimation of user stories would then become a self fullfilling prophecy In conclusion a separate estimation team provides estimations on a stable company wide

    Original URL path: http://www.improvement-services.nl/blog/?m=201408 (2015-12-05)
    Open archived version from archive

  • May | 2014 | ImprovemenT
    artefact are intertwined in a very clever way Removing a single element from Scrum like in RCS the Product Owner and the Product Backlog with User Stories will have desastreus consequences for the application of the method Apart from an underlined critique with respect to missing Scrum essentials the main question in this Dutch article is the rationale for RCS The reasons for the drastic deviation from Scrum are not provided which in itself raises questions In addition statements like Communication is more complex than software development or Scrum is too much focussed on itself doesn t make it easier to take RCS seriously Please make up your own mind Perhaps you have answers on the question why Scrum in its original and mature form would not be suitable for communication specialists just like Scrum is applied to a large and growing number of other non software domains Posted in Scrum Practices Search Recent Posts Beware of the Scrum Police Self Empowerment of Scrum Teams using Socratic Questioning Advanced Scrum Training at the Rugby Field That s how things are done around here Virtual Cattlegrids Metaphor for Agile Adoption Scrum of Scrums toward Agility on Strategic Level Agility and Resilience

    Original URL path: http://www.improvement-services.nl/blog/?m=201405 (2015-12-05)
    Open archived version from archive

  • February | 2014 | ImprovemenT
    and misinterpreted requirements piled up after every stage Late discovery of wrong presumptions could even be a fatal blow for the whole project The collaboration of the parties involved will harbor suspicions against each other resulting in many formal verification moments This control attitude will not only slow down the process but contributes significantly to the total cost of the end product Workers are focussed on their contribution only and don t feel the responsibility for the overall product This limitation of scope will be at the expense of craftsmanship and will reduce the usability of the final deliverable To cut a long story short chain management is not a team sport In a self empowered team the weakest link will be taken care for by all the team members Not the weakest player but the strongest team member will capture the pressure This type of collaboration is not like a chain but has more similarity with a rope all parties are involved from the beginning to delivery of the end result Application of rope management will of course utilize the diversity of skilled workers to a much larger extend Every player knows the overall goal and will therefore be motivated to contribute to the final product Craftsmanship and individual talents will be fully appreciated promoting a high quality end product In contrast with working in a chain effective and simple solutions for complex problem will emerge within the team Since it is based on the agile mindset rope management will make the chain much stronger than the sum total of the strength of all participants Although rope management may appear as chaotic and confusing to the traditional manager from the first impression I m convinced that it will overcome the chain management model despite its tempting explicitness and clarity

    Original URL path: http://www.improvement-services.nl/blog/?m=201402 (2015-12-05)
    Open archived version from archive

  • September | 2013 | ImprovemenT
    the number of white box tests that are required to obtain sufficient coverage Benchmarking suggests to keep the cyclomatic number of the majority of functions below 10 or 20 But software will work whether the cyclomatic number is 10 100 or even 500 The required test effort and the cost of maintenance are usually not part of the demo And to be honest most stakeholders are not interested either For me this is hard to understand since excessive complexity has a direct negative impact on development and exploitation cost of software The only plausible explanation I have heard so far is that the total cost of ownership will eventually land at someone s else plate Is working software the primary measure of progress I have reason to believe that I belong to a minority when I question the literal interpretation of the phrase working software In a recent conversation Jeff Sutherland made the statement that it is totally unacceptable not to have working software at the end of a sprint Teams that fail to do this are not worthy of trust I agree that working software is an important measure of progress And the strong emphasis on working software is an understandable response to the activities of the ivory tower architect and to prevent the infamous BDUF But these kind of ardent and sometimes even dogmatic statements cannot hide the fact that agile does not have a good answer for how to handle service level requirements all the ilities including the aforementioned complexity If working software is unmaintainable would that be still a reliable measure of progress On the other hand agile acknowledges the importance of quality software has to be high quality and quality is not negotiable In the Scrum Guide however the word quality is only mentioned three times in a completely unspecified manner And I also found this cliffhanger if you have a good definition of done the quality won t suffer Software quality as part of the definition of done The question remains what exactly is meant by quality and how do you ensure it If asked most developers will provide an outline of agile practices that will ensure the quality of their code such as pair work peer reviews refactoring test first continuous integration etc Although applaudable approaches the quality can only be assured when quantified by actual measurement The numbers will tell the tale So my point of departure would be to specify the relevant quality demands as part of the default definition of done It is up to the team how to arrive at the requested quality level At sprint review the team has to demonstrate that software functions not only work but also adhere to the agreed upon quality specification The measurement of quality is in general not a big deal e g most development environments are capable to automatically measure the cyclomatic complexity when software is checked in Agile Design Upfront A last remark from an old hand you can t

    Original URL path: http://www.improvement-services.nl/blog/?m=201309 (2015-12-05)
    Open archived version from archive

  • August | 2013 | ImprovemenT
    first architecture spike is that whilst setting the initial skeleton and creating a single vision of how it might hang together not much is set in stone The goal of this architecture spike is to rough out subsystem boundaries transition points between software layers physical constraints etc Subsystems and other details are typically faked with stubs although is sometimes desirable to have enough of the software be real in order to actually do some preliminary performance and capacity planning assessment The architecture spike will often demonstrate that some parts of the architecture are not going to work illogical partitioning state held in the wrong place unbalanced data transfer wrong footprint etc This type of architecture spike has been compared with sight reading in music Agile Modeling I can t get away from the impression that this approach corresponds with a Small Design Up Front validated with experimental code The problem I have is that it seems to ignore modeling as a means to validate the architecture In my view it is a mistake to assume you always need working code for a proof of concept Of course models have their restrictions and pitfalls but I think it is nonsense to put modeling aside as being non agile As Scott Ambler illustrates with his concept of Agile Modeling there is no need to turn back the clock Quality Driven Architecting But what I think is a much more serious drawback of this type of architecture spike is the absence of an overall vision on crucial product qualities such as extendability and maintainability As I hope we have learned by now these quality requirements must be build into the system right from the start moreover they must be enforced by the architecture Especially when the software we re going to deliver is part of a portfolio of products it is vital to translate the product roadmap into a sound architectural foundation to guarantee the required product quality attributes for all members of the product family It is of course a laudable goal to focus on working software delivering value adding features to end users But we tend to forget that in general the majority of the total cost of software projects comes after initial fielding the system In most cases these costs can be rooted back to missing quality attributes and not to missing features When the non functional qualities come at the bottom of the list the total cost of ownership will rise sharply while business opportunities are missed It is a fact that the majority of today s industrial software systems confront their owners and users with costly maintenance or legacy issues So in my opinion the pressing question that should be answered during the initial architecture spike s is what are in the longer term the true value adding aspects of the software system apart from the tangible and potentially shippable features Agile Architecture Method As far as I know the only agile method that makes an attempt to bake quality into the life cycle is the Agile Architecture Method as proposed by J D Meier Essentially this method helps to identify key engineering decisions or hot spots against the prioritized user stories during each iteration The main hot spots are not only cross cutting concerns such as data access exception management logging etc but also quality attributes such as security performance reliability etc The Agile Architecture Method offers a structured approach for the creation of candidate architecture s identification of relevant spikes identification of deployment constraints and guidance for inspections throughout the life cycle I believe that the explicit attention for cross cutting concerns and quality requirements is a strong element of this method since these are the areas in which high impact mistakes are often made I find it therefore quite confusing that Just in Time Architecture is presented as a way to find intersections between stories and quality attributes during iterations In my view it is impossible to address critical quality attributes Just in Time vital product quality requirements must be satisfied on system level and by definition they transcend individual modules and iterations Just in Time Architecture I have the impression that the Agile Architecture Method doesn t make a distinction between architecture and design Perhaps that s the reason for the flirtation with the unfortunate phrase Just in Time Architecture I believe that it is realistic and cost effective to define architecting as an evolving process which will flourish by an iterative approach However I do think that the essential product quality attributes must be agreed upon upfront together with their domain specific definitions measuring approach and acceptance criteria And of course the architecture spike or Spint 0 is a good candidate to nail down these overall quality requirements Then it is the responsibility of the architect that quality levels appear in the product backlog as acceptance criteria for selected user stories This approach offers the opportunity to explicitly monitor the required quality attributes further downstream and to take corrective measures Just in Time Using the architecture spike this way customers are helped to make business value decisions while the risk of degrading product quality during implementation is minimized promoting delivery of real customer value Posted in Agile Architecting Awakening the Agile Mindset Posted on August 19 2013 by erikphilippus The rectification of names The Chinese sage Confucius believed that social disorder often stemmed from failure to perceive understand and deal with reality Fundamentally then social disorder can stem from the failure to call things by their proper names and his solution to this was the Rectification of Names 正 名 This Confucian doctrine is based on the belief that from the right name the right reality should follow rather than assuming as we do in the West that names reflect reality During the Chinese Cultural Revolution the Red Guards destroyed all public signs which contained any reference to the reactionary bourgeois past New street signs with revolutionary names were mounted in many streets in Chinese cities These actions were fully in keeping with the rules based on the Rectification of Names Therefore the renaming imposed by the Red Guards not only left an age old feature of Chinese culture intact but actually re emphasized it First order change The renaming of street signs is a classic example of a so called first order change Likewise first order change in a church could mean changing the hours for services renovating the building choosing new choir robes etc First order change involves any kind of change that changes an existing process from one form to another form but leaves the original purpose and standard in tact It is a change that is consistent with prevailing values and norms meets with general agreement and can be implemented using people s existing knowledge and skills Second order change Second order change is a disruptive change which challenges the existing culture and organizational paradigm including current expertise and competencies A change becomes second order when it requires people to learn new approaches or it conflicts with prevailing values and norms Second order changes require leaders to work far more deeply with people in the organization The eventual outcome of such a paradigm change is a transformed or renewed organization Nothing endures but change Heraclitis 535 BC 475 BC I believe that the migration to an agile way of working involves a paradigm shift It challenges the traditional belief that a project will be successful only when you re able to predict its progress and outcome right from the start Hence the agile mindset acknowledges change as a fact of life and provides skills that allow for adaptation rather than prediction So second order change is what we should mean when we talk about transformational change from a fixed mindset toward an agile mindset As discussed in a previous post an agile mind is not something you acquire I think it is best described as a rediscovery I might be addressing different ways to evoke the agile mind in future posts please find below two invitations to leave the beaten path by means of an appetizer Re evaluate critical feedback The litmus test of a changing mindset is the shift of the internal dialogue The fixed mindset creates an internal monologue that is focused on judging This means I m a loser This means I m a better person than they are While the agile mindset is indeed sensitive to positive and negative information it is attuned to the implications for learning and constructive action What can I learn from this How can I improve In other words a person with an agile mindset has fallen in love with feedback You are invited to perceive honest constructive feedback as a rare and precious gift especially when they are critical or painful Co create a place where is is safe to fail The agile mindset promotes learning at every opportunity through both success and failure However to be able to learn from failure we must feel safe enough to fail Hence we need to find ways of creating safety as a platform for the adoption of the agile mindset Within this context safety is multi faceted and shared responsibility Help to create safety for the developers the managers the organization as well as for the customer You are invited to develop a gentle attitude toward failure both by yourself and others Posted in Agile Mindset Agile Architecting Friends or Foes Posted on August 19 2013 by erikphilippus The emergence of agile methods has shaken the foundation of the ivory tower architecture A new breed of architects called Agile Architects is stepping up Architecture has always been controversial in the agile community Should design be done up front how much and when does architecture turn into BDUF the big bad wolf of agile programming The agilists are right to some extend most traditional architecture processes are heavy weight long winded and time consuming In circles of architects however agile methods are perceived as architecturally weak disconnected from the realities of delivering large multidisciplinary software intensive systems in complex environments Agile Architecting is an attempt to combine the best of both worlds The Essence of Agile What does it mean to be agile In general terms the phrase agile refers to a person being very limber and dexterous but also indicates a state of alertness and watchfulness At first sight this advanced interplay between body and mind sounds like a beneficial achievement for a yoga practitioner so what exactly does it mean in the context of software architecture Agile is commonly described by its characteristics such as iterative development frequent inspection and adaptation self organizing and cross functional teams etc Most of the agile methods are based on a set of core principles focussed on software delivery and collaboration The Agile Manifesto sums these up by stating that it values Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan These are merely the externally observable artifacts but this palette of descriptive terms does not really answer the question what is the essence of agile Looking at the inappropriate application of the honorary title agile to a wide range of practices that are in essence non agile there seems to be enough reason to elaborate upon the essence of the agile body of thought First of all it is of vital importance to understand that the agile approach is a reaction to a software development tradition that goes back three decades This tradition is rooted in the stubborn belief that predictability is a vital prerequisite for any industrial software development project This doesn t really come as a surprise given the prevailing post war engineering paradigm of a makable world In view of the high percentage of failed software development projects for many years the holy grail of software development was to gain full command of projects Only when a project was executed according to a predefined masterplan it would deliver what was specified at the start The deeply rooted rational for this line of thinking is the seductive assumption that if you cannot predict a process you cannot control it The connection between predictability and controllability is further intensified by the conviction that high perceived predictability is a protection against the stress of an imminent runaway project As a result we ve seen a long procession of methods and tools which all promise that they would be able to send the escaped ghost of unpredictability back in the bottle Of course some useful engineering practices have surfaced the last decades but the horizon of predictability of software projects has not been stretched significantly In fact the traditional approach has yielded a growing number of troubled or failed projects As demonstrated by the rise and fall of the widespread waterfall approach it is just not possible to fully command and control a sizeable software development project from sand to glass by using a serial lifecycle starting from a BDUF Big Design Up Front The siren song of the predictive approach is that it is based on a logical linear model and thus makes sense Instead of questioning the paradigm the methodology has been gradually expanded into a complicated long winded and sometimes even bureaucratic practice We ve been trying to create predictive requirements and communicate them perfectly up and down the hierarchy for over 30 years and failed year after year In most cases the predicted delivery date is the first day of the schedule slip In Hebrew there s a saying Tafasta Merube Lo Tafasta which means if you try to catch everything you will catch nothing In Lao Tzu s Tao Te Ching a similar saying is found Trying to control the future is like trying to take the master carpenter s place When you handle the master carpenter s tools chances are that you ll cut your hand In other words if you try to obtain perfect knowledge up front it will have the reverse effect Agile accepts change uncertainty and therefore unpredictability as the natural state This can be a quite uncomfortable thought for most traditional managers which is probably the reason why many organizations still value perceived predictability more than they value the ability to change direction quickly Ironically the agile approach gives you more predictability than those carefully planned up front project plans can provide The goal of an agile way of working is to promote collaboration the interaction of people on interpersonal cultural and structural levels To refute a common misunderstanding agile is not equivalent with quick Agility means adopting a posture that allows you to respond rapidly to changing market conditions and customer demands In a nutshell agile is adaptive instead of predictive Agile Architecting Many agilists regard agile to be the antithesis of the project manager s favoritism toward plan centric management They sometimes caricature the role of the architect as an inhabitant of an ivory tower surrounded by elaborated models and producing bulky architectural documentation that is subsequently assigned to the development team for realization But in circles of architects many agile methods are perceived as architecturally weak disconnected from the realities of delivering large systems in complex environments Although it is not surprising that the traditional architect is regarded by most agilists as a typical representative of the old paradigm in software engineering we must beware of throwing the child out with the bath water To dispose of architecture as the basis for the realization of sizeable and complicated software intensive systems is short sighted and would certainly move back the hands On the other hand the rise of the agile approach will inevitably force the traditional architecture community to reflect on a new interpretation of architecture To some extend the agilists are right most traditional architecture processes are heavy weight long winded and time consuming Agile architecting is an attempt to reshape the architecture process according to the new paradigm of system development aiming at an increased level of agility in architects themselves the architecture process the resulting architectures and delivered systems alike A beneficial side effect of agile is that it highlights the inherent conflict of the architect Dealing with perishable system requirements of imperceptible customers Conflicts with the managers who want to see the project delivered yesterday instead of tomorrow Daily struggles with developers who want to code now and think later Politically coloured trade off decisions As every seasoned architect knows there are many such conflicts some subtle that keep the stress up and the spirits low Agile architecting comprises all relevant and interrelated technical and non technical skills that help the architects to respond effectively to these notorious dilemmas Architecting is the art of addressing all relevant cross cutting concerns balancing the needs of the different stakeholders This remains fully applicable for agile architecting The daily practice of an agile architect will still include articulating the architectural vision conceptualizing architectural approaches creating models decompositions and interface specifications and validating the proposed architecture against quality requirements and assumptions The difference is in the level of responsiveness toward new unexpected information that becomes available during system development The agile architect has an adaptive attitude that is opposite to the traditional belief that requirements and design solutions should be frozen as early as possible The agility of the architecture itself is another cornerstone of agile architecting What is the distinguishing characteristic of an agile architecture To remove a source of misunderstanding in advance an agile architecture is not equivalent with a flexible architecture Although flexibility in itself can be a useful feature the pursuit to arrive at an overall flexible architecture is like chasing the pot of gold at the end of the rainbow In many cases demanding flexibility as a generic architectural requirement rather points at indecisiveness An agile architecture is based on a well considered choice with respect to the variability of the

    Original URL path: http://www.improvement-services.nl/blog/?m=201308 (2015-12-05)
    Open archived version from archive

  • Agile Architecting | ImprovemenT
    are not only cross cutting concerns such as data access exception management logging etc but also quality attributes such as security performance reliability etc The Agile Architecture Method offers a structured approach for the creation of candidate architecture s identification of relevant spikes identification of deployment constraints and guidance for inspections throughout the life cycle I believe that the explicit attention for cross cutting concerns and quality requirements is a strong element of this method since these are the areas in which high impact mistakes are often made I find it therefore quite confusing that Just in Time Architecture is presented as a way to find intersections between stories and quality attributes during iterations In my view it is impossible to address critical quality attributes Just in Time vital product quality requirements must be satisfied on system level and by definition they transcend individual modules and iterations Just in Time Architecture I have the impression that the Agile Architecture Method doesn t make a distinction between architecture and design Perhaps that s the reason for the flirtation with the unfortunate phrase Just in Time Architecture I believe that it is realistic and cost effective to define architecting as an evolving process which will flourish by an iterative approach However I do think that the essential product quality attributes must be agreed upon upfront together with their domain specific definitions measuring approach and acceptance criteria And of course the architecture spike or Spint 0 is a good candidate to nail down these overall quality requirements Then it is the responsibility of the architect that quality levels appear in the product backlog as acceptance criteria for selected user stories This approach offers the opportunity to explicitly monitor the required quality attributes further downstream and to take corrective measures Just in Time Using the architecture spike this way customers are helped to make business value decisions while the risk of degrading product quality during implementation is minimized promoting delivery of real customer value Posted in Agile Architecting Agile Architecting Friends or Foes Posted on August 19 2013 by erikphilippus The emergence of agile methods has shaken the foundation of the ivory tower architecture A new breed of architects called Agile Architects is stepping up Architecture has always been controversial in the agile community Should design be done up front how much and when does architecture turn into BDUF the big bad wolf of agile programming The agilists are right to some extend most traditional architecture processes are heavy weight long winded and time consuming In circles of architects however agile methods are perceived as architecturally weak disconnected from the realities of delivering large multidisciplinary software intensive systems in complex environments Agile Architecting is an attempt to combine the best of both worlds The Essence of Agile What does it mean to be agile In general terms the phrase agile refers to a person being very limber and dexterous but also indicates a state of alertness and watchfulness At first sight this advanced interplay between body and mind sounds like a beneficial achievement for a yoga practitioner so what exactly does it mean in the context of software architecture Agile is commonly described by its characteristics such as iterative development frequent inspection and adaptation self organizing and cross functional teams etc Most of the agile methods are based on a set of core principles focussed on software delivery and collaboration The Agile Manifesto sums these up by stating that it values Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan These are merely the externally observable artifacts but this palette of descriptive terms does not really answer the question what is the essence of agile Looking at the inappropriate application of the honorary title agile to a wide range of practices that are in essence non agile there seems to be enough reason to elaborate upon the essence of the agile body of thought First of all it is of vital importance to understand that the agile approach is a reaction to a software development tradition that goes back three decades This tradition is rooted in the stubborn belief that predictability is a vital prerequisite for any industrial software development project This doesn t really come as a surprise given the prevailing post war engineering paradigm of a makable world In view of the high percentage of failed software development projects for many years the holy grail of software development was to gain full command of projects Only when a project was executed according to a predefined masterplan it would deliver what was specified at the start The deeply rooted rational for this line of thinking is the seductive assumption that if you cannot predict a process you cannot control it The connection between predictability and controllability is further intensified by the conviction that high perceived predictability is a protection against the stress of an imminent runaway project As a result we ve seen a long procession of methods and tools which all promise that they would be able to send the escaped ghost of unpredictability back in the bottle Of course some useful engineering practices have surfaced the last decades but the horizon of predictability of software projects has not been stretched significantly In fact the traditional approach has yielded a growing number of troubled or failed projects As demonstrated by the rise and fall of the widespread waterfall approach it is just not possible to fully command and control a sizeable software development project from sand to glass by using a serial lifecycle starting from a BDUF Big Design Up Front The siren song of the predictive approach is that it is based on a logical linear model and thus makes sense Instead of questioning the paradigm the methodology has been gradually expanded into a complicated long winded and sometimes even bureaucratic practice We ve been trying to create predictive requirements and communicate them perfectly up and

    Original URL path: http://www.improvement-services.nl/blog/?cat=10 (2015-12-05)
    Open archived version from archive

  • ImprovemenT › Log In
    ImprovemenT Username Password Remember Me Lost your password Back to ImprovemenT

    Original URL path: http://www.improvement-services.nl/blog/wp-login.php (2015-12-05)
    Open archived version from archive



  •