Respect the Sprint

You may have seen an AgileThought person around town wearing a nice black “Respect the Sprint” t-shirt…but what does “Respect the Sprint” mean?

Well, it has several meanings, and can be interpreted a few different ways, but here’s what it means to me:

Stick to the time box you set for yourself

There will be no “adding a few days” at the end of a sprint.  Believe it or not, I’ve seen teams do this before.  “Hey, we are almost done, so let’s just call next Tuesday the end of the sprint instead of this Friday”.   This is breaking a basic Scrum rule, and should not be done.   Period.

Take the “don’t change the sprint goal” rule seriously

Once you are in a sprint, do not fall to pressures of “hey can you do this story too?” and “can’t you just squeeze that story in”?  Or even worse “Forget those 4 stories you are in the middle of, drop everything and do these 3 stories you’ve never heard of instead”.  A reason for short time boxes is to resist change to the goal during the time box and focus on completing that goal.  At some point, we have to have something solid to shoot for, and we adjust our sprint length to the shortest possible time we can resist change. 

Play like you are behind

If you are working towards a major release, and that release consists of multiple sprints, you should have a sense of urgency even in early sprints.  Make sure you are hitting your goals you set each sprint, and getting things to done, not half-done or not even started.   Don’t have the feeling that those early sprints don’t count – if you get behind early, you aren’t going to make it up later by working harder.   Don’t let your team fall into the trap of looking at the release plan for a minimally viable product and thinking “It’s only sprint 2 – we have tons more time before we can release anyway – if we don’t meet our goal this sprint, we’ll make it up later.”  It’s easy to have the mindset that you have some huge cushion, and you then don’t meet your goals early on because you don’t feel the pressure of delivery – you must Respect the Sprint – get those early sprint goals done!  

That’s what Respect the Sprint means to me – it might mean something different to you. 

respect-the-sprint

Advertisements

Branching is easy, merging is hard

David Rubinstein of SD Times recently published an article on branching and merging titled “Branching and Merging: the heart of version control” at http://www.sdtimes.com/content/article.aspx?ArticleID=36328&page=1 

In this article, David discusses the rise of distributed version control systems (DVCS) within the software development community at large.  While I cannot disagree that DVCS systems are gaining in popularity, I personally have not yet seen them dig deep roots into the enterprise space yet.  I think there are multiple reasons for that, some perhaps that will never be overcome.

First, take the CTO/CIO perspective.  Your responsibility is the software systems of your company, and the source code of those systems is the most critical asset.  Are you going to store that critical asset in a system where there is no master centralized version?   Would you run an accounting system where there are many, many copies of the General Ledger?  (Well, maybe you do if you are doing something illegal!)  Especially those software systems that run financial transactions, or that may have compliance requirements, a DVCS solution for source code control is going to face a tough battle to get adopted because there is no central source.

From a configuration and release management perspective, there is a firm need to understand what code shipped when.  Companies need to be able to answer the question “what code did you ship to production” in a definitive and accurate way.  DVCSs need to be configured and governed such that that question can be answered, especially when the auditors come around asking questions.   The DVCS tools available today do not provide much help in answering this question, as they do not enforce a strict promotion model, and rely on the people using it to enforce that model.

From a developer perspective, I more often than not see enterprise developers struggle with merging.  Even simple merging, in my experience, is seen as a major overhead and a scary thing that can break code bases badly.  You simply cannot use a DVCSs without having a firm grasp on merging.  If developers are struggling with straightforward merging of with a centralized version control system (CVCS), it is not going to get any better for them with a DVCS.

As noted in David’s article regarding CVCS tools, there are several complaints that I’d like to address.

• Broken builds: With everyone ultimately working in the main line, code reconciliation on large projects is extremely difficult.
If code reconciliation is a concern, then this must be a bigger or at least the same concern with DVCSs, right?  With large, active projects, this is just the way of life, and a tool cannot solve it, centralized or distributed.  If you have a lot of code to merge, then you have a lot of code to merge.  Period. 

• Branching limitations: This prevents parallel and agile development from taking place.

Maybe this is just my experience, but I have not seen any modern CVCS tools that prevent parallel or agile development from taking place because of branching limitations.  When you need to create a branch, you create it, use it, and merge back regularly.  Once the branch isn’t needed anymore, get rid of it.  Have a plan for creating branches and stick with it.

• Arcane branching patterns: Users are locked in to their tool of choice.
Again, I’m not aware of any good CVCS tools that strictly enforce “arcane” branching patterns.  You define the branching pattern that you put into place in a CVCS tool.  I’m also not sure what is meant by “locked into their tool of choice”.  Doesn’t every version control system lock you into it?  

• Not distributed: Makes remote development difficult in terms of access to code.

Generally, yes, but CVCS vendors are addressing this.  If you have a centralized repository sitting in Atlanta, and have developers from India working on it, access could be slow.  Then again, the DVCS answer is to replicate the entire repository locally, making access fast, but you would think at some point you’d want to push code back to Atlanta?

A great example here is the upcoming release of Microsoft Team Foundation Server 2011 (TFS).  In these blog posts, Brian Harry of Microsoft talks about merging enhancements and offline workspaces that bring DVCS-like functionality to Microsoft’s CVCS product.

http://blogs.msdn.com/b/bharry/archive/2011/08/31/merge-enhancements-in-tfs-11.aspx

http://blogs.msdn.com/b/bharry/archive/2011/08/02/version-control-model-enhancements-in-tfs-11.aspx

• No flexible release cycle: Does not enable continuous integration and agile deployment of code.

I definitely have not seen this before.  At AgileThought, we are using a CVCS (TFS), and do extensive continuous integration, and agile deployment of code, through a structured promotion model.  I actually see this as a disadvantage for DVCS’s – since there is no central repository, where do you do continuous integration?  The answer I’ve seen often is to do define a single “blessed repository”, have someone sit in the role of “integration manager”, and routinely push to that repository so a continuous integration build can be run.  All in all, a very manual process, but CVCS tools support this concept very well. 

As pointed out in Mr. Rubinstein’s article, distributed systems have their drawbacks as well.  Git has an steep learning curve, and right now requires knowledge of a command line.  While “command prompt only” should never be a blocker for professional software developers, in my experience, it can stall adoption if developers are forced up a steep learning curve.  Also, the lack of a central source repository may not sit well with those responsible for the safekeeping of their companies source code. 

DVCS systems are extraordinarily powerful, and CVCS vendors have sat up and taken notice.  DVCS will likely always remain the de-facto standard for hugely distributed, contributory projects (such as open source projects).  However, I don’t believe that in the enterprise space, that a pure DVCS solution will be the future, but rather, a hybrid of CVCS with DVCS-like features.  Tools like Git will continue to innovate DVCS features,  and CVCS vendors will likely adopt the best features to address the needs of enterprises.