Agile requirements in different product lifecycle stages

Agile requirements in different product lifecycle stages Oliver Leering 6020755

Thesis Master Information Studies Program Business Information Systems Universiteit van Amsterdam Faculty of Science and Faculty of Economics and Business

Final version: May 28th 2013 Mentor: drs. A.W. Abcouwer drs. A.W. Abcouwer, signature: drs. A. Vreeken, signature:

| Master Thesis | Universiteit van Amsterdam | Oliver Leering |

ABSTRACT Research on agile software development, with a focus on requirements engineering, and the four product lifecycle stages; introduction, growth, maturity and decline. What are the effects of these four stages on agile requirements engineering? The introduction stage is focused on product development, based on customer requirements. When the product matures there is a shift to increasing the products’ efficiency and quality. It is also differentiated to enter new markets. The type of software development changes from adding new features to bug fixing and improving the product. How does agile requirements engineering fit in this process during the lifecycle? Requirements engineering is closely related to the critical success factor of agile; customer involvement.

| Page 2 |


CONTENTS Abstract__________________________________________________________________________________________2 Contents _________________________________________________________________________________________3 1

Introduction _______________________________________________________________________________6

2

Problem statement ________________________________________________________________________8

3

2.1

Relevance _____________________________________________________________________________8

2.2

Goal ___________________________________________________________________________________9

2.3

Research question ___________________________________________________________________9

Literature review ________________________________________________________________________ 10 3.1

Agile software development methods____________________________________________ 10

3.1.1

Critical success factors _______________________________________________________ 12

3.1.2

Pitfalls _________________________________________________________________________ 16

3.1.3

Agile applied in organizations _______________________________________________ 17

3.1.4

Scrum __________________________________________________________________________ 18

3.2

Requirements engineering ________________________________________________________ 22

3.2.1

Comparison of traditional and agile requirements engineering __________ 23

3.2.2

Two different approaches ___________________________________________________ 25

3.2.3

Requirements engineering techniques _____________________________________ 27

3.3

Product lifecycle ___________________________________________________________________ 30

3.3.1 3.4 4

5

Differences between the four stages ________________________________________ 31

Agile requirements engineering and the product lifecycle _____________________ 34

Case study background _________________________________________________________________ 37 4.1

Company ____________________________________________________________________________ 37

4.2

Products ____________________________________________________________________________ 38

4.2.1

CityControl ____________________________________________________________________ 38

4.2.2

Field Mobility Suite ___________________________________________________________ 38

Research method ________________________________________________________________________ 39

| Page 3 |


6

5.1

Model _______________________________________________________________________________ 39

5.2

Method ______________________________________________________________________________ 40

5.3

Data collection _____________________________________________________________________ 42

5.4

Data analysis _______________________________________________________________________ 44

Results & discussion ____________________________________________________________________ 45 6.1

The scrum process _________________________________________________________________ 45

6.1.1 6.2

The requirements engineering process __________________________________________ 47

6.2.1

Requirements engineering as a pre-development process________________ 47

6.2.2

Technical refinement _________________________________________________________ 48

6.2.3

Functional consultant background __________________________________________ 48

6.3

7

Lack of customer involvement ______________________________________________ 46

Product lifecycle ___________________________________________________________________ 49

6.3.1

Types of software development _____________________________________________ 50

6.3.2

Product lifecycle effects on agile ____________________________________________ 51

Conclusion _______________________________________________________________________________ 53 7.1

Future research ____________________________________________________________________ 54

8

References _______________________________________________________________________________ 55

9

Appendices ______________________________________________________________________________ 59 9.1

Interview guide ____________________________________________________________________ 59

9.2

Coding table ________________________________________________________________________ 60

9.3

Coding results ______________________________________________________________________ 61

9.4

Coding segments ___________________________________________________________________ 62

9.5

Interview transcripts ______________________________________________________________ 71

9.5.1

CIO _____________________________________________________________________________ 71

9.5.2

Functional Consultant ________________________________________________________ 78

9.5.3

Scrum Master _________________________________________________________________ 84

9.5.4

Product Owner________________________________________________________________ 92

9.5.5

Scrum Master _________________________________________________________________ 98

| Page 4 |


9.5.6

Functional Consultant _______________________________________________________ 104

9.5.7

Scrum Team Member _______________________________________________________ 113

9.5.8

Product Owner_______________________________________________________________ 120

| Page 5 |


1 INTRODUCTION Agile software development is based on the assumption that high-quality adaptive software is developed by small teams, using the principles of continuous design improvement and testing based on rapid feedback and change [ Dyba, 2008]. An agile methodology like Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing [Meso, 2006]. This is the opposite of traditional development, like the Waterfall methodology. These plan-driven methods are characterized by heavy upfront planning, focus on documentation, predictability, and repeatable processes [Boehm, 2002). These methods have been criticized for their inability to accommodate change and the high costs that are associated with updating documentation and plans [Highsmith, 2001]. In other words; waterfall is a predictable methodology and using a predictable process in an unpredictable environment almost always leads to trouble [Bose, 2008]. This has led to a shift from waterfall to agile software developing. Most companies nowadays develop software using an agile method, where Scrum is the most used methodology [deCesare, 2012]. The current research on agile is mainly focused on new product development. In my daily work, developing software, I encountered several products developed using Scrum. Some products were just introduced to the market and others already had several years of development behind them and a large customer base. Scrum seemed to be applied in the same way for all product teams. This raises some important questions like; what is the difference in developing new products and more mature products? Should agile be applied in the same way for these products or should there be a significant different focus in some aspects? Is agile an appropriate method when the product matures? Every product passes through a series of stages in the course of its life, with the total of the stages considered as the product life cycle [Cox, 1967]. The product lifecycle theory distinguishes four different stages; introduction, growth, maturity and decline. Hofer [1975] did research on business strategies and one of his findings is that the most fundamental variable in determining an appropriate business strategy is the stage of the product lifecycle. Hofer [1975] described the determinants for each strategy per lifecycle stage. In this research, these determinants are specifically translated to software development, based on the current literature. This will be used as a guideline to determine the differences in agile development for the product lifecycle stages.

| Page 6 |


Customer involvement is identified as the critical success factor in agile [Cohen (2003), Misra (2009), Chow (2008)]. This is because agile is an iterative process, where software is released or demonstrated to the customer in short intervals. Customer involvement is necessary to keep requirements clear and to check if requirements were implemented correctly. Current research on requirements engineering in agile environments is slightly divided on how to apply requirements engineering. An option is to integrate it in the agile development process [Paetsch (2003), deLucia (2010)], another option is to use an entirely separated agile process next to the agile development process [Vlaanderen, 2010]. This links requirements engineering, agile and customer involvement together to successfully develop software. This is also the focus during this research; effects on agile requirements engineering in different product lifecycle stages. In the next chapter the problem statement and research question are elaborated. Followed by the current literature on the research topics agile, requirements engineering and the product lifecycle. The last two chapters contain the results and conclusion of this research.

| Page 7 |


2 PROBLEM STATEMENT In this chapter the relevance, goal and research question of this research are further explained.

2.1 RELEVANCE Agile has become the common method for software development over the past years. Many academic researchers have studied the different aspects of agile; comparisons and overview of agile methods [Abrahamsson (2002), Lindvall (2002), Cohen (2004)], its critical success factors [Misra (2009), Chow (2007), Cohen (2004), Lindval (2002)], the team process [Moe (2009), Iivari (2010), Ryan (2008), Rising (2010)] and specific case studies [Kane (2006), Laanti (2010)]. Customer involvement and collaboration was identified as the most critical success factor for applying agile. Customer involvement and collaboration is very closely related to requirements engineering, which basically determines what the customer wants and needs and to make it clear to the development team how to develop the system. Requirements engineering is not very clearly embedded in the agile process. The agile process leaves much room for interpretation of certain aspects and how to apply this in real life. There is a certain amount of flexibility how to arrange the agile process. This is why almost every organization implements its own variant, based on organization size, culture and values. As Boehm [2002] mentions, this is a good thing. In most researches the process of gathering requirements is seen as part of the agile development process. This contradicts in a way, that one of agiles’ values is having a minimum of documentation and where requirements need thorough documentation to build the system to the customers’ needs. Vlaanderen [2010] proposes a method where requirements engineering is a separate agile process next to development. So there are some different opinions on how requirements engineering is applied in an agile environment and in what form. Because requirements engineering involves one of the critical success factors for agile, it is interesting to focus on this aspect in this research. Current research on agile methods focuses on the development of new products or functionality. Little is known about the application of agile on existing products or new products becoming mature. Research on the product lifecycle, which has been around for decades, shows that products cycle through different stages in their lifetime. The classical product lifecycle consists of four stages; introduction, growth, maturity and decline. Hofer [1975] states that the stage a product is in, is the most important variable to determine its business strategy. Also, for all stages, except the growth stage, major changes in business strategy are required. In this context it is obvious to assume that the application of agile, and especially requirements engineering, differs significantly in

| Page 8 |


the different stages. As products mature, for example changes become less frequent. This raises the question if agile methods should be applied in an identical manner for all products; probably not.

2.2 GOAL The goal of this research is to gain more insight in how requirements elicitation fits in the agile process and what implications this has when in different product lifecycle stages. The results of this study will help in how to position requirements engineering in agile; being part of the whole process, in a separate process in and in what form. It will also determine what focus and adjustments are needed in the process for products in different lifecycle stages.

2.3 RESEARCH QUESTION The research question is extracted from the literature review and the relevance and goal of this research; 

How do the product lifecycle stages affect agile requirements engineering?

The following sub-questions are defined; 

What effect does each stage have on the application of the agile process and requirements engineering in particular?



How to position the requirements engineering process in agile?



Should requirements engineering be in a separate agile process?



Do success factors change for agile in different lifecycle stages?

| Page 9 |


3 LITERATURE REVIEW This chapter gives an overview of the three main subjects in this research. It also gives an introduction on how the three subjects relate to each other in the context of this particular research.

3.1 AGILE SOFTWARE DEVELOPMENT METHODS Up to approximately the middle of the 90’s software was developed using plan driven methods [Lindval, 2002]. All system requirements were elicited and followed by architectural overviews and heavy documentation. When the system was fully specified and documented the actual development of the system started. A commonly used method is the ‘waterfall’ method. This method was supposed to fix the problem of continuously changing requirements by defining all requirements up-front and using this to develop the system [Cohen, 2004]. The waterfall method was intended to be used in large development projects, where projects mostly take a year, or more, to complete. If all requirements are clear and stable, meaning that the requirements have a minimum of change during the project, the waterfall method can be a suitable method for software development [Cohen, 2004]. This method tried to make software development an efficient and predictable activity [Dyba, 2008]. But practitioners found that in smaller projects the up-front design and associated documentation did not give them a flexible way to develop software. Furthermore the requirements often seemed to change during development [Dzamashvili (2010), Cohen (2004)]. This created serious issues. Months were spent on interviewing customers, building mockups to get all the systems’ requirements clear. A change in the development phase brought along high costs. Documentation, diagrams, overviews and mockups needed to be updated. Technology started to evolve rapidly and new hardware and software were released in shorter and shorter time cycles. From the mid 90’s on there was a need for flexible and lightweight methods to rapidly develop software [Cohen (2004), Abrahamsson (2002)]. This is when the agile software development methods started to emerge. Although agile was nothing new, the focus and value behind agile was significantly different related to the traditional development methods [Cohen, 2004]. However, most studies treated agile development as something ‘new’ and that consequently requires introduction and adoption [Dyba, 2008]. Accepting that Barry Boehm’s life cycle cost differentials theory, the cost of change grows through the software’s development life cycle, remains valid, the question today is not how to stop change early in a project but how to better handle inevitable changes

| Page 10 |


throughout its lifecycle [Highsmith, 2001]. Embracing change is one of the most important differences between traditional and agile methods. Cohen [2004] has summarized the challenges facing traditional methods; 

Satisfying the customer has taken precedence over conforming to original plans



Change will happen, the focus is not how to prevent it but how to better cope with it and reduce the cost of change throughout the development process



Eliminating change early means being unresponsive to business conditions, in other words, business failure.



The market demands and expects innovative, high quality software that meets its needs

This makes it very clear that new methods were needed to keep developing successful software. Methods with a completely different focus and value. Embracing change and being flexible. Different agile methods emerged. But what is agile and how exactly does it embrace change? The word ‘agile’ by itself means that something is ﬂexible and responsive, so agile methods implies its ability to survive in an atmosphere of constant change and emerge with success [Chow, 2007]. Agile is all about; “Deliver quickly. Change quickly. Change often” [Highsmith, 2001]. All agile methods share the same basic principles. One very important principle is that the method is iterative. This principle evolved from the traditional waterfall method [Cohen, 2004]. Iterative, in the context of agile software development, means that the system to be developed is divided in different subsystems. Each sub-system has its own requirements and can be developed and released as a part of the whole system. In other words, the project is split-up in multiple smaller waterfall iterations. The advantages are that these iterations can be executed simultaneously and that changes in requirements have smaller impact, because the iteration’s requirements are less complex. Furthermore, parts of the system can be delivered to the customers quicker, enabling the customer to test parts of system and give feedback to the development team. Over the years many different agile methodologies were applied in software development. The most used methodologies are Extreme Programming (XP), Scrum, DSDM, Adaptive Software Development, Crystal and Feature-Driven Development [Lindval, 2002].

| Page 11 |


In 2001 seventeen leading agile practitioners gathered to define the ‘Agile Manifesto’ [Highsmith (2001), Cohen (2004)]. They have come to the following main values for agile software development; 

Individuals and interactions over processes and tools



Working software over comprehensive documentation



Customer collaboration over contract negotiation



Responding to change over following a plan

About five years ago 17% of the enterprises used agile methods and the majority was interested in adopting them [Laanti, 2010]. Two years ago the majority of enterprises was actually using an agile method to develop software [deCesare, 2012]. Agile methods are adopted widespread and used by most of the software development companies worldwide. This implies that the adoption of agile methods is successful and helps companies to respond to constantly changing requirements and deliver high quality software in close collaboration with the customer. This raises a few questions. What are the success factors of agile? Are there any downsides on applying agile? How is agile applied in different organizations? What are customer and developer perceptions on agile methods? These questions are answered in the next paragraphs.

3.1.1 CRITICAL SUCCESS FACTORS There are several studies which researched the success factors of agile methods [Misra (2009), Chow (2007), Cohen (2004), Lindval (2002)]. There are some differences in the findings, this paragraph will give a reflection on the differences and will try to find the success factors which are generally accepted. The differences can mainly be traced back to the chosen research method and the used point of view. The study of Misra [2009] et al. identified fourteen success factors based on the current agile literature. The success factors were tested using an online survey, based on only people and organizational factors. It is remarkable that twelve different limitations are mentioned in this study. The most important ones are that the hypothesized success factors are very complex and highly subjective, there was a lack of sufficiently related literature and by adopting other research methodologies, other success factors may emerge.

| Page 12 |


Misra [2009] et al. defined success using five criteria; 

Reduced delivery schedules



Increased return on investment (ROI)



Increased ability to meet with the current customer requirements



Increased flexibility to meet with the changing customer requirements



Improved business processes

After statistical analysis of the results nine factors (out of fourteen) were accepted as success factors for agile software development; 

Customer satisfaction



Customer collaboration



Customer commitment



Decision time



Corporate culture



Control



Personal characteristics



Societal culture



Training and learning

From the open ended questions several potential success factors emerged; learning from failure, timing issues, other team characteristics and use of tools. The following factors were not identified as success factors; 

Team distribution



Team size



Planning



Technical competency



Communication and negotiation

The last two factors not being related to success is intuitively, and according to other literature, incorrect. Technical competency by the developers should be the basics for developing qualitative and successful software. Boehm [2005] and Highsmith [2001] suggest this being a success factor. For communication and negotiation it is mentioned by Boehm [2003] and Lindvall et al. [2002] that support for effective communication mechanisms should be in place for success.

| Page 13 |


Chow’s [2008] research defined success based on the perceived level of success of a project; 

Quality (i.e. delivering a good working product)



Scope (meeting all requirements by the customer)



Timeliness (delivering on time)



Cost (within estimated cost and effort)

In total twelve factors were taken into account in five categories; organizational, people, process, technical and project factors. All factors are based on current agile literature. The critical success factors (in order of importance) found are; 

Delivery strategy



Agile software engineering techniques



Team capability



Project management process



Team environment



Customer involvement

The following factors were not identified as success factors; 

Management commitment



Organizational environment



Project Definition Process



Project Nature



Project Type



Project Schedule

As long as the agile project picks a high-caliber team, practices rigorous agile software engineering techniques and executes a correct agile-style delivery strategy (frequent releases), the project could likely be successful. Interesting to see is that technical and people factors are the most important, where process, organizational and project factors have much less influence. The success factors match with the Agile Manifesto principles. The most interesting findings are that management commitment is a non-factor, agile-style work facilities are not a prerequisite for successful projects and that organizational environment is not related to success.

| Page 14 |


Cohen [2003] states that ‘to be agile is a cultural matter’. If the culture is not right, then the organization cannot be agile. The culture must also be supportive of negotiation, as negotiation forms a large part of agile culture. As discussed above, it is important to have competent team members. Organizations using Agile use fewer, but more competent people. Organizations that want to be agile need to have an environment that facilitates rapid communication between team members. Examples are physically colocated teams and pair programming. Cohen states the following factors as success factors for agile; 

Culture



People



Communication



Customer interaction and feedback

There are quite a few differences in the findings of three researches [Cohen (2003), Misra (2009), Chow (2008)]. The only unquestionable factor for success seems to be customer involvement and interaction. Some remarkable differences are on the subject of organizational environment and culture, communication and technical skills. These factors intuitively seem to be very important to be successful in using agile. Although the differences can partially be explained by the different point of views of how success is measured and what type of factors are measured (ie. people vs. technical), there are some (crucial) differences in findings which are difficult to explain. Maybe this illustrates how complex it is to measure the effects of agile. There are a lot of different factors involved, that can be categorized as follows; technical, people, process, organizational and project [Chow, 2008]. But, as mentioned, customer involvement is the success factor all researches agree on. And this is of course where it all started. Initial elicitation of requirements, which were thoroughly documented, and then eventually the entire system was built on. With traditional waterfall methods there is a minimum of customer involvement in the remaining project and no regular releases. The customer ended up with software not entirely according their (market) requirements. This is why agile emerged and, when applied correctly, can be very successful.

| Page 15 |


3.1.2 PITFALLS Agile methods have created a buzz in the software development community [Cohen, 2004]. Most software development companies have applied agile methods over the last five years and there is a common sense in current literature, that agile methods favor traditional waterfall methods [Misra, 2009]. Emphasis is mainly focused on the advantages of agile. The pitfalls haven’t drawn much attention. This could of course have several reasons; there aren’t any serious disadvantages in using agile or they are underestimated because agile is a buzzword these days. A few researchers highlighted the pitfalls of agile. Boehm [2002] wrote an article ‘Get ready for agile methods with care’. The message of this article is that both agile and plan-driven methods can be successful in projects with certain characteristics. A combination of both types of methods would be feasible and preferable in most cases. Several critical people factors are mentioned; amicability, talent, skill and communication. Due to the great flexibility of agile methods, developers have a greater responsibility in taking the right decisions. All of the agile methods put a premium on having premium people [Boehm, 2002]. The risk is that an agile team with less experienced or skilled developers is more likely to take wrong decisions, which can be disastrous to the project outcome. This can be on a design level or in the actual process. In agile there is a minimum of documentation that can be relied on. A significant consideration here is the unavoidable statistic that 49.9999 percent of the world’s software developers are below average [Boehm, 2002]. As mentioned there is much less documentation. This means that knowledge is not codified in designs, diagrams and other documentation. Most of the knowledge is in the team members’ heads, so called tacit knowledge. The risk that the team will make irrecoverable architectural mistakes because of unrecognized shortfalls in its tacit knowledge seems not to be underestimated [Boehm, 2002]. As mentioned customer involvement is very important for agile methods to be successful. Another risk is that the customer does not have enough tacit knowledge to make clear what the exact requirements are. It is also very important to apply agile on projects which have certain characteristics. Agile is best applied in turbulent, high-change environments. As where plan-driven methods are best applied in stable environment or where security or reliability in lifecritical systems is a key issue. Because many projects do not exactly fit agile or plandriven, a combination of both is necessary.

| Page 16 |


According to Dyba [2008] agile has been criticized mainly on the following five aspects; 1. Agile development is nothing new; such practices have been in place in software development since the 1960s 2. The lack of focus on architecture is bound to engender suboptimal design-decisions 3. There is little scientific support for many of the claims made by the agile community 4. The practices in XP are rarely applicable, and are rarely applied by the book 5. Agile development methods are suitable for small teams, but for larger projects, other processes are more appropriate Where most of these criticized aspects do not actually say anything about disadvantages in the use of agile, the lack of focus on architecture is the only aspect that could cause issues. Rising [2010] mentions that a chief architect should define the product vision and ensures the vision consistency throughout all the development phases in all product related projects. In short, there are several pitfalls which should be taken into account. The most important ones to have a clear vision on product architecture and to keep it consistent and to prevent having all the products’ knowledge in team members heads. These pitfalls can have serious consequences if underestimated or not acknowledged. But when taken into account in the whole development process, none of these pitfalls should be an obstacle in successfully applying agile.

3.1.3 AGILE APPLIED IN ORGANIZATIONS The previous paragraphs gave an overview of what agile is, how to successfully apply it and what the pitfalls are. But how is agile actually being used and implemented in organizations? Several researchers [Boehm (2003), Kane (2006), Rising (2010)] concluded that organizations tend to implement their own version of agile or a combination of methods. These organizations emphasize on what they think is important in the development process and adapt methods to their needs. Kane [2006] found that organizations have certain common core practices and that there was a certain variety in how agile approaches were applied. Some used use cases, some did not. Some used Scrum meetings, some did not. Groups also varied in the lengths of their iterations. Despite the variation, each group used many practices typical of current agile development approaches and aligned with the four principles outlined in the Agile Manifesto [Highsmith, 2001]. This implies that there is a fair amount of freedom in how agile methods can be applied. Important is that the key principles of agile are met. This variation in how agile is applied has to do with organization culture, project and product characteristics and team size. This makes it even more difficult to scientifically

| Page 17 |


measure the results of agile. There are a lot of different agile methods, which are applied in many different variations and combinations. Maybe this is a perfect fit, agile being applied in an agile manner. Customized to organizations needs and emphasis on specific agile principles which suit the project, organization, customer or team.

3.1.4 SCRUM As mentioned there are several agile methods. In the case study in this research Scrum is used for the software development process. This paragraph gives a brief introduction to Scrum and gives an insight on its most important characteristics. A scrum is a team of eight individuals in rugby. Everyone in the pack acts together with everyone else to move the ball down the field. For those who know rugby, the image is clear. Teams work as tight, integrated units with each team member playing a welldefined role and the whole team focusing on a single goal [Rising, 2010]. Scrum is a method based on project management [Kane, 2006], it does not describe any software development techniques. The main idea of Scrum is that systems development involves several environmental and technical variables that are likely to change during the process. This makes the development process unpredictable and complex [Abrahamsson, 2002]. Scrum has three key practices; managing the feature backlogs, the daily stand-up meeting for the development team and defining sprints to iteratively develop the system [Kane, 2006]. The overview below shows the entire Scrum process and its roles. Below the specific parts of the process and the roles and responsibilities will be described in further detail.

FIGURE 1: SCRUM PROCESS OVERVIEW [SCRUMPAD.COM]

| Page 18 |


3.1.4.1 Product backlog The product backlog contains all the requirements currently known [Abrahamsson, 2002]. These requirements are gathered from different sources, like the customer, developers, sales, marketing and so on. The items on the product backlog are constantly updated. Every item is estimated and prioritized. The items on the product backlog have a high(er) level of abstraction [Cohen, 2004]. They need to be further detailed and can be split up further down the process. The key point is that Scrum plans features, not tasks, as the first priority because features are what customers understand [Highsmith, 2001].

3.1.4.2 Sprint backlog A sprint is the iterative part of the Scrum process. Prior to a sprint there is a meeting where the team decides which items from the product backlog will be moved to the sprint. The sprint has a pre-defined length of one to four weeks. At this point, features in the sprint backlog are frozen and remain unchangeable for the duration of the sprint [Cohen, 2004]. At the end of the sprint all the features on the sprint backlog should be implemented and it must be possible to release these features as working software. Each sprint includes the traditional phases of software development; requirements, analysis, design, evolution and delivery [Abrahamsson, 2002].

3.1.4.3 Daily stand-up meeting In this meeting, each member of the team reports what they did since the last scrum meeting, what work is planned before the next scrum meeting, and obstacles. The meeting is short and facilitates open and frequent communication in the team [Kane, 2006]. According to Rising [2010] the following three questions are answered by every team member during the meeting; 1. What have you completed, relative to the backlog, since the last Scrum meeting? 2. What obstacles got in your way of completing this work? 3. What specific things do you plan to accomplish, relative to the backlog, between now and the next Scrum meeting?

3.1.4.4 Sprint-review and retrospective After a sprint, the sprint is reviewed by the team. Important to know is if all the backlog items for this sprint were implemented. It gives insight on how the backlog features were estimated at the beginning of the sprint and how much effort it took for the actual

| Page 19 |


implementation. When the team gains more experience the estimated work will better fit the duration of the sprint. The retrospective can also result in new backlog items and even change the direction of the system being built [Abrahamsson, 2002]. This is because every sprint more knowledge about the system is obtained, this can give new insights on how certain requirements should function. The review is also used to continuously improve the Scrum process.

3.1.4.5 Roles and responsibilities In Scrum there are several important roles which are mandatory to successfully applying Scrum. 

Product Owner

The product owner is officially responsible for the project, managing, controlling and making visible the product backlog list [Abrahamsson, 2002]. The product owner needs to have a complete overview of the product and requirements for all backlog items. The product owner communicates with the customers, the team and management. Features are added to the product backlog and also prioritized and estimated. The product owner decides, with the team, which features from the product backlog are moved to the sprint. 

Scrum Master

Scrum Master is responsible for ensuring that the project is carried through according to the practices, values and rules of Scrum and that it progresses as planned [Abrahamsson, 2002]. The Scrum Master has the important role to daily lead the stand up meeting and keep it short and focused [Rising, 2010]. The Scrum Master focuses on the items of the sprint backlog and makes sure the team progresses as planned. The Scrum Master is in charge of solving problems that stop the team from working effectively [Dyba, 2008]. When any issues or problems occur, the Scrum Master immediately takes action. This can be the case when a team member is exceeding the estimate for a certain feature on the backlog or when progress comes to a halt due to shortcomings in the development environment. 

Scrum Team

This is the project team that has the authority to decide on the necessary actions and to organize itself in order to achieve the goals of each sprint [Abrahamsson, 2008]. In the agile approach, work is coordinated by the self-managing team, in which the team itself

| Page 20 |


decides how work is coordinated [Moe, 2009]. In such teams, team members should share the authority to make decisions, rather than having: (a) a centralized decision structure in which one person (e.g. the team leader) makes all the decisions or (b) a decentralized decision structure in which all team members make decisions regarding their work individually and independently of other team members [Moe, 2009]. 

Customer

Customer participates in the tasks related to product backlog items for the system being developed or enhanced [Abrahamsson, 2002]. As mentioned, customer involvement is an important part of agile. Based on the customer’s requirements the system is built. The customer needs to have continuous input on requirements, feedback and planning.

| Page 21 |


3.2 REQUIREMENTS ENGINEERING In today’s software development environment, requirements often change during the product development lifecycle to meet shifting business demands, creating endless headaches for development teams [Rising, 2010]. It were the constantly changing requirements that started the evolution from traditional development methods to agile. Agile methods are attractive to software companies since they promise shorter time-tomarket, as well as higher flexibility to accommodate changes in the requirements [Dzamashvili, 2010]. This denotes the importance of requirements in software development. Requirements elicitation is the point where the customer’s needs and wishes are translated to something that is used as a basis to develop the system. The most important aspects of market-driven product development are requirements triage (initial selection), requirements prioritization and planning (release planning), i.e. deciding which of the thousands of potential requirements should be implemented, and when [Dzamashvili, 2010]. With the introduction of agile, the approach of managing requirements significantly changed. With traditional approaches, all requirements were gathered and documented in detail up front. Trying to define the entire system was an effort to eliminate change as much as possible in the development phase. Today, eliminating change early means being unresponsive to business conditions, in other words, business failure [Highsmith, 2001]. This raises the question how the field of requirements engineering changed with the large scale adoption of agile development methods? One of the agile principles is; working software over comprehensive documentation [Highsmith, 2001]. It will be interesting to see how agile is coping with requirements engineering and keeping documentation to a minimum. Some even see agile approaches and requirements engineering as incompatible because of this [Paetsch, 2003]. Since requirements change often, agile methods avoid detailed written documentation of requirements, in favor of a high-level written description that is "a promise to have a conversation," allowing details to be worked out through verbal communication with the customer [Kane, 2006]. Requirements engineering are one of the most crucial steps in software development process. Without a well-written requirements specification, developers do not know what to build, users do not know what to expect, and there is no way to validate that the created system actually meets the original needs of the user [Saiedian, 2000]. Requirements engineering is concerned with identifying, modeling, communicating and documenting the requirements for a system, and the contexts in which the system will be used [Paetsch, 2003].

| Page 22 |


3.2.1 COMPARISON OF TRADITIONAL AND AGILE REQUIREMENTS ENGINEERING Requirements engineering consists of the following five main activities [deLucia, 2010]; 

Requirements elicitation

In close cooperation with the customer and users, the product domain is explored. All requirements are gathered with different techniques, like interviews, brainstorming, usecases and workshops [deLucia, 2010]. Close collaboration and interaction with all project stakeholders is mandatory in this phase. 

Requirements analysis

All elicited requirements are analyzed. The main task here is to determine whether the elicited requirements are unclear, incomplete, ambiguous or contradictory, and then resolve these issues [Paetsch, 2003]. 

Requirements documentation

Documentation is used to communicate requirements to stakeholders and development teams. The development team uses this for knowledge sharing and as a reference for implementing the system features. 

Requirements validation

The requirements are validated through reviews, unit testing and acceptance tests. This also requires close interaction with stakeholders, to determine if the system meets the customers’ and users’ expectations. Reviewing and unit testing is mostly used for internal validation. This is a continuous process to validate implemented features with their requirements. Acceptance tests are performed by the users. They will test the system in an environment which is very similar to a production environment. This enables the user to determine the correct functioning of features. It may also lead to new insights and changes in requirements. 

Requirements management

Requirements management is about progress, prioritization and traceability. It is important to have a total overview of the development in progress. Not only on requirements which are under development, but also on requirements which are duplicate, unclear, on hold or need further discussion with stakeholders. Prioritization is important to determine which requirements are implemented first and when new

| Page 23 |


requirements emerge, to determine if they get higher priority over already planned requirements. DeLucia [2010] proposed the following reimplementation of requirements engineering in Scrum; Requirements engineering acticity Requirements elicitation

Requirements documentation



Scrum implementation Product owner formulates the Product backlog Any stakeholders can participate in the Product backlog Backlog refinement meeting Product owner prioritizes the Product backlog Product owner analyzes the feasibility of requirements Face-to-face communication

Requirements validation



Review meetings

Requirements management

 

Sprint planning meeting Items in Product backlog for tracking Change requirements are added/deleted to/from Product backlog

 

Requirements analysis

  



This reimplementation can be criticized on different aspects. As deLucia [2010] already mentions, the lack of documentation in agile can be an issue on the long term. This is also mentioned by Boehm [2003] as a pitfall. It prevents knowledge sharing and codification, because most of the knowledge is in the team members’ heads. Several techniques are mentioned to solve this issue. One of them is to assign team members to write, review and maintain requirements documentation in parallel with development. Doing this brings the risk being less agile. There must be a good balance between code and documentation. Not being too detailed, but keeping the high level overview in mind. This can be achieved with another suggestion, which is to apply UML modeling. With UML there are several ways (sequence diagrams, use cases) to quickly document a requirement on high level. Another point of criticism is comparing requirements elicitation with formulating the product backlog. The product backlog is a list of requirements to be implemented. It has nothing to do with the actual elicitation of requirements. First the requirements are elicited through interviews or brainstorming, then the requirement is added to the product backlog. This makes two (important!)

| Page 24 |


activities of requirements engineering very hard to integrate in the agile Scrum process, that is without violating the main principles of agile. Where management and analysis of the requirements can be integrated into Scrum, validation only has reviewing as a tool in Scrum. DeLucia [2010] describes this reimplementation as ‘the agile methodology manifesto supports a very efficient requirements engineering’. Keeping the criticized aspects in mind, ‘efficient’ could also be replaced by ‘minimum’. Paetsch [2003] mentions that the requirements engineering activities are not as clearly separated in agile, but that they merge in some way. Also, agile development processes are described vaguely and implementation is left to the development team. This of course leaves room for an emphasis on requirements engineering activities which are not obviously covered in agile. Requirements engineering is not clearly integrated into an agile method like Scrum. Where requirements engineering in traditional methods is a very extensive phase before the start of development, with focus on heavy documentation, in agile this isn’t the case. Agile prefers a minimum of documentation and no elicitation of all requirements up front. Requirements engineering is partially blended in, but certainly does not cover all the core requirements engineering activities.

3.2.2 TWO DIFFERENT APPROACHES In the previous paragraph, requirements were seen as an integrated process in the agile development method. Vlaanderen [2010] proposes the ‘agile requirements refinery’. Which applies Scrum principles to software product management (of which requirements engineering is an important part). This keeps requirements engineering in a completely separate process, next to the software development process. This is a completely different approach. The advantages seem obvious; complete focus on requirements, in an agile manner, which allows a much more extensive elaboration and management of requirements. Vlaanderen [2010] also denotes the importance of good requirements; the development of software by large teams of developers requires a steady flow of elicited product requirements. Without this steady flow of requirements, software vendors run the risk of delaying new software releases and bad code due to badly specified requirements, all resulting in the waste of large amounts of resources. This was the main source of applying requirements engineering in an entirely different process. The main difference is that at the end of a sprint, in Scrum for software development, the team produces a working software version and for this approach clearly specified requirements are delivered. But how does this work in practice?

| Page 25 |


Especially with new products, requirements are very high level and not detailed enough to be used for development. This makes it difficult to apply Scrum to complex requirements engineering, because Scrum uses sprints with a duration of 2 to 4 weeks. The agile requirements refinery, provides a solution for managing complex requirements [Vlaanderen, 2010]. This method enables a team to use requirements engineering in an agile environment, by gradually fine-graining the requirements. Requirements go through different phases and end up in detailed specifications. The following ‘agile requirements refinery’ phases are defined; 

Vision

Vision is the starting point for the lifecycle of most requirements [Vlaanderen, 2010]. It is an idea which reflects its most important characteristics. 

Theme

A theme is the formalized part of a vision. A vision can be split up in several themes. Feasibility of the theme is researched and the development team determines technical feasibility. It defines the business problem and the scope. 

Concept

Themes are broken into concepts. These are concrete descriptions of functionality, also called stories. A story must be defined in such detail that it can be used to derive several requirements. 

