Win a copy of Succeeding with AI this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Junilu Lacar
Sheriffs:
  • Tim Cooke
  • Jeanne Boyarsky
  • Knute Snortum
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • fred rosenberger
  • Frits Walraven

Clean Agile: Is scrum possible in maintenance projects

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ,

Congratulations on the new book. Agile is something which I have been reading about a lot lately because I think it's methodologies have impeded our growth rather than accelerating or facilitating the team. I understand that there are different flavors of agile scrum , kanban and so on. The team I work in works on maintaining as well as enhancing the application and we follow scrum method with 2 weeks sprint).

Now the part that doesn't seem to be working for us is , we take n number of story points based on an average of last 3 sprints and still either overachieving or underachieving it. Mostly underachieving , which puts a great deal of pressure on us towards the end of the sprint leading us  to work extra time to achieve 'sprint goal'. Why I believe it doesn't work is because in a maintenance cum development project you cannot keep control over expedite tasks , critical tickets from customers , Spikes and issues coming at us from other teams.  These are not measurable and therefore it is very difficult to include these variables to achieve a definite number of stories.  WHAT IS your view about this ? Does the book discuss this aspect of scrum and agile?

Another thing which puzzles me the most is the story sizing based on T-shirt sizes. Now they are relative but in maintenance teams most of the issues are one of a kind for eg. a DIFFERENT DB error eveyr time , so we cannot really relate to a base case until we have investigated it and found out the real problem. And once we know the real problem , every solution is XS .  HOW  do you think we can effectively give a suitable story points to each story so we have a meaningful result at the end of the sprint.

I apologize if the text is too long but i have capitalized the question word so that the question is not lost among the text. Thank again for providing this opportunity to interact with you.

Regards.
Rashmi





 
Marshal
Posts: 15565
263
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rashmi varma wrote:I think it's methodologies have impeded our growth rather than accelerating or facilitating the team.


Are you sure it's Agile that is impeding your growth?
 
Rashmi varma
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes , in my opinion scrum does not really suit a maintenance project and I have given detailed explanation for it as well.
 
Junilu Lacar
Marshal
Posts: 15565
263
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rashmi varma wrote:Yes , in my opinion scrum does not really suit a maintenance project and I have given detailed explanation for it as well.


So if you had a piece of wood to cut and you used a hammer to try to cut it, is it the hammer's fault that you failed to cut the wood?
 
Junilu Lacar
Marshal
Posts: 15565
263
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm just trying to follow your reasoning. You first said "it's [sic] methodologies have impeded our growth rather than accelerating or facilitating the team" and then said "scrum does not really suit a maintenance project."  Scrum is not the only way to be agile, just as a hammer is not the only tool you can use to work with wood. So to me, your logic in arguing the methodology is impeding your growth is faulty because by your own admission, you're using a framework that you don't think is suited for the kind of work you're doing, just as a hammer is not suited for cutting wood. So, is it really the fault of the methodology then? I'm not judging you, just trying to see through your logic.
 
author & internet detective
Posts: 39959
804
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My team does a mix of user support, maintenance and new development. We are a Scrum team. In fact, we are a long running Scrum team. We will be hitting sprint 200 this summer. (We work on many projects over time of course)

Rashmi varma wrote:Why I believe it doesn't work is because in a maintenance cum development project you cannot keep control over expedite tasks , critical tickets from customers , Spikes and issues coming at us from other teams and not to forget sick leaves. These are variables , not measurable and therefore it is very difficult to include these variables to achieve a definite number of stories.  WHAT IS your view about this ? Does the book discuss this aspect of scrum and agile?


