[#ALM] 3 Sprints, that’s what you need to get a team started seriously (and of course … let’s go Argentina!)

Hello!

This year, I’ve combined events oriented to developers, with a more business-oriented events. The difference is large, but it is amazing when you start talking to “the boss” of a hospital and explains a framework like SCRUM. He understands the basis and, in 15 minutes later, we can begin to talk about how transparency can help him in his daily basis.

Note: “the boss” is his personal presentation, this person is the director of a hospital and as has a title like CTO, CIO, CEO, CXXXXO the truth that tide.

In the middle of the nice talk, he asked me a classic of team management,

How long it takes a team to “start working well” under this framework?

The question has history. In general, to run a framework like SCRUM , the team that adopts this framework must implement it correctly. However, it is almost more important than the organization / company or context within which the team works also creates and adopts the values of SCRUM. I ever wrote about in an organization is harder to SCRUM for that SCRUM out in.

Having said that, and having a team that understand and adopt the values and practices of SCRUM, most experts agree that 3 sprints is the ideal amount of time in which a team can measure their work and begin to be productive. This is separate from the duration of the sprint, it can be from 1 week to 4 weeks. The important thing is that the practices associated with it are met and that the retrospectives are carried out well, POs to understand its value at the moment of arming and prioritized Product Backlog, etc. If you’ve been able to work in a team during more than 3 Sprints, you’ll see how metrics like “velocity” really starts to make sense and as the pace of work of the team begins to be more dynamic.

Returning to business events, this week I was in Nice at an event aimed at telecommunications companies. And once again, I was surprised to see as in the TELCO world, measurement of 3 weeks also applies to these types of projects. I was commenting on a similar theme with some people who are dedicated to create a layer of… software? on a “very special routers”, and at the time raised the possibility of posting their APIs on AZURE API Management, agree on how a complete cycle of several Sprints would need to start to have a serious idea of a co-ordinated team.

Now is time for me, so I can “cry a little” in my particular case. I work on very fast / short projects, and where the same objective carried out by more than 3 Sprints is an utopia. Another utopia is to think in the same team working more than 3 consecutive sprints (I call them elastic teams).

My experience in this particular case is based on the following:

Even if people can change in a team, it is important to have one or more people who bring forward best practices learned during the history of the team. Never, I repeat never, you should completely change the members of your team.
People can change, but the lessons remain. Implement a Wiki or a similar repo is important. In our case, what works is a OneNote shared in OneDrive, for us this brings very good results.
Unless you know the consequences, do not force or twist best practices. For example, if you decide not to implement a CI cycle, you must be aware of the consequences that this brings. In my case I have learned these lessons badly and pulling long hours during nights out personal errors later. Now that I know the context and I know what I stand, a Scrum Master helps me to carry them out.
It is essential that the Definition of Done, DOD is very clear for all: team, Product Owner, cleaning lady and even your mother. The equipment change, the user stories evolve, but the quality of what is expected to deliver cannot be changed .
It is not a bad practice to change the DOD. You can only do this between Sprints, never should change a DOD in the midst of a Sprint.
Technical debt (Technical Debt) is something that I still don’t have a good advise to share. I know that there are parts of a solution where I’m sacrificing today to pay it tomorrow, and also at certain times forced us as a team to not sacrifice nothing. I have not clear. (I think I expressed it in the best way for 3 years in painting walls, changing diapers, and the technical debt)
Finally and fundamental, it drives the fluid inside your team communication. Using tools such as Skype or Lync, tries to be mostly face to face, etc. Unless you’re programming SKYNET, surely you’ll be creating an app for people, and work with people… all said no?