Requirement

The requirement is a functionality where the following is described; description, rationale and a constraint that must be met to be able to implement the requirement. All requirements are check by the development team on feasibility and compatibility. In this way the requirement is described in sufficient detail to be implemented. The requirements refinery is flexible in such a way that the definition of a vision, theme or even concept is not necessary. It depends on the projects’ size. It is also possible to have some requirements and define a theme or vision afterwards. This means the requirements refinery is not restricted to a top-down approach, but can also be used bottom-up [Vlaanderen, 2010]. Furthermore, not all visions, themes, concepts and requirement make it through the refinery. The ‘development sprint’ starts half-way the ‘requirements sprint’, to ensure that for the

| Page 26 |


following development sprint all requirements are ready to be added to the sprint backlog. It can be said that the mentioned disadvantages of integrating requirements engineering (minimum of documentation and a lack of requirements elicitation) in the agile development process can be solved with the approach of a simultaneous agile requirements process next to development. In this agile requirements process the documentation is the product of a sprint, as opposed to a software product release in a development sprint. So there is a heavy focus on documenting requirements, but also on the other important aspects, like elicitation, reviewing and checking feasibility and compatibility. Because this approach is so extensive and has two separate agile processes, it requires dedicated resources for requirements and development. In other words; it’s difficult to have a developer specifying the requirements and implementing it. Making this approach only suitable for larger software development companies. But the key principle that complex requirements need structured detailing through refinement is something that should be taken in consideration for all development projects, large or small.

3.2.3 REQUIREMENTS ENGINEERING TECHNIQUES This paragraph gives a brief introduction to what requirements engineering is and, more important, what techniques are used to get detailed and useful requirements. In system engineering, requirements engineering is the science and discipline concerned with analyzing and documenting requirements. In other words, requirements engineering means that requirements for a system are defined, managed and tested systematically [Kauppinen, 2004]. It is important that we do not promise something that cannot be ultimately implemented or that cannot be done given the current budget or schedule [Saiedian, 2000]. To describe which techniques are used to elicit requirements, it is important to understand what makes a requirement successful and what challenges need to be conquered. Customer involvement is a key success factor in requirements engineering [deLucia (2010), Paetsch (2003), Kauppinen (2004), Saiedian (2000)]. As mentioned before, this is also the case in agile software development in general. Since requirements engineering is as close to the customer as it gets, this being a success factor seems not more than logical; “Nobody can talk better about what they do and why they do it than they [the customer] can while in the middle of doing it” [Saiedian, 2000].

| Page 27 |


Saiedian [2000] states the following challenges in requirements elicitation; 

Poor communication o

How we communicate can be just as important as what we communicate.



Resistance o

Resistance to new ideas is a perfectly natural part of any improvement process. Nobody likes being told they are obsolete or that they can do things better



Articulation and expertise problems o

Many systems have countless interconnections between subsystems and even environments that even experts in specialized disciplines have difficulty in understanding.



Problem perspective differences o

Development tends to be technology (or solution) driven without a contextualized sense of the problem to be solved

The challenges above underline the importance of customer involvement and having enough expertise on the system that has to be built and the business processes it needs to support. Also keeping a high-level overview of the system, to determine the impact of new requirements is important. Common requirements engineering techniques are interviewing, brainstorming, ethnography, prototyping, questionnaires and use case analysis [Paetsch (2003), deLucia (2010), Saiedian (2000), Macauley (1996), Bose (2008)]. But the success of all these activities ultimately depend on how well people communicate and work together [Saiedian, 2000]. And this will be the focus when covering these mentioned techniques, how to apply them in such a way that it leads to clear and in detail formulated requirements? Interviewing and brainstorming are the most relevant techniques for this study. Interviewing helps to get a rich collection of information and to gain knowledge about the system [Paetsch, 2003]. Interviewing has two general approaches, a closed and an open interview. In an open interview there are no pre-defined questions and the interview is an open exploration on a certain subject. A closed interview follows predefined questions, which are mostly are used in different interviews to gather qualitative data [deLucia, 2010]. Brainstorming is a group technique to generate new ideas and promote creative thinking [deLucia, 2010]. Brainstorming leads to a better problem understanding and a feeling of common ownership of the result [Paetsch, 2003]. Both techniques are about communicating with other people. This means not to

| Page 28 |


only speak to other people, but also to listen to other people. Saiedian [2000] summarized the most important communication techniques related to requirements elicitation. 

Never make assumptions



Ask for clarification



Gather information from multiple sources



Be sure to consider the skill-level and any resistance in the customer

But maybe the most important thing to take into consideration is that good requirements elicitation takes time and money and as such often faces a hard sell to justify to program managers with ever reducing budgets and schedules [Saiedian, 2000].

| Page 29 |


3.3 PRODUCT LIFECYCLE The product lifecycle is a concept that has been around for decades. A very simple and straightforward definition of the product lifecycle is; the concept of the product lifecycle basically describes the evolution of a product, as measured by its sales over time. Every product passes through a series of stages in the course of its life, with the total of the stages considered as the product lifecycle [Cox, 1967]. The number of product lifecycle phases mentioned in the literature varies between four and six, but in general a four stage cycle is used [Rink, 1979]. The following four cycles are defined; 1. Introduction The introduction stage is the commercial birth of a product [Cox, 1967]. It is introduced on the market and only has several customers, because it is new and unknown. The (software) product is introduced to customers with pilot projects. This means the customer gets the product at a discounted price, but gives important feedback on the product and tests new functionality in practice. 2. Growth In this stage the product grows to the maximum sales revenue. Further diffusion in the market through product development. Other competitors enter the market. 3. Maturity Sales reach a maximum and will no further grow. This stage focuses on improving efficiency in process, further differentiation of products and further market segmentation [Anderson, 1984]. 4. Decline In saturated markets, sales start to decline and competitors are leaving the market. As a result of low profits, some firms exit the market or introduce newer products or products that serve some niche markets [Karakaya, 2007]. There is strong evidence for the classical bell-shaped product lifecycle curve [Rink, 1979], although several studies found about a dozen different lifecycle patterns [Rink, 1979].

| Page 30 |


FIGURE 2: CLASSICAL BELL-SHAPED PRODUCT LIFECYCLE

The product lifecycle is a marketing model, which is often applied to non-durable consumer goods [Cox, 1967].During the last few decades, the classic product lifecycle stages have gotten shorter due to rapid changes in technology and intense competition. Shorter lifecycles mean more product development and new product introductions that often result in lower profits for businesses [Karakaya, 2007]. Software is developed fast and released to the market more frequently (when compared to hardware). This means that shorter cycles seem obvious in the software lifecycle. Different business strategies are opposed for at least the first three stages [Karakaya (2007), Kikuchi (2010), Anderson (1984)]. That is why it would be interesting to see the differences between the product lifecycle stages in the context of software development. What would be the strategy for the different stages, especially keeping the flexible and iterative characteristics of agile in mind?

3.3.1 DIFFERENCES BETWEEN THE FOUR STAGES Hofer [1975] did research on business strategies and one of his findings is that the most fundamental variable in determining an appropriate business strategy is the stage of the product lifecycle. Changes in business strategy are usually required in the introduction, maturity and decline phase. As mentioned, lifecycles have become shorter due to rapid changes in technology and intense competition [Karakaya, 2007]. This means more changes in a shorter period of time. This is one of the major reasons why agile methods emerged, to facilitate change. The differences between the product lifecycle stages could gain insight on different approaches to apply agile on the different stages.

| Page 31 |


Hofer [1975] described the determinants for each strategy per lifecycle stage. Below a summary, the determinants are translated to the current field of software development; 

Introduction stage

The most important determinants in business strategy are the rate of technological change in the product design and the customers’ requirements. The focus is primarily on product development, based on customer requirements. 

Maturity stage

The determinants are the nature of requirements, the rate of technological change in process design, the degree of product differentiation and the degree of market segmentation. In this stage the focus shifted from the product itself to the development process and differentiation of the product and market. Selling the product (with minor adjustments) in different markets and optimizing development to reduce costs. In summary, the maturity stage centers around increased efficiency, increased quality, and increased product and market differentiation when compared to introduction and growth [Anderson, 1984]. 

Decline stage

The determinants are customer loyalty, the degree of product differentiation, market share and product quality. This is where the focus is on quality and keeping customers to be loyal to the product, because the market is saturated and new customers are scarce (or even not there). These findings question the idea that a single set of strategies can be applied in all product lifecycle stages [Anderson, 1984]. In the context of this research it also questions the use of agile software development in different stages. Where the introduction stage mainly focuses on product development, which starts with customers’ requirements, changes to the product are very frequent. This fits the iterative character of agile, where software is released after every sprint. This is where product development is at its peak level. This will still be the case in the growth phase. But as mentioned by Hofer [1975] a different strategy is necessary in all stages, except the growth phase. In the maturity phase the product has matured in the sense that by that time, most requirements are implemented and tested in the field. Software releases become less frequent, because new functionality is added less frequently. The product is mainly in ‘support’ mode, which means that only bugs are fixed. In this stage the focus is

| Page 32 |


on optimizing the development process and product differentiation. The product is applied in other markets, with some adjustments where necessary, or applied in a different way (ie. a light version of the product) to serve new parts of the market. In the decline phase the market is saturated and product differentiation still has focus, but of course becomes more difficult, because differentiation already started in the previous phase. Besides differentiation, focus is on quality and customer loyalty. Focus on loyalty is more of a marketing thing, rather than having to do with software development. This means now it’s really shifting away from actual product development. Quality improvement is another story. The product could be improved by speed, durability and reliability. These are so called non-functional requirements. This shows that products in different lifecycle stages should have different strategies and fields of focus. For the introduction stage this means that there should be complete focus on product development, but in the remaining stages focus is shifting towards fields not directly related to product development. Furthermore, the frequency of change is becoming lesser when the lifecycle progresses. This implies different application of agile methods for each of the stages.

| Page 33 |


3.4 AGILE REQUIREMENTS ENGINEERING AND THE PRODUCT LIFECYCLE In the previous three chapters a review was given on the topics of agile software development, requirements engineering and the product lifecycle. In this chapter the findings in the literature are further elaborated in bringing the topics together. This will eventually lead to the research question. With the introduction of agile methods, it is possible to better respond to quickly changing environments. This is done in an iterative process with regular software releases. During a sprint focus is only on a small (working) part of the entire system. This enables the developer to work on functionality that is not too complex and can easily be overseen. It also makes it easier for the customer to focus and describe what the requirements are. If the delivered software is not meeting the requirements, it is also easier to make adjustments. This is because with regular releases, the team also gets regular feedback from the customer. In this way, during the development of the system, continuous adjustments and improvements can be made during the sprints. This prevents an entire system being built and released, which does not meet all the requirements specified before development started. Clear requirements are essential in this process. Getting clear requirements is strongly related to the critical success factor of agile; customer involvement. Close collaboration between the agile Scrum team and the customer is necessary to gain knowledge about the customers’ processes and translate these to requirements which form the basis for the system to be built. This research will focus on the requirements elicitation in the agile process, because it so critical in building a system which meets the customers’ expectations. What makes it interesting is that there is a paradox between requirements engineering and agile development. One of the agile values is ‘working software over comprehensive documentation’ [Highsmith, 2001]. This means that during the agile development process a minimum of documentation is produced by the team. This contradicts the elicitation of requirements, which need proper documentation to confirm its correctness to the customer and to serve as a basis for the developers. Findings in the literature show that requirements engineering and the agile process can be approached in different ways. Vlaanderen [2010] proposes a completely separate agile process for the elicitation of requirements. In this way the requirements are handled in sprints, just like the development of software. After each requirements sprint, the delivered requirements are used by the developers in the development sprint. In contrary to this approach, the gathering and documentation of requirements is embedded in the agile development process. DeLucia [2010] proposed a mapping

| Page 34 |


between traditional requirements engineering activities and agile Scrum activities. This approach is easy to criticize, because the elicitation of requirements is difficult to map to making a list of all requirements to be implemented (the product backlog). On the other hand, having two separate agile processes for requirements and development is fairly heavyweight and may not be as agile as intended. These two approaches differ highly from each other and leaves room for a completely different implementation of the agile process. As found in the literature [Boehm (2002), Kane (2006), Rising (2010)] the agile process is not defined in high detail and each software development company applies agile in a different way. This has to do with team size, complexity of the product, corporate culture and vision. The most important thing is to keep the four key values of agile in mind [Boehm, 2002]. This means that besides a lot of different agile methods, there is also a wide variety of applications of agile methods within organizations. Maybe there are even different applications within the same organization. The literature on agile does mention the different applications of agile, but no explicit research has been done on what exactly the differences are, why different approaches are chosen and in what way they are successful. Furthermore, the literature on agile mainly focuses on the development of new products. No researches were found where agile was applied on existing products or where research was extended to when the product was beyond the phase of introduction in the market. It is assumed that agile is being applied during the entire product life. It’s obvious that product (development) characteristics change when the product evolves. Where development will be turbulent in the beginning, with frequent releases and changes in requirements, the product will become more stable at a certain point of time. This is when the product is gradually evolving with the addition of new and improved functionality. This is also the case when bug fixing becomes an important part of development, no new functionality is added, but issues in current functionality are solved. This could mean that when the product evolves, a different focus on certain agile activities could improve efficiency, quality and so on. Maybe even changes in the agile process could make sense. This is where the product lifecycle comes in. The product lifecycle concept has been around for decades. It describes a products’ life in four phases; introduction, growth, mature and decline. With this concept software products could be placed in a certain phase. Applying the phase characteristics to the product, could help in giving insight on applying agile on products in different phases. Research by Hofer [1975] showed that each phase in the product lifecycle needs a different business strategy. In the upward phases (introduction and growth) focus is mainly on the product design. In the downward phases business strategy focus shifts

| Page 35 |


from the product to the process, where focus is on the processes around the product (for example development) to increase quality and efficiency. The classical bell shaped product lifecycle has four phases. In the first two phases of introduction and growth, the product has growing revenues and numbers of customers. In the following phases of maturity and decline, the product stops growing and eventually revenues will decline. The literature shows that different lifecycle stages need a different business strategy towards a product. The current agile literature focuses mainly on the initial development of products, which are then introduced to the market. Little is known on the application of agile on mature or even declining products. Development characteristics are likely to be very different in each lifecycle stage. In this context the appliance of agile on product development in different stages also tends to be very different.

| Page 36 |


4 CASE STUDY BACKGROUND This chapter contains some background information on the company where the data for this research was gathered. It will help in visualizing the context of how and where this research occurred.

4.1 COMPANY Sigmax is a Dutch company based in Enschede, it currently has approximately 120 employees. Sigmax delivers innovative mobile solutions that manage the maintenance and supervision activities for local authorities, police authorities and field service- and inspection companies. Sigmax also caters to client specific mobile solutions requirements and designs, builds and manages ICT infrastructure and office automation.

FIGURE 3: SIGMAX' NEW OFFICE SINCE 2012

Sigmax develops software for mobile devices running Windows Mobile and Android. Synchronization of data from the mobile devices to backoffice systems is very important to process gathered data and generate (management) reports. Synchronization is done using mostly wireless networking technologies. The backoffice system is web-based and relies on database systems like Oracle and MS SQL. Several development teams work on products using the agile method Scrum. Scrum was introduced about three years ago, which started as a pilot and is now the common development method for all development teams.

| Page 37 |


Sigmax was founded in 1998 and now comprises four business units, each with its own expertise; 

ICT Specialists o



Law Enforcement o



Mobile law enforcement for municipalities, police and public transport

Field Mobility o



Specialized in ICT infrastructures

Mobile solutions for field service and inspection

Mobile Solutions o

Focus on custom mobile solutions

4.2 PRODUCTS The two products that were subject to research are described on the paragraphs below.

4.2.1 CITYC ONTROL In order to ensure quality of life in densely populated areas, rules and regulations need to be set. The local city council is responsible for determining policies and directives and ensuring their enforcement. However, the process of enforcement and supervision and the ensuing administration can be particularly complex. With CityControl, patrolling officers can view in real-time the status of digitally recorded permits, issue fines and tickets, and easily consult the laws and regulations via a handheld computer. CityControl is a total solution for digital enforcement in public areas. CityControl is a mature product, which has been on the market for over five years. It has a large customer base of 80+ municipalities.

4.2.2 FIELD MOBILITY SUITE Operating as a maintenance and service organization, the goal is to provide the most optimal level of service to customers. The Field Mobility Suite (FMS) combines a hand computer or tablet with intuitive software, which eases the work of service technicians and help them to work both effectively and service-oriented. With the Field Mobility Suite it is possible to provide service technicians easy access to all the data they need to carry out their work instructions, so that valuable time is not lost on mistakes or lack of awareness. It also makes administrative hassle a thing of the past. Field Mobility also offers an add-on plan tool. This feature lets you plan large quantities of work instructions with a single mouse click. FMS is currently under heavy development to standardize the product. The product is growing rapidly. Approximately ten customers are using the product in the field.

| Page 38 |


5 RESEARCH METHOD This chapter describes the research method for this research. The research model is explained to give a general overview of this research. The chosen method is explained and a detailed description of data collection and analysis for this research is given. In the literature review three topics were consulted; agile software development, requirements engineering and the product lifecycle. Findings and shortcomings in the literature led to the research question. This study aims to answer these questions based on gathered data and the analysis of this data. In total nine interviews are conducted, divided into two different groups. These groups are two different agile teams, working on two different products. These two products are, at the time of this research, in different cycles of the product lifecycle. This will give clear insights on the use of agile requirements engineering in different phases of product life. With the gathered data and insights, an answer to the (sub) research questions can be formulated.

5.1 MODEL The research model helps to derive the research question from the research goal [Verschuren, 2007]. The model defines all steps needed to be taken to achieve the research goal.

FIGURE 4: RESEARCH MODEL BASED ON[VERSCHUREN & DOOREWAARD, 2007]

| Page 39 |


Below a brief description of the four phases in the research model; A. A literature study on the three main topics; agile software development, product lifecycle and requirements engineering. An overview of all topics is given and the topics are related to each other. B. Results of the literature study are used to collect data from agile teams from two different products. Data is collected by conducting interviews. C. Collected data is analyzed by coding the interviews. A thematic overview of findings is created. D. Discussion and conclusion on findings in literature and empirical research. This will gain insight on the effects of the product life cycle stages on agile requirements engineering.

5.2 METHOD A case study is a study in which the researcher tries to find a thorough and comprehensive understanding of one or more limited objects or processes [Verschuren, 2007]. The most relevant situation for a case study is when the main research question starts with ‘how’ or ‘why’ and is about a contemporary set of events over which the researcher has little or no control [Yin, 2009]. This is a perfect fit for this research. To be more precise this research will be a single case study. Single because one (business) case is thoroughly researched. Especially for a practical research, such as this, a case study has several advantages. With a case study it is possible to get an integral view of the research object. A case study is more agile, having the possibility to change course during the research. It is often believed that case studies cannot be used to generalize results, but the opposite is true [Flyvbjerg, 2006]. One can often generalize on the basis of a single case, and the case study may be central to scientific development via generalization as alternative to other methods. But formal generalization is overvalued as a source of scientific development, whereas “the force of example” is underestimated [Flyvbjerg, 2006]. This research is divided in two main parts, starting with a literature study and ending with a qualitative data collection and analysis. The literature study is used to gain full theoretical insight in the proposed constructs. This includes finding additional literature and creating an overview of properties, theories, patterns and drivers of the constructs. Adjustments on the conceptual model will follow, if necessary. The main advantage of literature study is that a lot of theoretical background is quickly available [Verschuren,

| Page 40 |


2007]. A disadvantage is that the used literature and its data originally was used for a different research goal than the current research [Verschuren, 2007]. This constantly needs to be considered during the research. The data collection and analysis will mainly consist of nine interviews. Interviews are one of the most important sources of information for a case study [Yin, 2009]. Other sources of data collection will be documentation and observations. This will be documentation on the agile process applied within the case study organization and the produced documentation during the agile process (eg. from product backlog, sprints). Observations will be made during attended sprint planning meetings, daily stand-up meetings and retrospectives. Using multiple data sources results in a more in depth research and is called triangulation [Verschuren, 2007]. The collected qualitative data is used to test what theoretical background can be used to answer the proposed research questions.

| Page 41 |


5.3 DATA COLLECTION Data will be collected through interviews. In total nine interviews are conducted. The interviews will be conducted among agile team members of two different products. For each agile product team four roles are selected; developer, product owner, scrum master and functional consultant. The roles cover all aspects of agile, from development to requirements elicitation to managing the agile process. This will give full understanding of the use of agile within the case study organization. Four interviews will be conducted for two product teams. One product is in the introduction stage of the lifecycle and the other product is in the maturity stage of the lifecycle. This will give insight in the use of agile in different stages. The ninth interview is held with the companies’ CTO, who introduced the use of Scrum. Below a schematic overview;

Product in

Product in mature

introduction stage

stage

Scrum Master Product Owner Developer Functional Consultant

CTO FIGURE 5: INTERVIEW SCHEDULE: ROLES AND PRODUCTS

Below a brief summary of the interviewees’ roles; 

Scrum Master

Facilitates the Scrum process, protects the development team from any interruptions during the sprint. 

Product Owner

Owns the product, decides what functionality is added to the product. Manages all the items on the product backlog and its priority.

| Page 42 |




Developer

Member of the Scrum development team. Develops user stories which are defined in the sprint. 

Functional Consultant

Responsible for writing user stories. These stories are the requirements for new functionality. Used to estimate the amount of work and by the developer as a guideline for the technical implementation. This is not a Scrum role. The interviews conducted are semi-structured appreciative interviews. Semi-structured interviews are flexible interviews, which are not completely formalized [Boeije, 2012] . During the interview it is possible to ask additional questions, depending on the direction of the interview. An interview guide will be developed before conducting the interviews. The interview guide is based on the literature study, research questions and hypotheses. The interview method used is appreciative interviewing [Avital, 2010]. This method is used to create a positive atmosphere during the interview, without judging or criticizing. The interviewer is looking for stories, examples and experiences to gain insight in the objectives. Using everyday language instead of academic language. This will allow the interviewee to easily elaborate about their personal experiences on the subject. Telling about positive, negative, fun and unexpected experiences. Giving opinions on what is good and what could use improvement. This gives the opportunity to gain a good insight on all aspects. Telling stories and experiences will result in providing the right context for the interviewer and making sense of the subject. Content of the interviews will contain the results of the literature study, giving insight in the different aspects of the constructs. All qualitative data gathered will be recorded and summarized for analysis. Goal is to conduct all interviews in person. Besides interviews, data is also gathered from documents and observations. By reading process documentation, produced documents during development and attending different types of meetings regarding agile, helps in getting multiple sources of evidence. This is one of the main principles of data collection [Yin (2008), Verschuren (2007)]. It supports in improving data validity. The interview results will help in how the research questions can be answered, based on the theoretical background in this study.

| Page 43 |


