Wham bam, thank you ma'am - a case against quick & dirty Sprints
Ok, ok, I confess. You will notice anyway I've been a software developer all my live and not one of those business type of guys who somehow ended up in IT and usually work in sales, marketing or even worse become a project manager and nowadays Scrum Master. You surely know these guys who talk about and often are responsible for software development while actually being unable to tell a static method from a Boolean and will look for a String pool in Acapulco, never suspecting this to be non-isle Java.
I've been spending my live engineering software, which means doing UML, data modeling, BPMN before eventually actually coding. Java, in my case (yes, there are String pools!). I'm one of those die hard kind of guys who still claim thinking before coding works best and who hate any sort of quick hacks, dammit! Dirty of some sort might be funny elsewhere, but not in my code.
I recently noticed a disturbing trend towards 2 week Sprints and blame mentioned business people for it. I understand why: biz folk don't know what's going on, don't understand developers and the code they come up with and therefore need timely Increments to at least have a feeling of control. What else can they do than hope for something clickable that doesn't crash?
So let's have a look at a 2 week Sprint, say we're starting Monday. There's the Sprint Planning taking place which shouldn't take longer than 4 hours, given you've got 8 hours for a 4 week Sprint. So half a day of your 10 work days is already gone, if developers actually start working on the Increment right after planning. Despite continuous integration, the application needs to be tested before an Increment can de delivered.
Even if you actually got world's fastest and best testers, you'll have to have code freeze on the 2nd Wednesday, at the latest. My bet is this won't work and you're gonna end up with an almost untested Increment. But let's assume a lunatic Wednesday freeze at lunch time, so you're left with just 7 days in a row to produce software. So do you really think you're gonna get much done in just 7 days including thinking about the best approach for a task, talking to colleagues to make sure you merge smoothly, write code with unit tests and do continuous integration in general? What about incidents and misunderstandings that will happen and cause some code to be worked on twice?
Well, all those tasks can of course be done by a development team of 3 - 9 members, but I wonder what kind of application you're working on. 'Hello World' for your girlfriend's phone?
My experience says 7 days is usually too short for professional software development, even if you've got a perfect Sprint Backlog and no questions will pop up during work. What if a question actually pops up that causes the Product Owner to turn to the stakeholders, who of course need at least 1 day to come up with a hopefully reasonable answer? In what kind of world will be no Impediment that causes delays?
Shall I assume a perfect Product Owner who's Product Backlog never contains a single mistake? Once again, what are you working on, a mobile banking app or another 'Hello World'? I bet there will be lots of panic and hellotta short cuts and quick hacks toward the end of every Sprint, just to meet the deadline. People will start to code as soon as possible, reduce thinking time which will of course cause trouble down the line and pretty soon lots of technical debt. Sprint after Sprint, the Increment will become less stable as developers stopped talking to each other to save some more time. Good luck with your 2 week a.k.a. 7 day Sprints! If you allow time for Review and Retrospective, you're gonna end up with even less development time.
I'd plea for this: Have a Product Owner and a Scrum Master who actually understand software development and can trust developers or at least are able to ask the right questions in between. They could and will be happy with a 4 week Increment, knowing it will enhance quality to allow developers to work 15 days in a row without trying to fake stability every 2 weeks. This would actually allow code freeze end of Monday or Tuesday of the last week if needed to thoroughly test the application before delivering a stable, releasable Increment.
My conclusion is this: The greater the shortage of competence outside the development team, the shorter the Sprints. Just for a feeling of control nobody has anyway. Black box fear doesn't make for a sound strategy, does it?
To me, 2 week Sprints don't make any sense if we're talking 'bout demanding, serious software. 4 week Sprints should allow enough time for professional software development, including thinking, arranging items with colleagues and proper continuous integration and stakeholders to be happy with progress.
Just make sure Product Owner and Scrum Master at least understand software development and you're gonna be fine. And please don't forget to take time into account for Daily Scrums plus Review and Retrospective at the end of each Sprint. Those important events will surely fit much better if one got 4 weeks.
Pinky promise (I was told this is the most valuable),
Marc Smeets
P.S. a dedication I promised: Thanks Bazzar Café @ Metro Düsseldorf for serving lots of food and Cappuccino and enduring me while writing. Girlies there unfortunately refuse to type my handwritten stuff, let's see if this dedication is gonna help.
Thank you for sharing your thoughts, Mr. Smeets. I've worked in productive two-week Sprints quite a bit and even advocated one-week Sprints for one product. I'd like to better understand your experiences and hope that the following will be helpful.
We certainly agree that thinking before diving into coding is invaluable! With refinement of the Product Backlog, Sprint Planning, and daily inspection and adaptation are you seeing Scrum and Development Teams stumbling? Is it a manifestation of bad practices? Is there an expectation of more up-front documentation? You made a comment regarding work not beginning after the Sprint Planning event. Has the Development Team decomposed enough tasks to begin work? Do they need to complete a bit more white boarding before ending Planning?
Testing is also key to the agile software development philosophy and Scrum. What practices, such as Test or Behavioral Drive Development, could improve the quality of the increment? Does the Development Team operate in a Waterfall manner and need to become more collaborative? From your comments it sounds as if that is how things are operating which is deadly. Are the automated build, automated testing, and continuous integration solutions inadequate?
There is a relationship to the previous issue and a panic near the end of a Sprint. Are the Sprint Backlog items too large? Is the Development Team biting off more than it can chew? A code freeze that far from the end of the Sprint is often indicative of a process of late testing. Would better collaborative test planning, test development, test execution, and test evaluation help alleviate the pain?
Needing to return to the customer for clarification during the Sprint absolutely has an impact on progress. What can be done to mitigate that? Does it happen frequently? Perhaps the conversations in developing the items need to be more effective. Some uncertainty may still arise, so how is that handled? Can a decision be made based on past experience? Is it more beneficial to just make a decision now than to delay the work? Is there a issue with implementing something then eliciting feedback during the Sprint Review event?
The comment about allowing time for Sprint Review and Retrospective is very troubling. The lack of the former means that the customer is not reviewing every increment which may be a contributor to some of the other issues. The lack of the latter means that reflections and improvements are not occurring which may be a significant impediment to change for the better.
In a two week Sprint, there are a base 80 work hours per person. The events remove a maximum (assuming half of the one month time-box length and 10% refinement) of 18 hours.(4, 2, 1.5, 2.5, 8). So we still have 62 hours (almost 8 days) per person to collaborate on meeting the definition of done for the increment. Sure there will be more time consumed by business requirements but the goal is to reduce them in order for the Development Team to focus. It is is difficult to grasp the concept of a cross-functional team needing more time than that to create even a small piece of functioning and tested software; there must be other factors causing that ineffectiveness.
In the end, the length of the Sprint must be whatever is best for the Scrum Team to create a done increment. Bringing to light those smells that indicate that there are problems with processes or organization is a benefit of the Scrum framework. Not identifying and addressing those issues means that they will probably continue to manifest despite a longer Sprint time-box
Hi Alan (if I may address you like this),
thanks for participating! I'm glad you have different experiences than mine and you're of course right with your analysis. You surely remember my fairy tale post (https://www.scrum.org/Forums/aft/2043), you replied to that too. This post is basically the second part and the result of recent experiences.
You saw me advocating for a Product Owner who at least understands software development, and this is the major point and main reason for longer / 4 week Sprints. If your Product Backlog is far from perfect, you're gonna run into trouble sooner or later and end up with questions only stakeholders can answer and changes of scope of committed items at the end(!) of a Sprint. You can surely imagine how fast you're running out of time under those circumstances.
Continuous integration, BDD and the like unfortunately don't make up for improper requirements, but your 100% right about the value of those, of course. Allowing time for Sprint Review and Retrospective sometimes actually requires quite some 'catfights', given you're dealing with clients used to waterfall. You surely encountered the same problems and needed to convince people. Sometimes, it just takes a while as it is hard to change old behavior at client's side.
Thanks again for your reply, you're welcome,
Marc
Yes, sir, Alan is fine. I went back to enjoy your tale once again! It helps to read this thread with the continuation aspect in mind. I wish you well on that journey.
I can understand your desire for a Product Owner with solid technical understanding. My experiences have shown me the opposite where the Product Owner continuously attempted to dictate the how. Finding and developing the right mix of people can be challenging.
Displaying the value of incremental and iterative software development to the customer can be an adventure. If they do not want to commit to reviews (whether weekly, bi-weekly, or even monthly), then the product will suffer. It's even more challenging if the Scrum Team is having difficulties performing well.
Thank you very much, Sir! I surely should have marked this post as second part. If I come up with another follow up, I will flag it as such.
I assume we all have the same problem world wide: people have difficulties switching from waterfall to Scrum. I can surely understand the difficulties you had with a dictator kind of Product Owner. Jesus Christ...
I think all we can do is try to help people understand what Scrum can actually do for them if properly implemented and keep pushing for improvement. I won't give up and you surely sound the same.
Thanks again for your replies and remarks,
Marc
Hi,
I think longer sprints would enable us to think about software architecture before starting to code. I would like to have time after code freeze for code review. Of even greater importance would be a continuous clean up cycle (independent from the current tasks) for merging code fragments, restructuring and code supervision in general to enhance quality.
Greetings
Jörg
whatever the length of your sprint, you can allocate, let's say, around 15% for architecture debate ; around 5% for clean-up...
Your increment must respect the DOD, whatever the length of your sprint.
If you don't have enough time in one-week sprint for architecture / test / review, how would you have enough time for that in 4-weeks sprint ?
> Your increment must respect the DOD, whatever the length of your sprint
Correct, and furthermore it is better to have longer Sprints in which a better DoD is observed rather than shorter ones with a weaker DoD.
Clients often tell me that they are doing 1 or 2 week sprints, and try to wear this as some sort of badge of honour. However the DoD is usually either absent or weak or simply not being observed. Ironically, when I advocate longer sprints of closer-to-release quality, they think I'm advocating a reduced level of agility. Politics is often behind the situation as short sprint length can be paraded as a vanity metric, whereas the technical debt being racked up is hidden and potentially someone else's problem.
Some work during a sprint cannot be measured relatively in percent.
There is always a minimum effort for conversation:
going to the meeting room, say hello, some nice smalltalk to be friendly.
So the shorter the Sprint, the more influence of this (not useless) absolute time.
Einstein is not always right: "not everything is relative"
Longer Sprints can assist with achieving a stronger Definition of Done. They can also result in the business or customer expecting more features delivered. If the team is less amture it could also lead to larger accumulations of technical debt. I believe there is a balance to be sought through understanding the Scrum Team, the organization, the customer, et al. that could change as the factors change. Of course I'm not advocating frequent Sprint length changes! Agreed . . . Wearing Sprint length as a badge of honor is certainly a mistake either way IMHO.
I propose you this metaphor.
You drive your car, and you want to drive as fast as possible, so you need high level of transparency on your speed.
If your speed is too high, you get arrested by the police and pay a fine. You lose money and time = technical debt.
You want your digital "speedometer" to be updated very frequently (ie short feedback loop = short Sprint)
But you also want your "speedometer" to be accurate (ie high level of quality = strong DOD).
A short feedback loop whithout accuracy gives poor transparency, and the opposite also.
I think it depends a lot on the kind of stuff on your backlog how a 2 week sprint duration turns out. I am the PO of a devops team that has 2-week sprints. Usually we only need 1 hour for the sprint review, 1.5 hour for the retrospective and rarely more that 2 hours for the sprint planning.
Sometimes we have complex issues involving other teams that cannot be completed in 2 weeks. In this case we may assign a separate user story for integration testing, which is usually very complex and time consuming in our case.
Also we start our test preparation we we are still building the software. We should do this better, because the developers can anticipate better ont eh test cases to expect.
It is still hard to complete all items in a two week period. But the advantage of a 2 week sprint is that it helps a lot to create focus. It forces developers to co-operate on a few items (we usuall hve less than 10 user stories in a sprint, with 8 developers). It helps to do devops. It allows to start a sprint with some larger issues and fill it with really small issues near the end.
Scrum states that team size should be 3-9 developers. A smaller application will require fewer developers while a larger one would require multiple teams of developers. It’s nothing profound in my last statement but bear with me.
The tricky part with an immature team is correctly gauging their capacity. There are no silver bullets and of course there’s the relative estimating strategies and team-consensus decision making ones like Planning Poker and Fist-of-Five. While these are certainly helpful, inexperience teams may not provide accurate estimates. Therefore, the only way to truly know is to run some Sprints and monitor/analyze the progress. Doing so will give the team quantitative data that they can input back into the upcoming Spring Planning session to subsequently construct a more feasible Sprint Backlog.
I would recommend paying closer attention to the team’s velocity. Refer back to any Sprints in which the team deviated from the Sprint Plan and try to indentify the culprit. An interesting case study analyzed a software engineering class using agile software development and concluded that the velocity stabilized after three Sprints: https://www.researchgate.net/publication/224236694_A_Capstone_Course_on…
This will vary by team, but working towards a stable velocity could assist with frequently releasing quality software to the market, which is a pinnacle in software development.