Scrum what? - Agile Software Development, Kanban, Scrum Questions Answered! - Recent questions and answers

How does CD and Scrum work together?

Wed, 13 Jul 2011 04:00:37 +0000

I'm working for a company now that is trying to do Continuous Deployment by having daily releases. They sometimes release more than once per day. They don't have an automatic integration system. They visually test the product before releasing every day. The have also made an attempt to introduce Scrum. But, they don't have defined sprints. They have only one meeting called the standup, but it's more of a planning meaning for the day.

I have just come from a company that did Scrum pretty well. They also had automated Continuous Integration, but not deployment, and run on 2 week sprints. They intended to do CD, but I didn't stick around long enough to find out how it went.

I'm concerned that CI and CD mean me working long days every day, and sprints being not even as long as a story sometimes. I'm worried that burnout is around the corner, and that I'm not going to vest fast enough to make it all worth it.

Are there resource (books or web) that explain how CD and Scrum work together. I have never worked for a company that does it 100% correctly, and would like to know how it's done both for my personal and profession wellbeing.

Answered: online kanban tools

Thu, 09 Jun 2011 14:54:07 +0000

You can also check our ABSOLUTELY FREE product - http://kanbanize.com/

Our users rate it as great tool for distributed teams. Also, we do regular releases based on user requests, so there is a great chance that you get something implemented for you.

Just try it :)

Answered: How to implement Sprint Backlogs and Release cycles?

Sun, 16 Jan 2011 12:48:33 +0000

I would not create a gap. Better do all the release planning and going live preparation during a sprint. Sprints should create a takt and if you miss one, you are out of the rhythm of the sprints. That's not a good idea IMHO.

Answered: Continuous Delivery vs Continuous Deployment

Wed, 01 Sep 2010 16:20:20 +0000

Continuous deployment is about deploying every change that passes your automated test suite to production.

Continuous delivery it's only part of that. It enables you to deploy your software anytime the business wants, but it does not necessarily mean you deploy every change.

So in short, Continuous delivery means to be able to release at any point in time, but continuous deployment means to release every change automatically.

Hope this sheds some light into the discussion.

Answered: How to get management buy in for introducing scrum?

Sun, 18 Jul 2010 15:55:57 +0000

You can try to pitch it in a structured way: Situation - Complication - Solution. If you get a slot for a short presentation you can try to describe how you do things today, what issues you see with the current approach and how you think you can fix those issues using Scrum (or any other Lean or Agile methodologies).
Make sure you communicate advantages for the overall company or your managers - don't focus on what's nice for you only. Good luck!

Answered: Big companies using Scrum?

Mon, 21 Jun 2010 01:44:47 +0000

Microsoft

- http://blogs.msdn.com/b/robcaron/archive/2005/04/01/404782.aspx
- http://www.eweek.com/c/a/IT-Management/Microsoft-Lauds-Scrum-Method-for-Software-Projects/

Yahoo
- http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption
- http://askville.amazon.com/Lessons-Yahoo-'s-Scrum-Adoption/AnswerDetails.do?requestId=27229743&responseId=68634213

Salesforce.com
- http://www.slideshare.net/sgreene/salesforcecom-agile-transformation-agile-2007-conference
-http://www.salesforce.com/dreamforce/DF09/pdfs/BKSP001_Greene.pdf

Answered: huge app without test coverage

Wed, 02 Jun 2010 10:44:06 +0000

If your app is huge, you have probably no chance to apply TDD principles. So I think you should write integration (end-to-end) tests for your app.

I agree with the others, you should write tests when:

- a new bug is found,
- a new feature is being implemented.

In the beginning I suggest you to write some end-to-end test cases as well, focusing on the most frequently used features of the software.

There is a book on the topic (I have not read it yet): http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

Answered: Dealing with bugs in Scrum

Tue, 01 Jun 2010 17:36:17 +0000

I agree that for bugs that just get uncovered during new development, the best practice is to get rid of them immediately. The longer a defect goes, the more expensive it becomes for the company. If that means less functionality or a thinner slice of functionality in a sprint then so be it. Eventually as your team matures they will start to anticipate those types of problems and plan better during the sprint planning. (ideally!)

If you work on a large product like I do, then you may also have defects that come from software that has already shipped to your customers. In that case, we utilize a defect support bucket concept.. the size of this bucket is based on history of the previous sprints.. Yes I know in the ideal world, customers wouldn't find any bugs we have missed but unfortunately no matter how much TDD or automated tests we use.. those users STILL manage to find things we just didn't think of!

Answered: Kanban: Changing story acceptance criteria whilst story is ongoing

Fri, 28 May 2010 05:43:05 +0000

In my opinion the product owner should be able to change in any state. Changing the story just means it will stay longer in the development column blocking other work from entering (if the WIP is exceeded). For me, that's perfectly fine as no-one has committed to deliver anything within a certain time box.

Does that make sense to you?

Answered: What's the difference between TDD and BDD?

Fri, 28 May 2010 00:53:09 +0000

BDD is simply TDD done right! TDD is not just about testing it is about documenting the expected behaviour of the system and preconditions for that behaviour.

i.e.

BDD

Given the user is logged in
*** test code***
And they are an administrator
***test code***
When the deleteUser is called
***test code***
Then the user will be removed from the system
***test code***
And they will also be removed from any groups they belong to
***test code***

TDD (done badly)

Test SomeClass delete method()
***test code***

The top one can be read and understood by a domain expert, the bottom one the reader would have to guess the intended behaviour by reading the test code.

The advantage of BDD is that the same semantics can also be used for user stories and acceptance criteria. Therefore acting as a bridge between specification and code.

Answered: Why does our velocity bounce?

Thu, 27 May 2010 22:41:49 +0000

Velocity bounce is a common agile smell, there's no silver bullet but there and some common causes:

  - Sprint is too long (complicated domains need shorter sprints)
  - There is some form of external pressure (real or perceived) during sprint planning
  - Story sizes are erratic, try to standardise on MMF - http://bit.ly/93Z6cw
  - Developers are using science rather than instinct when estimating (try extreme time boxing of sprint planning, that will force instinct estimates)
  - Sprint retrospective is not analysing sprint planning estimates and asking what went wrong

If you experiment and find that quite literally the problem is that the team are poor at estimating, you might want to get them to try the pomodoro technique (http://www.pomodorotechnique.com/), it's extremely good at no only increasing personal productivity but also making you very aware of your estimation skill (or lack of)