5.4 DATA ANALYSIS Qualitative analysis is the unraveling of data about a certain subject in categories, naming the categories with concepts, and defining the relation between concepts in the context of the problem statement [Boeije, 2012]. The analysis consists of two activities; the unraveling and structuring of data. The unraveling of the interview data consists of fragmenting the data. All fragments related to the concepts in the research are gathered. Fragments from all the interviews are compared, to see if they are related. The fragments from the interviews are categorized using codes. Open coding is used in this research. The result of open coding is a memo with ideas, expectations and reflections and a list of codes [Boeije, 2012]. These codes are linked to fragments from the interview data. Open coding results in data being more manageable and clear and it improves thematization [Boeije, 2012]. It also helps to reduce data from large amounts of rough data to structured fragments, themes and codes which can be easily related to, and compared with, each other. The interviews covered all Scrum roles in two different teams, this gave a very clear overview of the agile process for two products in different lifecycle stages. It showed the differences between the two products, which could be related to the different lifecycle stages they were in. For the mature product, Scrum was mainly used as a project management method to know how much work needed to be done and how to plan this in the sprints. There was little customer involvement. The introduced product showed a more agile way to iteratively develop software involving customers. In general this can be seen as a focus on the process and a focus on development, which is also described by Hofer [1975] as one of the determinants for business strategies in the mature and introduction stage. The interviews with the functional consultants focused on requirements engineering and the pre-Scrum process. This made the relation between requirements engineering and the agile Scrum process very clear. Both processes are separated, meaning that requirements are not elicited in the Scrum development sprints. It resembles the way Vlaanderen [2010] describes the use of a separate Scrum process to gather requirements, instead of being integrated in the agile process [Paetsch (2003, deLucia (2010)]. The interviews gave insight on the three main topics of agile, requirements engineering and the product lifecycle related to the current literature. It showed the effects of the product lifecycle stage on agile requirements engineering and most importantly; the underlying causes of these effects. This will show the importance of being aware in which lifecycle stage the product is in and where the focus should be.

| Page 44 |


6 RESULTS & DISCUSSION In this chapter the results of this research are discussed. It describes all findings related to the three main topics of this research; agile, requirements engineering and the product lifecycle. These findings were found after conducting and coding nine interviews, making observations and reading documents related to the agile process.

6.1 THE SCRUM PROCESS Scrum was introduced about two to three years ago, to replace the traditional waterfall method to develop software. Several issues were encountered with this method during development. Gathering requirements and creating a design at the start of a project, was extremely difficult. During the project new requirements popped up and initial estimates were exceeded. On the other hand there was no clear (short term) goal what needed to be done, there was no overview of the total work pending. The lack of a short term goal, also introduced constantly switching priorities in the development team. Sales managers putting high priority on functionality they sold to customers and project managers putting high priority on customer issues. Priorities changed by the day, making it unable for the development team to focus on tasks and finish them without constantly being interrupted. This caused development to take place in a very inefficient manner. This also shows in the coding results, which show a lot of process and requirements related segments (9.3). Scrum was becoming the standard software development method and introducing Scrum was believed to help the software development process to be more controllable and efficient. This was the primary goal to introduce Scrum, it was introduced as a project management method. Now it was possible to have a constant overview of work to do, work in progress, its priorities and resources needed to develop the software. Using time boxed sprints of four weeks, the amount of interruptions during development were significantly reduced. Although it took some time to get used to a fixed development period of four weeks, where it was not (or limited) possible to introduce new tasks and change priorities. This actually created a process which was less flexible than before, because the sales and support departments were unable to introduce new high priority issues directly to the development team. They at least had to wait till the next sprint, in theory. Another change with the introduction of sprints was that the product backlog needs constant updating of tasks and new functionality, used to fill in the sprints. When a task moves from the product backlog to the sprint backlog it is very important to have an accurate estimate and clear scoping for this task, otherwise it is impossible to fit in the sprint. This was, and still is, a big challenge. When Scrum was first introduced tasks were not clear and estimates too rough. This caused a

| Page 45 |


lot of unfinished tasks at the end of the sprint and false expectations about delivering certain software functionality. This is where requirements engineering became even more important; getting the desired functionality and scoping clear, translate to a workable design and an accurate estimate.

6.1.1 LACK OF CUSTOMER INVOLVEMENT In every organization where agile is used the process is, to some extent, adapted to the organizations’ needs and culture. This has to do with team size, complexity of the product, corporate culture and vision [Boehm (2003), Kane (2006), Rising (2010)]. The case study company follows the traditional Scrum method, using all core components like the product backlog, sprint backlog, daily standup, sprint planning meeting and retrospectives. At the end of each sprint the implemented functionality should be demonstrated to the product owner and other stakeholders. This is not always the case and is a deviation from the traditional Scrum method. The demonstration of implemented functionality is related to customer involvement. Functional consultants should always be able to verify the implemented user stories after each sprint and give feedback to the customer. In this way the customer is updated regularly about new development. When something is not according customers’ specifications or the customers’ perception about certain functionality has changed, this is noticed in time and changes can be applied in upcoming sprints. This is one of the strengths of agile, to be able to respond to change [Cohen, 2004]. There are several plausible reasons not to focus on customer involvement and feedback. One of them is that if a product is mature, very little new functionality is added. Furthermore, if a product is mature the Scrum team has gained a lot of knowledge on the product and customer’s processes, giving them the opportunity to decide for themselves if certain functionality fits the customer.

| Page 46 |


6.2 THE REQUIREMENTS ENGINEERING PROCESS The requirements engineering process is a very important process, which is strongly related to the Scrum process. By writing user stories, which contain a complete functional design, customer requirements are translated to a document which is used to estimate the amount of work and to help the developers to get a clear understanding of what needs to be implemented in the software. This process is not part of the Scrum process, but can be characterized as a pre-Scrum process. User stories are the basis for filling a sprint with work for the development team. The estimates for the amount of work is based on the user story. This means that being able to fill the sprint, develop the required functionality, release the functionality to the customer and having software that fits the customer’s process is all dependent on requirements. No particular method is used for requirements engineering. In most cases the product backlog is used to determine for which functionality a user story needs to be made first. One product team uses post-its on a whiteboard to determine the work to be done, in progress and finished. This is also used in Scrum during a sprint, to always have an overview of the current status of the sprint. Using Scrum for the requirements engineering process was found to be a bit too much. Creating user stories based on the prioritized product backlog currently is a good method to have enough user stories finished in time for the next sprint.

6.2.1 REQUIREMENTS ENGINEERING AS A PRE -DEVELOPMENT PROCESS The importance of requirements became clear with the introduction of Scrum. Before Scrum was used, no dedicated role was defined for requirements engineering. Requirements were mainly elicited by sales managers, project managers and developers. When Scrum was introduced, the writing of a user story and the actual development where planned within a single sprint. This led to an unwanted dependency between requirements and development, because development could only be started when the requirements are clear. With Scrum, for each new sprint (every four weeks in this case) enough requirements were needed to fill the next sprint. The role of functional consultant was defined to have constant flow of requirements filling the sprint. The functional consultant is involved early in the sales process, to get clear what the prospect needs. When the prospect becomes a customer, the requirements are translated to a user story for the internal organization and use in the Scrum process. The functional consultant is supposed to have a complete overview of all the products’ functionality and with the functional consultant being the single point of contact with the customer regarding eliciting requirements, this resulted in better quality and more consistent requirements.

| Page 47 |


The requirements engineering process is clearly a separate process from the Scrum development process. Both processes are fed from the product backlog, which contains all the items to be developed. As mentioned before, eliciting requirements and developing the wanted functionality in a single process, creates unwanted dependencies.

6.2.2 TECHNICAL REFINEMENT Although a dedicated role for the elicitation of requirements was defined, an issue arose with the user stories used for implementation. Because the user stories were only a thorough functional design, the technical solution of how to implement this functionality was not taken into account. This led to questions by the developers starting to implement a user story in the sprint. In some cases it was even impossible to find a technical solution to implement a new functionality. This caused delays in the sprint and unfinished work. This issue was solved by adding a technical refinement to the user story. Before the user story is used in the Scrum process it is reviewed by the functional consultant, scrum master and software architect to determine the technical implications of the user story. A technical chapter is added to the user story, providing a high level overview of how this functionality should be implemented.

6.2.3 FUNCTIONAL CONSULTANT BACKGROUND The product teams for CityControl and the Field Mobility Suite both have their own functional consultants responsible for the requirements. CityControl is the product in the mature stage of its product lifecycle and Field Mobility Suite is in the growth stage. Interesting to see is that the functional consultants for CityControl have a very technical background, they used to be part of the development team. The Field Mobility Suite functional consultants all have a background as project manager and still combine the role of project manager and functional consultant. This is a much less technical approach and much more a customer oriented approach. This implies that functional consultants with a technical background, are more technically oriented and have less focus on new functional development. This is the case for CityControl which is a mature product, that currently does not have a lot of new functionality added. The customers processes are clear, the product is mainly being improved and optimized. This requires technical knowledge for the implementation of optimizations, bugfixes and improvements. The Field Mobility Suite is a fairly new product, which just entered the growth stage. Customer processes still need to be fully explored to determine the best way to let this product fit these processes. This is why close customer interaction and involvement is needed, to gain knowledge about the

| Page 48 |


processes the customer uses. Combining the role of project manager and functional consultant is an efficient method to achieve this. Both roles are very customer oriented, making it possible to communicate with the customer and translating the customers’ needs to a user story in the most efficient way.

6.3 PRODUCT LIFECYCLE The previous paragraphs already gave some insight on the effects of different lifecycle stages on agile software development. Hofer [1975] described the determinants for the business strategy in the different stages. In the introduction and growth stage the focus should be on product development and increasing sales, in the maturity stage there is a shift to improving quality and efficiency. The focus shifts from development to the process and products are differentiated to enter new markets. The decline stage continuous having a focus on quality and market share, increasing customer loyalty. The described pattern for the different stages is also identified at the case study company. Two products (CityControl and the Field Mobility Suite) were subject to research. CityControl is in the mature stage, this product has been differentiated several times to serve the Belgian and Swiss market, besides the Dutch market. Different instances of CityControl were derived, to suit laws and regulations in other European countries and to expand market share. The product is currently in ‘support mode’, only bugs are fixed and functionality is improved, no new functions are added. An interesting development is that the derived versions of CityControl are now merged to one new version, to cut maintenance costs and support new platforms. Field Mobility Suite is in the growth stage, focus is on product development to add new functionality to the standard product, making it easy to deploy the product to new customers. A lot of effort is put into getting the requirements clear, to be able to develop a flexible and configurable standard product that suits the need of all customers. This shows that for these two products the type of software development is different. In the introduction and growth stage focus is on adding new functionality and in the mature and decline stage, focus is on improvement and bug fixing. This has impact on the agile process. For example; requirements are very important when adding new functionality, for bug fixing this isn’t the case. Coding results (9.3) did not show many direct codings related to the product lifecycle, but more implicit codings on agile.

| Page 49 |


6.3.1 TYPES OF SOFTWARE DEVELOPMENT During the research four different types of software development were identified; 

Tailor made

This is functionality specifically made for a customer and not reusable by other customers. This can be a module or a complete product. 

Standard

Functionality added to products which are useable for all customers. 

Enhancement (refactoring)

Product enhancement, mainly consisting of a technical nature. Improves the product maintainability or performance. 

Support

Bugs encountered in the software, which need to be fixed. It is important to distinguish these types of software development, because it is related to the product lifecycle and affects the agile process. The first two types mentioned (tailor made and standard) are about adding new functionality to the product. These types are the majority of work for products in the introduction and growth stage. Products are just introduced to the market and new functionality is added as the customer base grows. The last two consist of product enhancements, these types become the majority of work for products in the maturity and decline stage. The product is fully developed and only the existing functionality is improved. This affects the Scrum process in such a way that when adding new functionality, requirements play a very important role and with enhancements, requirements have a much less important role.

| Page 50 |


6.3.2 PRODUCT LIFECYCLE EFFECTS ON AGILE Below an overview of all the effects found on agile regarding the product lifecycle. The effects are discussed per lifecycle stage.

6.3.2.1 Introduction In the introduction stage focus is completely on product development. The elicitation of requirements is a very important process to develop a product according customer needs. It is also very important, because in this stage there is a relatively high amount of uncertainty. Meaning that functionality is not yet clear or changing during the project and important architectural and infrastructural decisions need to be made. This makes it hard to apply Scrum, because estimations fluctuate constantly and the team needs to rely heavily on external influences to get the architectural basis for the product ready and get the requirements clear. This is why requirements engineering is so important in this phase, to get the functionality clear and start developing on a solid product base using agile.

6.3.2.2 Growth In this stage product development is still key. The requirements engineering process before the start of a sprint is important, as well as the customer feedback when the sprint is finished. This is to keep the product evolving and enlarging the customer base. The focus is on the start and end of the process and less on the actual development. In this phase support issues and product enhancements are starting to build up.

6.3.2.3 Maturity This is where the growth comes to a halt. This means that very little new functionality is added to the product. The development mainly consists of support issues and enhancements (ie. reliability, performance). Gathering requirements and customer feedback now becomes less important. Bugs and optimizations do not change the products’ functionality, so no requirements or customer involvement is necessary. Focus is now on development to increase quality and efficiency. Agile is very suitable to adapt to changing requirements, but when the product is mature and stops changing one could ask what the purpose of applying Scrum is in this case? When support issues become a substantial part of development, which is already the case in the growth stage, this is often assigned to one or two dedicated developers. They are not working within the Scrum process, their main task is to solve blocking issues in production. This could be seen as a movement to working without agile in this stage. Scrum in this stage is mainly used for planning and to keep an overview of work in progress. Product differentiation in this phase can lead to changes to the product for specific

| Page 51 |


markets. It is likely that this phase has a mix of new functionality and support issues. In the case study company this resulted in having a Scrum team for development of new functionality and product enhancements and a small dedicated team for (urgent) support issues. Each sprint different team members from the Scrum team were assigned to fixing bugs.

6.3.2.4 Decline This stage is where market share decreases, this means very little new functionality is added to the product. Leaving the product almost fully in ‘support mode’. In this stage the question also is whether agile is the way to go. Not only the product is declining, but also the team. The team will be downsized when the amount of work decreases. When the team size comes below three team members, applying Scrum becomes a burden and much less efficient.

| Page 52 |


7 CONCLUSION Scrum is an agile method that has become the most used method in software development over the past years. It enables developing software iteratively with a fast time-to-market and high customer satisfaction. Organizations applying agile, however, have to be aware on how to apply the agile process, depending on the current lifecycle stage the product is in (6.3.2). The outcomes of this research show that requirements engineering is closely related to the critical success factor of agile (3.4) ; customer involvement and that a different focus is needed when applying agile requirements engineering in different product lifecycle stages (6.3.2). In the literature, requirements engineering, in relation to agile, is positioned in two different ways. It can be integrated in the Scrum process [Paetsch (2003), deLucia (2010)] or it is applied in a completely separate (Scrum) process [ Vlaanderen, 2010] (3.2.2). The case study showed that using a separate process is necessary, to avoid unwanted dependencies in the sprint (6.2.1). In other words, the requirements need to be clear when the sprint starts. If not, eliciting requirements can result in the need for further research or more work than estimated. This results in a delay for the actual implementation or the functionality is implemented with unclear requirements, which can have disastrous results. On the other hand, a separate process for requirements engineering was used for products in the mature and growth stage. This research showed that the type of development changes during the lifecycle (6.3.1). In the beginning there is a lot of new development (6.3.2.1), when the product matures this changes to less new development and increasing bug fixing and technical enhancements (6.3.2.4). This matches the business strategy determinants by Hofer [1975], where the introduction stage has a focus on development and the mature stage on the process, improving quality and performance (3.3.1) . This also means that the mature stage, with less new development, needs much less requirements and customer involvement (6.3.2.3). The research already showed that the growing product has functional consultants in a project manager combined role, which is much more customer oriented than the functional consultants for the mature product (6.2.3). They all have a technical background, as being developers in the past. If this is taken one step further, with a declining product, an organization must seriously consider to integrate requirements engineering in the Scrum process (6.3.2.4). At first, because requirements engineering becomes a very small part of the process and is mainly technical due to product enhancements. There should even be a critical look on the need of Scrum, choosing

| Page 53 |


another method could be more efficient in a situation where a product has (almost) no new developments. Preferably an even more light weight process (like Kanban). The business strategy determinants by Hofer [1975], translated to software development, are a good guideline on how to apply agile in different product lifecycle stages (3.3.1). It is necessary to determine the organizations’ focus on how to apply agile in different stages to keep development as optimal as possible (6.3.2).

7.1 FUTURE RESEARCH This research shows that the type of development changes during the lifecycle and that the appliance of agile also changes during the lifecycle. Customer involvement and requirements become less important along the way, the focus shift to increasing quality and performance, which implies technical enhancement of the product. Agile is applied in many different contexts; new innovative software, market leading applications which have been around for many years, standard software targeting the consumer market, tailor-made software for large multinationals and so on. In every organization there is a different situation. Or even situations, when there are different products in different lifecycle stages and can vary between standard and tailor made. It is important to be aware of the context where agile is applied and what the goal of applying an agile software development method is. In this way the focus of applying agile can be adapted to every situation, to create optimal circumstances for the product. Future research could further investigate on how to apply agile in different situations, how to recognize these situations and what needs adjustment in the process.

| Page 54 |


8 REFERENCES 

Agile software development o

Abrahamsson (2002). Agile Software Development Methods Review and Analysis. VTT Publications ISBN 951-38-6009-4

o

Abrahamsson (2008). Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum. IET Softw., 2, (1), pp. 58–64

o

Boehm (2003). People Factors in Software Management: Lessons From Comparing Agile and Plan-Driven Methods. The Journal of Defense Software Engineering.

o

Boehm (2002). Get Ready for Agile Methods with Care. IEEE

o

Chow (2007). A survey study of critical success factors in agile software projects. The Journal of Systems and Software 81 961–971

o

Cohen (2004). An Introduction to Agile Methods. Fraunhofer Center for Experimental Software Engineering

o

De Cesare (20120). Examining Perceptions of Agility in Software Development Practice. Communications of the ACM Vol. 53, No. 6

o

Dyba (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology 50 833–859

o

Dzamashvili (2010). The impact of agile principles on market-driven software product development. J. Softw. Maint. Evol.: Res. Pract.; 22:53– 80

o

Highsmith (2001). Agile manifesto. http://www.agilemanifesto.org

o

Highsmith (2001). Agile Software Development: The Business of Innovation. Software Management

o

Iivari (2010). The relationship between organizational culture and the deployment of agile methods. Information and Software Technology 53 509–520

o

Kane (2006). Agile methods in biomedical software development: a multisite experience report. BMC Bioinformatics, 7:273

o

Laanti (2010). Agile methods rapidly replacing traditional methods at Nokia: A survey of opinions on agile transformation. Information and Software Technology 53 276–290

o

Lindvall (2002). Empircal findings in Agile methods. Fraunhofer Center for Experimental Software Engineering

| Page 55 |


o

Meso (2006). Agile Software Development: Adaptive systems principles and best practices. Information Systems Management Journal

o

Misra (2009). Identifying some important success factors in adopting agile software development practices. The Journal of Systems and Software 82 1869–1890

o

Moe (2009). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology 52 480– 491

o

Pino (2010). Using Scrum to guide the execution of software process improvement in small organizations. The Journal of Systems and Software 83 1662–1677

o

Rising (2010). The Scrum Software Development Process for Small Teams. IEEE

o

Ryan (2008). Development of a team measure for tacit knowledge in software development teams. The Journal of Systems and Software 82 229–240

o

Sridhar (2007). Theoretical Reflections on agile development methodologies. Communications of the ACM Vol. 50, No. 3



Product Life Cycle o

Anderson (1984). Stage of the Product Life Cycle, Business Strategy, and Business Performance. The Academy of Management Journal, Vol. 27, No. 1, pp. 5-24

o

Day (1981). The Product Life Cycle: Analysis and Applications Issues. The Journal of Marketing, Vol. 45, No. 4, pp. 60-67

o

Cox (1967). Product Life Cycles as Marketing Models. The Journal of Business, Vol. 40, No. 4, pp. 375-384

o

Ebert (2006). The impacts of software product management. The Journal of Systems and Software 80 850–861

o

Hofer (1975). Toward a Contingency Theory of Business Strategy. The Academy of Management Journal, Vol. 18, No. 4, pp. 784-810

o

Karakaya (2007). Impact of product life cycle stages on barriers to entry. Journal Of Strategic Marketing 15 269–280

o

Kikuchi (2010). Influence of product life cycle stage on consideration set size: the case of ‘think products’. The Marketing Review, Vol. 10, No. 1, pp. 41-55

| Page 56 |


o

Metzner (1975). Product life cycle and stages of growth: an empirical analysis. Academy of Management Proceedings

o

Rink (1979). Product Life Cycle Research: A Literature Review. Journal of Business Research



Requirements engineering o

Bose (2008). Agile Methodology in Requirements Engineering. SETlabs Briefings Online

o

De Lucia (2010). Requirements Engineering in Agile Software Development. Journal of Emerging Technologies in Web intelligence, Vol. 2, No. 3

o

Kauppinen (2004). Implementing requirements engineering processes throughout organizations: success factors and challenges. Information and Software Technology 46 937–953

o

Kettunen (2009). Adopting key lessons from agile manufacturing to agile software product development—Acomparative study. Technovation 29 408–422

o

Macauley (1996), Requirements for Requirements Engineering Techniques. Proceedings of ICRE ’96 IEEE

o

Paetsch (2003). Requirements Engineering and Agile Software Development.

o

Pohl (1993). The Three Dimensions of Requirements Engineering.

o

Saiedian (2000). Requirements engineering: making the connection between the software developer and customer. Information and Software Technology 42 419–428

o

Vlaanderen (2010). The agile requirements refinery: Applying SCRUM principles to software product management. Information and Software Technology 53 58–70



Research o Boeije (2012). Analyseren in kwalitatief onderzoek. Denken en doen. Boom Lemma Uitgevers o Flyvbjerg (2006). Five misunderstandings about case-study research. Qualitative inquiry 12.2: 219-245. o Schultze (2010). Designing interviews to generate rich data for information systems research. Information and Organization o

Verschuren (2005). Het ontwerpen van een onderzoek, derde druk. Uitgeverij Lemma B.V.

| Page 57 |


o

Verschuren (2007). Het ontwerpen van een onderzoek, vierde druk. Uitgeverij Lemma B.V.

o

Yin (2008). Case study research. SAGE Publications Inc

| Page 58 |


9 APPENDICES 9.1 INTERVIEW GUIDE 





Korte intro o

Waar gaat het onderzoek over

o

Wat doe je momenteel bij Sigmax?

Ontwikkeling huidige product o

In welke fase zit het prouct qua ontwikkeling

o

Wat zit er in de nabije toekomst aan te komen

Scrum proces o

Geschiedenis (wanneer is het toegepast)

o

Hoe wordt het toegepast? Op welke manier wijkt het af van de ‘standaard’





o

Wat zijn de succesfactoren?

o

Waar liggen de ‘pijn’ punten?


Huidige proces

o

Gebruikte methoden

o

Wat is de relatie met Scrum (onderdeel van het proces of apart proces?)

o

Product vision

Relatie tot levenscyclus product o

Hoe is het Scrum / requirements proces veranderd de afgelopen tijd? Of hetzelfde?

o

Wordt er rekening gehouden met het volwassen worden van een prduct in het Scrum proces?

| Page 59 |


9.2 CODING TABLE o

o

o

Agile o

Process

o

Deviations

o

Application


Gathering

o

Process

Product lifecycle o

Introduction and growth

o

Mature and decline

| Page 60 |


9.3 CODING RESULTS Category

Code

Count

agile agile agile requirements requirements lifecycle lifecycle

process deviations application gathering process-req intro/growth mature/decline

70 15 30 23 30 6 9

% Codes 38,30% 8,20% 16,40% 12,60% 16,40% 3,30% 4,90%

Cases

% Cases

8 6 6 7 7 3 6

100,00% 75,00% 75,00% 87,50% 87,50% 37,50% 75,00%

| Page 61 |


9.4 CODING SEGMENTS Category

Code

Case

Text

agile

process

po1

Het product moest gedefinieerd worden, daar heeft Guido werk verricht. Er was op dat moment alleen maatwerk en geen product. Er is toen een basis gemaakt, daar zijn allerlei modules aan toegevoegd. Met het bouwen van die modules zijn toen van start gegaan door het vullen van de sprints.

agile

process

po1

Ik had toen al de wens om ontwikkeling en onderhoud los te trekken.

agile

process

po1

agile

process

po1

agile

process

po1

agile

process

po1

agile

process

po1

agile

process

po1

agile

process

po1

agile

process

po1

agile

process

po1

agile

process

po1

agile

process

po2

agile

process

po2

agile

process

po2

Laat ik het zo zeggen: scrum is wat je doet als je geen proces hebt en je in een crisis geraakt. Ik heb het in het verleden gezien, dat je een traditioneel watervalproject probeert te draaien. Op een gegeven moment loopt het project dan niet goed. Dan ga je elke ochtend even kort bij elkaar zitten, om elkaar op de hoogte te houden. Je gaat dan automatisch alles wat je niet per se hoeft te doen weglaten en dat is scrum. Wat ik daarmee bedoel is dat scrum volgens de definitie een project management framework is. . Wat we vaak zien is dat er een demo wordt gegeven door het ontwikkelteam aan de functioneel consultants en de projectleiders. Want wat je ziet is typisch: als wij denken dat we klaar zijn en zetten het neer bij de klant, dat er dan toch nog wat dingen naar voren komen die niet goed doordacht zijn Maar je wilt geen openheid over hoe je je capaciteit verdeeld over verschillende klanten. Het zijn de commerciële belangen. Het is met name de commercie hier in de weg zit. Het grootste probleem zit in de tegenstrijdige belangen. we hebben geacteerd vanuit het principe: nieuwe ontwikkelingen doen we in scrum en onderhoud doen we weliswaar in hetzelfde tempo, maar dat doen we door dedicated onderhoud medewerkers. Tweede ding is: als je een nieuwe module ontwikkeld en die neerzet bij de klant, dan kun je er donder op zeggen dat de issues daarna omhoog gaan. Vooral in het begin gaat dit pieken. Dat gegeven proberen we een beetje te cultiveren, door te zeggen: misschien moeten we dan maar in de sprint rework gaan faciliteren en dit onderscheiden van onderhoud. dat bevalt goed, het team lijkt heel groot, maar netto zijn er vier man continu bezig met nieuwe functionaliteiten. Er is wel een apart list team, deze werken nog zonder scrum, dit is een geheel nieuwe ontwikkeling. Als deze ontwikkeling op de tablet wat volwassener is, dan zouden ze mee kunnen gaan draaien in het scrum team Een belangrijk aandachtspunt is dat wij geen budgetten meegeven aan userstory's. Als je een projectmanager vraagt hoeveel mag een mobule kosten, dan kan hij daar geen antwoord op geven en waarom kan hij daar geen antwoord op geven? Omdat alles op één hoop gooit wordt in de offerte, in de offerte staan alleen maandelijkse licentiekosten. Dan heb je twee situaties: een is dat de functionaliteit er al is en de andere is dat de functionaliteit er nog niet is en dat het gemaakt moet worden. Als het gemaakt worden zijn er nog twee mogelijkheden. Namelijk het is maatwerk of het is een productverbetering. Het probleem met productverbetering is dat je deze voor meerdere klanten maakt. Dus hoeveel mag die functionaliteit We zagen dat we vooral plan technisch heel veel verschillende zaken aan het doen waren en niet goed de prioriteiten konden bepalen, van welke kant gaan we op? Ontwikkelaars werden heen en weer geslingerd met de taken die ze uit moesten voeren. Vooraf aan de sprint is er dan een totale schatting sessie, hierin komen de schattingen van de ontwikkelaars en dat wordt dan aangehouden in de user story's als realisatie tijd Wij moeten flexibel zijn, dat wordt van ons verwacht en als je dan heel star aan de sprint vasthoudt dan escaleert alles. Moet je dan gewoon die ruimte vrijhouden.

| Page 62 |


agile

process

po2

agile

process

po2

agile

process

po2

agile

process

po2

agile

process

po2

agile

process

po2

agile

process

po2

agile

process

po2

agile

process

po2

agile

process

fc1

agile

process

fc1

agile

process

fc1

agile

process

fc1

agile

process

fc1

agile

process

fc1

agile

process

fc1

agile

process

fc1

agile

process

tm

agile

process

tm

agile

process

tm

agile

process

tm

agile

process

tm

agile

process

tm

agile

process

sm

Dus dan kunnen we wel tussendoor feedback geven aan de klant, maar we worden gehouden aan de totale eind oplevering. Dat heeft met de offertes te maken en ook met aanbestedingen en wat dat aangaat dat past gewoon minder binnen scrum. ja dat wel, en ook om het op te kunnen knippen in hapklare brokken. Dat we bijvoorbeeld een gefaseerde doorvoer hebben, stel dat iets drie maanden werk is dat we dat dan toch in drie blokken van één maand kunnen knippen ja of om bij te kunnen sturen tussen releases. Met die tussen releases na sprints gaan we niet naar de klant toe. Dat heb ik nog niet meegemaakt Maar dat wordt nog niet heel structureel aangepakt dat een release naar de klant gaat, feedback ontvangen, en dan weer verder ontwikkelen. Wellicht is dat nog een van de verbeterpunten nee, dit wordt dan in de schatting sessie ingeschat. Dat wordt met het hele team besproken. Bij cc zes wordt er een inschatting gedaan met het hele team, eerder werd inschatting gedaan door een enkele ontwikkelaar die meeste kennis had van wat er gemaakt moest worden. Daar zijn ze nu weer van af gestapt. Als het echt helemaal in het nauw komt dan wordt er wel eens gezegd om het ontwerp zelf in de sprint te maken. Dat past niet goed bij scrum. Dat maakte dan wel moeilijker om uit sprintlijst zaken te halen om de sprint te vullen. Ik merk dat we dan steeds vaker afhankelijk zijn van wat de functioneel consultants opleveren. Scrum is het meest geschikt voor nieuwe modules en nieuwe functionaliteit waar je iteratief doorheen gaat. er wordt dan wel meer getest, het is dan inderdaad reactieve, de klant meldt een bug. Dan wordt er misschien nog een regressie test gedaan, om te kijken of de omgeving om de oplossing nog werkt. We zagen al snel dat zes weken te lang was. Hierdoor werd de flexibiliteit teniet gedaan. Je kunt niet schakelen tijdens de sprint, dus als er een vraag binnenkomt inparkeren tot de volgende sprint of de daarop volgende sprint. het kost teveel tijd, het is erg arbeidsintensief om iets bij de klant op te leveren. Er moet vaak een installatie gedaan worden bij de klant, die zit vaak aan de andere kant van het land er zijn een hoop reiskosten. Vaak is het een kostenafweging. ja, ik zou graag eens meemaken dat we bijvoorbeeld sprints van twee of drie weken doen en dat je elke keer iets oplevert naar de klant en de feedback dan iteratief in de volgende sprint werd verwerkt wat sowieso gedaan hebben is dat de bugs na een half jaar na de introductie van scrum uit de sprints zijn gehaald, omdat bugs dynamisch zijn. Je kunt wel voor 40 uur onderhoud in een sprint stoppen, maar daar is niks agile aan, want de klant moet dan toch een maand of zelfs wel twee maand wachten voordat een issue opgelost is, omdat het pas na de sprint klaar is. Bij kritische fouten moet er gewoon sneller geschakeld worden. Dus zeg maar 90% van de bugs zitten buiten scrum volgens scrum zal ik officieel niet betrokken hoeven te zijn bij de sprint, maar in de praktijk wordt er door mij tijdens de sprint nog wel wat bijgestuurd, bijvoorbeeld als er vragen zijn. Het is belangrijk dat er constant communicatie is bij eventuele onduidelijkheden en dat is afgestemd wordt. Bij voorkeur op tijd, dus voor het einde van de sprint, zodat er nog op gereageerd kan worden. En dit doen we ook constant In sprints worden ook vaak wat ruimte gereserveerd voor meer werk. Vaak wordt er wordt er per user-story extra tijd gereserveerd. Wat je ook vaak ziet is dat de laatste twee-user-story's niet worden uitgevoerd in de sprint. Je hebt eigenlijk eerst een planningsessie waarbij uitgelegd wordt wat we gaan doen. Daarna komt er een detailschatting sessie voor elke user story. Een ding wat me wel opgevallen is, is de feedback van de klant. Dat zie ik niet terug. Of zelden in ieder geval. Het is voor ons ondoenlijk gebleken omrequirements te stellen, ontwerp, en de implementatie in dezelfde sprint. We hebben een keer een sprint gehad waar alleen naar achterstallig onderhoud in zat. En verder wat er meestal een verzameling van bugs in eenuser-story gestopt en dan wordt er 40 uur aan besteed bijvoorbeeld. als je gaat time boxen hoef je niet meer te schatten. En vaak wordt dat gedaan van: we weten het niet dus we gaan wel time boxen. Je zegt eigenlijk: ik wil gewoon 40 uur aan een bugfix hebben. Scrum wordt dan toegepast om inzichtelijk te houden waar iedereen mee bezig is. Ook om te bepalen hoeveel tijd er wordt gespendeerd aan een bug Waar we toen vaak tegenaan liepen was dat we vaak nieuwe dingen gingen doen die heel onzeker waren. Vaak waren er nieuwe ontwikkelingen, zoals het

| Page 63 |


agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

sm

agile

process

fc2

agile

process

fc2

agile

process

fc2

agile

process

cio

generiek opzetten van koppelingen. Wij gingen dat dan als eerste doen als team binnen -Sigmax . Dit heeft ervoor gezorgd dat sprints heel vaak niet gehaald werden Het is namelijk lange tijd het geval geweest dat mensen nog voor 50% andere werkzaamheden buiten de sprint hadden. Dat werkt gewoon echt slecht. Je moet gewoon mensen hebben die volledig beschikbaar zijn. de product eigenaar maakt de-user-story aan op de productbacklog, met wat vage kreten hier en daar en eventueel een offerte die eraan. Dat is globaal wat je als input krijgt. Het ligt aan de grootte van de functionaliteit of er een ontwerp gemaakt wordt, als dit iets is klein is dan gebeurt dit niet. Als ik zie hoe ze dit bij-FMS doen, dat vind ik niet verstandig. Ik vind persoonlijk dat het daar doorslaat, ze gebruiken daar sjablonen, daar staat veel te veel in, zowel functioneel als technisch. Dit was zo uitge uitgebreid, je hoeft het alleen nog maar in te kloppen in de code. Dat gaat te ver denk ik, het is niet efficiënt. Alles moet tot op bepaalde hoogte duidelijk zijn en de rest komt dan vanzelf. En idealiter zou het zo moeten zijn dat elke user story die op de productbacklog wordt gezet, dat het team die 2-3 keer heeft gezien voordat je die toevoegt aan de sprint. Daardoor stapelden bugs zich op. Intussen zijn ze bijna allemaal opgelost. Dat krijg je als je alleen maar nieuwe functionaliteit bouwt, dan loopt de buglijst hoog op. Vooral niet meer. U moet wel proberen alleen de dingen te maken die belangrijk zijn, je moet constant scherp blijven op wat belangrijk is. Tijdens de ontwikkeling dan blijken iets toch minder belangrijk was dan vooraf ingeschat. dat is wel redelijk gelukt, door het hele proces los te laten verdwijnt er veel overhead is er meer tijd voor ontwikkeling. Dit is ook waar hij het meeste last van hebben, dat er geen goede user story's zijn Wat er ook moet gebeuren is dat de commerciële afspraken met de klant op een wat langere termijn gemaakt worden. Deze moeten helder en eerlijk gemaakt worden ja, maar je hebt natuurlijk specifieke klanten en je algemene productontwikkeling Sm: ja, je zou er eerlijk over moeten communiceren denk ik, dat je zo werkt. Maar je hebt natuurlijk een product, je werkt niet altijd voor een klant. Daarnaast past het ook niet bij scrum om te zeggen: over een half jaar is het klaar. Sm: op zich, de releases leveren we wel uit naar de klant en deze gaan ze ook testen en dit gebeurt ook na iedere sprint. ik denk dat het momenteel wel werkt, maar intern moeten we eerlijk zijn over de hoeveelheid werk die in een sprint gedaan kan worden. het komt erop neer, dat ze dit niet tegen de klant durven te zeggen, dat de oplevering later wordt. Daarnaast is het ook zo: als jij degene bent die tegen de klant zegt dat het later wordt, dan krijg je daar ook van de schuld. De architecten doen de inschattingen. Ik denk niet dat dit de beste manier is, uiteindelijk zal het hele team dit moeten doen. Dit is niet alleen voor de inschattingen, maar ook dat het hele team op de hoogte blijft en dat de teamleden de-user-story's allemaal een keer gezien hebben, dit werkt makkelijker als er aan de sprint wordt begonnen. Als je met zaken bezig bent die volledig nieuw zijn, dan wordt het inschatten een stuk lastiger. Wat we nu doen is dat ze één of twee personen vrijmaken in het team, die houden zich puur en alleen met onderhoud bezig. Op het moment hebben we zoveel onderhoud, dat deze capaciteit ook constant nodig is. Je kunt dan zeggen wat je aan het eind van de sprint en functionaliteit kunt verwachten. Het voordeel daarvan is dat je weet wat er gaat komen, en dat je dit weer kunt gebruiken voor de volgende sprint planning. ik denk dat je wel in staat zou moeten zijn om kleine functionele wijzigingen aan een product, waar de klant heel veel aan heeft, snel door te kunnen voeren. Vooral de zaken die blokkerend voor een klant zou kunnen zijn. Dit hoeft ook niet per se in het scrumteam te gebeuren, maar je zou ook een of twee personen buiten het team kunnen houden die dit soort zaken oppakken. De vraag is ook even wie is de klant? Intern of extern? Wat we sowieso altijd doen is een demo van het ontwikkelteam aan de functioneel consultants. Dit is dus een presentatie aan de interne organisatie, ook aan verkoop en het management. Ik denk ongeveer een jaar of drie. Het is vooral begonnen omdat we zagen dat de watervalprojecten niet altijd denderend liepen. Daar hadden we veel uitlopen. In het begin liep die projecten soepel, maar naarmate ze vorderen

| Page 64 |


agile

process

cio

agile

process

cio

agile

process

cio

agile

process

cio

agile

process

cio

agile

process

cio

agile

process

cio

agile

process

cio

agile

process

cio

lifecycle

maturedecline

po1

lifecycle

maturedecline

po2

lifecycle

maturedecline

po2

lifecycle

maturedecline

fc1

lifecycle

maturedecline

tm

lifecycle

maturedecline

tm

lifecycle

maturedecline

sm

lifecycle

maturedecline

cio

liep het steeds meer uit, omdat er steeds meer en aangepaste requirements op tafel kwamen. wij ontwikkelen niet in scrum samen met de klant. Dit is omdat klanten altijd van tevoren weten wat de kosten zijn en het is heel moeilijk om een variabel eind doel aan de klant te verkopen dat er meer in de sprint werd gedrukt dan dat er eigenlijk in kon. De schattingen waren nog niet heel nauwkeurig, de schattingen werden gewoon niet goed gemaakt en werd niet genoeg in detail naar gekeken. volgens het boekje doe je scrum met de klant, tenminste als je maatwerktrajecten. Dat doen wij niet. Bij scrum kun je eigenlijk alleen het aantal features laten variëren, de capaciteit van het team en de lengte van de sprint staan vast het wordt meer als marketing en verkoopding gebruikt. De klant is er verder niet echt van op de hoogte dat wij scrum gebruiken, als je intensief samenwerkt zullen ze het ongetwijfeld merken. Het zorgt er wel voor dat je regelmatig feedback krijgt en dat is goed. Hier brengt scrum realisme. Je loopt er dan snel tegenaan als iets niet past qua werk. Ook zorgt scrum ervoor dat iedereen een doel heeft, dit is een korte termijn doel. ik denk dat dat wel handig kan zijn. Het vereist alleen veel discipline. Bij cc zes merk ik dat dat nog niet gebeurd, het aantal functioneel ontwerpen is nog beperkt, dus dat kan nog wel op een andere manier. Daar moeten we wel een modus zien te vinden ja, maar dat wil je niet, want het product release je een keer per half jaar, maatwerk wanneer je met de klant afgesproken het dat het klaar moet zijn en onderhoud wanneer het nodig is, afhankelijk van de prioriteit. Voor onderhoud scrum niet zo goed proces. Daar heb je al behoefte aan iets anders, dat hebben we nu nog niet. Als een product dus volwassener wordt, dan zie je andere behoeften in de projectmanagementmethode. soms dan zit er iets meer de visie van de klant achter dan dat je zou willen, maar je hebt wel budget nodig om het product ontwikkelen. Dit moet betaald worden door de klant. Idealiter zou je een product ontwikkelen met het geld dat je in kas hebt, maar deze situatie komt bijna nooit voor. Over het algemeen ga je dus altijd vanuit de klant vraag iets maken. Dus als het product volwassener wordt, dan wordt de rol van product owner ook anders. De druk op projecten is groot, dus als je dat moet combineren zit daar wel spanning. Maar dit weegt wel op tegen de voordelen. Bij-City-Control is de situatie anders, omdat het product verder doorontwikkeld is en er vanuit de gemeente bepaalde zaken wettelijk vastgelegd wat de werkwijze is. Dit is bijFMS niet het geval Bij het opzetten van de architectuur is er dus minder geschikt en daarnaast is het in de onderhoudsfase en in de afbouw ook minder geschikt We gaan dan wel scrum toepassen, maar dat is dan meer voor het plannen en het toekennen van resources. Je ziet dan gewoon dat het agile achtige karakter er af gaat. Je hebt dan geen nieuwe functionaliteit die je nog teruggekoppeld aan de klant. In de eindfase is het meer bugfixers. we hadden eerst Park Control, hier is een differentiatie voorgekomen voor de politie, Mobile politie. Dit zijn kort twee aparte producten geweest, maar deze zijn snel weer samengevoegd. Vervolgens kwam er een variant voor de Belgische markt, dit was weer een apart product naast het bestaande product. Dit zorgde voor veel dubbel werk, daarna kregen we ook nog een variant voor de Zwitserse markt. Hierbij is als basis de variant voor de Belgische markt gebruikt. Toen hadden we drie verschillende producten. Dit bleek niet werkbaar en vervolgens wordt dit allemaal weer geïntegreerd in cc zes. je ziet dat met de komst van scrum voor cc vijf juist minder samengewerkt wordt met de klant. Waar veel dingen in eerste instantie voor een klant gedaan werden, en dus die klant het product bepaalde. Het laatste halfjaar wordt cc vijf duidelijk afgebouwd en dan merk je vooral dat het team kleiner wordt. Het zijn voornamelijk bugfixers maar ook wel wat nieuwe functionaliteit. Maar in sommige gevallen is dit lastig te doen, in veel gevallen weten we ook door onze kennis wat de klant wil. Daarom ga je niet altijd daar klant bij betrekken. Je ziet gewoon dat het erg lastig is als je heel veel klanten hebt om ze echt actief te betrekken. Maar dat heeft misschien ook weer met de levensfase van het product en het team te maken. Dit soort dingen moeten toch elke keer weer ontdekt worden. Je kunt wel een blauwdruk maken van de manier waarop je werkt binnen de hele organisatie, maar dat werkt gewoon niet

| Page 65 |


requirements

processreq

po1

requirements

processreq

po1

requirements

processreq

po1

requirements

processreq

po1

requirements

processreq

po1

requirements

processreq

po1

requirements

processreq

po1

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

po2

requirements

processreq

fc1

requirements

processreq

fc1

requirements

processreq

fc1

Vaak zie je dat eenuser-story uit twee delen bestaat, het ene deel is de wat vraag en het andere deel is de hoe vraag. Als je de wat vragen hebt beantwoord, dan gaat het team zich automatisch afvragen hoe het dan geïmplementeerd moet worden. Onze ervaring is dat als een functioneel consultants een user story maakt, dat er dan op een gegeven moment een punt komt waarbij er inmenging nodig is van een techneut. de productbacklog wordt gedeeld en dus gebruikt voor de ontwikkeling en derequirements. Op de productbacklog staat een kleine omschrijving en toelichting van de klant wens. Op basis daarvan weten de functioneel consultants wat er wanneer klaar moet zijn, maar er wordt niet gewerkt met vaste sprints. Het is dus wat minder strak geregeld. Er staan dus items op de productbacklog die al uitgewerkt zijn en die nog niet uitgewerkt. De items die uitgewerkt zijn, kunnen naar de ontwikkel sprint. De nog niet uitgewerkte items, daar moeten nog user-story's van gemaakt worden. het is vaak een combinatie van beschrijving, voorbeelden, technisch en functioneel ontwerp. Een user story kan zowel een technische verbetering zijn als een functionele toevoeging. het is misschien wel het idee of de illusie dat functioneel consultants weet wat de klant heeft en wil. Met andere woorden: de klant zit aan tafel in de vorm van functioneel consultants. Maar dat is niet helemaal hetzelfde. Een andere reden is toch heel plat: dat je iets te veel openheid biedt aan de klant. Tijdens zo een demo komen er nogal wat technische aspecten voorbij, de demo wordt opgegeven door het ontwikkelteam. Mijn gevoel is dat je daar onbedoeld duidelijkheid kan geven naar een klant vanuit het ontwikkelteam. En te vaak gaan errequirements onduidelijk de sprint in. Eerder was projectmanager en functie consultants een gescheiden rol. Het was dus zo dat de projectmanager en de functie consultants naar de klant ging. Hierdoor hoeft de projectmanager veel minder diep in het project te zitten en raakt daardoor het gevoel met het project kwijt. Daarom hebben we dit in een rol gecombineerd. Schattingen en tegenvallers. Niet gepland werk wat er tussendoor moest gebeuren. Escalaties en soms ziekte teamleden. Maar voornamelijk toch het tegenvallen van het geschatte werk ten opzichte van het daadwerkelijke werk. Eerder hadden we nog wel eens sprints dat we dit in één klap probeerden te doen, maar dan waren er of onduidelijkheden of er waren ineens extra requirements en dan bleek het ineens niet meer te passen in de sprint. Dat hebben we wel geleerd omdat zoveel mogelijk los te trekken. . Nee, aan de verkoopkant wordt echt keihard met requirements aangegeven wat wij opleveren. Het ontwerpen en derequirements duidelijk krijgen is een soort voor fase voor je scrum sprint. Daar worden we ook wel steeds strikter in: zo van jongens onduidelijkheden kunnen we niet meenemen in de sprint. Dit wordt geëist, dus het wordt wel steeds meer onderdeel van het scrum proces. Die bewaking en ook dat het gedaan wordt, dat vergt ook nog wat extra planning en daar heb je capaciteit voor nodig. Die capaciteit wordt niet op eenagile achtige manier gedaan. Dat doen we nog niet, ze hebben nu gewoon een workload, ze proberen gewoon de scrum voor te blijven met het maken van Story's. Niet dat daar steeds meer een bottleneck komt te liggen, we willen graag starten maar de requirements zijn nog niet helder. Dat is wel een aandachtspunt Als we een sprint gaan vullen met het maken van requirements, dan krijg je waarschijnlijk ook de situatie dat jerequirements gaat maken waar uiteindelijk helemaal niks mee gedaan gaat worden. Dat vind ik echt het grote risico. Je blijft wel reactief. We zijn ze te ad hoc hier, te veel zaken die er tussendoor komen, te flexibel, te verkopen gedreven. Om ver vooruit te gaan werken met derequirements dat voel ik gewoon nog niet zoveel voor. Om nou het hele requirements proces als een agile proces te zien ik weet niet of dat gaat werken. Je zag dan dat het ontwerp en de realisatie in een sprint zaten. Je krijgt dan een afhankelijkheid van elkaar, dat wil je niet, want dan zitten de programmeurs te wachten tot het ontwerp klaar is. bij aanbestedingen gaan we vaak op eigen interpretatie requirements inschatten. Daarbij is geen contact met de klant mogelijk. Hierbij is het goed zoeken naar de balans, uiteindelijk bij de opleveringen zal pas blijken of derequirements goed zijn geïmplementeerd.

| Page 66 |


requirements

processreq

fc1

De ervaring is dat het voorwerk heel belangrijk is, hoe beter de requirements, hoe minder het risico De volledige specificatie gaat niet naar de klant, maar wel het functionele gedeelte. En we merken in het begin dat de-user-story definities erg vaag waren en ik heb gemerkt dat dit juist heel belangrijk is. als je ergens nooit aan gewerkt hebt, dan weet je niet hoe het in elkaar steekt. Dan is het moeilijk in te schatten hoeveel tijd kost om ergens veranderingen in aan te brengen. Voor cc vijf is het redelijk makkelijk functionele wijzigingen in te schatten, maar zodra, voor bijvoorbeeld cc zes, de basis nog niet klaar is, is het moeilijk in te schatten functionele wijzigingen technisch toegepast moeten worden. Daardoor een schatting sessie vaak uit in een discussie over derequirements De functioneel consultants schrijven de user story's, wat we nu tegenwoordig doen is dat enkele techneuten vooraf bekijken hoe dit technisch opgelost moet worden. Dit gebeurt in de weken voordat sprint start, dan is de user story al enkele keren besproken. het is meer om te zorgen dat je niet teveel overhead in projecten krijgt, vaak heb je toch bij de klant een projectmanager en een functioneel consultants zitten. Dit hebben we nu gecombineerd en dat werkt efficiënter. Tenminste dat zou het moeten zijn. Ik beschrijf het puur technisch, en vervolgens wordt er technische beschrijving toegevoegd aan de-user-story. Ik denk dat ongeveer 80% van de user story functioneel is en 20% technisch. dat proberen we te voorkomen door het goed te organiseren, wat we doen is dat we wekelijks een soortuser-story Review hebben. We gaan dan met de functioneel consultants en de architecten tafel zitten. We lopen dan de-userstory door om te bepalen of dit duidelijk is voor de ontwikkelaars. het is heel moeilijk, zeker in de overheid wereld, daar worden aanbestedingen gedaan. Derequirements schrijvende gemeentes voor in hun aanbesteding en vervolgens moet je op prijs aanbieden.

requirements

processreq

fc1

requirements

processreq

tm

requirements

processreq

tm

requirements

processreq

sm

requirements

processreq

fc2

requirements

processreq

fc2

requirements

processreq

fc2

requirements

processreq

cio

lifecycle

introgrowth

po2

lifecycle

introgrowth

po2

lifecycle

introgrowth

po2

lifecycle

introgrowth

fc2

lifecycle

introgrowth

fc2

We maken nu een standaard product, maar het is als maatwerk begonnen.

requirements

gathering

po1

requirements

gathering

po1

requirements

gathering

po1

requirements

gathering

po1

requirements

gathering

po1

requirements

gathering

po1

requirements

gathering

po2

Feitelijk heb je eigenlijk twee scrumteams, het team dat de uitvoering doet en het team dat de-user-storys maakt. De klant kan wel zeggen: ik wil een uren registratie module, maar voordat je daarmee aan de slag kunt moet je eerst een user story maken. User story moet dan nog gereviewed worden en noem maar op. ja, de functioneel consultant verzameld user story's in zijn project. Het startpunt is daarbij de offerte en het projectplan, daarna gaat de functioneel consultants gesprek met de klant over de exacte afstemming. nee, de klant wordt alleen bevraagd en geïnterviewd en vervolgens wordt er een user story opgesteld die alleen voor de functioneel consultants en het team is. De klant krijgt alleen de functionele beschrijving en niet de volledige userstory Dus de discussie met de klant is er zeker, maar niet alles wordt terug gekoppeld. Maar ik ben er wel heilig van overtuigd dat het merendeel van de projecten misgaat op onduidelijkerequirements. Ik geloof 30% van de projecten. Er is vaak ook technische diepgang nodig, alleen een functioneel consultants er naar laten kijken is niet genoeg. Je moet meer diepgang hebben wij komen nu altijd met een voorgestelde story lijst vanuit het product management. Dan heb ik het over cc vijf. Dit wordt gevoed aan de hand van issues, klant wensen en verkochte zaken. Daar maken we een lijst van.

Met cc vijf zitten we nu in een eindfase, met het nodige onderhoud wat we nog doen voor cc vijf. Dat is wel grappig, met cc zes zitten we in de opbouwende fase en met-City-Control vijf zitten we in de afbouwende fase. Uiteindelijk is het doel om tot een kwalitatief maar ook functioneel beter product te komen het belangrijkste was eigenlijk om weer tot een product komen. Dus eerst hebben we het product gedifferentieerd en nu zijn we weer aan het integreren naar een product toe. Vooral om de auto en support kosten binnen de perken te houden.

| Page 67 |


requirements

gathering

po2

requirements

gathering

po2

requirements

gathering

po2

requirements

gathering

po2

requirements

gathering

po2

requirements

gathering

po2

requirements

gathering

fc1

requirements

gathering

fc1

requirements

gathering

fc1

requirements

gathering

fc1

requirements

gathering

fc1

requirements

gathering

tm

requirements

gathering

tm

requirements

gathering

sm

requirements

gathering

fc2

agile

deviations

po1

agile

deviations

po2

agile

deviations

po2

agile

deviations

po2

Daar hameren we nu op dat daar een stuk voorwerk is door de functioneel consultant. Of dat er al in een sprint daarvoor een functioneel ontwerp gemaakt wordt en in de sprint er na een technisch ontwerp of de daadwerkelijke realisatie. ja we hebben een tijd gehad dat dat minder goed ging, dan heb je dus ongedefinieerde user story's, dat werkt niet. Dan is de Story heel summier omschreven. Daar zijn we op teruggekomen, er moet een functioneel consultants zijn die dit verder uitdiept en ook echt een scoping van maakt. diagrammen en usecases maken onderdeel uit van de user story. Voornamelijk Fc1 en Martijn doen dit nu. Waar nodig gebruiken ze bijvoorbeeld usecases, die passen ze toe in hun functioneel ontwerp. Dus de afhankelijkheid van functioneel consultants wordt steeds groter, dat merk je Het is natuurlijk heel moeilijk de requirements op te stellen, van de architectuur van het nieuwe product. Er zijn dan nog zoveel open einden. Het opstellen van de architectuur is al een deel het opstellen van de requirements. Dat hangt zo nauw samen met elkaar. onze ervaring heeft geleerd dat het maken van functionele ontwerpen, dus het verzamelen van requirements, niet goed in de sprints passen. Vaak zie je dat degenen die de ontwerpen maakt, ook nog andere werkzaamheden heeft buiten de sprint. Nu is het bij de overheidsmarkten vaak een beetje anders. Vaak zijn de requirements al duidelijk vanuit de aanbesteding. Je hebt dan weinig inspraak op de requirements die de klant stelt, deze moet je dan natuurlijk wel vertalen naar internerequirements. Dit gaat niet volgens een bepaalde methodiek, we hebben wel een standaard sjabloon voor functionele ontwerpen, hierdoor kunnen we met een goede snelheid de sprints zullen Maar bij requirements verzameling in het verkooptraject, dat kun je bijna niet met iteraties voor elkaar krijgen. Dit is zo dynamisch dat het niet in te schatten is en er ook nog allerlei afhankelijkheden zijn. In het verkooptraject zijnderequirements vaak onduidelijk veranderen ze ook nog vaak, pas als de opdrachten binnen is worden derequirements verder uitgewerkt, zodat ze in een sprint kunnen Dus dan heb je nog een sessie nodig met de klant om het te begrijpen, dat wordt ook ingecalculeerd bij zo groot project. Bij de kleine projecten wordt dat vaak niet gedaan en dan wordt het risico gewoon genomen, dan wordt er veel gewerkt op basis van aannames. ik denk dat het gewoon vaak te weinig aandacht heeft gekregen. Op een moment dat je een klant hebt die iets groots wil, dan krijgt het vanzelf aandacht. Als het om kleine features gaat, meestal niet het geval. door veel onzekerheden en doordat de requirements niet duidelijk waren en door druk van klanten toch functionaliteit toevoegen aan een sprint terwijl deze niet duidelijk was. Waar ik over kan praten is mijn klant en daar is het zo dat de user story een vertaling is van het functioneel ontwerp dat de klant gemaakt heeft en dat je ontwerp hebben we met de klant gedeeld. Dus daar zit eigenlijk al een soort van check. De klant heeft dan een businessrequirements verhaal, dit bevat heel veel tekst. Dit vertalen wij dan maar een functioneel ontwerp. Dit wordt dan afgestemd met de klant. Het functioneel ontwerp dient vervolgens als basis voor de user story. . Wat we vaak zien is dat er een demo wordt gegeven door het ontwikkelteam aan de functioneel consultants en de projectleiders Wat ik zie is dat het product management er nog wel eens bij in schiet. Dat meer tijd genomen moeten worden om user story's voor te bereiden. Je ziet gewoon dat als een user story niet goed voorbereid is, dan gaat die min of meer ongedefinieerd de sprint in. We hebben in het verleden situaties gehad dat de sprint bijna volledig afgerond werd behalve-user-story een, dat is niet volgens scrum. normaal gesproken moet je tijdens de sprint ook heel iteratief terugkoppeling geven aan de stakeholders. Dat gebeurt ook niet altijd, soms is dat pas aan het eind van de sprint of beide release. Normaal gesproken zou je ook altijd een demo moment moeten hebben aan het einde van de sprint. Dat schiet er ook wel eens bij in. Dus het stukje voorbereiding en de terugkoppeling tijdens de sprint, dat is denk ik het minst goed belicht bij-Sigmax.

| Page 68 |


agile

deviations

po2

agile

deviations

po2

agile

deviations

po2

agile

deviations

po2

agile

deviations

fc1

agile

deviations

tm

agile

deviations

sm

agile

deviations

sm

agile

deviations

sm

agile

deviations

sm

agile

application

po1

agile

application

po1

agile

application

po1

agile

application

po1

agile

application

po2

agile

application

po2

agile

application

po2

agile

application

po2

agile

application

po2

agile

application

po2

agile

application

po2

agile

application

po2

agile

application

po2

we houden wel onze focus factor redelijk laag, zodat je wat meer tijd hebt voor niet gepland werk en eigenlijk is dit niet volgens scrum. Dan heb je wat ruimte voor escalaties. Dan houden we daar een slag om de arm en houden we daar op die manier ruimte voor, maar eigenlijk is dat niet helemaal 100% scrum. Je zou de sprint eigenlijk gewoon helemaal vol moeten plannen en alle verstoringen buiten de deur willen houden Dat is hier ook bijna niet toe te passen bij-Sigmax, wij leveren niet gedurende de sprint een tussen product op aan de klant. Wij werken wel echt toe naar een eindproduct. Dat zou eigenlijk pleiten voor een waterval methode nee, we leveren pas een eindproduct op als het echt helemaal af is. We vragen minimaal feedback tussen door van de klant. Dat is niet echt agile, dat doen we wel met stakeholders. Dan word ik er bijvoorbeeld bijgehaald. Waar we wel van afwijken zijn de schatting methodieken. Je werkt in principe met planning poker, met van die kaartjes. Wat eigenlijk bij scrum hoort is een demosessie. Dat schiet er vaak bij in. eigenlijk alle facetten op één na en dat is de klant demo. We hebben dat wel een paar keer geprobeerd, maar dat kost teveel tijd. Demo's bij klanten doen we eigenlijk niet. Dit doen we niet omdat we eigenlijk te veel klanten hebben om bij elke klant demo te gaan geven. wat was de initiële schatting en wat is de uiteindelijk bestede tijd aan een functionaliteit. Als je dat goed gaat doen kun je op een gegeven moment een focus factor voor het hele team gaan berekenen. De deadlines werden zo kritisch, dat we hebben besloten om het hele proces los te laten. Vervolgens wordt aan de hand van de productbacklog de sprintbacklog gemaakt, dit gebeurt met de scrum master, de projectleiders en ik. Één keer in de twee weken zitten we om tafel om dit te bekijken. Daarin wordt bepaald of scherp hebben wat er opgeleverd moet worden en wat er in de eerstvolgende sprint komen. Ik ben bang dat wij gestart zijn met scrum om het scrummen. Ik denk dat er wel problemen waren waar scrum wel goed voor uitkwam. De ontwikkelaars hadden heel veel last van wisselende prioriteiten en verstoringen. Dat was wel een heel groot probleem. Er zat veel te veel dynamiek in de groep, dat kwam door alle storingen meldingen die binnenkwamen. Er is een lijst metuser-story gemaakt voor het team. Er is dus een product backlog en een sprintbacklog gemaakt. We zijn begonnen met een sprintlengte van vier weken, dat is nu nog steeds zo. Klopt, als je dan dusdanig openheid geeft, dan zegt die klant: maar je bent afgelopen sprint met functionaliteit voor een andere klant bezig geweest, dat was niet de bedoeling. Met scrum hebben we toen geprobeerd dit te verbeteren. Dit hebben we langzaam ingevoerd. We zijn begonnen met releases in vaste periodes. Wat ik vooral merk is dat het een stuk rust geeft voor het team. De planning wordt beter. Je prioriteit bepaling wordt beter. Het heeft ons wel verder geholpen. dat had meestal als gevolg dat de user story onder aan de sprint niet werden voltooid en die gingen dan naar een volgende sprint. Wat ik wel de kracht van agile en scrum vindt en ook de winst factor vindt is dat je met een team gaat voor een klus en ook een einddoel in die klus. Dus je neemt elkaar taken over en houdt mekaar scherp. Het geeft een stuk rust naar het team. In een afgebakende periode werk je aan een oplossing. Je weet dat er niet allerlei gekke zaken tussendoor komen. Dus het geeft ook een stuk rust, dat vind ik heel belangrijk. ik zie het voorlopig nog niet gebeuren. Onze product leent zich daar niet zo goed voor. Politie korps wil gewoon een eindproduct en niet een soort van test konijn zijn. Dat leent zich daar niet zo goed voor Bij bij onderhoud wordt vaak de omschrijving van de storing melding meegenomen in de sprint, dan heb je niet echt een requirements document. Dit is gewoon echt een storing melding. We gebruiken het nu wel voor onderhouds items, puur weer om het netjes in te kunnen plannen en je capaciteit daarvoor te gebruiken. Eigenlijk zou het voor onderhoudsitems zo moeten zijn dat je een prioriteitenlijst hebt die afwerkt. Daar heeft het wel een positief effect op, maar ik denk dat agile het meest geschikt is voor de initiële fase. Als je nog aan het bouwen bent met product en tussen versies oplevert naar de klant.

| Page 69 |


agile

application

po2

agile

application

po2

agile

application

po2

agile

application

fc1

agile

application

fc1

agile

application

fc1

agile

application

fc1

agile

application

tm

agile

application

tm

agile

application

tm

agile

application

tm

agile

application

sm

agile

application

sm

agile

application

sm

agile

application

sm

Ik vind agile ook weer minder geschikt in de hele prille fase, dat merk ik nu ook bijvoorbeeld als er nog gewerkt wordt aan de architectuur en je hebt nog niet echt iets tastbaars dan vind ik scrum iets minder geschikt. bij cc vijf hebben scrum toegepast op bestaand product en bij cc zes passen we het voor het eerst op een helemaal nieuw product vooral als de architectuur duidelijk is en er kan begonnen worden met het bouwen van functionaliteit dan scrum een goede toepassing We wilden een agile methodiek toepassen om de software ontwikkeling te structureren en feitelijk inzichtelijk te krijgen waar we staan op elk willekeurig moment in tijd. Een week later viel er weer iets anders om een pakket, het was een beetje een rommeltje. Als je dat wil structureren gaan werken met een vaste periode van ontwikkeling inclusief de requirements die daaraan ten grondslag liggen. Scrum is dan een methodiek om inzicht te krijgen in hoeveel werk er ligt, iedereen weet van elkaar waar ze aan werken, bij komend voordeel is dat er kennisdeling plaatsvindt. Voor ons waren de voordelen voornamelijk structuur en inzicht in het werk, weten waar je aan kan werken en wanneer. Dan ben je volgens mij niet agile bezig, je zou dan die acht weken op moeten knippen in vier sprints en dan na elke sprint tonen aan de klant wat er gerealiseerd is. De klant kan dan testen met de functionaliteit. Zo kun je veel sneller schakelen, de feedback kan dan in de volgende sprint verwerkt worden en de klant hoeft maximaal maar vier weken te wachten. Dit wordt bij-Sigmax nog niet heel veel toegepast ja, wat ik gemerkt heb bij cc vijf is dat sprint werkt goed volgens plan op het moment dat derequirements heel erg duidelijk zijn. tijd en kosten. Dat is volgens mij de grootste reden. Scrum wordt intern ook gezien als iets dat geld kost, door allerlei bijeenkomsten die ten koste gaan van de ontwikkeling. Bij het schatten of plannen je gerust enkele dagen druk zijn met het team. Kun pas schatten als het ontwerp is en derequirements. Het zijn twee dingen: de urgente issues in het veld en als de requirements niet duidelijk waren. Werk dat niet afkomt in een sprint doorgeschoven naar volgende sprint als niet gepland werk In die tijd was het ook zo dat de sales mensen bij de ontwikkelaars aan het bureau stonden: zo van, waarom werk jij hier niet aan? Het was redelijk chaotisch, en toen heb ik gezegd: hier moeten we wat aan veranderen. Er is op een gegeven moment een visie gekomen waarbij we van project denken na product denken zijn gegaan. Dit betekent dat we geen klant specifieke wijzigingen meer doen, maar alleen functionaliteit toevoegen meerdere klanten kunnen gebruiken. Het grote verschil is denk ik dat onderhoud een veel kleinere impact heeft, het is het aanpassen van bestaande code en nieuwe functionaliteit betreft meestal nieuw code. n waar het voornamelijk de laatste tijd misgaat is het moment dat eenuserstory groter wordt dan 100 uur, stel dat je een storing hebt van 200 à 300 uur dan krijg je heel veel Ongepland werk. Je raakt dan het overzicht kwijt.

| Page 70 |


9.5 INTERVIEW TRANSCRIPTS 9.5.1 CIO O: misschien kun je even kort vertellen waar je als directeur/eigenaar van Sigmax je je op het moment vooral mee bezig houdt? W: ik zit momenteel erg dicht op cc zes. Daar ben ik ook echt in het team bezig om te kijken wat we allemaal moeten, ik hou me bezig met architectuur, de visie uitstippelen en verder alles om te zorgen dat het goed loopt. En verder hou ik uiteraard ook een vinger aan de pols bij de andere producten, zoals-FMS. O: kun je wat vertellen over de geschiedenis van scrum bij-Sigmax? W: we zijn er een paar jaar geleden mee begonnen, wanneer precies weet ik niet meer. Ik denk ongeveer een jaar of drie. Het is vooral begonnen omdat we zagen dat de watervalprojecten niet altijd denderend liepen. Daar hadden we veel uitlopen. In het begin liep die projecten soepel, maar naarmate ze vorderen liep het steeds meer uit, omdat er steeds meer en aangepaste requirements op tafel kwamen. Of dat je er achter kwam dat er tijdens het project gewerkt is aan zaken die eigenlijk niet zo heel belangrijk waren. Bij waterval lijkt alles in het begin altijd goed gegaan later alle troep boven drijven. Toen zijn we begonnen met scrum, het was hip en mensen lazen erover. Toen dachten we laten we dat eens proberen kijken of het helpt. O: scrum werd dus vooral ingezet voor het beheersbaar maken van projecten en niet om beter aan te sluiten bij de klant wens? W: ja, dat gebeurde ook wel. Maar dat was wat in mindere mate. Ik denk ook dat scrum daar bij ons niet helemaal de oplossing voor levert. We hebben wel tussentijdse releases en de klant ziet wel dingen, maar wij ontwikkelen niet in scrum samen met de klant. Dit is omdat klanten altijd van tevoren weten wat de kosten zijn en het is heel moeilijk om een variabel eind doel aan de klant te verkopen. Dit is eigenlijk een mix waarbij we wel een vast budget met de klant afspreken. Beide waterval methode hadden we ook methodes om de uitloop te beperken. Dit deden we door in het ontwerp al veel voor beeldschermen te gebruiken, zodat dit bij de klant ging leven. Ontwerp ging dan in iteraties, dit zorgt ervoor dat de klant beter weet wat hij wil en veranderende dan minder in de loop van het project. O: het toepassen van scrum, is dat geleidelijk gegaan?

| Page 71 |


W: we hebben scrum daar product geïntroduceerd. In het begin was het een beetje zoeken van hoe werkt het allemaal, je schafte wat boeken aan en je sturen wat mensen op cursus. Daarna begin je en dan ontdek je een beetje wel of niet moet. O: waar liep je in het begin vooral tegenaan? W: dat er meer in de sprint werd gedrukt dan dat er eigenlijk in kon. De schattingen waren nog niet heel nauwkeurig, de schattingen werden gewoon niet goed gemaakt en werd niet genoeg in detail naar gekeken. Er werd in te grote brokken geschat, in maximaal taken van een dag schatten. Veel belanghebbenden van het project riepen dan dat iets in een sprint mee moest. Op een gegeven moment kom je er achter dat dit een illusie is. In het begin deden we de schattingen met het complete team, ik zat daar dan wel eens bij en dan dacht ik: hoeveel euro's worden hier per minuut verbrand? Dat doen we nu ook anders. We houden nu de teams kleiner, waardoor er ook een betere kennisdeling is. Iedereen blijft dan goed op de hoogte. O: en wat versta je onder een kleiner team? W: de literatuur en de ervaring zegt een man of zes. Dat de teams hebben die eigenlijk te groot zijn, daardoor treedt een hoop in efficiëntie op. Er moet dan veel te veel met elkaar afgestemd worden. Vanuit het oogpunt van kennisdeling uit het ook het beste als iedereen overal bij betrokken is. Maar of dit efficiënt is, dat is sterk de vraag. Dit kun je vanuit verschillende gezichtspunten bekijken. O: je ziet heel vaak dat als scrum in een organisatie wordt toegepast om aan dat dan het proces wordt aangepast aan de organisatie. Kun je daar voorbeelden van noemen? W: volgens het boekje doe je scrum met de klant, tenminste als je maatwerktrajecten. Dat doen wij niet. Bij scrum kun je eigenlijk alleen het aantal features laten variëren, de capaciteit van het team en de lengte van de sprint staan vast. Beide watervalmethode zie je dat alles vast is, dit kan natuurlijk nooit werken. In cc zes staan de functionaliteiten ook grotendeels vast, dus je kunt niet minder functionaliteit maken. De grootte van het team kan nog enigszins gevarieerd worden maar niet veel. Aan het einde zal daardoor een flexibiliteit moeten zitten in de op levertijd. Dat is eigenlijk niet zoals het volgens scrum zal moeten. Ik denk ook dat scrum het allerbeste werkt bij product ontwikkelen en bij maatwerk iets minder, omdat je bij een product kunt zeggen: bepaalde functionaliteit maken we niet. Dit betekent dat als je meerdere klanten hebt, die betalen per licentie, dan ben je niet verplicht om bepaalde functionaliteit te maken, zoals bij een maatwerk project. Dit heeft ook te maken met de productfase, in het begin

| Page 72 |


werken voor een klant specifiek, maar naarmate het aantal klanten groeide kun je niet meer voor een klant iets maken. Dit is een van de principes van scrum, debacklog staan alle functionaliteiten, degene met de hoogste prioriteit wordt geïmplementeerd. Dit betekent automatisch, dat functionaliteit die onder aan de lijst blijven staan nooit geïmplementeerd zal worden. Dit is erg belangrijk, en zorgt ervoor dat je je alleen bezig houdt met belangrijkste zaken. Functionaliteit die onder aan de lijst blijven staan, dat heeft een duidelijke reden. O: je zei eerder al dat er niets samengewerkt wordt met de klant in het scrum proces. Is dit een bewuste keuze? W: het is heel moeilijk, zeker in de overheid wereld, daar worden aanbestedingen gedaan. Derequirements schrijvende gemeentes voor in hun aanbesteding en vervolgens moet je op prijs aanbieden. Kunt dan eigenlijk niet met scrum werken, want je hebt geen enkele variatie mogelijkheid. Je gaat dan wel vaker opleveren naar de klant, zodat deze kan testen en feedback kan geven. De klant kan daardoor andere ideeën krijgen, waardoor je meer werk kunt verkopen. Daarnaast is het ook zo dat de klant graag zekerheid wil hebben, ze hebben een vast budget willen precies weten wat ze daarvoor gaan krijgen en wanneer. Het is dan moeilijk om samen met de klant aan scrum te werken, omdat er dan van alles kan veranderen. Scrum werkt daardoor beter bij producten met licentie verkoop, want dan ben je je eigen klant en bepaal je zelf wat er geïmplementeerd wordt. Bij producten werd scrum beter dan bij maatwerk. Bij de maatwerk projecten die we hebben pakken we eigenlijk alleen enkele onderdelen van scrum. Hier helpt scrum om de klant inzicht te geven in de huidige ontwikkelingen. Als er dan uitloop is, dan kan het vroegtijdig aan de klant gesignaleerd worden, in plaats van na een half jaar. O: dus er wordt na een sprint altijd opgeleverd richting de klant? W: dat ligt eraan, soms heb je functionaliteit die niet zoveel laat zien aan de klant. Maar bij een product zoals cc vijf wordt er na elke sprint opgeleverd. Daar moeten we van af, omdat dit veel te veel werk is. We moeten naar een situatie waarbij de twee of drie oplevering een per jaar hebben. Tussentijds misschien hotfix, voor dringende issues. Je kunt uiteraard nog steeds iets aan een klant laten zien, maar dit is iets dan een oplevering. O: in welke mate is het bij de klant bekend dat Sigmax met scrum werkt?

| Page 73 |


W: het wordt meer als marketing en verkoopding gebruikt. De klant is er verder niet echt van op de hoogte dat wij scrum gebruiken, als je intensief samenwerkt zullen ze het ongetwijfeld merken. Het zorgt er wel voor dat je regelmatig feedback krijgt en dat is goed. O: is momenteel het requirements proces een apart proces dat voorafgaat aan het scrum proces? W: het is gefaseerd. Als je nu naar cc zes kijkt, dan is de gemeente Leeuwarden grootte gebruiker. Daar is eerst een ontwerpfase geweest samen met de klant. Dat is tot in redelijke detail uitgewerkt. Je ziet dat er nu tijdens de ontwikkeling nog steeds afstemming is met de klant over bepaalde zaken. Hier moeten we zorgen dat er constant voor de sprint weer bekend is. O: ik kan me voorstellen dat het scrum proces en dan vooral het voor en na traject, dat dit wezenlijk verschilt tussen cc en FMS? W: je merkt vooral verschil als er nieuwe mensen in het team komen. De efficiëntie is dan een stuk minder omdat iedereen op de hoogte is. Bij cc vijf passen we scrum niet helemaal goed toe, daar worden bijvoorbeeld functies verkocht, waarbij beloofd wordt dat deze de volgende sprint opgeleverd worden. Daar is een slechte afstemming tussen verkoop en het team. Je zag dat daar geen realisme was betrekking tot het beloven van deadlines aan de klant, daardoor liepen de sprint niet goed, omdat er teveel werk in zat. Hier brengt scrum realisme. Je loopt er dan snel tegenaan als iets niet past qua werk. Ook zorgt scrum ervoor dat iedereen een doel heeft, dit is een korte termijn doel. Bij waterval ligt het doel veel te ver weg en is het niet in detail te beschrijven. Wat ik ook vaak zien is dat derequirements functioneel worden opgesteld, maar dat er dan allerlei technische vragen zijn van hoe dit geïmplementeerd moet worden. Daardoor zie je dat de schatting sessies enorm uitlopen. O: wat je ook ziet is dat de functioneel consultants momenteel bij cc meer technische achtergrond hebben en dat de functioneel consultants bij FMS ook projectmanager zijn. Een bewuste keuze? W: klopt, hierdoor kwamen we er snel achter bij-FMS dat er meer technische diepgang nodig was. Bij cc werd verondersteld dat deze technische diepgang er was, maar dit bleek ook niet altijd zo te zijn. Dat is deels ook zo, maar het was toch nog niet goed genoeg

| Page 74 |


O: maar aan de andere kant zou je het ook als een beperking kunnen zien. Als je iets functioneel sprint, zou je geen technische belemmeringen moeten hebben. Zie je dan ook dat bepaalde zaken functioneel minder worden om ze technisch te laten passen? W: bij cc vijf weet ik het niet, bij cc zes gaan we een nieuw product neerzetten. Daar zorg ik dat de mentaliteit is: in één keer goed doen. We moeten geen beslissingen nemen waar we later heel veel spijt van krijgen. Er moet gewoon goed vooruit gedacht worden, wat gebeurt er bijvoorbeeld als we Ecuador als klant krijgen? Door dit soort vragen wordt iedereen getriggerd om te bekijken is dit wel iets algemeens of juist iets klant specifieks? Ik probeer iedereen te stimuleren om daarin mee te denken. O: het helederequirements proces gebeurt nu bij-FMS deels met scrum? In ieder geval met papiertjes? W: ja, ik geloof het wel. Je zou natuurlijk het requirements proces ook gewoon via scrum kunnen laten lopen. O: is dat iets waarvan je zegt: dat is handig? W: ik denk dat dat wel handig kan zijn. Het vereist alleen veel discipline. Bij cc zes merk ik dat dat nog niet gebeurd, het aantal functioneel ontwerpen is nog beperkt, dus dat kan nog wel op een andere manier. Daar moeten we wel een modus zien te vinden O: maar zou het opstellen vanrequirements volgens scrum proces beter helpen om de ontwikkel sprint te vullen? W: feitelijk is het een project management methode, dus als deze methode beter werkt dan een andere methode, dan helpt het natuurlijk. Je ziet nog wel eens dat ontwerpers flink aan de bak moeten om hun ontwerp op tijd af te krijgen en als je dat wat meer gaan plannen dan kan dat helpen, ja. Maar dat is duidelijk iets, waar nu nog een beetje naar gezocht wordt O: ja, wat ik ook al vaker heb gehoord is dat er qua requirements een afhankelijkheid is van de klant. Je krijgt dan al snel de situatie dat je niet volledig kunt focussen op een ontwerp, omdat je nog afhankelijk bent van bijvoorbeeld een interview met de klant. Hierdoor is het moeilijk te zeggen: volgende week maandag is het af. Dit is ook vaak het geval met onderhoud werkzaamheden.

| Page 75 |


W: ja klopt. Soms zit het onderhoud in de sprint, dit is als het groot en complex is. Maar soms ligt het er ook helemaal of zit het er half in. O: maar komt dit dan omdat het nog niet helemaal duidelijk is hoe hiermee om te gaan? W: support en ontwikkeling zijn twee andersoortige processen. Support heeft altijd een bepaalde lijst staan van wat ze moeten doen, niet alles is heel dringend, maar sommige zaken zijn heel dringend een moeten direct opgelost worden. Bij ontwikkeling kun je zeggen: we gaan de komende vier weken dit doen en daar komt verder niks meer bij. Bij support is het zo, dat als een klant een groot probleem heeft, je niet kunt zeggen: over vier weken ben je aan de beurt. Je hoort dus ook wel dat ervoor onderhoud andere methodes worden gebruikt dan scrum, bijvoorbeeld kanban. O: maar soms zie je toch die support dingen in een sprint terechtkomen. W: klopt, maar dat zou niet moeten. Maar dat heeft misschien ook weer met de levensfase van het product en het team te maken. Dit soort dingen moeten toch elke keer weer ontdekt worden. Je kunt wel een blauwdruk maken van de manier waarop je werkt binnen de hele organisatie, maar dat werkt gewoon niet O: dus als onderhoud de overhand krijgt, dan heb je eigenlijk wat minder behoefte aan een ondersteunend proces zoals scrum W: dat niet denk ik. Als het product volwassener wordt, dan ga je niet meer voor individuele klanten programmeren. We moeten ons goed beseffen dat naarmate het product volwassener wordt, we twee verschillende soorten programmeurs krijgen. Je hebt de programmeurs die aan het product werken, dit wordt gedreven door onze visie en soms individuele klant wensen en daarnaast heb je ook maatwerk. Als een klant iets specifieks wil hebben, dat niet geschikt is voor andere klanten, dan willen we dit niet in ons product hebben. Dit zal dan meer een soort plug-in worden. Dit loopt ook niet samen met de algemene productontwikkeling. De algemene productontwikkeling kan goed met scrum gedaan worden, maar van maatwerk kun je je afvragen of dit wel handig is. Die splitsing in teams hebben we nu nog niet, maar ik zie wel aankomen dat we daar iets mee moeten gaan doen O: dus die drie verschillende facetten (ontwikkeling, onderhoud, maatwerk) kun je ook in een sprint krijgen?

| Page 76 |


W: ja, maar dat wil je niet, want het product release je een keer per half jaar, maatwerk wanneer je met de klant afgesproken het dat het klaar moet zijn en onderhoud wanneer het nodig is, afhankelijk van de prioriteit. Dit kan dus moet samengaan sprint. De belangen zijn anders. Je moet dat dus niet in een team gaan doen. Voor onderhoud scrum niet zo goed proces. Daar heb je al behoefte aan iets anders, dat hebben we nu nog niet. Als een product dus volwassener wordt, dan zie je andere behoeften in de projectmanagementmethode. Je moet dan goed kijken wat verschillende onderdelen zijn, en welke methoden daar het beste bij past. O: wat je ziet in de theorie van de product levenscyclus is dat tijdens de introductie en de groeiende volgens op het product ligt daarna komt de focus meer op het proces te leggen, dat wil zeggen op het verbeteren van de efficiëntie en kwaliteit W: in het begin van de ontwikkeling ben je eigenlijk niet bezig met het product, maar met het ontwikkelen van klant features. Toevallig ga je daar later dan je product van maken. Dat is de fase dat je nog heel dicht een op een met de klant zit te werken. Naarmate je meer klanten krijgt, bepalen wij zelf deze features ervoor al die klanten uit moet gaan zien O: maar eigenlijk zou het toch in het begin ook al zo moeten zijn dat je een product ontwikkeld en niet klant specifiek? W: soms dan zit er iets meer de visie van de klant achter dan dat je zou willen, maar je hebt wel budget nodig om het product ontwikkelen. Dit moet betaald worden door de klant. Idealiter zou je een product ontwikkelen met het geld dat je in kas hebt, maar deze situatie komt bijna nooit voor. Over het algemeen ga je dus altijd vanuit de klant vraag iets maken. Dus als het product volwassener wordt, dan wordt de rol van product owner ook anders. O: zie je de huidige ontwikkeling van cc zes als een nieuw product of als een differentiatie van cc vijf? W: wat je nu ziet is dat cc vijf eigenlijk aan het afbouwen is, we willen dus eigenlijk weer opnieuw met dit product gaan groeien. Daarom hebben we ervoor gekozen om een grotere internationale markt gaan bedienen, waarvoor we dan cc zes gaan ontwikkelen O: en is de ontwikkeling van cc zes dan meer klant gedreven of komt dit uit de organisatie zelf?

| Page 77 |


W: deels is het klant gedreven. We hebben nu een grote klant: Leeuwarden, deze hebben een visie zoals het product in de komende jaren in Nederland zou kunnen gaan werken. Het bedrag dat Leeuwarden betaald is echter niet voldoende voor de ontwikkeling, dus we investeren dan zelf in het product zodat we het kunnen maken zoals wij dat zelf willen

9.5.2 FUNCTIONAL CONSULTANT O: kun je in het kort vertellen wat je momenteel bij Sigmax doet? R: ik ben functioneel consultant en projectmanager. Ik vertaal de klant wensen na-userstory's, zodat het gebruikt kan worden in de sprints. Daarnaast ook verkoop ondersteuning. Dat is het in grote lijnen. O: het scrum proces bij-Sigmax, kun je eens vertellen wat jouw ervaringen daarmee zijn? R: wanneer er exact mee begonnen is dat weet ik niet, maar van de een op de andere dag was het er. We zijn volgens scrum gaan werken. Ik denk dat het goed is geweest voor onze afdeling, waarin je over een korte periode afspreekt: dit zijn de doelen die we moeten gaan halen. Je kunt dan zeggen wat je aan het eind van de sprint en functionaliteit kunt verwachten. Het voordeel daarvan is dat je weet wat er gaat komen, en dat je dit weer kunt gebruiken voor de volgende sprint planning. Dan zorgen dat de user story's op tijd klaar zijn en reviews zijn. Dit brengt dus ook in de voor fase een stukje discipline om de story's op tijd af te krijgen. Dat was ook een totale verandering. Vroeger maakten we alleen een functioneel ontwerp en nu een user story met bijvoorbeeld scherm afdrukken en invalshoeken van verschillende stakeholders. Aan de ene kant gaat het goed voor de grote trajecten, maar aan de andere kant is het een stuk proces voor de kleinere trajecten. Nu is het zo dat een sprint vier weken duurt, alles wat hier tussenin gebeurt kan pas in de volgende sprint meegenomen worden. Het is dus bijvoorbeeld lastig om kleine functionele wensen klanten hebben, als je daar zit voor de implementatie, snel te implementeren. O: OK, maar dit is toch ook niet de bedoeling of juist wel? R: ik denk dat je wel in staat zou moeten zijn om kleine functionele wijzigingen aan een product, waar de klant heel veel aan heeft, snel door te kunnen voeren. Vooral de zaken die blokkerend voor een klant zou kunnen zijn. Dit hoeft ook niet per se in het scrumteam te gebeuren, maar je zou ook een of twee personen buiten het team kunnen houden die dit soort zaken oppakken.

| Page 78 |


O: maar scrum is al speciaal bedoeld om snel in te kunnen spelen op veranderingen, maar jij zegt: het moet nog sneller kunnen? R: ja, met kleine veranderingen bedoel ik zaken die je in een paar uurtjes kunt wijzigen. Dat vind ik dat dat moet kunnen. Je ziet dat als we nu gaan uitrollen naar grotere klanten, dat er toch wat kleine functionele zaken naar boven komen. Je zou hier sneller op moet kunnen reageren. Je kunt niet tegen die klant zeggen: in het meest ongunstige geval moet je acht weken wachten. O: het vullen van de sprint met user story's. Hoe loopt dat? R: het is erg belangrijk dat de user story's volgens een vast sjabloon gemaakt worden. Hiermee zorg je dat je iets op dezelfde manier beschrijft. Dit maakt het al veel duidelijker voor het ontwikkelteam. Op het moment dat mensen er mee gaan beginnen moet het ook echt klaar zijn, dit is gewoon een soort van discipline. Je moet op tijd allesafhebben en ingeschat hebben, ook om te kunnen bepalen of het in de sprint past O: dat lukt altijd goed? R: het vullen van de sprints is geen enkel probleem, maar de discipline om de Story's op tijd af te hebben is wel lastig. Dit komt ook door de dubbelrol die wij hebben als functioneel consultants en project manager. Vooral het project management kan heel erg druk zijn, dan moet je echt bewust tijd maken om user story's te schrijven O: zie je dit als een voordeel of als een nadeel dat je zo een dubbelrol hebt? R: het is een kwestie van prioriteiten stellen. Ik zou zelf liever alleen functioneel consultants zijn, zodat je daar volledig op kunt focussen. Het is een keuze vanuit het management, zodat we zo breed mogelijk inzetbaar zijn O: is dan ook het doel om het klantcontact bij een persoon neer te leggen? R: het is meer om te zorgen dat je niet teveel overhead in projecten krijgt, vaak heb je toch bij de klant een projectmanager en een functioneel consultants zitten. Dit hebben we nu gecombineerd en dat werkt efficiënter. Tenminste dat zou het moeten zijn. O: bij cc zie je dat de functioneel consultants voornamelijk een technische achtergrond hebben, terwijl bij-FMS de consultants een projectmanager rol hebben. Dat is wel een andere insteek.

| Page 79 |


R: klopt, ik weet niet of dat goed of slecht is. Ik denk dat wij bij-FMS daardoor meer kijken vanuit een klant perspectief. Daarna zijn er weer mensen die er op kijken om te kijken hoe het geïmplementeerd moet worden. O: deze technische afstemming, zit dit in het scrum proces of juist ervoor? R: het is in ieder geval zo dat als een user story de sprint ingaat, dat er al een technisch ontwerp toegevoegd is. Ik beschrijf het puur technisch, en vervolgens wordt er technische beschrijving toegevoegd aan de-user-story. Ik denk dat ongeveer 80% van de user story functioneel is en 20% technisch. O: is dat altijd zo geweest, of is dat zo gegroeid? R: nee vroeger hadden we een apart functioneel ontwerp en een apart technisch ontwerp. Je ziet nu dat deze veel meer gecombineerd wordt en dat werkt volgens mij wel mooi. O: zie je nog vaak dat er iets terugkomt uit een sprint omdat het niet duidelijk is? R: dat proberen we te voorkomen door het goed te organiseren, wat we doen is dat we wekelijks een soortuser-story Review hebben. We gaan dan met de functioneel consultants en de architecten tafel zitten. We lopen dan de-user-story door om te bepalen of dit duidelijk is voor de ontwikkelaars. Daarna kijkt de ontwikkelaar er ook nog een keer vooraf naar te kijken of het helemaal duidelijk is. Dit is het ideale proces, maar soms komt dit er allemaal niet van. Met dit proces voorkom je vrijwel altijd dat er onduidelijkheid zijn tijdens de sprint. O: maar als er toch een onduidelijkheid voorkomt, wordt het werk dan doorgeschoven naar de volgende sprint of wordt het nog opgelost in de huidige sprint? R: kan, de sprint wordt niet verlengd, dus meestal wordt het doorgeschoven. We hebben ook een paar keer gehad dat we eens sprint helemaal hebben gestopt en weer opnieuw zijn begonnen. We hebben vroeger ook wel eens verlengd, maar daar word je niet vrolijk van. De voorbereiding is dan gewoon niet goed en dan gaat het van kwaad tot erger O: wat is dan de reden dat een sprint helemaal gestopt wordt?

| Page 80 |


R: bijvoorbeeld in de laatste sprint waren we bezig met allerlei productverbeteringen, maar toen bleek dat er toch nog wat moest gebeuren voor een klant. Toen zijn we gestopt en opnieuw begonnen om de zaken voor de klant op te gaan pakken. O: zijn de sprints voornamelijk gevuld met functionaliteit of zit er ook wel onderhoud in? R: als je kijkt hoe we het afgelopen jaar de sprint hebben gedaan, ik durf het niet keihard te benoemen, maar ik denk dat 70-80% nieuwe functionaliteit was. Nu zijn we ook weer bezig om sprint met de productverbeteringen op te pakken, dat is echt iets technisch in het product dat zie je functioneel niets van terug O: als je kijkt naar de levenscyclus van FMS, het vullen van een sprint met productverbeteringen, dan zou je zeggen dat het product al redelijk volwassen is? R: ik kan het niet technisch beoordelen maar als ik het functioneel bekijk dan zijn we aardig op stoom, ik heb het idee dat bij nieuwe klanten wel gewoon standaard product uit kunnen rollen. We maken nu een standaard product, maar het is als maatwerk begonnen. Daar zit heel veel legacy in. Daar zitten gewoon zaken in waarvan niemand weet waarom ze er zo in zitten. Als je daar nu naar kijkt dan denk je: waarom zit dit er zo in? O: en hoe gaat het samenwerken met de klant? Normaal gesproken geef je een demo na elke sprint aan de klant, gebeurt dit ook altijd? R: nee, het gebeurt niet altijd. De vraag is ook even wie is de klant? Intern of extern? Wat we sowieso altijd doen is een demo van het ontwikkelteam aan de functioneel consultants. Dit is dus een presentatie aan de interne organisatie, ook aan verkoop en het management. Die kunnen dan zien wat er gemaakt is verkocht kan worden aan de klant en deregelijke. Aan de klant presenteren we het ook, maar dan is het meer een voldongen feit. Dus niet in de zin van een demo, maar meer: dit is waar je het mee moet gaan doen. O: maar dat laatste gebeurt niet na elke sprint? Dit zijn meer de reguliere releases? R: klopt, het is niet zo dat wij na elke sprint naar de klant gaan een demo te geven. We leveren gewoon op wat er gemaakt is, de klant gaat er dan meewerken en geeft feedback in de vorm van gevonden issues, bugs of functionaliteit die nog aangepast wordt.

| Page 81 |


O: maar loop je dan niet het risico dat de klant uiteindelijk zegt: dit is niet wat ik bedoeld had? Omdat er dan ook een redelijke tijd zit tussen verzamelen van derequirements en de uiteindelijke oplevering? Er is geen tussentijdse feedback. R: daar heb je gelijk in. Waar ik over kan praten is mijn klant en daar is het zo dat de user story een vertaling is van het functioneel ontwerp dat de klant gemaakt heeft en dat je ontwerp hebben we met de klant gedeeld. Dus daar zit eigenlijk al een soort van check. De klant heeft dan een businessrequirements verhaal, dit bevat heel veel tekst. Dit vertalen wij dan maar een functioneel ontwerp. Dit wordt dan afgestemd met de klant. Het functioneel ontwerp dient vervolgens als basis voor de user story. O: dus de klant heeft wel hele goede kennis van de eigen processen? R: ja, maar eigenlijk ook weer niet. Wat ik vaak zien is dat er vanuit het management bepaalde processen worden bedacht, maar dat deze in de praktijk niet goed werken. Dan zie je dat we functionaliteit maken die op papier prima werkt, maar in de praktijk niet. Daarom hebben we het product nu in hoge mate confederaal gemaakt, zodat we dit makkelijk kunnen wijzigen in de procesflow. O: is het dan ook zo dat bij kleinere wijzigingen op een volledige user story wordt uitgewerkt? R: het is wel zo dat voor kleine wijzigingen, bijvoorbeeld een inconsistentie op het scherm, daar ga ik geen uitgebreide user story van maken O: hoe zorg je dan dat dit snel opgepakt wordt? R: dan worden er gewoon een paar regels tekst op papier gezet met wat scherm voorbeelden. De grote dingen moet je gewoon beschrijven maar de kleine dingen moet tussendoor kunnen. Uiteraard moet je wel hoe goed schrijven en duidelijk maken hoe het moet worden. Als je dat niet doet krijg je uiteindelijk toch we iets waarvan je denkt: dit is het niet. O: het requirements proces, werken jullie hier nog volgens een bepaalde methodiek? Jullie gebruiken daar toch Trello voor? R: ja klopt, maar we hebben ook de productbacklog in TFS gebruikt. Ook vaak doen is dat we tweewekelijks de prioriteit doorspreken met de product eigenaar. Op basis daarvan bepalen de prioriteit.

| Page 82 |


O: dit lijkt wel op scrum. Is dat ook zo? R: ik denk dat het niet helemaal volgens scrum is, stoppen de requirements niet sprints. Het moet wel aansluiten op het ontwikkelsprints, dus dit zorgt ervoor dat je wel een vast tijdsbestek hebt om de user story's te beschrijven. We beginnen al gelijk met de user story's bij het begin van een ontwikkelsprint, deze zijn dan voor de volgende sprint. Behouden goed bij wat de status is van de user story's en de prioriteit. O: is het ook moeilijk om somsuser-story's af te krijgen onder bepaalde afhankelijkheden hebt met andere werkzaamheden? R: dat heb ik nog niet zo ervaren, omdat ik het afgelopen jaar voornamelijk vanuit een functioneel ontwerp heb gewerkt. Het functioneel ontwerp is dan eigenlijk één op één overnemen wat in de businessrequirements van de klant staat. De klant geeft dan ook akkoord op het ontwerp. O: maar ik kan me voorstellen dat de klant daar een beetje huiverig voor is, die denken misschien dat er geen wijzigingen meer mogelijk zijn. Is dat dan ook zo zit er nog een bepaalde mate van speling in? R: Dat kan altijd. Maar moet wel in het achterhoofd houden dat er natuurlijk een prijs is gekoppeld aan de functionaliteit. Dus als de klant iets anders wil, dan moet daar wel voor betaald worden. Maar kleine wijzigingen voeren we wel door, indien mogelijk. Maar als het niet kan dan doen we het ook niet. O: kun je misschien aangeven het scrum proces en het opstellen van requirements door de tijd veranderd is? R: in het begin was alles nieuw. Als je kijkt naar de user story's die we in het begin maakten nu maken daar zit best wel veel verschil in. Het is allemaal veel uitgebreider en kwalitatief beter. Je weet nu waar je op moet letten als je iets opschrijft. Wat is belangrijk voor de ontwikkelaars om te weten. Dat is een proces van feedback waardoor het steeds beter is geworden O: en als je het door de tijd bekijkt? Wordt het proces dan steeds zwaarder en uitgebreider of juist niet? R: wat we wel geleerd hebben is dat we zo min mogelijk hetontwikkelteam proberen te belasten. Wat we nu vooral doen is dat we nieuw consultants en de architect een Story

| Page 83 |


maken en dat deze pas daarna naar de ontwikkelaar gaat, om zoveel mogelijk zaken er vooraf al uit te halen discussie en onduidelijkheden te voorkomen.

9.5.3 SCRUM MASTER O: kun je misschien even kort vertellen wat je bij-Sigmax doet? P: we hebben een team van ontwikkelaars, een team van ongeveer 8-10 man. Die werken volgens scrum, dit betekent dat we sprints hebben die met user story's gerealiseerd worden. Dit is functionaliteit toegevoegd wordt aan het product, de-userstory staat uit taken. Ik begeleid dit proces. Ik zorg dat eruser-story zijn, ik zorg ervoor dat het team niet verstoord wordt, bijvoorbeeld als er extrarequirements komen of als er andere verstoringen zijn, dan zit ik daar tussen. Ik zorg ervoor dat er gerealiseerd wordt wat er afgesproken is. Niet meer en niet minder. Vooral niet meer. U moet wel proberen alleen de dingen te maken die belangrijk zijn, je moet constant scherp blijven op wat belangrijk is. Tijdens de ontwikkeling dan blijken iets toch minder belangrijk was dan vooraf ingeschat. O: wat voor effect heeft dit dan op de sprint? Wordt deze dan verkort of verlengd? P: de sprint is altijd vier weken. Het enige dat kan wisselen is de inhoud van de sprint. Als er bijvoorbeeld iets wegvalt, dan kan besloten worden om iets extra's toe te voegen. Probleem vaak is wel dat als je nog iets toe wilt voegen datderequirements duidelijk moeten zijn, dit is niet altijd het geval. Het komt voor dat user story nog niet voldoende helder is, dan weet je niet eens wat je moet maken. O: kun je iets vertellen over de geschiedenis van scrum bij-Sigmax? P: ik heb er vanaf het begin bij gezeten. Guido is ermee begonnen, ik ben pas een half jaar scrum master. In het begin hebben we wat gespeeld met de lengte van de sprint. We hebben geëxperimenteerd met een sprintlengte van zes weken, dit beviel niet omdat het moeilijk te managen is. We zitten nu op vier weken dit is net lang genoeg. Meestal wordt ook in de laatste week de code al bevroren. Je gaat dan alleen tekst bevindingen oplossen en de documentatie afronden. Dat doen we nu ongeveer twee jaar O: hoe is de introductie verlopen? Is het scrumproces gelijk helemaal ingericht? P: we hebben een bord met briefjes, daarop staan de user story's. We hebben eenbacklog en een product backlog. Er is een product owner en een scrum master. We doen planningsessies en schatting sessies en een retrospectief. Dat was vanaf het begin

| Page 84 |


al, we houden een burndown chart bij. Wat we niet zo goed doen is het bijhouden wat de focus factor in de afgelopen sprint is geweest. O: wat bedoel je daar precies mee? P: wat was de initiële schatting en wat is de uiteindelijk bestede tijd aan een functionaliteit. Als je dat goed gaat doen kun je op een gegeven moment een focus factor voor het hele team gaan berekenen. Of voor individuele teamleden, dan kun je dit gaan vergelijken met user story's van vergelijkbare omvang. Eigenlijk is dat ook het doen van scrum, niet dat je het alleen in sprints doet, maar ook een soort feedback krijgt van het gedaan? Dan kun je dit weer verbeteren, zodat je uiteindelijk voorspelbaar wordt O: kun je sprints over het algemeen helemaal afronden? P: dat hangt er een beetje vanaf, we hebben nu net sprint 26 gehad deze is gestopt. Dit omdat er zoveel extra requirements kwamen, dat slaat nergens meer op. We hebben toen besloten om de lopende Story's af te maken, en er dan niet stoppen. Sprint 25, dat was de sprint hiervoor, daar kwamen derequirements eigenlijk uit voort. Dit was functionaliteit voor Carglass. De deadlines werden zo kritisch, dat we hebben besloten om het hele proces los te laten. O: maar dit kwam omdat de deadline voor het einde van de sprint lag? P: ja, maar ook tijdens de sprint kwam er een hele hoop werk bij. We hebben toen bewust het proces even helemaal losgelaten. Ik weet niet of dat goed is of slecht. O: maar dit had als doel om toch de deadline te halen? P: dat is wel redelijk gelukt, door het hele proces los te laten verdwijnt er veel overhead is er meer tijd voor ontwikkeling. Het schrijven van user story's en inschattingen laten we dan weg. Het werk naar aanloop van de sprint en na de sprint verdwijnt dan grotendeels. Dit is ook waar hij het meeste last van hebben, dat er geen goede user story's zijn. Je kunt dan ook moeilijk zeggen: we starten de sprint niet want er zijn geenuser-story's. Dan zit iedereen met de armen over elkaar. Dit brengt wel een bepaalde risico met zich mee, het is wel goed gegaan. Het is een beetje de vraag, ga je eerst goed specificeren wat je wilt hebben of niet. Het werken zonder scrum ging niet helemaal ongestructureerd, we hadden wel wat opgeschreven. Het was toen gewoon heel lastig om de planning van de klant te mappen de planning van de sprint. Bijvoorbeeld sprint 23 en 24 zijn heel netjes verlopen. Toen hebben we gewoon alles gehaald, wel hebben we toen heel veel discussie gehad over wat nu precies de

| Page 85 |


functionaliteit worden en ook hoe de functionaliteit technisch toegepast moet worden. Daardoor begonnen de planningsessies heel lang te duren, dit waren middagen lang en dan de volgende dag weer. Dat was echt niet leuk. Dan ben je alleen maar aan het praten over wat er moet worden, zonder dat je iets aan het doen bent O: was je dan ook echt derequirements aan het opstellen? P: nee dat niet echt, maar wel om ze helder te krijgen en ze technisch toegepast moeten worden. Daarnaast was het soms ook functioneel niet helder. De functioneel consultants schrijven de user story's, wat we nu tegenwoordig doen is dat enkele techneuten vooraf bekijken hoe dit technisch opgelost moet worden. Dit gebeurt in de weken voordat sprint start, dan is de user story al enkele keren besproken. Op deze manier kunnen we dit makkelijker in het team brengen. Dit zorgt voor een betere vulling van de sprint, de requirements zijn dan een stuk duidelijker en er is minder risico dat er iets over het hoofd is gezien. Dit vereist wel dat de user story's helder zijn en dat je weet wat je voor een klant gaat doen. Maar dit is wel lastig, in sprint 26 dachten we dat we alleen aan het product gingen werken, dus alleen verbeteringen zouden doen. Maar in sprint 25 hebben we een snelle tijd voor een klant toegevoegd, daar kwam tijdens sprint 26 nog heel veel feedback op van de klant. Dit was ook gebonden aan commerciële afspraken, dan ontkom je er niet aan hier iets aan te doen O: wat vind je jezelf van? Het zijn toch wel grote verstoringen? P: dat klopt ja, ik reageer daar ook niet enthousiast op, maar aan de andere kant vind ik het ook wel prettig als er elke maand salaris gestort wordt. Dat proces helpt als je zo nu en dan ook eens iets doet voor een klant. Wat er ook moet gebeuren is dat de commerciële afspraken met de klant op een wat langere termijn gemaakt worden. Deze moeten helder en eerlijk gemaakt worden. In dit geval was de deadline 1 oktober 2012 en dat wist iedereen. We dachten ongeveer eind december klaar te zijn. Hier zijn gewoon slechte afspraken gemaakt met de klant O: maar scrum heeft ook als doel om snel te kunnen reageren op wijzigingen bij de klant? P: klopt, maar dan moet je wel met de klant afspreken dat je volgens scrum werkt. Moet dan ook de inhoud van de sprint afstemming met de klant en na elke sprint een oplevering doen. Bij die klant is er toen in maart iets verkocht met als deadline 1 oktober. Toen hadden we in maart al het idee dat het krap was, maar uiteindelijk zijn we pas in augustus begonnen met het werk

| Page 86 |


O: dus de klant wensen zijn dan niet goed afgestemd op scrum? P: nou ja, we doen geen scrum met de klant, we doen alleen intern scrum. We proberen allederequirements van de klanten in de sprints onder te brengen. Maar als je dan heel veel functionaliteit beloofd aan een klant die op 1 oktober klaar is. Er zijn ook wel vaker deadlines die midden in een sprint vallen. Moet eigenlijk wel met de klant communiceren dat je scrum gebruikt. O: maar zal er dan iets voor te zeggen zijn? P: ja, maar je hebt natuurlijk specifieke klanten en je algemene productontwikkeling. Daar zitten wel spanningen. Wat er heel veel gebeurt is dat er functionaliteit wordt verkocht met een deadline. Dat is op zich ook goed. Eigenlijk zou je dan met de klant af moeten spreken dat je scrum gebruikt en in welke sprints de functionaliteit gemaakt gaat worden. Maar je weet dan niet wat de klant precies gaat krijgen, wel wanneer. Dit geeft een stukje onzekerheid naar de klant toe. O: dus de klant weet nu niet dat wij met scrum werken, of wat scrum behoudt is? P: ja, dat zou kunnen. De klant is in die zin in elk geval geen onderdeel van het proces. Maar in principe is de product eigenaar de vertegenwoordiger van de klant en deze zorgt ervoor dat productbacklog is ge sorteert op dat geen wat belangrijk is. Het probleem met scrum is, dat je niet precies weet wat er op welk moment klaar is. Je vult alleen sprints met user story's en aan het einde van de sprint levert je een werkbaar product op. Als je het dan goed zou willen doen, zou je dat met de klant af moeten spreken. Maar een klant hoort veel liever; als je betaalt, dan is het over een half jaar klaar. O: ja oké, maar je zou natuurlijk kunnen zeggen over zes sprints is het klaar, dat is dan over een half jaar P: ja wel, maar zover kijk je niet vooruit. Dat zou dan weer veel op een waterval methode lijken O: dus samengevat is het eigenlijk zo dat bepaalde commerciële afspraken scrum in de wielen lopen P: ja, je zou er eerlijk over moeten communiceren denk ik, dat je zo werkt. Maar je hebt natuurlijk een product, je werkt niet altijd voor een klant. Daarnaast past het ook niet bij scrum om te zeggen: over een half jaar is het klaar. Ik kijk juist maar een maand vooruit

| Page 87 |


en reageert dan op feedback en wijzigen. Bij projecten is het vaak zo dat de oplevering later is dan gepland en de functionaliteit tegenvalt. Dit is met scrum niet anders. De voordelen zijn dat je iteratief bezig bent, en sneller kunt reageren op veranderingen en dit kun terugkoppelen naar de klant. Je kunt de klant ook vaker functionaliteit laten zien en alvast laten testen O: maar dit tussentijds op te leveren aan de klant is iets wat momenteel niet gebeurt of wel? P: op zich, de releases leveren we wel uit naar de klant en deze gaan ze ook testen en dit gebeurt ook na iedere sprint. O: ik haal uit je verhaal dat je voornamelijk voor een klant bezig bent, je levert dan alleen op naar deze ene klant? P: nee, we leveren ook op naar enkele andere klanten. In principe hebben we een product dat we op kunnen leveren naar al onze klanten. O: krijg je daar dan goede feedback op als je na een sprint een opleving doet? P: dat verschilt. In principe is het al een beetje van ons ontkoppeld. De functioneel consultants doen derequirements, sommige klanten daar weer weten wij niks van. Er zijn enkele klanten die hebben gewoon het standaard product gekocht, daar zijn geen specifieke aanpassingen voor geweest. Er komen natuurlijk wel issues terug van deze klant die opgelost moeten worden. Vanaf het ontwikkelteam is er wel een redelijke afstand tot de klant, de functioneel consultants zitten dichter bij de klant. Zij moeten het proces van de klant vertalen naar het product, dus het product zo configureren dat het proces van de klant er in onder te brengen is. Zij moeten dus veel meer van de klant weten O: maar vind jij dat de klant nog veel meer betrokken zou moeten worden bij de ontwikkeling van het product? P: ik denk dat het momenteel wel werkt, maar intern moeten we eerlijk zijn over de hoeveelheid werk die in een sprint gedaan kan worden. In sprint 25 zat een hele hoop functionaliteit, hiervan heb ik vanaf het begin gezegd dat dit niet haalbaar was, dat krijg je niet voor elkaar in vier weken. Vervolgens is dat eigenlijk nooit veranderd en ook niet in de communicatie naar de klant

| Page 88 |


O: maar waarom wordt dat dan toch doorgedrukt? P: het komt erop neer, dat ze dit niet tegen de klant durven te zeggen, dat de oplevering later wordt. Daarnaast is het ook zo: als jij degene bent die tegen de klant zegt dat het later wordt, dan krijg je daar ook van de schuld. Vaak zitten er in een project ook afhankelijkheden, waardoor er dan voor gekozen wordt om nog even niks tegen de klant te zeggen te hopen dat een andere partij steken laat vallen, waardoor je weer extra tijd wint. Op zich is dit wel een normaal en begrijpelijk spel, maar aan de andere kant moet het ook geen gewoonte worden. Ik heb er wel begrip voor, als je tegen klant zegt dat de deadline een half jaar verschuift, dan loop je wel het risico dat de klant zegt: ik ga naar een ander. Dat wil je ook niet. Dat is altijd een lastige wisselwerking. Er moet wel een moment komen waarop je wat eerlijker naar de klant toe wordt. Maar dat is voor mij makkelijk praten, ik hoeft het niet te doen. O: wat je vaak ziet is dat het scrum proces wordt aangepast aan de organisatie. Kun je daar wat voorbeelden van? P: het meten doen we momenteel. Dus het bepalen van hoeveel tijd aan een bepaalde functionaliteit is besteed. Dat willen we wel weer gaan doen. Waar we nu mee zitten is dat de samenstelling van het team heel erg wisselt, waardoor inschattingen sowieso niet goed kloppen in verband met inwerktijd. Voor nieuwe mensen is het lastig in te schatten hoe snel ze werken. Dat maakt de waarde van het meten minder waardevol. We hebben het wel een tijdje toegepast, maar ik weet niet precies wat daar de resultaten van waren. De laatste tijd hebben we de planning wat meer wat ad hoc gedaan, eerder deden we nog wel eens planning poker. Met van die kaartjes met waarden erop. Het probleem daarmee was, dat de geschatte uren nogal uiteen liepen, vooral omdat de scope niet duidelijk was. Er is nu een persoon die de inschattingen doet. Dat is vooral omdat we nu in de voorbereiding heel erg achterlopen, dan moet het allemaal snel. Dan kunnen we tenminste weer aan het werk. De architecten doen de inschattingen. Ik denk niet dat dit de beste manier is, uiteindelijk zal het hele team dit moeten doen. Dit is niet alleen voor de inschattingen, maar ook dat het hele team op de hoogte blijft en dat de teamleden deuser-story's allemaal een keer gezien hebben, dit werkt makkelijker als er aan de sprint wordt begonnen. O: is het inschatten dan zo intensief? Voorheen deden wel met het hele team?

| Page 89 |


P: dat kon wel eens dagenlang duren, als je dat per taak doet. Een user story bestaat uit 20-40 taken, in een sprint zitten ongeveer drie à vier user-story's. Dit komt ook vaak omdat je discussie krijgt tijdens het inschatten over wat functionaliteit precies moet zijn. De user story's zouden dan weer beter gedefinieerd moeten zijn. De vraag is echter of je die discussie moet voeren met het hele team. Momenteel is het zo dat we met drie technische mensen en de functioneel consultants de-user-story doornemen en technisch verduidelijken. Dit maakt het inschatten een stuk makkelijker en er komt minder werk terug uit de sprint. Daarnaast zijn er ook verschillende zaken die het inschatten kunnen bemoeilijken. Als je functionaliteit hebt die je vaker hebt gemaakt, dan kun je nieuwe functionaliteit daaraan relateren. Als je met zaken bezig bent die volledig nieuw zijn, dan wordt het inschatten een stuk lastiger. Ook het werken met nieuwe mensen maakt het lastiger om in te schatten. Deze zijn onervaren met het product en soms ook met de gebruikte technologie. Een schatting sessie met het hele team heeft dan alleen waarde voor kennisdeling. O: wat vind je van de huidige team grootte? P: die vind ik wel goed. Misschien is het wel iets aan de grote kant, de grote is nu tussen de acht en 12. Als iedereen op stoom is dan is het denk ik een vrij groot team. We zijn nu nog aan het groeien en aan het in leren, dan gaan we niet zo hard en hebben mensen elkaar meer nodig. Over een half jaar zal dit misschien wat te groot kunnen zijn O: wat is het probleem van een te groot team? P: dan is het overzicht weg en is het moeilijker te hanteren. Ik denk dat mensen dan sneller uit het werk gaan lopen en dat je dat niet in de gaten hebt. Dan zou je misschien beter twee scrumteams van vijf personen kunnen maken. Het is moeilijk in te schatten, op het moment is het nog niet nodig. Het ligt er ook een beetje aan hoe je je functionaliteit kunt splitsen, bijvoorbeeld PA ontwikkeling en BackOffice. O: dat is nu toch ook het geval? P: ja klopt, maar het hangt altijd wel met elkaar samen, daarom is het moeilijk om het op te splitsen. O: hoe gaan jullie nu om met onderhoud issues? Is dit een aparte rol buiten het scrum proces?

| Page 90 |


P: dit draait niet mee in het scrum proces. Wat we nu doen is dat ze één of twee personen vrijmaken in het team, die houden zich puur en alleen met onderhoud bezig. Op het moment hebben we zoveel onderhoud, dat deze capaciteit ook constant nodig is. De op levermomenten voor bugs loopt apart van scrum. Dat werkt veel meer ad hoc. De rol voor onderhoud wisselt ook per sprint. Dit bevalt nog niet zo heel goed, ik zou liever meer ruimte in de planning hebben en dan ad hoc beslissen wie er aan een issue werkt in een sprint. Er zijn ook mensen die aan andere producten werken ledig voor een sprint inzetbaar zijn. O: Vind er nog een kruisbestuiving plaats tussen SLE en SFM? P: niet heel erg. Toen Martijn scrum master werd voor SLE heeft hij een overleg gepland tussen SFM en SLE. Om te kijken hoe bepaalde zaken liepen. Echt gestructureerde feedback tussen teams is er niet. Ik heb het mij wel eens voorgenomen om bij meetings van andere teams te gaan zitten, maar dat is er nooit van gekomen. O: SLE is wel eerder begonnen met scrum dan SFM. Is daar nog een bepaalde basis van over genomen? P: ja wel een Excelsheet voor de backlog. Dat gebruiken we van elkaar, maar verder is er weinig. O: en met betrekking tot derequirements, als daar niet genoeg aanvoer is wat is daar dan doorgaans de reden van? P: de functioneel consultants die de user story's moeten schrijven, zitten grotendeels ook bij de klant en geven ook ondersteuning bij verkooptrajecten. Daardoor komen ze niet toe aan de user story's, de sores bij de klant is altijd veel belangrijker. Daarnaast zijn er ook mensen die belangrijk werkt aan de specificatie, voornamelijk technisch. Dat vormt nog wel eens een bottleneck. Het heeft dus vaak te maken met prioriteiten. Als je ervoor kiest om een nieuw consultants mee te nemen naar verkoopgesprekken, dan kunnen ze dus geen user story schrijven O: wat gebeurt er als er niet genoeg user story zijn, je gaf al aan dat je moeilijk met je armen over elkaar kunt gaan zitten? P: meestal is er wel een summiere beschrijving, deze gebruiken we dan als basis met bepaalde aannames. De kwaliteit daarvan is wel minder, je merkt dan ook dat er onduidelijkheden tijdens de sprint gaan staan en dan is de sprint veel minder efficiënt.

| Page 91 |


Dit betekent ook dat de functioneel consultants dan tijdens de sprint. User story moet gaan verduidelijken.

9.5.4 PRODUCT OWNER O: zou je even kort toe kunnen lichten wat je momenteel bij-Sigmax doet? A: ik ben product eigenaar van FMS. Dit is een gedelegeerde taak. Ik verzamel de wensen van klanten en geef deze een prioriteit. Mijn belangrijkste taak is om mij enerzijds te bemoeien met de road map. Wij hebben onze road map in Trello staan. Daarnaast houd ik de productbacklog bij. Daar staan alle verbeteringen in van technisch tot onderhoud tot functioneel. Vervolgens wordt aan de hand van de productbacklog de sprintbacklog gemaakt, dit gebeurt met de scrum master, de projectleiders en ik. Één keer in de twee weken zitten we om tafel om dit te bekijken. Daarin wordt bepaald of scherp hebben wat er opgeleverd moet worden en wat er in de eerstvolgende sprint komen. Dan zijn er vervolgens een heleboel stappen in de ontwikkeling waar ik minder bij betrokken ben. Alleen na de uitrol kom ik weer in beeld met de helpdesk afdeling. O: kun je iets vertellen over de geschiedenis van scrum bij-Sigmax? A: toen ik bij-Sigmax kwam werken, werd er al scrum toegepast bij City Control. Binnen SFM werd er totaal niet ge scrumt. Dat was grofweg de situatie. Toen heb ik met een aantal mensen het proces doorgesproken, want ik wilde eigenlijk wel graag scrum toepassen. Toen hebben we de procesflow opgesteld en wat procesbeschrijvingen gemaakt. Dat is de eerste stap geweest. Kwamen er twee dingen samen. Het product moest gedefinieerd worden, daar heeft Guido werk verricht. Er was op dat moment alleen maatwerk en geen product. Er is toen een basis gemaakt, daar zijn allerlei modules aan toegevoegd. Met het bouwen van die modules zijn toen van start gegaan door het vullen van de sprints. Dat viel samen met het feit dat Wim binnenkwam, hij was projectmanager en is gestart met scrum. Van de een op de andere dag is hij daarmee begonnen. O: maar waarom werd scrum toegepast? Waren er bepaalde problemen? A: hele goeie vraag. Ik ben bang dat wij gestart zijn met scrum om het scrummen. Ik denk dat er wel problemen waren waar scrum wel goed voor uitkwam. De ontwikkelaars hadden heel veel last van wisselende prioriteiten en verstoringen. Dat was wel een heel groot probleem. Er zat veel te veel dynamiek in de groep, dat kwam door alle storingen meldingen die binnenkwamen. Ik had toen al de wens om ontwikkeling en onderhoud los te trekken. Dus dat kwam wel goed uit, laten we

| Page 92 |


vaststellen wat het ontwikkelteam in de komende periode gaan doen. Dat dat scherp is, en onderhoud zit daar dan niet bij. We hadden ons voorgenomen om scrum te gebruiken, omdat het zich in de praktijk heeft bewezen. We probeerden er niet een specifiek probleem mee op te lossen, anders dan het verstoringen probleem. Want dat was wel heel groot. Toen zijn we gewoon begonnen O: is het bij de introductie volledig toegepast, met alles erop en eraan? A: ja. Er is een lijst metuser-story gemaakt voor het team. Er is dus een product backlog en een sprintbacklog gemaakt. We zijn begonnen met een sprintlengte van vier weken, dat is nu nog steeds zo. O: is er momenteel een scrum team of zijn er meerdere? A: er zijn nu twee projectteams. Er is een liftteam en een scrum team. Voor-FMS is er een scrum team. Het lift team werkt niet volgens scrum. Ze zijn wel betrokken bij de dagelijkse meetings. Het liftteam bestaat in totaal uit drie man. O: dat is eigenlijk te klein om scrum toe te passen. Of denk jij daar anders over? A: persoonlijk ben ik wel overtuigd geraakt van scrum, geval voor je interne organisatie. Laat ik het zo zeggen: scrum is wat je doet als je geen proces hebt en je in een crisis geraakt. Ik heb het in het verleden gezien, dat je een traditioneel watervalproject probeert te draaien. Op een gegeven moment loopt het project dan niet goed. Dan ga je elke ochtend even kort bij elkaar zitten, om elkaar op de hoogte te houden. Je gaat dan automatisch alles wat je niet per se hoeft te doen weglaten en dat is scrum. Voor mij is scrum een Lien proces, je gaat dan heel effectief werken. Je gaat niet bouwen wat de klant niet wil hebben en je laat documentatie zoveel mogelijk achterwege. O: OK duidelijk. Vaak zie je dat het scrum proces aangepast wordt aan de organisatie, heb jij daar voorbeelden van? A: ik denk dat scrum veel open einde laat. Wat ik daarmee bedoel is dat scrum volgens de definitie een project management framework is. Scrum kun je een project managen. Het zegt niks over welke ontwerp methodiek je volgt. In die zin is het ontwikkelteam vaak nog wel helder: het doel is om functionaliteit toe te voegen aan de hand van de gestelde requirements. Feitelijk heb je eigenlijk twee scrumteams, het team dat de uitvoering doet en het team dat de-user-storys maakt. De klant kan wel zeggen: ik wil een uren registratie module, maar voordat je daarmee aan de slag kunt moet je eerst een user story maken. User story moet dan nog gereviewed worden en noem maar op.

| Page 93 |


Dat red je niet in de opstart van de sprint. Vaak zie je dat eenuser-story uit twee delen bestaat, het ene deel is de wat vraag en het andere deel is de hoe vraag. Als je de wat vragen hebt beantwoord, dan gaat het team zich automatisch afvragen hoe het dan geïmplementeerd moet worden. Onze ervaring is dat als een functioneel consultants een user story maakt, dat er dan op een gegeven moment een punt komt waarbij er inmenging nodig is van een techneut. Deze kan dan meer informatie verschaffen over de hoe vraag. Hoe moet het technisch geïmplementeerd worden. Dit maakt het makkelijker in te schatten. Dus er komt dan een technisch ontwerp in de user story, zodat het hele plaatje compleet is. Dit moet allemaal uitgezocht worden voordat hetontwikkelteam ermee aan de slag gaat. Dus daar hebben wij onze eigen smaakje van scrum te pakken O: het requirements proces is dus een scrum proces? A: jazeker. O: werkt dat dan op dezelfde manier als het ontwikkel scrum proces? A: de productbacklog wordt gedeeld en dus gebruikt voor de ontwikkeling en derequirements. Op de productbacklog staat een kleine omschrijving en toelichting van de klant wens. Op basis daarvan weten de functioneel consultants wat er wanneer klaar moet zijn, maar er wordt niet gewerkt met vaste sprints. Het is dus wat minder strak geregeld. Er staan dus items op de productbacklog die al uitgewerkt zijn en die nog niet uitgewerkt. De items die uitgewerkt zijn, kunnen naar de ontwikkel sprint. De nog niet uitgewerkte items, daar moeten nog user-story's van gemaakt worden. O: en wat wordt er precies onder eenuser-story verstaan? A: het is vaak een combinatie van beschrijving, voorbeelden, technisch en functioneel ontwerp. Een user story kan zowel een technische verbetering zijn als een functionele toevoeging. O: en het verzamelen van de requirements, gaat dat in nauwe samenwerking met de klant? A: ja, de functioneel consultant verzameld user story's in zijn project. Het startpunt is daarbij de offerte en het projectplan, daarna gaat de functioneel consultants gesprek met de klant over de exacte afstemming.

O: komende-user-story's ook bij de klant terecht?

| Page 94 |


A: nee, de klant wordt alleen bevraagd en geïnterviewd en vervolgens wordt er een user story opgesteld die alleen voor de functioneel consultants en het team is. De klant krijgt alleen de functionele beschrijving en niet de volledige user-story. De functioneel consultants bespreekt op hoog niveau met de klant wat er moet komen, dit is de basis voor het uitwerken van meerdere user story's. Deze worden functioneel uitgewerkt en daarna volgen er nog technische toevoegingen hoe dit precies geïmplementeerd moet worden. Dus de discussie met de klant is er zeker, maar niet alles wordt terug gekoppeld. O: is er dan naar de sprint wel een terugkoppeling naar de klant toe? A: nee, dat zou natuurlijk wel moeten. Wat we vaak zien is dat er een demo wordt gegeven door het ontwikkelteam aan de functioneel consultants en de projectleiders. Die laatsten vormen dan een vertegenwoordiging voor de klant. Volgens de letter van scrum is dat niet de bedoeling en ook in de praktijk is het niet goed. Want wat je ziet is typisch: als wij denken dat we klaar zijn en zetten het neer bij de klant, dat er dan toch nog wat dingen naar voren komen die niet goed doordacht zijn O: wat is dan de reden dat er alleen intern een demo wordt gegeven en niet naar de klant toe? A: het is misschien wel het idee of de illusie dat functioneel consultants weet wat de klant heeft en wil. Met andere woorden: de klant zit aan tafel in de vorm van functioneel consultants. Maar dat is niet helemaal hetzelfde. Een andere reden is toch heel plat: dat je iets te veel openheid biedt aan de klant. Tijdens zo een demo komen er nogal wat technische aspecten voorbij, de demo wordt opgegeven door het ontwikkelteam. Mijn gevoel is dat je daar onbedoeld duidelijkheid kan geven naar een klant vanuit het ontwikkelteam. Vaak moet het geen tijdens een demo verteld wordt, nog commercieel vertaald worden naar de klant. Niet dat we de klant aan het bedonderen zijn, maar er zitten gewoon keuzes in die je als klant wellicht anders gemaakt zal hebben. Je had iets dan heel luxe kunnen maken, maar gezien het feit wat de klant ervoor betaald heeft is het op deze manier implementeert. O: OK, maar je ziet toch dat de succesfactor van scrum is het samenwerken met de klant, maar dan zijn er toch nog commerciële invloeden openheid naar de klant bemoeilijken. Daarnaast is het ook zo dat in die tijd gemaakt wordt van meerdere klanten. A: Klopt, als je dan dusdanig openheid geeft, dan zegt die klant: maar je bent afgelopen sprint met functionaliteit voor een andere klant bezig geweest, dat was niet de

| Page 95 |


bedoeling. Maar ik ben er wel heilig van overtuigd dat het merendeel van de projecten misgaat op onduidelijkerequirements. Ik geloof 30% van de projecten. Maar je wilt geen openheid over hoe je je capaciteit verdeeld over verschillende klanten. Het zijn de commerciële belangen. Het is met name de commercie hier in de weg zit. Het grootste probleem zit in de tegenstrijdige belangen. O: we hebben het er al even over gehad, de requirements als een apart proces naast scrum of onderdeel van scrum. Hoe zijn de sprint momenteel gevuld voornamelijk met nieuwe functionaliteit of ook onderhoud? A: goeie vraag. Ik zie daar een kleine verandering, hoe hebben we lange tijd geacteerd: we hebben geacteerd vanuit het principe: nieuwe ontwikkelingen doen we in scrum en onderhoud doen we weliswaar in hetzelfde tempo, maar dat doen we door dedicated onderhoud medewerkers. Doordat je dit in hetzelfde tempo doet, kun je wel medewerkers wisselen tussen onderhoud en de scrum sprint. Dat je tijdens de sprint dedicated medewerkers hebt voor onderhoud. Er zit wel een essentieel verschil in, omdat onderhoud bugs vaker uitgeleverd worden dan één keer per sprint. Dus we proberen wel om de opgeloste bugs zoveel mogelijk mee te laten gaan in de reguliere releases. Maar soms moeten dus gewoon sneller. Tweede ding is: als je een nieuwe module ontwikkeld en die neerzet bij de klant, dan kun je er donder op zeggen dat de issues daarna omhoog gaan. Vooral in het begin gaat dit pieken. Dat gegeven proberen we een beetje te cultiveren, door te zeggen: misschien moeten we dan maar in de sprint rework gaan faciliteren en dit onderscheiden van onderhoud. Dus als ik een nieuwe module hebben oma dan moet deze eerst geaccepteerd worden door de klant. Een formele acceptatie doen meestal niet, maar deze is niet zaligmakend. Dus het werk dat komt uit de oplevering van nieuwe modules, wordt gepland in de volgende sprint. O: wat is momenteel de verhouding tussen onderhoud en nieuwe functionaliteit in de sprints? A: een goeie. In totaal hebben we acht ontwikkelaars in het scrum team en twee man op onderhoud. Het onderhoud is dus 25% O: bevalt deze team grootte? A: dat bevalt goed, het team lijkt heel groot, maar netto zijn er vier man continu bezig met nieuwe functionaliteiten. O: je hebt niet het idee om het twee aparte scrum teams van te maken?

| Page 96 |


A: nee, we hebben een scrum team. Er is wel een apart list team, deze werken nog zonder scrum, dit is een geheel nieuwe ontwikkeling. Als deze ontwikkeling op de tablet wat volwassener is, dan zouden ze mee kunnen gaan draaien in het scrum team O: en zijn er nog aandachtspunten bij de aanvoer van requirements voor de scrum? A: die heb ik al een beetje belicht. Er is vaak ook technische diepgang nodig, alleen een functioneel consultants er naar laten kijken is niet genoeg. Je moet meer diepgang hebben. En te vaak gaan errequirements onduidelijk de sprint in. Weet je wat nog een aandachtspunt is? Een belangrijk aandachtspunt is dat wij geen budgetten meegeven aan user-story's. Als je een projectmanager vraagt hoeveel mag een mobule kosten, dan kan hij daar geen antwoord op geven en waarom kan hij daar geen antwoord op geven? Omdat alles op één hoop gooit wordt in de offerte, in de offerte staan alleen maandelijkse licentiekosten. Dan heb je twee situaties: een is dat de functionaliteit er al is en de andere is dat de functionaliteit er nog niet is en dat het gemaakt moet worden. Als het gemaakt worden zijn er nog twee mogelijkheden. Namelijk het is maatwerk of het is een productverbetering. Het probleem met productverbetering is dat je deze voor meerdere klanten maakt. Dus hoeveel mag die functionaliteit dan kosten? O: en wat levert dat voor problemen op? A: als een klant iets snel wil hebben, dan is dat de motivatie om het snel op te leveren en dus zo goedkoop mogelijk te maken. Maar als de klant geen haast heeft, hoe beperk je dan het aantal uren dat aan deze functionaliteit wordt besteed? Zowel voor de user story als voor de technische implementatie? Daar zit nogal een uitdaging O: ondertussen schoot mij nog een vraag binnen: de functioneel consultants voor-FMS hebben allemaal een project management achtergrond, terwijl de functioneel consultants voor City Control allemaal een technische achtergrond. Wat is de gedachte hierachter? A: klopt dit is een hele bewuste keuze. Eerder was projectmanager en functie consultants een gescheiden rol. Het was dus zo dat de projectmanager en de functie consultants naar de klant ging. Hierdoor hoeft de projectmanager veel minder diep in het project te zitten en raakt daardoor het gevoel met het project kwijt. Daarom hebben we dit in een rol gecombineerd. O: maar dan zijn er toch ook tegenstrijdige belangen?

| Page 97 |


A: tuurlijk. De druk op projecten is groot, dus als je dat moet combineren zit daar wel spanning. Maar dit weegt wel op tegen de voordelen. Bij-City-Control is de situatie anders, omdat het product verder doorontwikkeld is en er vanuit de gemeente bepaalde zaken wettelijk vastgelegd wat de werkwijze is. Dit is bij-FMS niet het geval

9.5.5 SCRUM MASTER O: kun je kort vertellen wat je bij-Sigmax doet? P: ik ben nu ruim een jaar de scrum master voor cc vijf. Dit betekent dat ik de sprints voorbereid samen met de product eigenaar. Dus zoveel mogelijk faciliteren dat de user story's in sprints komen, daar komt het allemaal op neer. Bij-City-Control hebben we een aantal jaren gehad dat er constant nieuwe functionaliteit werd toegevoegd, dit leek niet op te houden. We komen nu in een fase dat we meer onderhoud en minder nieuwe functionaliteit. Dit komt omdat we nu bezig zijn met cc zes, hier komt alle nieuwe functionaliteit in. Daarvoor staan bakken werk klaar om toe te gaan voegen. Dit wordt een mega uitdaging, daar hebben we in 2013 nog heel veel te doen. Het cc en team wordt nu afgebouwd, er zijn al een aantal mensen over naar cc zes. De laatste twee à drie sprints zitten we echt in de onderhoudsmodus. Af en toe zit er nog nieuwe functionaliteit tussen, maar het is nu voornamelijk stabiel en afmaken. Dit zodat iedereen zo snel mogelijk over kan naar cc zes.bij cc zes is men eigenlijk net gestart met scrum, daar doet men voornamelijk de dagelijkse stand ups. En volgende week start de eerste sprint voor cc zes daar ben ik ook de scrum master voor. Ik zie nu verschillende problemen woon op kunnen lossen door het toepassen van scrum. Daar ben ik nu mee bezig om daar heel veel nieuwe dingen op te gaan zetten. Het is ook belangrijk om de rollen duidelijk te krijgen. O: misschien kun je wat vertellen over de geschiedenis van de toepassing scrum bijSigmax? P: ik ben een van de promotors van scrum geweest. Ik werk nu ongeveer vier jaar bijSigmax en in het begin zag je dat er een behoorlijk groot ontwikkelteam was. Op dat moment het grootste ontwikkelteam bij-Sigmax met zes ontwikkelaars en wat we daar toen deden was eigenlijk alleen maar maatwerk realiseren. Dit gebeurde in allemaal losse componenten en losse releases die we ook weer los uitleverden. Er was geen enkele samenhang en ook geen enkele vorm van planning. Het was heel veel overwerken en balletjes in de lucht houden geen enkele structuur. In die tijd was het ook zo dat de sales mensen bij de ontwikkelaars aan het bureau stonden: zo van, waarom werk jij hier niet aan? Het was redelijk chaotisch, en toen heb ik gezegd: hier

| Page 98 |


moeten we wat aan veranderen. Ik had daarvoor al een jaar lang in een scrum team gewerkt. Ik heb geprobeerd om het op de agenda te zetten, het probleem was dat nog niet iedereen het wilde. Op een gegeven moment hebben we doorgezet. C en ik hebben een cursus gedaan, C was toen de teamleider. Na verloop van tijd ben ik de teamleider en scrum master geworden. Toen hebben we de boel in geregeld en normaal gesproken moet het na twee à drie sprints goed lopen. Waar we toen vaak tegenaan liepen was dat we vaak nieuwe dingen gingen doen die heel onzeker waren. Vaak waren er nieuwe ontwikkelingen, zoals het generiek opzetten van koppelingen. Wij gingen dat dan als eerste doen als team binnen -Sigmax . Dit heeft ervoor gezorgd dat sprints heel vaak niet gehaald werden. Afgelopen kerst is de eerste keer dat we sprint hebben gehaald volgens mij, in anderhalf jaar tijd, dat is dus niet handig. Toch zijn er ook heel veel voordelen geweest O: maar hoe komt dat dan? P: ja, door veel onzekerheden en doordat de requirements niet duidelijk waren en door druk van klanten toch functionaliteit toevoegen aan een sprint terwijl deze niet duidelijk was. Onder hoge druk hebben toch te vaak zaken toegevoegd die niet duidelijk waren. We zijn ook steeds meer afgestapt van maatwerk en meer gaan product denken. Dat werd wel zijn vruchten af O: maar hoe komt het dan dat de requirements beter zijn geworden? Komt dit doordat de rol van functionele consultants is toegevoegd? P: dit is eigenlijk een rol die buiten het scrum proces is geplaatst, dit betekent dat de functionele consultants allerequirements uitwerkt voordat de sprint begint en dat deze dus duidelijk gespecificeerd sprint in kunnen. Daar is eerder nogal wat misgegaan, en verder hebben we nog twee nadelen. Cc heeft een hele oude code base er is nooit iets aan architectuur gedaan, code is een grote chaos. Inmiddels zijn er al wel verschillende zaken verbeterd. Alles werd door elkaar heen gebruikt, het was een grote chaos, dit heeft voor heel veel problemen gezorgd. Dat is gewoon een historie die je meeneemt. Daarnaast hebben we de installeer baarheid van ons product, we hebben inmiddels meer dan 80 klanten. Zie het allemaal maar eens uitgerold krijgen, een uitrol kost ons ongeveer een dag. We hebben ongeveer drie à vier updates per jaar, met 80 klanten betekent dit dat een persoon voltijd een jaar bezig is alleen maar met releases maken. Als je een product hebt dat lastig te installeren is betekent dat dat je daar veel tijd kwijt raakt. Bij-FMS hebben ze daar bijvoorbeeld wel tijd aan besteed, daar kun je veel

| Page 99 |


makkelijker elke keer de Delta testen. Tegen dat soort dingen loop je aan, dat heeft eigenlijk niks met scrum te maken maar met de historie O; maar de introductie van scrum, hoe is dat gegaan? Je zegt net dat bij cc zes scrumpas net ingevoerd is P: cc zes daar heb ik me in eerste instantie helemaal niet mee bemoeit, destijds heeft de projectleider daar vooral veel tijd ingestoken. Deze was echter veel meer fan van de traditionele waterval methode, die hoefde ook niet zo nodig scrum toe te passen . Daarom heeft het ook nog even geduurd voordat het geïntroduceerd is. Er zijn toch steeds veel meer mensen die willen dat wij volgens deze methode gaan ontwikkelen. Ik geloof daar elf ook heel erg in. Bij cc vijf hebben we op een gegeven moment gewoon gezegd dat we scrum gaan invoeren. Dus helemaal volledig ingevoerd, eigenlijk alle facetten op één na en dat is de klant demo. We hebben dat wel een paar keer geprobeerd, maar dat kost teveel tijd. O: maar was dit dan een demo naar de klant of intern binnen de organisatie? P: intern. Demo's bij klanten doen we eigenlijk niet. Dit doen we niet omdat we eigenlijk te veel klanten hebben om bij elke klant demo te gaan geven. Er is op een gegeven moment een visie gekomen waarbij we van project denken na product denken zijn gegaan. Dit betekent dat we geen klant specifieke wijzigingen meer doen, maar alleen functionaliteit toevoegen meerdere klanten kunnen gebruiken. Vooral als meerdere klanten een module kunnen gebruiken, dan krijgt deze al vrij snel een hoge prioriteit. Deze wensen komen vooral bij de klant vandaan, de product eigenaar kiest dan uiteindelijk wat we gaan implementeren. Ik vind dat we dat wel aardig voor elkaar hebben O: maar waar komt deze keuze vandaan? Normaal gesproken betrek je je klant zoveel mogelijk bij de ontwikkeling door vaak functionaliteit op te leveren P: laatst hebben we bij een module deze eerst geïnstalleerd bij een klant. Daar hebben we feedback opgehad, dit hebben we verwerkt en later is deze module ook bij andere klanten uitgeleverd. Maar in sommige gevallen is dit lastig te doen, in veel gevallen weten we ook door onze kennis wat de klant wil. Daarom ga je niet altijd daar klant bij betrekken. Je ziet gewoon dat het erg lastig is als je heel veel klanten hebt om ze echt actief te betrekken. Je krijgt een feedback, en dan moet je ook wat mee doen. Dat is dat wat we dan wel weer doen. Eigenlijk moet je nieuwe functionaliteit altijd bij enkele

| Page 100 |


klanten installeren en vervolgens de feedback verwerken voordat je dit bij alle klanten uitrolt O: je ziet vaak dat het scrum proces aangepast wordt aan de organisatie. Heb je daar enkele voorbeelden van bij Sigmax? P: dan moet ik even kijken. Als ik het zo bekijk dan hebben wij alleen de klant demo weggelaten, maar ik merk toch wel dat daar een sterke behoefte aan is. Je kunt wel een release-Notes maken, maar de afdeling verkoop en op de klant wil het toch graag even in het echt zien. Dat we dat niet doen zie ik nog steeds wel als een gebrek. Omdat we nu vooral onderhoud doen wordt de noodzaak daartoe wel minder. Maar eigenlijk is het de bedoeling dat het team de demo geeft aan de product eigenaar aan het einde van een sprint, maar eigenlijk zijn er veel meer afdelingen binnen-Sigmax behoefte aan Hebben. Als je die allemaal gaat betrekken dan zit je bij een demo ook zo weer met 10 a 15 man. Dan zijn er weer mensen zeggen: is dit nu wel nodig. Wat we daarvoor bedacht hebben is dat we ons product na een sprint installeren in onze demo omgeving. Op deze manier kunnen verschillende mensen het product zelf bekijken. Dat is een beetje hoe dat opgelost hebben, dat werkt goed. Dat is eigenlijk een afwijking die ik zie en verder schatten we niet op punten maar op uren. Dit is met de resource planning makkelijker. Een ander ding waar ik had het voor moeten vechten is dat een ontwikkelaar altijd volledig in de sprint zit. Het is namelijk lange tijd het geval geweest dat mensen nog voor 50% andere werkzaamheden buiten de sprint hadden. Dat werkt gewoon echt slecht. Je moet gewoon mensen hebben die volledig beschikbaar zijn. Vaak wordt er dan gezegd: we hebben een capaciteitsprobleem, dan kan Marco wel twee dagen helpen in de sprint. Dan kun je beter zeggen: dat doen we niet. Want ze krijgen niet alles mee omdat ze ook nog andere werkzaamheden hebben, en als die andere werkzaamheden uitlopen dan komt er een conflict met het werk in de sprint, waardoor deze weer niet afkomt. Het idee van scrum is ook dat je volledig toegewijde mensen hebt, dat is gewoon efficiënter. En wat we verder nog doen is het boeken van uren op een user-story . Dit maakt het mogelijk om na een sprint te bekijken wat een bepaalde functionaliteit heeft gekost en hoeveel overschrijding is geweest. Dit kun je gebruiken om de volgende schatting beter te doen. In de retrospectieve wordt hiernaar gekeken door middel van rapportages. En voor verkoop is dit interessante informatie betrekking tot offertes. Men is er vaak toe geneigd om veel toeters en bellen aan scrum te hangen, maar ik heb dat juist niet gedaan. Gewoon lekker simpel houden. O: de requirements, je zei al dat dat een proces is dat buiten het scrum proces ligt. Kun je toelichten hoe dit normaal gesproken in zijn werk gaat?

| Page 101 |


P: de product eigenaar maakt de-user-story aan op de productbacklog, met wat vage kreten hier en daar en eventueel een offerte die eraan. Dat is globaal wat je als input krijgt. Het ligt aan de grootte van de functionaliteit of er een ontwerp gemaakt wordt, als dit iets is klein is dan gebeurt dit niet. Bij grotere modules wordt er voorafgaand aan de sprint een presentatie gehouden door de functionele consultants, die legt uit wat de bedoeling is en vraagt of mensen nog toevoegingen hebben. Op basis daarvan wordt eenuser-story gemaakt. De grotere brokken liggen bij de functionele consultants en de kleinere dingen bepaalt de product eigenaar. De user story's verwerken we dan in de sprint. Als ik zie hoe ze dit bij-FMS doen, dat vind ik niet verstandig. Ik vind persoonlijk dat het daar doorslaat, ze gebruiken daar sjablonen, daar staat veel te veel in, zowel functioneel als technisch. Dit was zo uitge uitgebreid, je hoeft het alleen nog maar in te kloppen in de code. Dat gaat te ver denk ik, het is niet efficiënt. Alles moet tot op bepaalde hoogte duidelijk zijn en de rest komt dan vanzelf. Dit zorgt er ook voor dat het team meer initiatief neemt en gaat nadenken over de functionaliteit. Hierdoor krijg je een creatieve proces waarin het hele team meedenkt. Daarnaast leg je een stuk creativiteit bij het team neer, als je ontwikkelaars alleen maar gedetailleerde ontwerpen in de code laat inkloppen, dat vindt men niet leuk O: je zei al dat de laatste tijd sprints voornamelijk met onderhoud worden gevuld, wat zijn volgens jou de grootste verschillen tussen sprint met nieuwe functionaliteit of met onderhoud? P: voor onderhoud worden de openstaande bugs gebundeld en samengevat in een userstory. Het grote verschil is denk ik dat onderhoud een veel kleinere impact heeft, het is het aanpassen van bestaande code en nieuwe functionaliteit betreft meestal nieuw code. En waar het voornamelijk de laatste tijd misgaat is het moment dat eenuser-story groter wordt dan 100 uur, stel dat je een storing hebt van 200 à 300 uur dan krijg je heel veel Ongepland werk. Je raakt dan het overzicht kwijt. Agile is eigenlijk dat je iteratief werkt, daarvoor het werk moet opsplitsen in kleine stukken. Daar geloof ik heel erg in het werk opsplitsen in hapklare brokken O: hoe gaat het met de aanvoer van requirements. Is er altijd genoeg sprints mee te vullen? En komt het vaak voor dat user story's niet duidelijk zijn waardoor de sprint niet gehaald kan worden? P: wat we in het verleden niet gedaan hebben is dat we verschillende sprints vooruit gewerkt hebben. We keken alleen naar de volgende sprint niet verder dan dat. Wat ook vaak gebeurde was dat vlak voor het begin van de sprint er vaak nog nieuw werk

| Page 102 |


binnenkwam. Daar had je dan niet genoeg tijd voor om deze goed te bekijken en in te schatten. Dat zie je gewoon direct weer terug in de sprint erna. Eigenlijk moet je zeggen: het is niet duidelijk, we gaan het niet doen. Dat gebeurt nu wel steeds meer. Vroeger waren er situaties waarbij de verkoper tegen de klant zei: als je vandaag tekent dan komt het morgen in de sprint. Dat is ook een kwestie van gewenning bij verkoop, dat dit gewoon niet kan. De product eigenaar kijkt nu ook goed naar de offertes, waardoor dit ook allemaal beter gaat lopen. O: de requirements zijn dus duidelijk geen onderdeel van het scrum proces? P: het speelt zich met name af in de schatting sessies. Er zijn altijd twee schatting sessies. In de eerste schatting sessie gaat de product eigenaar aan het team uitleggen wat er moet komen, dan heb je het eigenlijk overrequirements. In de tweede schatting sessie gaan we dan in detail kijken naar de taken hoeveel tijd deze kosten. En idealiter zou het zo moeten zijn dat elke user story die op de productbacklog wordt gezet, dat het team die 2-3 keer heeft gezien voordat je die toevoegt aan de sprint. Dan pas krijg je eigenlijk een goeierequirements definitie. Er moeten gewoon twee of drie slagen voordat je hem in de sprint stopt. Vaak lukt het ons om onduidelijke requirements tegen te houden maar soms ook niet. O: als je scrum vergelijkt met het begin waren er veel nieuwe functionaliteit was en waar meer onderhoud is, is scrum dan nog steeds wel efficiënt? P: dat hangt er een beetje van af hoeveel mensen nu nog werkzaam bent in je team. Ik vind wel: als je met drie mensen in een team zit dan moet je scrum niet toe willen passen. Dit is nu ook het geval in ons eigen team voor cc vijf. Eigenlijk moet je er dan mee stoppen. Dat gaan we denk ik nog wel doen binnenkort. Minimaal vier fulltime ontwikkelaars beschikbaar hebben scrum toe te kunnen passen. Maar we hebben nu gewoon het proces toegepast en het is een automatisme, het kost dus ook niet veel energie om het gewoon te blijven doen, dus voorlopig houden we dat ook nog maar even zo. Eigenlijk zou je veel beter Kanban kunnen toepassen. Dat is een lichtere variant van scrum, daar heb je ook een plan bord. Dat is veel geschikter als je in een onderhoudsfase zit van het product. O: maar de mensen die onderhoud doen zitten toch niet in de scrum? Zij werken niet volgens een bepaalde methode? P: klopt, we hebben nu twee mensen die fulltime onderhoud doen. Maar zij komen soms helemaal niet toe aan het oplossen van bugs, omdat er zoveel klanten zijn. Toen ik

| Page 103 |


begon als scrum master hadden we 600 bugs op de backlog staan, dat kwam omdat we heel veel nieuwe klanten gekregen en alleen bezig waren met nieuwe functionaliteit. Daardoor stapelden bugs zich op. Intussen zijn ze bijna allemaal opgelost. Dat krijg je als je alleen maar nieuwe functionaliteit bouwt, dan loopt de buglijst hoog op. Dat zorgt er ook voor dat je toch soms tijdens sprints bepaalde verstoringen krijgt door bugs met een hoge prioriteit O: je zegt dat er veel onderhoud in de sprint zit, hoe zit dat dan? Dit werd toch juist buiten de sprint gehouden? P: ja klopt, eigenlijk wordt er buiten de sprint veel analyse gedaan van de bugs, die worden dan vervolgens in de sprint opgelost. We werken nu toe naar het einde van cc vijf, dit zal nog twee à drie sprints duren daarna is het klaar

9.5.6 FUNCTIONAL CONSULTANT O: misschien kun je kort even toelichten wat je bij-Sigmax doet? C: op dit moment ben ik functioneel consultant. Waarbij ik in de praktijk voor 50% meewerken aan de realisatie en ontwikkeling van cc zes. Dus eigenlijk het nieuwe standaardproduct. Dit bestaat uit het schrijven van user story is voor het scrum proces. En de andere 50% vul ik in als consultant bij verkooptrajecten. En dat kan zijn een aanbesteding of een aanpassing op een bestaand product O: het scrum proces. Jij bent daar in het verleden ook in een andere rol bij betrokken geweest. C: voor cc vijf was altijd een ad hoc ontwikkeling. Zo van: als het vandaag niet klaarkomt dan wordt het wel morgen. Op een gegeven moment is de overgang gekomen naar scrum. We wilden een agile methodiek toepassen om de software ontwikkeling te structureren en feitelijk inzichtelijk te krijgen waar we staan op elk willekeurig moment in tijd. Daar hebben we scrum voor gekozen, dat is natuurlijk een collectieve keuze geweest van een aantal mensen. Toen heb ik, pak m beet, een jaar scrum gedaan op een standaardproduct. In principe pasten we scrum toe voor het oplossen van bugs en het implementeren van additionele functionaliteit die de klant wenste. Waarbij ik zelf werk in de voorloop naar scrum, ik zit dus zelf niet meer in het scrum proces. Ik zorg voor de voeding van de scrum sprints. Dus dat is een iets andere rol. O: je zegt dus dat de introductie van scrum is gekozen om te kunnen bepalen vanwaar staan we en wat doen we?

| Page 104 |


C: ieder had zijn eigen ding wat hij of zij eruit wil halen. Op een gegeven moment weet je niet meer waar je aan werkt. Je hebt een hele grote bak met werk. De klant riep dat hij iets wilde hebben, hebben dan ad hoc een ontwerp gemaakt. Dat was een beetje de werkwijze, de klant ging akkoord met het ontwerp. Het werd geïmplementeerd en een beetje getest en vervolgens uitgeleverd. Een week later viel er weer iets anders om een pakket, het was een beetje een rommeltje. Als je dat wil structureren gaan werken met een vaste periode van ontwikkeling inclusief de requirements die daaraan ten grondslag liggen. Scrum is dan een methodiek om inzicht te krijgen in hoeveel werk er ligt, iedereen weet van elkaar waar ze aan werken, bij komend voordeel is dat er kennisdeling plaatsvindt. Door de dagelijkse meetings weet je ook wat je collega aan het doen is. Waar je idealiter zodanigekennisdeling hebt dat je het werk van je collega over zou kunnen nemen. Er is een duidelijke scheiding tussen projectleider en product owner. Projectleider bemoeit zich niet met het scrum proces en beheert de planning en de product owner bepaald de prioriteit. Dat heeft als voordeel dat als een verstoringen zijn, wat de consequenties zijn als je die verstoringen prioriteit geeft boven het werk in de sprint. Vroeger kwam er gewoon iemand binnenstappen, die zei: dit moet gebeuren en dan werd dit ad hoc opgepakt. En dat kost heel veel tijd en die tijd vindt niemand meer terug. En nu is het inzichtelijk wat er afgerond is na een sprint. Als het niet gehaald is, wat is dan de reden dat het niet gehaald is? Dan heb je een retrospectief om met elkaar te bekijken waarom dit zo gebeurd is, wat is een goed gegaan en wat is er slecht gegaan. En dan met name wat is er slecht gegaan en wat kunnen we daaraan doen? In die zin brengt scrum wel heel veel voordelen. O: maar normaal gesproken als je scrum toe om beter te kunnen inspringen op veranderingen en om beter aan je klant verwachtingen kunnen voldoen. Past dat in het huidige proces? C: het is bij mij een beetje dubbele ervaring, want we zijn gestart met een ontwikkelperiode van zes weken. We zagen al snel dat zes weken te lang was. Hierdoor werd de flexibiliteit teniet gedaan. Je bent zes weken bezig tijdens de ontwikkeling, terwijl de deadline in de gemeente wereld vrij hard is. Een aanbesteding met een deadline sluit niet aan op jouw periodieke sprints. Dus dan is er niks agile aan wat mij betreft, behalve dat je een mooie structurering hebt van je werk. Een periode van twee weken was bij ons tekort, voordeel is wel dat je heel snel kunt schakelen, maar vaak zijn de ontwikkelingen aan onze kant dusdanig groot dat dit geen nut heeft. Dus je hebt wel weer je structurering, maar de sprints zijn zo kort dat je aan het eind van de sprint niks kunt opleveren. Daarom hebben we een middenweg kozen van vier weken, dat lijkt bij

| Page 105 |


ons het optimum te zijn waarbij we in ieder geval een stuk functionaliteit aan ons product toe kunnen voegen, een belofte aan onze klant kunnen doen dat het daadwerkelijk wordt opgeleverd, maar wel met de kanttekening dat als je het oplevert terugkoppeling in een volgende sprint weer meegenomen moet worden . Dus die sprints heb ik niet echt als een voordeel ervaren, moet ik heel eerlijk zeggen, ten opzichte van project werken. Bij het project werken had ik eerlijk gezegd dezelfde ervaring als bij scrum, waarbij je bij scrum gewoon een beperkende factor hebt. Je kunt niet schakelen tijdens de sprint, dus als er een vraag binnenkomt inparkeren tot de volgende sprint of de daarop volgende sprint. O: dus agile is eigenlijk minder agile dan ad hoc werken. Het is minder flexibel? C: maar ik kan me wel voorstellen bij de ontwikkeling dat als je met hele korte sprints van twee weken gaat werken dat je dan snel kunt schakelen. Dan zie ik ook wel de voordelen van scrum. Voor ons waren de voordelen voornamelijk structuur en inzicht in het werk, weten waar je aan kan werken en wanneer. Je kunt vooruit plannen. Dat waren voor ons de belangrijkste voordelen O: je ziet dat scrum vaak op een bepaalde manier wordt toegepast binnen een organisatie. Daarbij wordt vaak geweken van de standaard. Vaak omdat dit beter of efficiënter werkt. Heb jij hier voorbeelden van bei de toepassingen binnen Sigmax? C: moet ik even heel goed nadenken, ik begrijp precies wat jouw vraag is. Ik heb samen met Sm een scrum training gehad. Wij wijken inderdaad af van de standaard, maar wel met de juiste argumenten. Ik herinner me van de training dat er werd gezegd dat scrum vaak toegepast in een minimale vorm, daarvan werd bij de training gezegd: dan kun je scrum beter niet toepassen. Dan gaan ze bijvoorbeeld alleen de standups doen, met een bord waar de taken ophangen. Als er dan een taak tussendoor bijkomt dan hangen ze die er ook bij op. Dus wat je doet is, je gebruikt kleine onderdelen van scrum, je gaat niet in volle glorie alles gebruiken. Wat je dan doet is je zelf voor de gek houden. Je moet wel zorgen dat als je een sprint start van vier weken, daar ga je bijvoorbeeld met 400 uur in aan werk in die je kunt doen in die periode, dan moet je niet tussentijds taken toevoegen of verwijderen. Dan hou je jezelf dus voor de gek met scrum. Maar als je kijkt naar-Sigmax, als je scrum zelf bekijkt, je hebt een sprint, dat is een periode, dan heb je twee schatting sessies en een retrospectief achteraf. Daarna heb je een oplevering. Als je puur daarnaar kijkt, dat is wat wij doen bij-Sigmax. De dagelijkse stand ups doen we bijSigmax. De productenbacklog houden we ook goed bij. Waar we wel van afwijken zijn de schatting methodieken. Je werkt in principe met planning poker, met van die kaartjes.

| Page 106 |


Daar staan de relatieve getallen op, de uitgangspositie daarbij is dat mensen beter relatief kunnen schatten dan absoluut. Je gaat daarbij uit van een taak en vervolgens ga je relatief schatten ten opzichte van deze taak. Met software ontwikkeling is dit niets te doen, elke taak heeft zijn eigen karakter. Deze zijn vaak niet te vergelijken met andere taken, daarom worden de taken individueel geschat. Dit is het enige punt waar we op afwijken. Het doel is om de schattingen zo accuraat mogelijk te krijgen, dat is hier mee gelukt. O: hoe werkt het huidige requirements proces en dan ook in combinatie met scrum? Vind je dat het meer een apart staand proces is of toch onderdeel van het scrum proces?

C: onze ervaring heeft geleerd dat het maken van functionele ontwerpen, dus het verzamelen van requirements, niet goed in de sprints passen. Vaak zie je dat degenen die de ontwerpen maakt, ook nog andere werkzaamheden heeft buiten de sprint. De focus factor is elke keer anders. Uit praktisch oogpunt hebben we deze persoon uit de sprint gehaald en zetten we deze voor de sprint. Deze werd dan dus vooruit. Als je kijkt naar de toepassing in de werkelijke wereld om aan dus bij andere bedrijven, dan zie je ook vaak dat for scrum vooruit wordt gewerkt. Je hebt bijvoorbeeldbacklog en daar staan dan 20 items op, hoe hoger het item op de ordening gedetailleerder de uitwerking is en dus ook derequirements helder zijn. Hoe lager op de backlog minder duidelijk terequirements zijn, je kunt er dan eigenlijk nog niks mee in een sprint O: de backlog is dus wel de rode lijn in de requirements? C: ja, wat je in feite krijgt scrum proces verkoop en project proces. Wat je ziet is dat in het verkoop traject derequirements worden verzameld, door in gesprek te gaan met de klant en uiteindelijk stel je daarvoor scope op waarvoor je akkoord krijgt. Nu is het bij de overheidsmarkten vaak een beetje anders. Vaak zijn de requirements al duidelijk vanuit de aanbesteding. Je hebt dan weinig inspraak op de requirements die de klant stelt, deze moet je dan natuurlijk wel vertalen naar internerequirements. Deze vertaalslag gebeurt voor een sprint. Dus dat je een stuk functionaliteit in de sprints brengt die qua requirements uitgewerkt is O: en wordt het requirements proces nog uitgevoerd volgens een bepaalde methodiek of gebeurt dit ook gewoon ad hoc?

| Page 107 |


C: in principe werk je debacklog af, ook als er een klant zou komen met een vraag voor een functionele uitbreiding, dan wordt er wel een setrequirements verzameld, maar die gaat als item op de backlog. Wat er gebeurt is dat er een periodiek overleg is, waar de prioriteit bepaald wordt. Wat je dus doet is dat de toptien van debacklog accuraat geschat blijft, dan heb je dingen die je daadwerkelijk wilt gaan doen, en dan ga je periodiek per sprint bekijken hoeveel mensen je hebt. Als je 400 uur capaciteit beschikbaar hebt, dan haal je je 400 uur werk van de backlog. Waar je ten alle tijden voor moet zorgen is dat het werk sprint sluitend is, voor de capaciteit die je op dat moment zou hebben. De requirements worden ingebracht door de functioneel consultants of door de klant. O: lukt dat ook altijd? C: het gaat steeds beter. In het begin hebben we een hele tijd gehad dat we niet vooruit konden werken. Je zag dan dat het ontwerp en de realisatie in een sprint zaten. Je krijgt dan een afhankelijkheid van elkaar, dat wil je niet, want dan zitten de programmeurs te wachten tot het ontwerp klaar is. Dat is ook een van de redenen dat we het er buiten hebben gehaald. Dat gaat steeds beter, de afgelopen twee maand is het ons gelukt om vooruit te werken. Dus om de user story's gereviewed in de sprint in te brengen, zodat de ontwikkelaar gelijk aan de gang kan. Dit gaat niet volgens een bepaalde methodiek, we hebben wel een standaard sjabloon voor functionele ontwerpen, hierdoor kunnen we met een goede snelheid de sprints zullen O: wat je vaak ziet is dat derequirements ook in een scrum proces uitgewerkt worden. Dit scrum proces sluit dan vervolgens aan op het ontwikkelproces. Zie jij dit als een goede oplossing? C: nou wij hebben eigenlijk twee soorten werkzaamheden. Ik denk dat de internerequirements, dus waarvoor je een document gaat uitwerken, dat je deze prima in een sprint stoppen. Maar bij requirements verzameling in het verkooptraject, dat kun je bijna niet met iteraties voor elkaar krijgen. Dit is zo dynamisch dat het niet in te schatten is en er ook nog allerlei afhankelijkheden zijn. In het verkooptraject zijnderequirements vaak onduidelijk veranderen ze ook nog vaak, pas als de opdrachten binnen is worden derequirements verder uitgewerkt, zodat ze in een sprint kunnen O: hoe gaat de interactie met de klant? Wordt er alleen geïnterviewd of worden ook mockups gemaakt of zo?

| Page 108 |


C: dit wordt vaak niet gedaan, bij aanbestedingen gaan we vaak op eigen interpretatie requirements inschatten. Daarbij is geen contact met de klant mogelijk. Hierbij is het goed zoeken naar de balans, uiteindelijk bij de opleveringen zal pas blijken of derequirements goed zijn geïmplementeerd. Vorig jaar hadden we een heel groot project, waarbij er zo onbenullig veel requirements werden gezet, daar had je geen overzicht meer over het geheel. Dan heb je gewoon nog een sessie nodig met de klant, om al die requirements door te nemen zo van: wat bedoel je daar nou precies mee? Er waren namelijkrequirements bij waarbij wij echt niet konden bedenken wat de klant daar mee bedoelde. Dus dan heb je nog een sessie nodig met de klant om het te begrijpen, dat wordt ook ingecalculeerd bij zo groot project. Bij de kleine projecten wordt dat vaak niet gedaan en dan wordt het risico gewoon genomen, dan wordt er veel gewerkt op basis van aannames. Mijn ervaring is dat het beter werkt om nog een keer klant om tafel te zitten, dan worden derequirements duidelijker van. Daarna zijn derequirements helemaal helder en akkoord met de klant, vervolgens kunnen ze verder uitgewerkt worden O: OK, vind dan de weg naar de klant plaats? Volgens mij wordt er niet na elke sprint niet aan de klant gedemonstreerd? C: nee wat je nu vaak ziet, is dat een volledige module in een of twee sprints wordt gerealiseerd en deze gaat dan naar de klant. Hier zit geen tussentijdse feedback in naar de klant. Het risico is dan dat de klant nog op en aanmerkingen heeft op de module. O: maar het is toch juist de bedoeling van scrum om de klant te betrekken om dit soort dingen te voorkomen? C: ja, maar dat is ook wat ik eerder zei, als je twee sprints hebt van vier weken dan ben je acht weken verder. Dan lever je het op naar de klant en dan krijg je feedback. Dan ben je volgens mij niet agile bezig, je zou dan die acht weken op moeten knippen in vier sprints en dan na elke sprint tonen aan de klant wat er gerealiseerd is. De klant kan dan testen met de functionaliteit. Zo kun je veel sneller schakelen, de feedback kan dan in de volgende sprint verwerkt worden en de klant hoeft maximaal maar vier weken te wachten. Dit wordt bij-Sigmax nog niet heel veel toegepast O: OK, is daar dan een bepaalde reden voor? C: het kost teveel tijd, het is erg arbeidsintensief om iets bij de klant op te leveren. Er moet vaak een installatie gedaan worden bij de klant, die zit vaak aan de andere kant van het land er zijn een hoop reiskosten. Vaak is het een kostenafweging. De tijd die het

| Page 109 |


kost om elke keer een release te maken en op te leveren, kunnen we besparen. Dat risico kunnen we nemen om te proberen om in een keer iets goeds op te leveren. Die afweging wordt vaak gemaakt. O: dit werkt wel dusdanig goed dat de klant vaak krijgt wat hij verwacht? C: ja het is gebleken dat wij er niet vaak naast zitten en op de momenten dat er naast zitten is de impact zo beperkt, dat het niet uit had gekund om het interactief om de twee weken te doen O: maar dit heeft wel te maken denk ik met het feit dat je al met een volwassen product te maken, dat al jarenlang in ontwikkeling is waardoor je veel product kennis hebt? C: ja dat klopt, de wijzigingen worden ook steeds kleiner, waardoor het allemaal goed te overzien is. Er zit weinig risico in. Ik denk wel dat bij de ontwikkeling van cc zes, waar je heel veel nieuwe functionaliteit hebt, een iteratief werkproces wel nuttig zou zijn. Dit doen we echter niet, we hebben er daar ook voor gekozen om per module een oplevering te doen en geen tussentijdse leveringen. Dit wordt ook een beetje gevoed door de deadline die zij stellen voor de productie en de sprints die ertussen leggen om dit te kunnen bewerkstelligen O: het is dan dus de tijdsdruk met jou in de weg zit? C: ja, ik zou graag eens meemaken dat we bijvoorbeeld sprints van twee of drie weken doen en dat je elke keer iets oplevert naar de klant en de feedback dan iteratief in de volgende sprint werd verwerkt O: maar is de klant wel in staat om goed te beschrijven wat hij wil? C: onze klantenkring is prima in staat om te vertellen hoe ze het willen hebben, handhaving bestaat al jaren het is niet nieuw nieuw proces. Dus kunnen gevolgd door u wel vertellen wat hun werkproces is, waarbij-Sigmax wel de expertise heeft om dit te vertalen naar een oplossing. Dus daar hebben we niet heel vaak een afwijking met de klant O: en hoe is het scrum en requirements proces over de afgelopen jaren veranderd? In het begin zal er veel nieuwe functionaliteit zijn geweest, maar nu zal er meer onderhoud gedaan worden dan dat er nieuwe functionaliteit wordt toegevoegd? C: wat sowieso gedaan hebben is dat de bugs na een half jaar na de introductie van scrum uit de sprints zijn gehaald, omdat bugs dynamisch zijn. Je kunt wel voor 40 uur

| Page 110 |


onderhoud in een sprint stoppen, maar daar is niks agile aan, want de klant moet dan toch een maand of zelfs wel twee maand wachten voordat een issue opgelost is, omdat het pas na de sprint klaar is. We hebben nu een persoon die buiten het scrumproces aan onderhoud werkt O: dus er zit helemaal geen bug meer in de sprints? C: er worden wel eens bugs meegenomen in een sprint, maar we zijn dan fouten die goed in te schatten zijn en dusdanig kritisch zijn dat ze snel opgeleverd worden. Bij kritische fouten moet er gewoon sneller geschakeld worden. Dus zeg maar 90% van de bugs zitten buiten scrum O: worden er momenteel ook veel kwaliteitsverbeteringen doorgevoerd? Zijn deze dan klant geïnitieerd of intern? C: deze worden voornamelijk opgemerkt door klanten of bij interne testen en worden dan meegenomen in de sprint O: zie jij verschillen tussen sprints gevuld met nieuwe functionaliteit en het onderhoud en verbetering? C: vaak worden de bugs niet voorbereid, er wordt een grove schatting aangekoppeld. Daar was geen voorwerk behalve dan dat de bug fixed moest worden. Voor structurele bugs, zoals bijvoorbeeld dat de verbinding wegvalt, wordt een analyse gedaan kijken wat het probleem precies is en hoe lang het duurt om het op te lossen. In het begin werd het werk ook vaak minder goed voorbereid sprint de sprint in gedaan, dit werkt niet goed, omdat de ontwikkelaar vaak een eigen interpretatie heeft. Dit zorgde voor een groter risico dat derequirements uiteindelijk niet in lijn waren met de klant verwachting. Daarom zijn we naar een methode gegaan waarbij we derequirements expliciet maken. De ervaring is dat het voorwerk heel belangrijk is, hoe beter de requirements, hoe minder het risico. Dus vaak zien we dan dat na de ontwikkeling de implementatie overeenkomt met derequirements O: gaan de requirements ook naar de klant ter verificatie? C: in de begintijd gingen ze wel naar klanten, deze kon dan feedback geven en zo kwam hij uiteindelijk tot de definitieverequirements. Dit is een goede werkwijze die we nog steeds vaak bij-Sigmax toepassen. De volledige specificatie gaat niet naar de klant, maar wel het functionele gedeelte. Bij FMS zien we dat de requirements wel voor akkoord naar de klant gaan, maar dit heeft denk ik te maken met het type klant. Bij gemeenten is

| Page 111 |


het vaak zo dat derequirements al duidelijk is, dit is een andere mentaliteit waar wij mee te maken hebben O: hoe werkt het met het testen van de functionaliteit? C: bij ons kijkt het testen altijd naar de implementatie. Vaak wordt er een test specificatie gemaakt door tester getest wordt. Dit betekent in de praktijk dat na de sprint er nog een week gebruikt wordt om te testen, daarna wordt er een week besteed aan rework en daarna heb je pas een release. Dit gebeurt bij zowel sprints die heel erg geënt zijn op klant ontwikkeling als en geent zijn op de ontwikkeling O: hoe ben jij als functioneel consultant betrokken tijdens sprint bij de ontwikkeling? C: volgens scrum zal ik officieel niet betrokken hoeven te zijn bij de sprint, maar in de praktijk wordt er door mij tijdens de sprint nog wel wat bijgestuurd, bijvoorbeeld als er vragen zijn. Het is belangrijk dat er constant communicatie is bij eventuele onduidelijkheden en dat is afgestemd wordt. Bij voorkeur op tijd, dus voor het einde van de sprint, zodat er nog op gereageerd kan worden. En dit doen we ook constant O: en wat gebeurt er in de situaties als er vragen komen blijkt dat er toch nog onduidelijkheden zijn werk eventueel uitloopt? C: die momenten hebben we gehad, dan krijg je een escalatie. Er zijn situaties geweest waarbij de ontwikkelaar aangeeft dat het mooi bedacht is, maar dat het technisch niet uit te voeren is. Dit wordt dan geëscaleerd naar de scrum master of de product owner, we zeggen dan: we dachten dat het 8:00 uur kostte, maar het gaat 40 uur kosten. Daar moet dan akkoord voor gegeven worden. En dit wordt dan opgelost in de sprint. Er kunnen ook functionele zaken zijn die niet duidelijk zijn naar de tekentafel. Dan wordt de-user-story stopgezet, daar wordt dan in de huidige sprint niet meer naar gekeken, deze gaat mee in de volgende sprint. In sprints worden ook vaak wat ruimte gereserveerd voor meer werk. Vaak wordt er wordt er per user-story extra tijd gereserveerd. Wat je ook vaak ziet is dat de laatste twee-user-story's niet worden uitgevoerd in de sprint. Deze worden dan doorgeschoven naar de volgende sprint O: wat je vaak ziet is dat als een product volwassen wordt dat er dan differentiatie optreedt, hoe zie jij dit met betrekking tot cc 5 en zes? C: we hadden eerst Park Control, hier is een differentiatie voorgekomen voor de politie, Mobile politie. Dit zijn kort twee aparte producten geweest, maar deze zijn snel weer samengevoegd. Vervolgens kwam er een variant voor de Belgische markt, dit was weer

| Page 112 |


een apart product naast het bestaande product. Dit zorgde voor veel dubbel werk, daarna kregen we ook nog een variant voor de Zwitserse markt. Hierbij is als basis de variant voor de Belgische markt gebruikt. Toen hadden we drie verschillende producten. Dit bleek niet werkbaar en vervolgens wordt dit allemaal weer geïntegreerd in cc zes.

9.5.7 SCRUM TEAM MEMBER O: requirements aan een heel nauw samen zes factor van agile, namelijk het samenwerken met de klant D: je ziet dat met de komst van scrum voor cc vijf juist minder samengewerkt wordt met de klant. Waar veel dingen in eerste instantie voor een klant gedaan werden, en dus die klant het product bepaalde. Nu is het zo dat in het voortraject er wel contact met de klant is via de functionele consultants, maar tijdens de ontwikkeling eigenlijk niet O: zo even kort kunnen toelichten wat je bij-Sigmax doet? D: ik ben ontwikkelaar en ik heb de afgelopen drie jaar aan cc Nederland gewerkt, ook wel cc vijf genoemd. Het is een product waar nu een beetje in het eindstadium zit. Sinds een paar maanden werk ik ook aan cc zes. Dit is de opvolger van cc vijf O: OK, het scrum proces. Ik denk dat jij de introductie van scrum meegemaakt hebt? Kun jij vertellen hoe dat begonnen is en hoe het zich ontwikkeld heeft? D: ik zit me af te vragen hoe het precies begonnen is. Ik kan me niet meer zo heel duidelijk voor de geest halen. Het ging gefaseerd en vrij moeizaam, overgang van projectmatig werken naar scrum. Het is best wel een overgang. Als mij is het eerst begonnen met zorgen dat je-user-story hebt. Er is dus begonnen met de standups en deuser-story's. En we merken in het begin dat de-user-story definities erg vaag waren en ik heb gemerkt dat dit juist heel belangrijk is. Het hele duidelijke stories hebben, de user story's zijn de requirements. Het heeft een hele tijd geduurd voordat we een multifunctioneel team hadden. Dekennisdeling ging in sneltreinvaart, door scrum weet iedereen waar de ander mee bezig is. O: want wat is er als laatste toegevoegd aan het scrum proces? De retrospectief en de schatting sessies? D: die deden we sowieso wel volgens mij. De retrospectief is altijd makkelijk om vorm te geven, je vertelt elkaar wat er goed en niet goed gegaan is gegaan de afgelopen periode

| Page 113 |


O: is de schatting sessie dan het vullen van de product backlog? D: nee, de productbacklog door de scrum master en de product owner. Je hebt eigenlijk eerst een planningsessie waarbij uitgelegd wordt wat we gaan doen. Daarna komt er een detailschatting sessie voor elke user story. De vraag is dan wat kunnen we doen in de komende sprint? Dat schatten dat merk je gewoon, dat is heel moeilijk. Gedeeltelijk ligt dat aan, als je ergens nooit aan gewerkt hebt, dan weet je niet hoe het in elkaar steekt. Dan is het moeilijk in te schatten hoeveel tijd kost om ergens veranderingen in aan te brengen. Voor cc vijf is het redelijk makkelijk functionele wijzigingen in te schatten, maar zodra, voor bijvoorbeeld cc zes, de basis nog niet klaar is, is het moeilijk in te schatten functionele wijzigingen technisch toegepast moeten worden. Daardoor een schatting sessie vaak uit in een discussie over derequirements O: dat zou je eigenlijk moeten voorkomen D: ja, wat ik gemerkt heb bij cc vijf is dat sprint werkt goed volgens plan op het moment dat derequirements heel erg duidelijk zijn. Meer stoort is je in je sprint hebt, hoe makkelijker het is om het geheel te schatten. Het aantal mensen in het team heeft er een grote invloed op. Hoe kleiner het team wordt, niet op het juiste woord is, hoe efficiënter en hoe meer er volgens planning gewerkt wordt. Of dat nou te maken heeft met de overhead om elkaar in te lichten of dat er een groot team meer werk verzet wordt en dat daar ook meer extra werk uitkomt O: dus kleinere teams kunnen efficiënter werken? D: ja, dat is mijn ervaring. Met een man of vier werken in een sprint dat werkt goed, ook wel eens in een team gezeten met acht mensen, dat werkt een stuk minder goed. Er zaten dan ook mensen in de sprint die voor 50% nog andere werkzaamheden hadden. Dan kom je heel snel in de knoop met afhankelijkheden, persoon is bijvoorbeeld met een taak bezig, maar heeft daar geen tijd voor, omdat er nog andere taken zijn en de tweede persoon zit daar dan weer op te wachten. Dat soort dingen krijg je dan O: het is ook vaak zo dat het scrum proces wordt aangepast op de organisatie. Er worden soms dingen toegevoegd of weggelaten wordt dan meestal gezien als efficiënter of makkelijker. Kun je daar voorbeelden van noemen? D: ik heb eigenlijk geen theoretische kennis van hoe het scrum proces volgens het boekje zou moeten werken. Ik ken alleen de-Sigmax praktijk. Dus dat vind ik nogal een moeilijke vraag. Een ding wat me wel opgevallen is, is de feedback van de klant. Dat zie

| Page 114 |


ik niet terug. Of zelden in ieder geval. Je ziet duidelijk: in het begin van de sprint is er iets gedefinieerd, en dat maak je dan af. O: maar wie bepaalt dan op het eind of de gemaakte functionaliteit goed is? Is dat dan degene die de requirements opstelt? Of gaat het gewoon naar de klant en als het niet terugkomt dan is het goed? D: ja, meer dat laatste. Wat eigenlijk bij scrum hoort is een demosessie. Dat schiet er vaak bij in. Een voorbeeld waarbij het wel heel goed is gegaan cc vijf is het verzamelen van gegevens uit verschillende bronnen. Daar hebben we het wel gedaan, er is eerst intern gekeken. Wat zijn de verwachtingen? Dus eigenlijk wat zijn de requirements, daarna hebben we een keer een klant erbij betrokken, daar kwam allerlei feedback op. Over het algemeen is het zo dat iempo1quirements opstelt en vervolgens wordt het implementeert. De tester heeft nog een beetje invloed, want deze test de functionaliteit en bekijk of deze voldoet aan de requirements O: in de literatuur over agile staat juist de klant heel erg centraal D: wat je ook ziet is dat als we het wel goed hebben gedaan, dat het in eerste instantie niet helemaal goed is, maar naar wat feedback is het helemaal 100% en dan is het klaar O: maar wat is jouw idee waarom dit niet of bijna niet gedaan wordt? D: tijd en kosten. Dat is volgens mij de grootste reden. Scrum wordt intern ook gezien als iets dat geld kost, door allerlei bijeenkomsten die ten koste gaan van de ontwikkeling. Bij het schatten of plannen je gerust enkele dagen druk zijn met het team. Vaak is mijn gevoel dan: het kost teveel O: maar het levert toch wel wat op als je het regelmatig naar de klant terug koppelt? Je voorkomt dan een mismatch D: mijn gevoel is dat, als er iets aan de klant geleverd wordt helemaal compleet is, dat dan daar ook nog een extra werk uitkomt. Dat zou niet het geval zijn als je vooraf alles precies specificeerd. Maar dat is maar puur een aanname O: maar dat zou ook weer met de requirements te maken? Maar komt dat dan ook vaak omdat de klant precies kan vertellen wat hij wil? Schrijf-Sigmax ook voor hoe de klant moet werken?

| Page 115 |


D: ja, we hebben een standaard product met een standaard werkproces dat voor alle klanten gelijk is. Dat werkt gewoon prima. Bijvoorbeeld voor het uitschrijven van boetes, heb je te maken met wetgeving en een voorgeschreven werkwijze O: OK, het scrum proces is wel duidelijk. Hoe werkt requirements proces? D: het opstellen van derequirements gebeurt buiten de sprint, in het algemeen in ieder geval. Meestal worden door de projectleider of functionele consultants gedaan. Deze gaan vaak naar de klant toe om inzichtelijk te krijgen wat ze willen en daar wordt dan vaak een functioneel ontwerp voor uitgewerkt. Voor cc vijf is dat altijd Fc1. Dan heb je de functionele requirements, de technische bedenken we zelf wel O: je zegt het gebeurt buiten de sprint. Hoe kijk jij daar tegen aan? Is het iets dat helemaal buiten het scrum proces valt of maakt het er juist onderdeel van uit? D: het wisselt heel erg bij ons, ik merk dat als het er wel onderdeel van uitmaakt, dat je dan wrijving krijgt ofwel met de implementatie ofwel met de doorlooptijd. Het is voor ons ondoenlijk gebleken omrequirements te stellen, ontwerp, en de implementatie in dezelfde sprint. Want dat maakt het onmogelijk om het goed in te schatten. Kun pas schatten als het ontwerp is en derequirements. Plus dat je met afhankelijkheden zit, want vaak worden door dezelfde persoon gedaan. Waar het vaak op neer komt is dat de functionele consultants niet meewerkt in de sprint, deze stelt gewoon buiten de sprint de requirements op. Deze komen dan vervolgens voor de implementatie terecht in de eerstvolgende sprint O: wat moet ik me voorstellen bij derequirements? Is dat gewoon een verhaal van hoe het moet gaan werken? D: dat verschilt heel erg. Het heeft te maken met de grootte van de van de functionaliteit die je gaan maken. Het kunnen enkele regels zijn die iemand opschrijft tot een compleet ontwerp bestaande uit tientallen pagina's O: weet niet of jij er zicht op hebt, maar worden de requirements nog opgesteld volgens een bepaalde methodiek? Ik hoorde je in het begin zeggen dat als er iets mis gaat dat dan meestal de requirements niet duidelijk zijn D: ik heb er niet zo zicht op hoe dat gedaan wordt O: maar als de requirements niet duidelijk zijn, wat is daarvan de oorzaak van? Heeft dat dan te maken met tijdsdruk?

| Page 116 |


D: ik denk dat het gewoon vaak te weinig aandacht heeft gekregen. Op een moment dat je een klant hebt die iets groots wil, dan krijgt het vanzelf aandacht. Als het om kleine features gaat, meestal niet het geval. Er wordt dan omschreven worden, maar meestal blijkt het dan niet helemaal duidelijk te zijn. Daar zijn we nu wat alerter op geworden, ook tijdens de schatting sessies zijn we daar nu alert op. Als je met aannames gaat schatten, dan zie je dat het heel erg mis gaat. Dan kom je er tijdens de ontwikkeling achter: wat wordt er nu bedoeld? O: het kan dus zo zijn dat je tijdens de ontwikkeling tegen onduidelijkheden aanloopt en dat dit dan terug gaat naar de functionele consultants. Wordt de sprint dan langer of gaat het dan naar de volgende sprint? D: het is beiden wel gebeurt, soms heeft het hoge prioriteit en dan wordt er een schatting sessies ingelast om het alsnog te bespreken O: kun je misschien iets vertellen van hoe het scrum proces is veranderd over de tijd. Want we nu begonnen met scrum was cc iets meer in ontwikkeling, het product is nu een stuk volwassener. De laatste tijd zal het meer naar onderhoud zijn gegaan in plaats van nieuwe functionaliteit D: sowieso toen we begonnen met scrum had cc wel al een solide basis. Het stond al redelijk als product en voor mijn gevoel zijn productie van scrum ook minder grote projecten gedaan. Het voelt heel anders als je drie maand een klant project bezig bent of dat dit in vier verschillende sprints is opgesplitst en je er met verschillende mensen aan dezelfde functionaliteit werkt. Het laatste halfjaar wordt cc vijf duidelijk afgebouwd en dan merk je vooral dat het team kleiner wordt. Het zijn voornamelijk bugfixers maar ook wel wat nieuwe functionaliteit. Maar dat is meestal niet zo groot. Grote herstructureringen worden eigenlijk niet meer gedaan. Een ding wat je wel heel duidelijk ziet is dat in het begin had iedereen zijn eigen specialiteit en degene met specialiteit pakken toch te dingen op die het beste bij zijn of haar specialiteit passen. Dat is wat meer door elkaar heen gaan lopen dat je multi inzetbare mensen krijgt. Hetgeen overigens niet altijd ten goede komt van de kwaliteit. Iedereen is behoorlijk op de hoogte, maar zit er toch vaak niet diep genoeg in. Vaak zag is dat had gemaakt ging het ook onderhouden, dat zorgt er automatisch voor dat het op dezelfde manier gebeurde. Op het moment dat steeds andere mensen aan dezelfde functionaliteit gaan werken is het wat moeilijk om dezelfde lijn vast te houden. Dat kun je natuurlijk afdekken door gewoon duidelijke afspraken te maken, dan alles duidelijk en uitgebreid documenteren

| Page 117 |


en iedereen moet dat dan maar goed doornemen. Maar dat werkt in de praktijk niet altijd O: de bedoeling van scrum is ook om een minimum aan documentatie te maken. Ik kan me ook voorstellen dat je sprints heb die volledig gevuld zijn met bugfix? D: ja. Bij cc hebben we altijd wel iemand gehad volledig buiten de sprint met onderhoud bezig was. We hebben een keer een sprint gehad waar alleen naar achterstallig onderhoud in zat. En verder wat er meestal een verzameling van bugs in eenuser-story gestopt en dan wordt er 40 uur aan besteed bijvoorbeeld. Dat is dan meer een administratief dingetje om het in de sprint te krijgen dan dat het daadwerkelijk scrum te maken. O: precies want wat is dan nog de waarde van scrum? D: in principe zodra je gaat time boxen, was het volgens mij niet meer in scrum. Er moet wel iets definiëren dat je af kunt krijgen en niet een bepaalde tijd gaan spenderen aan onderhoud en zien hoe ver je komt O: wat is nu het verschil tussen onderhoud en nieuwe functionaliteit in sprint? Het hele voortraject zal sowieso anders zijn. De schatting sessies zal een stuk simpeler zijn D: als je gaat time boxen hoef je niet meer te schatten. En vaak wordt dat gedaan van: we weten het niet dus we gaan wel time boxen. Daar komt het vaak op neer. En dat wordt ook vaak gedaan met issues in het veld waar we niet de vinger op kunnen leggen. Dus die moet je dan eerst zien te reproduceren en om wat er gezegd we besteden er twee of drie dagen aan en mocht er niks gevonden zijn dan stoppen we ermee en gaan we verder met andere werkzaamheden. Daar valt wel wat voor te zeggen, ik zou niet weten wie het anders in scrum proces moet vatten. Je kunt niet zeggen we gaan door tot het opgelost is. Bij het inschatten van nieuwe functionaliteit is het duidelijk afhankelijk van hoe helder zijn derequirements en is ook iedereen op de hoogte van de requirements. Vaak zie je tijdens de schatting sessie dat iemand die erg veel kennis van heeft de moeite neemt om uit te leggen wat precies de bedoeling is. Waarmee ook gelijk de anderen stuurt qua schattingen. Schattingen op basis van bestaande functionaliteit zijn het makkelijkst. Daar heb je de meeste feeling bij van wat er al is ten opzichte van de uitgangspunten. O: maar zijn dat dan aanpassingen die functioneel anders zijn of ook het oplossen van bugs?

| Page 118 |


D: kan beiden zijn, als hij zegt er komen twee schermpjes tussen bestaande schermen dan is dat prima aan te passen bij bugs is het ook prima in te schatten zodra je weet wat de oorzaak is O: gebeurt er ook nog veel buiten sprints om of is alles gevat in de sprints? D: behalve onderhoud en een stuk voorwerk met betrekking tot derequirements gebeurt alles in de sprints. Alles wordt gevat in sprints ook om administratieve redenen. Er wordt dan time boxing gedaan, dat is dan meer om planning technische redenen. Wat mij betreft hoort dit niet in een sprint. Je zegt eigenlijk: ik wil gewoon 40 uur aan een bugfix hebben. Scrum wordt dan toegepast om inzichtelijk te houden waar iedereen mee bezig is. Ook om te bepalen hoeveel tijd er wordt gespendeerd aan een bug O: maakt de toepassing van scrum het dan onnodig tijdrovend? D: nee op zich niet, het is meer een stukje boekhouding O: maar wordt dan het verschil gemaakt of iemand buiten de sprint onderhoud doet of dat ik toch in de sprint meegaat? D: volgens mij ligt het een beetje aan de hoeveelheid werk die er ligt. Op een gegeven moment als backlog te groot wordt worden er resources toegekend aan onderhoud buiten de sprint O: gebeurt het ook wel eens als er iets heel urgent is dat er iets functioneel buiten de sprint aangepast wordt? Of moet er altijd gewacht worden tot de volgende sprint? D: ja er zijn wel eens storingen. De reden kan heel erg verschillen, maar meestal zijn het bugs. Functionele wijzigingen worden over het algemeen altijd wel in de sprint gedaan. Het zijn twee dingen: de urgente issues in het veld en als de requirements niet duidelijk waren. Werk dat niet afkomt in een sprint doorgeschoven naar volgende sprint als niet gepland werk O: je krijgt dan bijvoorbeeld een item aan waar nog 8 uur aan gespendeerd worden en dat wordt dan gedeeltelijk in een volgende sprint gezet? D: ja. Dat gebeurt eigenlijk sowieso altijd. Je rondt nooit precies af wat je gepland hebt, het is altijd meer of minder meestal meer. Ik krijg het niet voor elkaar om planning te

| Page 119 |


werken, dat is ook niet erg want de rest van de user story komt dan in de volgende sprint terecht. Dat zie je ook veel met ReWork dat uit testen terugkomt. O: want hoe past het testen eigenlijk in scrum proces? D: ten eerste is het inzetten van een tester qua resources heel lastig. Hij kan twee dingen doen: het verifiëren van items of het testen van een release. Daar komen vrijwel altijd dingen uit. Dat kan 2:00 uur zijn maar kan ook twee weken zijn. Dit komt dan altijd in de volgende sprint we terug. Bij een user story wordt er altijd tijd voor extra werk gereserveerd O: maar wat er dan wel gewerkt met een product backlog? Dus met een grote bak waar al het werk in zit? D: ja voor de sprint wordt er werk van de product backlog afgehaald die naar de sprint backlog gaat. Dit gebeurt door de scrum master en de product owner. Er wordt dan bepaald wat de komende sprint gedaan wordt O: groot is het scrumteam nu? D: nu vrij klein er zitten nog maar een paar mensen in. Het cc 6 team is nu groter O: heeft de-Android ontwikkeling een eigen scrumteam ? D: nee dit is nu nog een eilandje . Misschien dat we straks wel drie verschillende scrumteams krijgen, voor PDA, windows mobile en android.

9.5.8 PRODUCT OWNER O: Misschien kun je even kort vertellen wat je bij-Sigmax doet. A: Als operationeel manager heb ik nu product management onder mijn hoede. Momenteel-City-Control vijf en ik ben ook betrokken bij de ontwikkeling van-CityControl zes. Ik voel momenteel niet direct het product management voor-City-Control, dit ligt momenteel bij onze directeur Cio rijk. Voor-City-Control vijf doe ik dat wel envoor-City-Control zes is het de bedoeling dat ik dit ook weer op ga pakken. O: even in het kort: City Control 5 is de oude versie. A: City Control zes is daar de opvolger van met een volledige webbased backoffice. Die borduurt voort op de functionaliteit die we in Genève op hebben geleverd. De PDA moet dan de Nederlandse en ook de buitenlandse klanten kunnen bedienen. Ook de-Android ontwikkeling sluit aan op CC zes. De naam-City-Control International daar gaan we

| Page 120 |


afscheid van nemen. Dat gaan we-City-Control 6 noemen, dit vinden we commercieel wat interessanter. City Control zes is dus de opvolger van de oude producten. Zodat ook de Nederlandse klanten voelen dat dit een opvolger is van het oude product. Cc zes wordt dus echt de opvolger van cc vijf. Alle klanten gaan migreren naar cc zes. We hebben een aantal klanten die als eerste zullen worden bediend, waaronder Leeuwarden. Sion, Genève zullen daarna volgen. Ik bemoei me redelijk veel met de features die daar inkomen. Met cc vijf zitten we nu in een eindfase, met het nodige onderhoud wat we nog doen voor cc vijf. Dat is wel grappig, met cc zes zitten we in de opbouwende fase en met-City-Control vijf zitten we in de afbouwende fase. O: oké, toepassing van het scrum proces kun je misschien wat vertellen over de geschiedenis van wanneer scrum is toegepast en hoe dat gegroeid is bij-Sigmax. Ik denk dat jij de introductie ook hebt meegemaakt? A: ja dat klopt. Ik heb de datum niet helemaal scherp, maar met-City-Control vijf zijn we begonnen. Volgensm mij is dat inmiddels meer dan een jaar geleden. Ik heb het niet helemaal scherp hoor. Ik kan het wel voor je uitzoeken. We zagen dat we vooral plan technisch heel veel verschillende zaken aan het doen waren en niet goed de prioriteiten konden bepalen, van welke kant gaan we op? Ontwikkelaars werden heen en weer geslingerd met de taken die ze uit moesten voeren. De releases waren niet duidelijk. We hadden niet echt eenduidige release momenten. Releases kwamen ook altijd veel te laat. Toen hebben we gezegd dit moeten we verbeteren. Met scrum hebben we toen geprobeerd dit te verbeteren. Dit hebben we langzaam ingevoerd. We zijn begonnen met releases in vaste periodes. Daarna zijn we dus stories gaan vullen. Er zijn vaste release momenten gekomen, ook vaste afspraken na een sprint, zodat je daadwerkelijk 14 dagen later een release kunt maken. Wat ik vooral merk is dat het een stuk rust geeft voor het team. De planning wordt beter. Je prioriteit bepaling wordt beter. Het heeft ons wel verder geholpen. O: en toen het geïntroduceerd werd was-City-Control toen ook in een andere fase? Was er meer ontwikkeling van functionaliteit of was er toen ook al veel onderhoud? A: nee, toen zaten nog niet in de afbouwfase. Het was niet meer de initiële fase maar, het was wel een product in ontwikkeling waar nog nieuwe functionaliteit aan werd toegevoegd. Ik ben op zich wel tevreden over scrum. Maar we hebben ook lange tijd wel gezien dat we de sprint doelen niet haalden. Daar kwam ook kritiek op. We zijn allemaal aan het sprinten maar we halen nog steeds de doelen niet.

| Page 121 |


O: waar gaat dat mee te maken dan? Met slechte inschattingen? A: ja klopt. Schattingen en tegenvallers. Niet gepland werk wat er tussendoor moest gebeuren. Escalaties en soms ziekte teamleden. Maar voornamelijk toch het tegenvallen van het geschatte werk ten opzichte van het daadwerkelijke werk. We zien nu wel dat het beter gaat, ook beter gaat naarmate het team kleiner wordt. Als je een groot team hebt dan heb je meer tegenvallers en minder samenhang. Het geeft nu wel meer rust en planning tijd. O: hoe wordt er ingeschat? Door wie wordt dat gedaan en op basis waarvan? A: wij komen nu altijd met een voorgestelde story lijst vanuit het product management. Dan heb ik het over cc vijf. Dit wordt gevoed aan de hand van issues, klant wensen en verkochte zaken. Daar maken we een lijst van. We hebben periodiek gedurende de sprint wel schatting sessies om te introduceren elke nieuwe user story's erbij komen en omdat even door te spreken. Vooraf aan de sprint is er dan een totale schatting sessie, hierin komen de schattingen van de ontwikkelaars en dat wordt dan aangehouden in de user story's als realisatie tijd O: je vertelde dat het scrum proces gefaseerd ingevoerd is. Heb je het idee dat scrum helemaal toegepast wordt volgens het boekje? Of zijn er nog bepaalde zaken die weggelaten worden omdat dit efficiënter is of dat er specifieke zaken toegevoegd zijn omdat dit handiger is? A: wij laten wel wat zaken weg, dan komen we niet aan toe. Op zich proberen we het redelijk volgens het boekje te doen. Wat ik zie is dat het product management er nog wel eens bij in schiet. Dat meer tijd genomen moeten worden om user story's voor te bereiden. Je ziet gewoon dat als een user story niet goed voorbereid is, dan gaat die min of meer ongedefinieerd de sprint in. Daar kun je dan tegenvallers op ontvangen O: dus de user story's is zeg maar het vastleggen van de requirements? A: ja. Daar hameren we nu op dat daar een stuk voorwerk is door de functioneel consultant. Of dat er al in een sprint daarvoor een functioneel ontwerp gemaakt wordt en in de sprint er na een technisch ontwerp of de daadwerkelijke realisatie. Eerder hadden we nog wel eens sprints dat we dit in één klap probeerden te doen, maar dan waren er of onduidelijkheden of er waren ineens extra requirements en dan bleek het ineens niet meer te passen in de sprint. Dat hebben we wel geleerd omdat zoveel mogelijk los te trekken.

| Page 122 |


O: maar wat gebeurt er dan in zulk soort situaties? Werd de sprint dan langer gemaakt of werd het verplaatst naar de volgende sprint? A: dat had meestal als gevolg dat de user story onder aan de sprint niet werden voltooid en die gingen dan naar een volgende sprint. Dat is natuurlijk nooit prettig voor degenen die op een latere user story zit te wachten. We hebben in het verleden situaties gehad dat de sprint bijna volledig afgerond werd behalve-user-story een, dat is niet volgens scrum. En nu focussen we er wel op dat Story een de aandacht krijgt en dat we die ook afronden. Dus dat doen we allemaal wel redelijk volgens het boekje. Wat doen we dan niet volgens het boekje? Ik denk met name dat stukje product management en normaal gesproken moet je tijdens de sprint ook heel iteratief terugkoppeling geven aan de stakeholders. Dat gebeurt ook niet altijd, soms is dat pas aan het eind van de sprint of beide release. Normaal gesproken zou je ook altijd een demo moment moeten hebben aan het einde van de sprint. Dat schiet er ook wel eens bij in. Dus het stukje voorbereiding en de terugkoppeling tijdens de sprint, dat is denk ik het minst goed belicht bij-Sigmax. Maar tijdens de realisatie zelf, de standups, het overleg met elkaar, het overnemen van taken en ook de retrospectives, dat wordt wel allemaal netjes gedaan. O: dus wat je zegt is eigenlijk dat er voornamelijk wordt afgeweken door tijdsdruk? A: ja en misschien vergeten we nu ook op dingen waar we ons niet van bewust zijn. Wat is echt scrum? Hoe hoort het? O: ik bedoel ook meer hoe zijn bepaalde zaken gegroeid omdat dit binnen de cultuur van-Sigmax makkelijker of beter gaat. Dat je daar bijvoorbeeld andere ideeën over hebt. Zo van we kunnen dit misschien beter weglaten of toevoegen omdat dit beter of efficiënter is. A: we houden wel onze focus factor redelijk laag, zodat je wat meer tijd hebt voor niet gepland werk en eigenlijk is dit niet volgens scrum. Dan heb je wat ruimte voor escalaties. O: dus je hebt niet bijvoorbeeld mensen helemaal buiten de sprint die alleen maar de verstoringen doen? A: nee, zo zou het idealiter moeten zijn maar we merken gewoon dat het in de praktijk, of door de ondercapaciteit, dat ze toch schipperen. We weten dat het komt uit een

| Page 123 |


voorgaande sprint maar we kunnen het nog niet exact inschatten. Dan houden we daar een slag om de arm en houden we daar op die manier ruimte voor, maar eigenlijk is dat niet helemaal 100% scrum. Je zou de sprint eigenlijk gewoon helemaal vol moeten plannen en alle verstoringen buiten de deur willen houden O: dat heeft dan waarschijnlijk ook te maken het feit dat bepaalde kennis bij bepaalde mensen zit? A: ja ook dat een Sigmax is ook een bedrijf dat houdt van snel schakelen en soms.... Wij moeten flexibel zijn, dat wordt van ons verwacht en als je dan heel star aan de sprint vasthoudt dan escaleert alles. Moet je dan gewoon die ruimte vrijhouden. O: eigenlijk is het dan agile binnen agile? A: Ja. O: wat zijn voor jou de succesfactoren om scrum succesvol te passen? Uit de literatuur komt naar voren dat de voornaamste succesfactor het samenwerken met de klant is, het heel veel schakelen met de klant A: ja, dat zie ik hier iets minder. Dat is hier ook bijna niet toe te passen bij-Sigmax, wij leveren niet gedurende de sprint een tussen product op aan de klant. Wij werken wel echt toe naar een eindproduct. Dat zou eigenlijk pleiten voor een waterval methode O: dus hetgeen in een sprint gemaakt is gaat niet altijd daarna naar de klant toe? A: nee, we leveren pas een eindproduct op als het echt helemaal af is. We vragen minimaal feedback tussen door van de klant. Dat is niet echt agile, dat doen we wel met stakeholders. Dan word ik er bijvoorbeeld bijgehaald. Wat ik wel de kracht van agile en scrum vindt en ook de winst factor vindt is dat je met een team gaat voor een klus en ook een einddoel in die klus. Dus je neemt elkaar taken over en houdt mekaar scherp. Je hebt dan als programmeur afgifte gedaan van dit gaan we halen in een sprint en dan is ook alles erop gericht om dat te halen en ook dat einddoel te halen. Dat vind ik het sterke van scrum en daarnaast vind ik dat het voor de plannen een stuk rust geeft, want je weet gewoon dat je met afgebakende periodes werkt, je maakt gewoon lijsten met werk. Op gezette momenten wordt dat doorgesproken en dat gaat dan de sprint in. Dan heb je niet de afdeling verkoop die er dan ineens tussendoor komt en dat ineens alles omgegooid moet worden om weer wat anders te gaan doen. Het geeft een stuk rust naar het team. In een afgebakende periode werk je aan een oplossing. Je weet dat er niet

| Page 124 |


allerlei gekke zaken tussendoor komen. Dus het geeft ook een stuk rust, dat vind ik heel belangrijk. O: dus dat is eigenlijk de succesfactor van waarom scrum wordt toegepast bij-Sigmax? A: ja. O: dat de klant niet zo erg bij het scrum proces betrokken wordt is dat iets wat zo gegroeid is? Hoe kijk je daar tegenaan? A: volgens mij is dat een keuze. In principe wordt de accountmanager nu als klant gezien en betrokken en dit wordt ook naar beste inzicht gedaan. Wat we zien is aan de verkoopkant wordt het niet als agile verkocht, wij verkopen niet een bak uren aan de klant en zeggen: we gaan ongeveer dit maken, we koppelen precies aan jou terug wat jij krijgt. Nee, aan de verkoopkant wordt echt keihard met requirements aangegeven wat wij opleveren. Dus dan kunnen we wel tussendoor feedback geven aan de klant, maar we worden gehouden aan de totale eind oplevering. Dat heeft met de offertes te maken en ook met aanbestedingen en wat dat aangaat dat past gewoon minder binnen scrum. Kijk, als je al het einddoel het gedefinieerd dat past scrum minder goed bij. Maar het plannen van het werk past dan wel weer goed. O: maar ik neem aan: er wordt gewoon keihard een einddoel gedefinieerd zeg je maar ongetwijfeld zal het ook zo zijn dat daar nog dingen wijzigen. Van klein tot misschien wel groot. A: misschien is dat een van de verbeteringen, dat we toch wat meer klantgericht werken O: maar dat is dan toch ook waarom je-agile toepast juist om die veranderingen te kunnen managen? A: ja dat wel, en ook om het op te kunnen knippen in hapklare brokken. Dat we bijvoorbeeld een gefaseerde doorvoer hebben, stel dat iets drie maanden werk is dat we dat dan toch in drie blokken van één maand kunnen knippen O: zodat je sneller ziet als het fout gaat of niet klopt? A: ja of om bij te kunnen sturen tussen releases. Met die tussen releases na sprints gaan we niet naar de klant toe. Dat heb ik nog niet meegemaakt O: maar is dat iets waarvan je zegt: dat zou nuttig kunnen zijn?

| Page 125 |


A: ik zie het voorlopig nog niet gebeuren. Onze product leent zich daar niet zo goed voor. Politie korps wil gewoon een eindproduct en niet een soort van test konijn zijn. Dat leent zich daar niet zo goed voor O: is dat omdat je denkt dat in zo een geval te veel ongenuanceerde feedback terugkomt? Of omdat de klant misschien te weinig kennis van het eigen proces heeft? A: de klant moet tijd inruimen te gaan testen. Willen ze dat? We verwachten gewoon een eindproduct en ze verwachten niet allerlei tussen versies. Dat wordt niet zo verkocht, er wordt niet verteld dat er met scrum gewerkt wordt O: maar ik kan me voorstellen dat die klant op een gegeven moment iets krijgt en denkt: dit was niet helemaal de bedoeling? En dat het dan weer terugkomt A: misschien is het iets waar we nog meer naartoe moeten, maar zover zijn we nog niet. Komt ook bij dat we een klant niet zo heel makkelijk iets kunnen laten zien nu. Misschien moeten we daar naar toe dat we iets makkelijker in een test omgeving bijSigmax kunnen installeren voor de klant, om die klant al inzicht te laten geven. Zo staat het er bij schiet er maar eens op. Bijvoorbeeld voor de-Android ontwikkeling zouden we dat kunnen doen. Dat wordt nu ook gevraagd aan de-accountmanagers, laat die versie nou eens zien bij de klanten vragen om feedback. Maar dat wordt nog niet heel structureel aangepakt dat een release naar de klant gaat, feedback ontvangen, en dan weer verder ontwikkelen. Wellicht is dat nog een van de verbeterpunten O: OK, nu gaan we van het scrum proces naar derequirements. Je had al gezegd dat de requirements vastgelegd worden in Story's en dat aan de hand daarvan bepaalde zaken ontwikkeld worden. Zou je kunnen beschrijven hoe die requirements tot standkomen? Wie maakt die stories? Worden er altijdrequirements gebruikt voor ontwikkelingen die in de sprints terechtkomen? Ik kan me voorstellen dat het voor issues en bugfix eens anders loopt? A: ja we hebben een tijd gehad dat dat minder goed ging, dan heb je dus ongedefinieerde user story's, dat werkt niet. Dan is de Story heel summier omschreven. De omschrijving is dan bijvoorbeeld: de module voertuig export moet gemaakt worden, dat is veel te breed. Daar zijn we op teruggekomen, er moet een functioneel consultants zijn die dit verder uitdiept en ook echt een scoping van maakt. Voor de grote modules moet gewoon echt een functioneel ontwerp komen en dit ontwerp gaat dan de sprint in. Als daar geen tijd voor is dan moeten maken van het ontwerp de sprint in. Bij bij onderhoud wordt vaak de omschrijving van de storing melding meegenomen in de sprint, dan heb

| Page 126 |


je niet echt een requirements document. Dit is gewoon echt een storing melding. Dit zijn vaak ook kleinere wijzigingen. Voor cc vijf krijgen we nu ook een onderhoud sprint met allemaal kleine wijzigingen. Daar heb ik niet van elke storing een uitgewerkt functioneel ontwerp, het is meestal een verwijzing naar de melding. Dan krijg je dus heel veel kleine story's in de sprint O: maar voor de user story's gaat de functioneel consultants in conclaaf met de klant? A: ja, wel als er een functionele uitbreiding is. O: user story is dat is de enige methode die gebruikt wordt op zijn nog andere methoden? A: diagrammen en usecases maken onderdeel uit van de user story. Voornamelijk Fc1 en Martijn doen dit nu. Waar nodig gebruiken ze bijvoorbeeld usecases, die passen ze toe in hun functioneel ontwerp. O: daar koppelen zij dan zelf een inschatting aan? A: nee, dit wordt dan in de schatting sessie ingeschat. Dat wordt met het hele team besproken. Bij cc zes wordt er een inschatting gedaan met het hele team, eerder werd inschatting gedaan door een enkele ontwikkelaar die meeste kennis had van wat er gemaakt moest worden. Daar zijn ze nu weer van af gestapt. In het begin kwamen er ook steeds groter historisch op het bord van bijvoorbeeld 80 uur, deze worden nu steeds verder opgeknipt om ze beter beheersbaar te maken. In een grote groep schatten heeft als nadeel dat je heel veel mensen van het werk af hebt, maar het heeft wel weer als voordeel dat je meer saamhorigheid hebt in de groep en dat iedereen op de hoogte is. Dit maakt het ook mogelijk om taken over te nemen en te werken aan andere user story's. Dat heeft wel weer een positief effect. O: maar met het hele team schatten: daar wordt de schatting ook beter van? A: ja, dat zal wel moeten. O: hoe staat het verkrijgen van de requirements in verhouding tot het scrum proces? Zie jij het als een onderdeel van scrum of als een apart proces? A: ik denk dat laatste, maar we worden wel steeds beter omdat goed op elkaar aan te laten sluiten. Het ontwerpen en derequirements duidelijk krijgen is een soort voor fase voor je scrum sprint. Het moet gewoon vanuit een stukjeproductmanagement, het moet gewoon afgetikt zijn voor je het in een sprint op kunt nemen. Daar worden we ook wel

| Page 127 |


steeds strikter in: zo van jongens onduidelijkheden kunnen we niet meenemen in de sprint. Dit wordt geëist, dus het wordt wel steeds meer onderdeel van het scrum proces. Waar ik het voorheen vooral zag als een losstaand iets, het gaat nu steeds nauwer op elkaar aansluiten. O: je bedoelt dat doordat het steeds nauwer op elkaar aansluit je het meer als een proces gaat zien? A: precies. Dat is wel een van de lastige dingen, je wilt eigenlijk dat als er nieuwe story's zijn deze toevoegen in de sprint. En dan wordt er nog wel eens vergeten dat iets nog niet helemaal uitgekristalliseerd is, dan moet dan nog een ontwerp van gemaakt worden of de requirements zijn nog niet helemaal helder. Die bewaking en ook dat het gedaan wordt, dat vergt ook nog wat extra planning en daar heb je capaciteit voor nodig. Die capaciteit wordt niet op eenagile achtige manier gedaan. Dat is wel echt een proces wat er weer als een project voor aankomt. Als het echt helemaal in het nauw komt dan wordt er wel eens gezegd om het ontwerp zelf in de sprint te maken. Dat past niet goed bij scrum. Dat vind ik wel: in een scrum sprint daar gooi je wel vrij makkelijk wat in en dat wordt dan door de groep opgepakt, maar juist het voorwerk dat moet je heel goed in plannen en afstemmen zodat dit klaar is voordat de sprint start. Dus de afhankelijkheid van functioneel consultants wordt steeds groter, dat merk je O: wordt het requirements proces en het product management nog volgens een bepaalde methodiek uitgevoerd? A: dat is wat ik bedoel, daar hangt dan geen scrum methodiek achter. Misschien zouden we dat wel moeten gaan doen hoor. Dat je daar dan ook een product backlog van hebt en dat de functioneel consultants daar dan op dezelfde manier mee omgaan. Dat doen we nog niet, ze hebben nu gewoon een workload, ze proberen gewoon de scrum voor te blijven met het maken van Story's. Niet dat daar steeds meer een bottleneck komt te liggen, we willen graag starten maar de requirements zijn nog niet helder. Dat is wel een aandachtspunt O: wat ik zeg maar in de literatuur tegenkom is dat er een grote groep zegt dat derequirements onderdeel is van het scrum proces maar dat er ook een groep is die zegt dat requirements in een apart proces afgehandeld worden. Dan worden bijvoorbeeld de product backlog gezien als derequirements, terwijl dit misschien een beetje kort door de bocht is dat dit maar een hele summiere beschrijving is van de requirements.

| Page 128 |


A: dat klopt je kunt wel allerlei zaken uit de product backlog gaan selecteren voor de sprint, maar dit betekent niet dat het ook klaar is om mee te nemen in de sprint. Dat is wel eens moeilijk. Eigenlijk zou het zo moeten zijn dat elk item op de productbacklog voorzien zou moeten zijn van uitgebreiderequirements. Dus helemaal uitgeschreven wat je precies wilt, vanuit welke rol en dan moet je dat zo in de sprint mee kunnen. Zo werkt het hier niet, vaak stand zitten er nog wat onduidelijkheden en er moet dan nog uitgezocht worden. Dat maakte dan wel moeilijker om uit sprintlijst zaken te halen om de sprint te vullen. Ik merk dat we dan steeds vaker afhankelijk zijn van wat de functioneel consultants opleveren. O: hoe zou je er tegenaan kijken om van het requirements proces een apart scrum proces te maken voorafgaand aan het ontwikkel scrum proces? A: wellicht is dat de oplossing daarvoor, maar zover zijn we nog niet. Ik zie het er voorlopig nog niet van komen. Als we een sprint gaan vullen met het maken van requirements, dan krijg je waarschijnlijk ook de situatie dat jerequirements gaat maken waar uiteindelijk helemaal niks mee gedaan gaat worden. Dat vind ik echt het grote risico. Je blijft wel reactief. O: maar wanneer zal het dan wel interessant kunnen worden, heeft dat dan met schaalgrootte te maken? A:... En voorspelbaarheid, het blijkt nu nog te vaak dat we hetgeen we moeten doen de komende maand of komende twee maanden dat het na een maand weer helemaal anders is. Om dan te veel voor te werken in die requirements, dat zou een verspilling van werk kunnen betekenen. We zijn ze te ad hoc hier, te veel zaken die er tussendoor komen, te flexibel, te verkopen gedreven. Om ver vooruit te gaan werken met derequirements dat voel ik gewoon nog niet zoveel voor. O: je zou voor derequirements natuurlijk gewoon een sprint van twee weken kunnen definiëren. Dan kijk je er maar twee weken vooruit A: ik voel er dan meer voor dat als we de requirements niet scherp hebben, dan gaan we in de komende sprint een ontwerpfase meenemen als zijnde een story. De sprint daarop kunnen we dan de requirements realiseren. Dan voel ik daar nog meer voor. En dat doen we ook wel eens. Om nou het hele requirements proces als een agile proces te zien ik weet niet of dat gaat werken.

| Page 129 |


O: en de sprintlengte hoe lang is nu een sprint? A: vier weken. In sporadische gevallen wordt er een lange sprint aangehouden. Wat er ook wel eens gebeurd is dat werk wordt niet afkomt in een bepaalde sprint dat dit wordt doorgeschoven naar de volgende sprint, waardoor de volgende sprint eigenlijk korter wordt. Dan gaan we dan handig mee om. O: de relatie tot de levenscyclus van het product, hebben we eigenlijk al een beetje besproken. Je ziet vaak dat ook eens verschuift van prikkeling van het product naar de efficiëntie van het proces. Dit gaat dan voornamelijk om efficiency en kwaliteit. Hoe zie jij dat? De sprints zullen nu voornamelijk issues en bugs bevatten? A: in principe vind ikagile daar minder geschikt voor. Scrum is het meest geschikt voor nieuwe modules en nieuwe functionaliteit waar je iteratief doorheen gaat. Zo zou het eigenlijk moeten zijn, met terugkoppeling of dat je het op knippen in meerdere blokken. We gebruiken het nu wel voor onderhouds items, puur weer om het netjes in te kunnen plannen en je capaciteit daarvoor te gebruiken. Eigenlijk zou het voor onderhoudsitems zo moeten zijn dat je een prioriteitenlijst hebt die afwerkt. O: als je bijvoorbeeld een sprint hebt met alleen maar onderhouds items, dan kan ik me voorstellen dat de sprint planning veel minder werk vereist? Of wordt het gewoon dan helemaal overgeslagen? A: het kost inderdaad minder tijd. Je hebt dan ook geenrequirements die om de hoek komen kijken. Je zult dan gewoon te sprint met storingen en de omschrijving daarvan. Die komen dan uit de helpdesk applicatie. Ik vind agile daar minder geschikt voor. Het is qua planning wel weer handig, dat het team hebben voorgehad dat je bij kunt houden wie waarvoor werkt. Daar heeft het wel een positief effect op, maar ik denk dat agile het meest geschikt is voor de initiële fase. Als je nog aan het bouwen bent met product en tussen versies oplevert naar de klant. Dat zie ik nu met cc zes ook, we gaan nu een versie voor Sion opleveren, een demo omgeving. Daarna weer verder voor Leeuwarden met aanvullende functionaliteit. Daar isagile heel geschikt voor. Ik vind agile ook weer minder geschikt in de hele prille fase, dat merk ik nu ook bijvoorbeeld als er nog gewerkt wordt aan de architectuur en je hebt nog niet echt iets tastbaars dan vind ik scrum iets minder geschikt. Ik vind het pas echt interessant als je ook echt kunt werken naar een release. Bij het opzetten van de architectuur is er dus minder geschikt en daarnaast is het in de onderhoudsfase en in de afbouw ook minder geschikt

| Page 130 |


O: ja, je zegt dan minder geschikt: misschien helemaal niet meer gebruiken of uitgekleed gebruiken? A: dat hebben we nu met cc zes ook gedaan. De eerste sprint was echt de architectuur op poten zetten en het aantal concepten bepalen. Je ziet dan dat er wel wat aan het sprintbord hangt, maar er wordt minder nauw gelet op de burndown. Het is dan minder gefocust op het opleveren van een release. Aan de andere kant zorgt het er wel voor dat je eindeloos in een architectuur fase blijft hangen, je ziet ook dat je door moet en besluitvaardig zijn, dat er knopen doorgehakt worden. Dat forceert het weer wel. Maar misschien in afgeslankte vorm. Het is natuurlijk heel moeilijk de requirements op te stellen, van de architectuur van het nieuwe product. Er zijn dan nog zoveel open einden. Het opstellen van de architectuur is al een deel het opstellen van de requirements. Dat hangt zo nauw samen met elkaar. O: dat heeft dan te maken met de productie visie. Is dat ook echt iets wat aandacht aan besteed wordt? Want ik kan me voorstellen dat als je zegt dat de architectuur nog niet helemaal duidelijk is... A: misschien is het ook een soort prefase van een product, dat je dat eerst duidelijk hebben. Maar ik zie wel dat zolang je dat nog niet helemaal duidelijk hebt, die nog niet keihard oprequirements kunt werken. En dan vind ik agile wel iets minder geschikt. Maakt het allemaal iets moeilijker planbaar, moeilijk in te schatten. Als je vraagt: hoeveel tijd kost het om de nieuwe architectuur op te zetten? Iedereen haalt dan zijn schouders op. O: als een product volwassen wordt dan gaat de focus meestal meer naar efficiency en kwaliteit, dat zou je daar dan eigenlijk wel mee kunnen bevestigen. Je gaat eigenlijk proces uitkleden en daar wordt het dan efficiënter van het gaat minder tijd kosten. A: ja klopt. We gaan dan wel scrum toepassen, maar dat is dan meer voor het plannen en het toekennen van resources. Je ziet dan gewoon dat het agile achtige karakter er af gaat. Je hebt dan geen nieuwe functionaliteit die je nog teruggekoppeld aan de klant. In de eindfase is het meer bugfixers. O: automatisch wordt natuurlijk ook de kwaliteit beter als je bugfix gaan. Maar wordt daar dan ook gefocust om de kwaliteit te verbeteren bijvoorbeeld met testen? Of is eigenlijk meer reactief, dat er alleen gereageerd wordt op de klant aanmeldt

| Page 131 |


A: er wordt dan wel meer getest, het is dan inderdaad reactieve, de klant meldt een bug. Dan wordt er misschien nog een regressie test gedaan, om te kijken of de omgeving om de oplossing nog werkt. Je krijgt wel een hele andere vorm van testen dan als je met een nieuw product bezig bent. Eigenlijk was het testen makkelijker je kunt heel gefocust testen op de gemelde bug. O: wat je ook ziet als een product volwassenen wordt is dat je differentiatie krijgt, kun je daar iets over vertellen? Met cc 5 en cc zes dat lijkt dan meer eendoorontwikkeling of een nieuwe technologie. Waarbij je dan het product weer opnieuw gaat introduceren in de markt A: ja daar komt dan wel op neer. We gaan het oude product over bouwen in het nieuwe product en delen hergebruiken O: wat is er dan in de essentie anders tussen die verschillende versies, functioneel gezien? Of komt het meer door de andere technologie waardoor het anders inzetbaar is A: ook dat, en als het bekend is dat er product verbeteringen doorgevoerd kunnen worden. We hebben een aantal modules die we proberen verder te verbeteren. We hebben nog een aantal modules die we links laten liggen en waar nog helemaal niks mee doen. Op zich zet je je producten opnieuw in de markt, met een nieuw jasje aan, maar we kijken ook heel kritisch welke modules niet meer nodig zijn, waar minder belang aan wordt gehecht. Uiteindelijk is het doel om tot een kwalitatief maar ook functioneel beter product te komen O: en wat is dan het punt waarop je zo een beslissing neemt. Je zou kunnen zeggen we blijven doorontwikkelen met de huidige versie A: het belangrijkste was eigenlijk om weer tot een product komen. Dus eerst hebben we het product gedifferentieerd en nu zijn we weer aan het integreren naar een product toe. Vooral om de auto en support kosten binnen de perken te houden. Dat spreekt een beetje tegen dat je steeds meer differentiatie krijgt, willen nu juist wel integreren om het beheersbaar te houden. Maar als je dat niet tegenhoudt dan krijg je inderdaad snel differentiaties. Veel differentiaties zijn gewoon kostbaar O: wat is dan een voorbeeld van een differentiatie? Openbaar vervoer zetten we bijvoorbeeld City Control in, dit is dan een andere markt

| Page 132 |


A: in Genève hebben we dan een versie neergezet die volledig web based is en in Nederland hebben we dat niet O: maar procesmatig zal het dan ook anders zijn als het buitenland gebruikt wordt A: ja er is een andere proces flow. In België hebben we weer een stukje financiële afhandeling die er in zit. Deze variaties proberen we nu allemaal weer bij elkaar te brengen. De wetgeving is ook anders, maar dit proberen we wel in dezelfde software te gieten door middel van configuratie. We hebben gemerkt dat differentiaties veel te kostbaar zijn, daarom gaan we nu weer naar een product O: dus eigenlijk hou u niet bewust rekening met dat de volwassen wordt, maar worden er intuïtief wel bepaalde wijzigingen gedaan A: bij cc vijf hebben scrum toegepast op bestaand product en bij cc zes passen we het voor het eerst op een helemaal nieuw product O: hoe zie jij dat verschil van scrum qua introductie? Wat zijn de grootste verschillen? Je had er natuurlijk ook wel ervaring mee A: vooral als de architectuur duidelijk is en er kan begonnen worden met het bouwen van functionaliteit dan scrum een goede toepassing

| Page 133 |

Agile requirements in different product lifecycle stages

Recommend Documents