Forums

By posting to our forums you are agreeing to the Forum terms of use.
Experience report "Move from Waterfall to Scrum"
Last Post 14 Feb 2014 08:02 PM by Richard Lynn Paul. 14 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Christian
New Member
New Member
Posts:9
Christian

--
06 Nov 2013 06:16 AM
    Hello,

    I would like to share with you my experience of using Scrum.

    Background
    In the beginning of this year our team-leader proposed to use for our next project Scrum. Before using Scrum our team consisted of 5 software-developers which were used to work in a traditional waterfall process. I was one of them. Nearly for every one of us was Scrum something new. The target of this new project was to migrate an existing set of web-applications to an new software-stack. With migrating I don’t mean put an existing software application from Server X to Server Y. What we had to do, was completely rewrite those web-applications from scratch with another software-stack. This software-stack was quite new for us, we just made a few experiences with it in a Proof-of-Concept, and we expected a lot of complexity while the migration. From the business view (sales, marketing, etc.) the new project didn’t provide any benefit, cause there were no new features provided, but from the IT view we would be able to save a lot of money with the new (open-source) based software-stack. According to this situation our IT management decided to handle this project as an “internal IT-project” without as most as possible business interaction.
    The deadline of this project is fix (April 2014) and also the content (Migrate all web-apps) is fix. Because of several reasons we decided further against one external developer, so the resources four our project are also fix.

    Team forming / Preparation
    According to the fact that our team-leader was responsible for this project, he tooked the role of the Product Owner. I was interested to learn more about Scrum and so I voluntary tooked the role of the Scrum Master. The other four developers stayed in the development team. In addition it was the wish to integrate an test-expert (another department) and an UI-expert into our development team, to be so as much cross-functional as possible. So before we started our first sprint in April 2013 we had a Product Owner (our team-leader), an development-team of six persons and me as the Scrum Master. Before we dived into the first sprint I tried to teach the team as best as possible about Scrum (process, meetings, roles, DoD). Further we used a software-tool to organize our Product Backlog and our Sprint Backlogs. The tool was for free, it was used by two other developers of the company who tried to be “a bit more agile” and they recommend it to us. Before we began our first Sprint Planning meeting our Product Owner created the first PBIs in the Product Backlog.

    Sprint 1
    We thought that we had finished our preparation and so we decided to start the work. According to the fact that the content of this project was fixed I decided to use 4-week Sprint. I didn’t neither expected much change of the scope/content, nor I expected an strong business influence. Inside of the Sprint Planning meeting we found the first PBIs and the development team estimated them by “playing” Planning poker. Our estimations were based on optimal hours. The idea of using relative T-Shirt sizes was at this moment unknown for me. Finally at the end of the meeting we had an Sprint Backlog with several PBI’s and inside of those PBI’s we had created some tasks which we had to do in this sprint. It was just that, not more, and we thought it was not a bad start. For none PBI existed an acceptance criteria, all we got was an DoD to decide if an PBI was done.
    While the next four weeks the development team worked on the PBIs of the Sprint Backlog. At the end of those four weeks, when the time-box expired, we did the Sprint Review and the Sprint Retrospective. The team didn’t finished all PBIs of the Sprint Backlog, but the whole Scrum team was quite satisfied with the increment. There was no detailed check for the several DoD-criterias of the Product Owner for each “done” PBI of the Sprint, it was more some kind of “Black Box” approval. Inside the retrospective we found several points like “The requirements (PBI) were not detailed enough”, “The Sprint Backlog inside the software-tool was not up-to-date” or “We spent a lot of time while discussion design-possibilities”. Beside those problems the team identified also a lot of positive aspects like “Pair Programming is a cool thing”, “Increased quality awareness” or “KnowHow exchange”.

    Continue like this
    The next few sprints were quite similar to the first one, usually at the end of the Sprint we had enhanced the existing increment, but there often left some work of PBIs which were not done. We, as the Scrum team were still quite satisfied with the increment and no one was angry that the development team hadn’t finished the whole work of each sprint. The Product Owner didn’t really administered the Product Backlog, and so he communicated mostly in every Sprint Planning one or two rough requirements to the development team. That were his priorities. For the rest of the time the development team tried to plan the things by their own to do the things which would make most sense. Inside of the retrospectives we found further items, which were good and bad in our development process. For some of them we found solutions or workarounds to remove those impediments, but others stayed open. One thing what we changed for example was the Sprint Duration, which we shortened from 4 weeks to 2 weeks to easier plan the Sprint and to increase our reactivity.

    Big Liberty
    Before we began the new project there were three developers (including me) and our team-leader responsible for the support of the existing web-applications. According to the fact that I wanted to shield the development team as much as possible from the support-duties, I proposed that just our team leader and I would be responsible for all support-duties of the productive system. With this proposal we reached the target that the other two developers could work concentrated on the new project, but on the same time it was clear that the Product Owner (our Team-Leader) and I (Scrum Master) spent a lot of time with the supporting/maintaining the productive applications. In the result we both were just able to be a “time-partial” Product Owner and Scrum Master. For the development team this had a big impact, because the part of the “Inspection” from the Product Owner for the product were affected as same as the “Adaption” part for the impediments of Scrum Master.

    Impediments
    One positive aspects is that we are now able to make our impediments transparent. On the other hand we were just able to solve small and simple impediments in the past. Beside the above mentioned “time-partial Product Owner and Scrum Master” problem I think that we’ve got in our project at least the following three major impediments: “Test Driven Development (TDD) is not established”, “Code Quality was improved, but our process allows it still unclean code” and “Technical documentation doesn’t really exists”. According to the TDD our major issue is that we don’t have a set of “intelligent” test data, against which we would be able to create our JUnit Tests. Without them, our automated unit tests can’t be really reproducible because the data records in our development database can be changed overnight. To tackle this problem I wrote a concept and a small prototype to record stable test data records. To finalize this work and to create a solid base of “intelligent” test data records I estimated an effort of 10 days. In the end we discussed this with our Product Owner (=Team Leader) and he refused this work according to the ambitious project deadline of the 30.04.2014. I know that Scrum doesn’t prescribe the development team to do TDD, but at this moment I was disappointed about this decision, but I also understood his reasons for this decision. Today I believe that there exists another problem according to this situation. According to the fact that I (or we) are not able to solve also the bigger and harder impediments I believe that members of the development team are no longer willing to spent their time in the Retrospective to make our impediments transparent. This behavior is wrong, but I understand them, cause why should they spent their time in Retrospectives when in the end nothing (important) is changed?

    Definition of Done (DoD)
    Yeah, we have one ;-), but unfortunately it is not really present. Before we started our first sprint I let created the DoD by the Development Team. Inside of our DoD there are typical points like “Code is checked-in”, “Code conforms Code Conventions”, or “There exists Unit Tests for our code”. Some of them are a bit vague, but in general it is not that bad. Several points of the DoD are used by the Development Team, other not. One option can be to revise the existing DoD.
    Before a Sprint Review begins, the Development Teams has set most of the PBIs of the Sprint Backlog to “Done”. The Product Owner just checks the applications from a “Blackbox”-perspective, without the DoD. Further he doesn’t check each PBI, which was set to “Done” by the Development Team, if it is really “done” for him.
    Perhaps we ‘ve here a misinterpretation cause the Scrum Guide says “…The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;”. On the other hand the guide says “
    The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;”. So, while the Development Team has finished the work on a PBI of the Sprint Backlog on which state does it sets this PBI?

    Management
    Our management knows that we do Scrum, but I believe that it does not know much about Scrum. It was also not their idea to use Scrum, this came as described from our Team Leader. One import points which comes from the management and strongly impacts our work is the project-end of the 30.04.2014. According to this, I don’t think that we ‘ve the required time to remove impediments as needed and to optimize our development process.
    Further people of the management are not yet involved in the Sprint Review. For the management exists once per month a steering committee were our Product Owner (Team Leader) presents the current state of the project to the management. I think this is wrong and our managers (stakeholders) should come to the Sprint review. In addition I know that our Product Owners administrates a Gantt-diagram to visualize the project progress to the management. I think that this is also wrong, and instead of the Gantt-diagram it would be correct to invest the required time in the Project Backlog. On the basis of an proper Product Backlog, which contains the estimates for the PBI, it would be also possible to make forecasts for the project end to the management.

    Failures
    Were made a lot… Just with that little Scrum knowledge we had before we ran into the above mentioned situation, which contains the description of multiple failures. Beside this I would firstly check the next time if Scrum makes sense for the project and the company. In our case there were several preconditions (lack of technical excellence like TDD, missing Scrum knowledge in Scrum team, unsuitable software-tool, missing management-support) not met. Another important issue are the double roles which the Product Owner and I play for the maintenance of the productive system. Additional to this, the Product Owner is for us also the Team Leader.
    One important activity which we haven’t also do yet is the integration of the “Product Backlog Refinement”-Activity inside of our Sprints. I think with doing this our Product Backlog would be make sense and be current.

    Forecast
    Regardless of the described situation, I believe that we can reach our target and finish the work before the deadline expires. Perhaps people will think that we did Scrum inside this Project, but I think that we did a lot of work like we ‘ve did it before. One result will be that we will see a lot of productive bugs after the project-end, which needs to be fixed in a maintenance project. Further I would expect that we get critical performance issues, because the performance testing is neither automated nor part of the DoD. Our developers will be frustrated about this, and they will get an Déjà-Vu with the situation that happened several years ago when we created the current productive system. People will think that Scrum didn’t helped us to write software better and faster, and so they will not continue this way.
    I think that we just do “a bit of” Scrum, and I know in this case we shouldn’t name it so ;-). I think we are just in the transformation process from an traditional waterfall process to Scrum. The biggest advantage of Scrum for me was to make our weaknesses transparent (to me), and I think that the next step will be the creation of this transparency also for others.
    I believe that this project was planned to tough, to not just build the Product, but also improve the process. Scrum will be a success story for us when people understand that they have firstly to invest in things like “technical excellence” and they need to understand that the creation of the Software can take longer than on the traditional way, but in the end it will be much cheaper because thanks to a good quality the costs for maintenance will sink.

    What do you think about this situation? Have you made similar experiences?

    Best regards,
    Christian
    StanD
    New Member
    New Member
    Posts:1
    StanD

    --
    07 Nov 2013 09:32 AM
    Hi Chrisitian,

    Sounds like a bad start, especially in the adoption of Scrum / Agile in your organisation. Not the right project (fixed scope / fixed date) and a lack of knowledge and experience to be succesfull.
    Get yourself an experienced Scrum Master who can facilitate your team and get your organisation aware of the potential of Agile / Scrum. And what you really need to be succesfull. A bit of Scrum is no Scrum. Just use it as it's ment to be...

    Best regards,
    Stan
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:559
    Ian Mitchell

    --
    07 Nov 2013 10:37 AM
    > According to the fact that I (or we) are not able to solve also
    > the bigger and harder impediments I believe that members of the
    > development team are no longer willing to spent their time in
    > the Retrospective to make our impediments transparent. This
    > behavior is wrong, but I understand them, cause why should they
    > spent their time in Retrospectives when in the end nothing
    > (important) is changed?

    That's a shame, because getting better transparency is a useful outcome of a Sprint Retrospective. The problems that you can't solve need to be made clear to those who *can* fix them. For example, this might be done by flagging blockers on a task board, or a RAID log or dashboard, or by only accepting work that you know you are able to finish.

    > So, while the Development Team has finished the work on a PBI
    > of the Sprint Backlog on which state does it sets this PBI?

    What you need is a signal that a given item is ready for review by the Product Owner. This could be a state that is simply called "awaiting review". The Product Owner does not have to delay until the Sprint Review before reviewing items.

    > Regardless of the described situation, I believe that we can
    > reach our target and finish the work before the deadline
    > expires. Perhaps people will think that we did Scrum inside
    > this Project, but I think that we did a lot of work like
    > we ‘ve did it before.
    ...
    > What do you think about this situation? Have you made similar
    > experiences?

    I suspect that you have indeed done a lot of work the old way. When you talk about how you can "reach our target and finish the work before the deadline expires", that's a very waterfall and stage-gated view. It indicates that risk is still being deferred to a "deadline".

    In Scrum work should be finished regularly in timeboxes - that is the essence of incremental release at the end of a sprint. For example, if there are 10 sprints and you are on Sprint 9, the accumulated risk should be very low at that point. You should have delivered value continually and the highest risks should already be mitigated.

    What you seem to have achieved, however, is a greater level of transparency than you had before. That's the first and most important step in agile adoption, so keep on with this. In my experience, a problem that is seen clearly and acknowledged is on its way to eventually being solved.
    Christian
    New Member
    New Member
    Posts:9
    Christian

    --
    07 Nov 2013 03:04 PM
    Thanks for your opinions! I don't believe that it is possible for us to switch from one day to another complety from Waterfall to Scrum. Did this anyone before? I think this is a change process, and we are now doing some "ScrumBut", but it is clear that I'm not satisfied with the current process and I want to improve it.

    According to Ian's Statements I have some thoughts:


    That's a shame, because getting better transparency is a useful outcome of a Sprint Retrospective. The problems that you can't solve need to be made clear to those who *can* fix them. For example, this might be done by flagging blockers on a task board, or a RAID log or dashboard, or by only accepting work that you know you are able to finish.

    According to the fact the our company uses the traditional waterfall process for all the other projects, I don't believe that we are in the position to refuse work. Further I think that we have quite most of the required skills to fix the impediments, but the problem is that we are not able to bring them in the next Sprint. There is a big difference on our side between the importance of the product (which matters) and the (un)importance of the process. Finally I think that it is also a shame, that we do the work the makes the impediments transparent, but we are not capable to fix them.


    What you need is a signal that a given item is ready for review by the Product Owner. This could be a state that is simply called "awaiting review". The Product Owner does not have to delay until the Sprint Review before reviewing items.

    I like this proposal. I'm just afraid that in practice this pattern will not work alway for us, because our Product Owner will be occupied with other tasks outside of this project. I think that this is an "impediment" which just could be fixed by the management if they really want it.


    I suspect that you have indeed done a lot of work the old way. When you talk about how you can "reach our target and finish the work before the deadline expires", that's a very waterfall and stage-gated view. It indicates that risk is still being deferred to a "deadline".

    In Scrum work should be finished regularly in timeboxes - that is the essence of incremental release at the end of a sprint. For example, if there are 10 sprints and you are on Sprint 9, the accumulated risk should be very low at that point. You should have delivered value continually and the highest risks should already be mitigated.

    I agree and really like the point about the risk which is deferred to a deadline. What we do in each of our Sprints is to produce a working increment which is shown to the Product Owner, and quite only to him... So we have here in fact a much higher transparency than before for us as the (Scrum) team. But what happens on our side, when we don't see in a specific sprint much progress? Nothing! We just continue with the next Sprint and do there some of the work, which was not "done" in the previous one. As I've written it in my initial post, I think to better understand and estimate the risk of our work, we firstly need to setup a proper Product Backlog, because with this we will be able to estimate the work which left and so to estimate the end-date.

    Greetings,
    Christian



    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    07 Nov 2013 09:13 PM
    > ! I don't believe that it is possible for us to switch from one day to another complety from Waterfall to Scrum. Did this anyone before?

    I've coached several organizations to do this. They change the process framework immediately (usually after a 2 day training class and about a week of "Pre-Game"), but the waterfall mindset and culture can take months or years to switch.
    Christian
    New Member
    New Member
    Posts:9
    Christian

    --
    08 Nov 2013 12:44 AM

    Posted By Charles Bradley - Scrum Coach and Trainer on 07 Nov 2013 10:13 PM
    I've coached several organizations to do this. They change the process framework immediately (usually after a 2 day training class and about a week of "Pre-Game"), but the waterfall mindset and culture can take months or years to switch.


    What do you thing are the key points for being succesfull in a most short time? How was the Management support in those cases? Did they known before the benefits of Scrum and being Agile?
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    08 Nov 2013 06:29 PM
    Thank you for sharing a comprehensive description of your scrum adoption!


    ...

    What you need is a signal that a given item is ready for review by the Product Owner. This could be a state that is simply called "awaiting review". The Product Owner does not have to delay until the Sprint Review before reviewing items.

    I like this proposal. I'm just afraid that in practice this pattern will not work alway for us, because our Product Owner will be occupied with other tasks outside of this project. I think that this is an "impediment" which just could be fixed by the management if they really want it.


    By making this visible, it's more likely to be fixed. The PO will see it on the task board (you do have a task board that's visible to everyone, right?) and when things start piling up in that column he may feel more pressure. The team should be trying to fix things themselves and not rely on management to do it, and this should also be discussed in the retrospectives (it sounds like it is). If it *has* to be management that fixes it, they could either see the problem from the board or it could be brought to their attention.


    As I've written it in my initial post, I think to better understand and estimate the risk of our work, we firstly need to setup a proper Product Backlog, because with this we will be able to estimate the work which left and so to estimate the end-date.

    If you want visibility on whether you will complete the work by the deadline, then yes, you need a full product backlog with all the PBIs that must be completed. Then you can do release planning, for example with a burndown chart by sprint.

    As an additional comment about prioritization... you're migrating an existing product and are mandated to include all functionality, but some functionality will be more important than others, and the PO is the one to do this. You say that he talks about one or two PBIs as his priorities and the team selects other things to do. The PO is responsible for the backlog and at a minimum is responsible to have enough PBIs in sufficient detail to fill the sprint.
    Christian
    New Member
    New Member
    Posts:9
    Christian

    --
    09 Nov 2013 02:51 AM
    Dear Robert,
    thanks for your helpfull input.

    One important point which you have written concerns the transparency of the the task board. We 've got a task board about the current Sprint, but this one is just based on the (not-ideal) software tool which I've mentioned in my initial post. So, each person who is interested in our work has to "pull" the information by opening the tool. I know that this is not ideal. I think those information need to be more transparent to everyone, especially to our management. The information should be "pushed" to them. I believe what really would help would be a big screen at the entrance of our bureau which just shows the Sprint Taskboard, the Sprint Burndown, the Product Backlog, the Release Burndown and the Impediment Backlog.

    About the responsibilities and the completnes of the Product Backlog I agree with you.
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    09 Nov 2013 09:44 AM
    I suggest a physical whiteboard with post-its. Google "scrum task board" for images and you'll see what I mean.

    You don't need software. I can't imagine doing an agile transformation without big physical information radiators. Maybe if you had a huge screen I could see it working with software.

    It can be jarring to introduce that into a workplace, especially if the culture is one of clean and tidy desks but IMO it's very important. Nobody can ignore it, and it shows that the way of doing things is changing.

    What happens is that everyone can see the work. People can also see when someone gets up to move an item from one lane to the next, it's a signal for the change in state of the task. Everyone can see how much is Done, which is also important, as we tend to forget the things we've finished and instead focus on all the things we still have to do.
    Christian
    New Member
    New Member
    Posts:9
    Christian

    --
    14 Nov 2013 09:37 AM
    Hello,
    i think our impediments can be summarized, and those things should go in our Impediment Backlog:
    - Missing transparency of the Scrum artifacts (Product Backlog, Sprint Backlog, Impediment Backlog)
    - Missing Product Backlog Refinement Activity
    - Missing Acceptance Criterias for PBI
    - Weak Definition of Done (Missing Test automation, Missing Performance Test, Weak technical Documentation)
    - Missing Product Owner and Scrum Master support (time-partial roles)
    - Missing Scrum Knowledge
    - Missing Management Attendance
    - Weak Software-Tool Support
    - Old waterfall tradition is still present (Organization structure, Gantt diagrams, steering meetings, Scrum Master is leaded by the Product Owner…)
    - Missing “Definition of Ready”

    Beside those points, I've got an uncertainty about the following aspects:
    - For me it is still unclear how deep should the Product Owner check the created PBIs by the Development Team. How do you handle this in your projects? Does the Product Owner checks each criteria of the DoD for each created PBI?
    - Does there exists exceptions for the idea of a cross-functional team? Our web-applications support for example different languages, and according to the idea of a cross-functional team I would except that we've got a language translator for just a few ours per Sprint in our team. Today we don't have this person in our team, just send the required translation to an external translator.
    - I don't have a good understanding what should happen when PBIs of the Sprint Backlog are not "done". I know the Product Owner should check then if he can use the "done" work and put the undone work back to the Product Backlog, but my questions affects another point. What should happen when this happens over several Sprints, again and again. Does the Product Owner has any "tools" to push the team? I don't thing so, because the Product Owner just can "pull" the work from the Development Team. But what are the consequences of this? I think the only option for the Product Owner is just to stop all the work of the Development Team, but this would mean that the whole projects stop also...

    Best regards,
    Christian
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    15 Nov 2013 12:06 AM
    I'll speak to your questions first from a personal perspective, realize that it differs from ideal scrum.
    - PBIs for us are either stories, bugs, or tasks. Stories have acceptance criteria and story points. Bugs have expected results but not acceptance criteria. Tasks are things that need to be done (not coding) and also do not have acceptance criteria. At each review, the PO (me) checks that all the stories meet all the acceptance criteria. It's the teams responsibility to ensure that the stories meet the Definition of Done, I assume all stories meet DoD if they're in the Done column. If the development team says bugs and tasks are Done, I similarly assume they meet DoD. Full disclosure, I do check business critical bugs during the sprint but not at the demo. Our DoD includes coded, reviewed, QAed - all within the control of the team which is important. Since we have some regulatory compliance our process is pretty controlled and it would be hard for a story or bug to reach Done without meeting the DoD, so I can't remember any reworks based on not meeting DoD after the sprint review. So for us, checking the DoD for each PBI would be a waste of time. I can think of other environments where it would make sense to check the DoD for each PBI during the review, but for us, it's handled during the development process. But it sounds to me like your PO is not checking the PBIs enough which I'll get to in a moment.
    - We try to avoid a PBI that cannot be completely owned and completed by our cross-functional scrum team. It really shouldn't be in the Sprint Backlog if the team cannot do it themselves. You can change acceptance criteria and/or DoD so that it is not dependent on external resources. Using your example, I would have a story that would have in its acceptance criteria that a page can be viewed in multiple languages, without requiring it to have the words translated properly. The actual translations by the external translator could be done after, during, or before the sprint but wouldn't be tied to whether the story is Done or not.
    - If you are repeatedly having PBIs marked as Done, but then being put back into the development pipeline because they're not actually Done, then you have a serious problem. Did they not meet the acceptance criteria? Then you have a problem with PO inspection at the review. Did they not meet the Definition of Done? Then you have a problem with dev process or with the DoD. Did they meet both the acceptance criteria and the DoD but the PO is saying they are not working after the fact? Then you have a requirements problem and they should be new PBIs and not reworked PBIs.


    I've just reviewed your first post again, and I think you'll have a lot of trouble actually adopting scrum in your situation, and possibly damage your ability to implement it in the future.


    In the beginning of this year our team-leader proposed to use for our next project Scrum.

    Why? Because you need to respond more quickly to the business? Because your waterfall approach is not working? You will need at some point to provide a business case as to why you should adopt scrum.


    According to this situation our IT management decided to handle this project as an “internal IT-project” without as most as possible business interaction.

    So scrum without business interaction? The whole point is to be able to deliver value prioritized by the business in small increments to allow for frequent requirement changes while shielding the developers from the problems caused by frequent requirement changes.


    The deadline of this project is fix (April 2014) and also the content (Migrate all web-apps) is fix.

    If your requirements are fixed, why do you need agile? But also, if requirements are fixed, why are so many PBIs being approved as Done and then needing to be done again?


    On management support, it's important, and it sounds like you don't have it. But it will be difficult to get their support, because as you've said, this project has no business value except as a cost savings for IT. So the risk is that management will only pay attention if you miss your deadline, at which point the culprit may be "all the time wasted on this scrum stuff" rather than all the impediments that you identified during inspection and retrospectives. You will need to bring a solid business case to management as to why scrum should be adopted and why they should support it.

    I think you've got a good summary of impediments, but are these impediments to getting the work done, or to adopting scrum? For example, why do you need management attendance? All of the scrum ceremonies are to benefit the team and management should not be required in a self-organized team.

    Also, why is the team-lead who initiated the scrum adoption negligent in PO responsibilities?
    Christian
    New Member
    New Member
    Posts:9
    Christian

    --
    15 Nov 2013 09:21 AM
    Dear Robert,

    your thoughts are again really helpful for me. Thanks a lot for this input!


    …Since we have some regulatory compliance our process is pretty controlled and it would be hard for a story or bug to reach Done without meeting the DoD… So for us, checking the DoD for each PBI would be a waste of time.

    I think an important part which differs between our companies concerns the regulatory compliance of the software development process. For our development team it is possible to deploy software on the “demo machine” without doing steps which would be required by the DoD. Some of those steps are for example reaching a specific percentage of test-coverage or creating a technical documentation.

    In the beginning of this year our team-leader proposed to use for our next project Scrum.

    Why? Because you need to respond more quickly to the business? Because your waterfall approach is not working? You will need at some point to provide a business case as to why you should adopt scrum

    Well, I don’t know his initial thoughts, and the team had not known much about Scrum. There wasn’t a business case created for this decision. I think it is clear, that it was a mistake to not scrutinized this decision. I assume that some of his ideas were to foster team collaboration and to get an higher efficiency.

    On management support, it's important, and it sounds like you don't have it. But it will be difficult to get their support, because as you've said, this project has no business value except as a cost savings for IT. So the risk is that management will only pay attention if you miss your deadline, at which point the culprit may be "all the time wasted on this scrum stuff" rather than all the impediments that you identified during inspection and retrospectives. You will need to bring a solid business case to management as to why scrum should be adopted and why they should support it.

    This one is so true. I think it will not be enough to just make our impediments transparent, instead I agree with you for the need of the business cases.

    I think you've got a good summary of impediments, but are these impediments to getting the work done, or to adopting scrum? For example, why do you need management attendance? All of the scrum ceremonies are to benefit the team and management should not be required in a self-organized team. Also, why is the team-lead who initiated the scrum adoption negligent in PO responsibilities?

    The impediments hinder us in a establishing a better software-development process. Without this improvements we will not be able to be more effective and in middle-term we will not be able to provide “more” product-function into our Sprints. Nearly all which counts in our organization is the short-term benefit and so are the product tasks much higher ranked than the process improvements. Without management attendance we will not be able to change this. Also for the negligent PO responsibilities, our management has to understand that it can’t well work when people are overloaded.
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    16 Nov 2013 12:44 AM
    Happy to provide input and enjoy the discussion. I applaud you and your team for attempting to improve. I hope the feedback you get on this forum is helpful.


    I think an important part which differs between our companies concerns the regulatory compliance of the software development process. For our development team it is possible to deploy software on the “demo machine” without doing steps which would be required by the DoD. Some of those steps are for example reaching a specific percentage of test-coverage or creating a technical documentation.

    It sounds to me then that the PO should be reviewing the DoD for each story in the demo as you alluded to earlier. Is the PO concerned about the stories that are accepted and then sent back into the Product Backlog? You could suggest that inspecting the PBIs more closely could mitigate this. After some time, the team will realize that a story won't be accepted without it actually being Done and will become more diligent. Once that happens, inspection of the DoD should become a formality.


    (why did team-leader propose scrum?)
    Well, I don’t know his initial thoughts, and the team had not known much about Scrum. There wasn’t a business case created for this decision. I think it is clear, that it was a mistake to not scrutinized this decision. I assume that some of his ideas were to foster team collaboration and to get an higher efficiency.
    ...
    (management support)
    This one is so true. I think it will not be enough to just make our impediments transparent, instead I agree with you for the need of the business cases.

    Ok, so you are doing it to get better. One way to make a case for scrum adoption is to prove that it is making the team better, through higher quality and/or output. Unfortunately, it sounds like no-one outside the team is watching and will only notice what you are doing if you don't meet the deadline. So you could show velocity or have some other metric (# of features/sprint, # of pages/sprint) to show the benefits you've reaped so far (if there are any - are there?), but will they care since they are focused on short-term benefits and the product you're building has no value until it's totally complete and can replace the legacy system?


    The impediments hinder us in a establishing a better software-development process. Without this improvements we will not be able to be more effective and in middle-term we will not be able to provide “more” product-function into our Sprints. Nearly all which counts in our organization is the short-term benefit and so are the product tasks much higher ranked than the process improvements. Without management attendance we will not be able to change this. Also for the negligent PO responsibilities, our management has to understand that it can’t well work when people are overloaded.

    The impediments you list are your opinion of the impediments and not the team's identified impediments, correct?

    You cannot count on management involvement for process change relating to this scrum adoption. They did not mandate it and might think that the short-term benefit IS more important than process improvements because maybe they think the process is fine. They might also think it's fine for the PO to not have enough as much time as you think is necessary for this project because the project doesn't add any value until it's done and the other things they have him/her doing may be more valuable.

    Establishing a better process should happen naturally by the team identifying ways to improve (and implementing them - we use a did this improve checklist for all the proposed improvements each sprint). These should be things within the team's control.

    For impediments, I reviewed the scrum guide and it seems to me that the removal or mitigation of impediments is owned by the ScrumMaster. On our team, we call out impediments during review/retrospective and have a mitigation strategy (although sometimes that strategy is 'live with it' if it's something that will not be fixable).

    Keeping in mind the primary goal is to provide valuable working software (and not a working scrum team), here's a review of your impediments from your first post.


    “time-partial Product Owner and Scrum Master” problem

    Your PO and SM are overloaded with support responsibilities and can't dedicate the time required and requested by the team. Can those support responsibilities be transferred to someone else or can others without those responsibilities become the PO and SM?

    Test Driven Development (TDD) is not established

    How is this an impediment to completing your PBIs? Is there something in the DoD that would require TDD?

    Code Quality was improved, but our process allows it still unclean code

    How is this an impediment to completing your PBIs? Does the code work?

    Technical documentation doesn’t really exists

    How is this an impediment to completing your PBIs? Is it in the DoD? If so, see my previous comments about inspecting DoD by the PO.

    I'd encourage you to engage the team on what they think the impediments are and how they think they should be mitigated. Maybe you've done that but the way you've presented it in your posts is what you think the impediments are. You're probably right, I've been there where I can see the problems, but you should focus on what the team thinks the impediments are and try to resolve those because then the team will be much more open to identifying impediments if they think they will be addressed. When you get an impediment where you think 'only management can fix this' try to brainstorm with the team as to other ways you could workaround or reduce the impact of the impediment. They may come up with some creative ideas.
    Christian
    New Member
    New Member
    Posts:9
    Christian

    --
    20 Nov 2013 11:27 AM
    Again Robert, thanks a lot for your inputs!

    Is the PO concerned about the stories that are accepted and then sent back into the Product Backlog?

    The PO knows which items were “done” and which are not “done”. According to the fact that he is “time-partial” his granularity of the different PBIs is not very deep.

    So you could show velocity or have some other metric (# of features/sprint, # of pages/sprint) to show the benefits you've reaped so far (if there are any - are there?), but will they care since they are focused on short-term benefits and the product you're building has no value until it's totally complete and can replace the legacy system?

    The benefits of our Scrum implementation is an really important points. Which is better since we use Scrum? According to our development process I’ve written several points in my previous posts. For me the biggest advantage is that we/I have now an better transparency about strengths and our weaknesses (potentials). One thing which I’ve not spoken about concerns the benefits according to our product. For me one really important aspect is here the earlier feedback from our test-experts and our business analysts instead of the old waterfall process. With Scrum we don’t wait until we ‘ve finished each parts of an application and then show the app to the tester and later to the business. We involve those persons much earlier and are so able to bring their feedback in the product, which increases the acceptance and the product quality.
    But to be honest, there are other points which will usually come with Scrum which we haven’t yet. For example I think of the priority of our PBIs. Usually when an project has an fixed end-date, but the content is variable it is clear that just the most important parts are done, and for example not the lowest priority requirements.

    The impediments you list are your opinion of the impediments and not the team's identified impediments, correct?

    No this is not correct. The impediments which I’ve listed here are the sum of both (the Dev-Team and me as the SM).

    Establishing a better process should happen naturally by the team identifying ways to improve (and implementing them - we use a did this improve checklist for all the proposed improvements each sprint). These should be things within the team's control.

    I don’t fully agree with this. I believe also that the team should identifying ways to improve. One formal meeting for this is the Sprint Retrospective. To remove an impediment or to establish a process improvement, I believe that in most cases it needs an initial effort. Someone has to do something. I think that Scrum provides two possibilities to realize an process improvement. One possibility is that the SM does the work, or the other possibility is that in the next Sprint this task (process improvment) is planned and the Dev-Team will work on it. The problem in our situation is that in quite all situation I don’t have the required time to do the process improvement from my role as the SM, and on the other hand the PO and management don’t really care about process improvments in this project, because the prioritize the Product work much higher, and so in the end they are not planned in the next sprint(s). So, I don’t believe that improvement process is for us in our (team’s control) hand.

    Can those support responsibilities be transferred to someone else or can others without those responsibilities become the PO and SM?

    The idea is good. I thought also on it, but we are in an project with fixed resources and so there is no possibility to reorganize this.

    (Test Driven Development) How is this an impediment to completing your PBIs? Is there something in the DoD that would require TDD?

    For me TDD is not that important as automated regression tests, but TDD is a way which allows teams to build and establish automated regression tests. Inside of the DoD, the team has written “automated regression tests”, so this is an point which is violated for quite each “done” PBI. But who cares? The PO says, that he doesn’t has the required budget to establish an set of test data records which is the pre-condition to do the automated regression tests… But back to your question how this points hinder us in the completion of our PBIs. Scrum says that while a Sprint the product is not just developed (coded) but also tested. For the first sprint this is quite easy, because there is not “much” functionality which can be tested. With each Sprint the functionality of the increment increases and so the effort to test the increment. Now – without automated regression tests exists two possibilities. The first one is, that the regression test will be done by manual tester(s). It is clear that this one would be very expensive and time-consuming. The second approach is that just the new features of the sprint will be tested. In consequence the effort for the test is not so high, but in consequence the quality of the test will be worse. The result of this is that we will find bugs much later and the fix of them will cost us much more than it will be the case with automated regression tests. We do the second approach, but I believe that neither of those two approaches is something which is acceptable. The only “escape” is the test automation.

    (Code Qualitiy) How is this an impediment to completing your PBIs? Does the code work?

    A weak code quality affects us in each future Sprint and will decrease our velocity. When we ‘ve to enhance a component, and this one isn’t written well, it is clear that future changes will be more expensive. According to the fact that Scrum and Agile foster the idea of “Collective Code-Ownership” and try to avoid “knowledge-silos” it is obvious that for some new developers they will spent more time to understand the existing code, before the will be able to make the required changes. It is quite similar also for your third mentioned point about the technical documentation.

    I think were a quite done in this thread, or at least we need a break. For me the next important task is to increase to transparency of our situation in the company. People firstly have to understand what Scrum is, what Scrum is not, and what miss to getting better. Then I’ve to make clear our impediments, and with each of them I should “estimate/calculate” the impacts (best in money). I think this will be a lot of work, but it is the only thing which will work. This information can be understood by our Management and so I hope that the required process improvements will get an higher priority than before.
    Richard Lynn Paul
    New Member
    New Member
    Posts:3
    Richard Lynn Paul

    --
    14 Feb 2014 08:02 PM
    Quick change was possible due to an outstanding Department Leader.

    I participated in an agile-scrum department that was able to double programmer productivity almost immediately—but there was some temporary stress increase as the change from waterfall to agile was made—they were able to produce a User's Guide for each feature while the programming and QA was happening, and they were able to release features most needed by customers in a truly agile and quick manner.

    They accomplished this by the following practices and some others:
    An analyst prepares some ideas for a project's features and then schedules a meeting (Feature Blitz) where all the development team [domain expert(s), programmer, code reviewer, SQA engineer, the analyst, and any manager that really wanted to attend] decide the features needed, their specs, their implementation, the proposed order they will be coded and list of dependencies, breaks them into iteration-sized mini-projects, and at the end of the meeting assigns people to each of the above roles for each mini-project. The specs are the notes and digital photos from this meeting. Next each member of the team enters estimates of hours for them to finish their role's work for each iteration or mini-project. The managers, in Iteration Planning, then swap around any resources or mini-project to maximize the use of everyone's time, keeping in mind that changes may require the new team member to meet with the analyst or others to get up-to-speed on what happened at the Feature Blitz and that the new team member may not be able to do the role's work as fast as the one who helped decide the particular implementation in the Feature Blitz. Next there is a commitment meeting where the development team (the four roles besides domain expert) commits to their deadlines even if they have to do overtime, which rarely happened because people became good at estimating their work ability. Simultaneously during an iteration, the analyst writes the User's Guide, the QA engineer wrote a test suite with corner cases and exceptions that programming may not have thought about, the programmer and code reviewer discuss the details of the implementation and do the coding. Obstacles and progress were discussed frequently among the whole team and communicated to management and other stakeholders. QA tested each code drop so a programming path that wasn't going to work was caught quickly and little code had to be thrown out. QA had enough time to do their job properly and checked how the feature functioned with other features. Analysts, QA, programmers, and domain experts generated other enhancement ideas not only for the project, but for other projects as there was more time for exploratory testing, prototyping, and thinking about the entire product/program. At the end of the iteration, the released product was more closely bug-free than the waterfall methodology. Lastly, QA had test suites that could be assigned in the future to other QA members or customer support for re-testing prior to each product/program release.
    You are not authorized to post a reply.


    Feedback