My team uses a few techniques to deal with this:
  • We subtract about 45 hours for user support/ops. The exact number varies over time based on how long things take and holidays. But overall, it's pretty good. And it lets us deal with the small standard requests and problems on a timely basis. Can't connect to the binary repo? No problem, we can help
  • Switch to two week sprints. We switched a number of years ago. It's easier to ask people to wait 2 weeks in the worst case to be considered for the next sprint
  • Put bigger support tasks and defects in the backlog. Not everything is urgent just because it is maintenance
  • Have an awesome product owner. This really matters
  • Re-plan if needed. Sick leave can happen to any team. This has nothing to do with a maintenance project. As can other things. The first sprint that we were all suddently at home because of COVID-19, we definitely didn't complete the work we committed to. But we met with the product owner to replan. (I know Scrum says you are supposed to ditch the psrint and start over. We did not. But we ensured the work most important to the product owner got done
  • Be creative.  Understand the principles and values of Scrum and follow those over the letter of the law. I'd say my team does 90% of Scrum. But Scrum is a means to and end and we are achieving that. (Well not an end. Continuous Improvement)
  • Speaking of "not quite Scrum" and creativity: my team plans about 10% of our tasks each sprint to be "below the line". We commit as a team to do all the "above the line" tasks. And we will probably do some of the "below the line" tasks. But we don't promise which ones or how many. This ensures if tasks go fast or support is low, we can work on things important to the product owner. But if support is high, we haven't overcommitted ourselves.


  • Rashmi varma wrote:Another thing which puzzles me the most is the story sizing based on T-shirt sizes. Now they are relative but in maintenance teams many of the issues are one of a kind for eg. a DIFFERENT DB error every time , so we cannot really relate to a base case until we have investigated it and found out the real problem (which usually takes more time). And once we know the real problem , almost every solution is XS/S .  In any refinement meeting even if we feel a story is bigger than S and we cannot divide it further , we are too afraid to use M because well with T shirt size , the size of the story point increases exponentially (or in a fibonacci series ). HOW  do you think we can handle the sizing in a project where we have several "kinds" of stories without any base case to compare with? IS it really suitable for us? DO you think kanban(scrumban) is more suitable for these kinds of projects?


    I think the Scrum vs Kanban decision depends more on flow of work than how easy/hard it is to estimate. If you get a log of tasks that can't wait two weeks, Kanban is probably better.

    It's not just maintenance teams that have work that is hard to estimate in advance. This is true of research type work too. It isn't a reason not to use Scrum. Also, that investigation you talk about should be included in your story point estimate. If it takes 3 hours to find the problem, and 15 minutes to fix it, you have a four hour task. (round up for context switching and the like).

    For development tasks, we use story points as follows:
  • 1 - Trivial - very rare. Ex: upload a new license file that has already been obtained. This is a standard request, repeatable and easy
  • 2 - Small development task that we have a general sense of what to do.
  • 3 - Large development task or small development task that has a lot of uncertainty (it sounds like you have a lot of these)
  • 5 - Very large development task or large develpment task with a lot of uncertaintly. Rare
  • 8 - Has to be justified why it isn't being broken up. An example might be a vendor onsite or audit. Breaking that up feels arbitrary.





  •  
    Rashmi varma
    Greenhorn
    Posts: 16
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    ok
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 39959
    804
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    <moderator hat on>
    This forum is for discussion. The author is one of the people who will be discussing. Everyone in the forum is welcome to contribute and discuss.

    Also, let's assume all posters are being helpful rather than getting to "who said what".
    </moderator hat on>
     
    Junilu Lacar
    Marshal
    Posts: 15565
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It's too bad OP has lost interest because this is something that many people struggle with, including myself.

    Are points really useful? Some people seem to think they are. On the other hand, I've seen points being abused and weaponized against developers. In those cases, we end up back on square one with the developers feeling bad that they suck at estimation. Do we developers really suck that much? Or is it just the nature of some of the work we do?

    For example, if I'm dealing with a new input device like a barcode scanner and I have to integrate it into an existing app that uses a different kind of scanner, with a different device driver. How long is it going to take to integrate this new type of scanner? I would have no idea if I knew little to nothing about the driver, about the current design (do I need to refactor first?), about what kind of tests I'd have to write, etc. It's with cases like this that points become less meaningful to me. But then, when the process is rigid and we're coerced into giving a point estimate, then we just pull something out of thin air (or more likely, from down there) knowing full well we're probably 100-200% off on the wrong side. Should we say "points don't work!" or should we say "Trying to give a point estimate kind of don't make sense right now. Maybe later, when we know a little more."

    What I'm trying to get at is that there are a lot of tools that Agile gives us and in the right context, they're useful. In other contexts, not so much.
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 39959
    804
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I view points as a "work throttle". In your barcode scanner example, i"d probably plan a 5 story point spike with acceptance criteria like "barcode scanner integrated or list of remaining work." In the best case, the barcoded scanner is integrated. In the worst, at least I know more about it can have a conversation with the product owner about what was learned. And an estimate that is better than "I have no idea" for the following the sprint.
     
    Junilu Lacar
    Marshal
    Posts: 15565
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Jeanne Boyarsky wrote:

  • Be creative.  Understand the principles and values of Scrum and follow those over the letter of the law. I'd say my team does 90% of Scrum. But Scrum is a means to and end and we are achieving that. (Well not an end. Continuous Improvement)

  • I think this is really the key to your success, Jeanne. Unfortunately, and herein lies the rub, it often takes a mature team to realize this. Novice teams and agilists don't have this "Ha" (of Shu-Ha-Ri) mentality of going with the flow and rolling with the punches. They are compelled by their inexperience to follow the form (what they know) and when the form says "You need point estimates," that's what they lock their focus on instead of venturing into the unknown and trying to learn more about the problem.
     
    Junilu Lacar
    Marshal
    Posts: 15565
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I think this is a complex and multifaceted problem though. Teams that have difficulty in settling on a more or less reliable point estimate scale are often the teams that have a lot of technical debt. This is one of the main sources of the kind of problems that OP mentioned: expedited tasks, critical tickets, and requests coming from other teams. Architecture and organizational structure also often play a role and I'm often reminded of Conway's Law, especially when uncertainty revolves around design, architecture, and external dependencies (when will they have that service ready for us to use?). Another contributing factor is what teams often refer to as "technical debt" or what Uncle Bob simply calls "a mess," that comes from poor engineering practices. This is another often overlooked part of the puzzle of the failure to become agile.
     
    Junilu Lacar
    Marshal
    Posts: 15565
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I just found an encouraging passage in the book:

    In Chapter 2, Uncle Bob wrote:I expect estimates, and I expect them to be honest. The most honest estimate is “I don’t know.” However, that estimate is not complete. You may not know everything, but there are some things you do know. So I expect you to provide estimates based on what you do and don’t know.


    I think it's worth talking about these kinds of conversations. Bob goes on to further suggest maybe giving a range, like 5 to 15 days, "combining what you do and don't know into an honest probability for managers to manage." That is all well and good if indeed that information is used appropriately to manage outward from the team rather than inwards as it often is, unfortunately. By "outward" I mean that managers use the information of 5 to 15 days to see what kind of impact that may have with the schedule and how that affects downstream activities and commitments. This in turn should give them an idea of the likelihood of having to adjust plans going forward and potentially by how much.

    The problem, however, comes when managers use developer estimates to manage inwards, where estimates become "commitments" that developers get held accountable to, where going past the estimates (underestimating) somehow reflects poorly on the developers, as if they weren't doing their jobs or were less competent than what their original estimates would imply they should be. I know it sounds cynical but this still happens all the time, and may be even exacerbated by the (misinformed) expectations that some managers have of so-called Agile teams.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
      Bookmark Topic Watch Topic
    • New Topic