You know something is wrong…

These words are a follow up of the article: Scrum is not agile.

In there I presented an opinion about why I think Scrum, although an agile methodology, is pretty restrictive. Now, let’s say you want to use Scrum in your project, but the organization is not willing to do it. What can you do in that case? I will try to explore different paths here that can help in that situation.

When you are participating in a development effort, sometimes you see that things are not going well. People are frustrated, there is a lack of order in the process and there is a lot of room for improvement. It does not matter if you are a developer, a QA engineer, or something else in the team, you can still push towards using a given methodology to improve the process. I have seen teams that, even having a Scrum Master, did not apply the methodology as they should.

With this post, I want to give you a few tips on how you can start making small changes towards the end goal of using Scrum. This is not the only way, and also, depending on the characteristics of the project, the organization, or even the people within the team, you may encounter that you need to implement everything as a big-bang, instead of gradually. Again, this is just my point of view, things I have done, but it is definitely not the ultimate recipe.

Starting small: Standups and Sprints

The first small step you can take is to have a daily meeting. This, as it usually is with sprints, may already be happening in the project. So no big change here.

The other thing that we need is to have the notion of sprints. If you are not using sprints in the project, this may seem like a big change. But, nowadays, a lot of software projects use some sort of sprints, so I believe you will not have issues here.

The duration is something that presents a challenge. I have tried one week sprints, and these are my conclusions regarding that:

  • It may be good in those cases where the requirements are too hard to be groomed. Just because it may be easy to be able to build a week worth of work, than two or three weeks (at least at the beginning).
  • In general, it does not give enough room to work comfortably, because you need to be able to deliver an increment by the end of every week.
  • Pressure may also be an issue, everything seems urgent (it has to be done this week!).
  • Tickets need to be smaller. Sometimes, a ticket just cannot be broken down into smaller pieces. This may be a problem with only one week of sprint, there are a lot of chances of it becoming carried over to the next sprint.

In my opinion, the best duration is two weeks. This gives the team plenty of time between the beginning and the end, removes pressure, allows bigger tickets and it is widely used.

Be true and transparent

Ok, so now we have sprints and daily meetings. We are getting there.

First of all, you have to be firm on the idea of using Scrum. And more importantly, you need to have solid evidence on why you need to start using it. The evidence may be:

  • Metrics: these cast light on a lot of problems that we are facing, such as, a high number of defects, a high number of defects per user story, average time that it takes for a ticket to be done, etc. Be aware that this is information that no one likes to see, but it is important, because we want to be better.
  • Feelings: there is no way of measuring this (at least that I know of). But you know how you feel, and you know how the team feels. You can see it right there in their tone of voice, in the participation in meetings, in the willing to create good things (good code, good design, etc.). In other words, you know if the people in the team are motivated and involved in the project or not. You may be asking “what do feelings have to do with software development?”. That is a fair question. In my opinion, happy workers produce better results. They just work better. They care about their work, and their coworkers, and are willing to make an effort at work.
  • Costs: you know things are not working out. You know there is a long time between a ticket is started and finished. You know that a ticket that should take a given amount of time is taking twice or three times longer. This immediately traduces in expenses. It´s a great initiative to try to reduce costs working better. And for sure, the organization would love to hear such initiatives.
  • Any other thing you have at hand: the items I mentioned before are my usual go-to evidence. But you may find or see others in your project. For example, you may be seeing that development is slow, increasing the time-to-market of your application. Use that.

Most of the times I tried to start using Scrum for real, I saw that people get onboard almost immediately. They say “let’s do it!”. But, as any other change, it takes time to really happen. So you will see that, while they get onboard easily and fast, they may fail when the actual work should start to happen.

Being transparent” means to me, that you need to sit down and prepare your case. Defend the methodology, present the current situation (the evidence), and state, very clearly, why Scrum will fix those problems. When I know I will have to have that conversation in the near future, I start collecting examples. I try to force the process onto some of the tickets, and measure the results on them, comparing with other tickets (non-process ones). Sometimes this is an eye opener, because you are saying “I want for us to start using this process, because HERE you can see the outcome” (with project work!).

Make it happen, but gradually!

We know that changes are hard for people. Process changes are not the exception, so my advice is: be patient. Changes take time and effort, so don’t get frustrated if you do not see results right away.

In my experience, what works best is to gradually perform the change. Baby steps towards Scrum will allow you to get some of the benefits, while laying the ground for the next steps. It will also motivate people to get onboard, when they start seeing those benefits taking place.

The big change: do Grooming

In my personal opinion, in any software development methodology that we use, we need well defined requirements. It doesn’t matter if we are using user stories, use cases, scenarios or any other requirements definition templates: we still need a proper amount of details for those requirements to be implemented. Failing to add details to requirements, guarantees problems when we try to implement them.

So, if your project does not have grooming sessions, this is the place to start. Grooming, according to pure Scrum, also implies estimating the tickets. But if I were trying to make the organization start following Scrum, I would settle with adding proper details to ticket.

Requirements that respect quality attributes (incose) bring the following benefits:

  • They speed up the development, because developers do not need to ask a lot of questions, the details in the ticket are enough.
  • Increased morale and motivation in the team: suddenly, tickets are clearer, developers can focus on building great software, without any blockers along the way, without waiting for answers, without being blocked by other parts of the organization (UI/UX design people, for example).
  • Tickets are now sizable: we are not doing it yet, but you know you could.
  • Product Owner will see that, when tickets have more details through grooming sessions, he/she will spend less time answering questions, and can invest that time on thinking about what feature to work on next.

Next in the queue: Estimate and Plan

If you have successfully established ongoing grooming sessions, the team has the dynamics of asking questions to the PO, getting answers, getting details in the tickets. The team as a whole, is working more comfortably. Next step is to add estimates.

Regardless of the schema you choose to represent the story points, it is a key milestone to have size in the tickets. If the team sizes the tickets (preferably in the grooming sessions), it will have a pretty good idea of how many story points it can complete in each sprint. The velocity is the average number of story points that the team can complete in a sprint.

This piece of information allows the team to have a better planning: if we know our velocity, we can add tickets to the sprint up to that threshold. This has several advantages:

  • Prevents the frustration that the team feels with the carry-over tickets at the end of each sprint.
  • Allows management to have a better idea of when things will be done. For example, the Product Owner may know that a given set of features are estimated in 150 story points. If the velocity is 50 story points per sprint, then he/she knows, with a good level of confidence, that it would take 3 sprints to complete the features. This allows the PO and management to plan the releases with more certainty, and prioritize accordingly.
  • The idea of a sprint is to add a fully functional increment to the system. If we respect the velocity, there is a good chance for that to happen.
  • There is a morale boost that is hard to explain, but I will give it a try. If you have a daily TO DO list, and at the end of the day you have 4, 5 or 6 items that you did not finish, how do you feel? I feel frustration. I feel that I have not been up to the tasks I needed to do. I feel like I am behind schedule. The same thing occurs if the team sees, sprint after sprint, that 4, 5, 6 or more tickets were not finished. How would you feel if, at the end of the day, you finished all of your tasks? The same thing happens to the team if all tickets are done!

Now it gets rough: the shield

If you are doing grooming and estimating, I bet you have a well-formed sprint respecting the velocity of the team.

Scrum says that we should not allow goal-altering changes happen in the middle of the sprint. In other words, no new tickets should be added to the sprint, nor tickets should be removed from it, if those actions threatens the goals of the sprint.

This is hard. If management (our bosses) comes and asks for a change, we all want to keep our jobs, so we are inclined to comply. This is very hard. But there is no other way… we have to say NO.

It is hard for people in general to say NO. After all, we are a part of an organization, and we want it to succeed, so it is only natural that we try to comply with those change requests. But is it worth it to jeopardize the entire process machinery only to comply with our bosses?

When we perform constant changes in the middle of the sprint, in general, the following happens:

  • The team feels like it is working on quick sands, instead of solid grounds.
  • Quality falls down. People may stop worrying about the quality, because they know, there will be changes that may force us to throw away what they are doing now.
  • Frustration and demotivation, because there is no clear north. It’s hard for people to feel good in a team (organization) that does not know where it is going. People work better when they get behind a common goal.
  • We lose the process, with all of its benefits. We go back to chaos.

We have to say NO. There is no other way. But, it is important to know that we not only have to say NO to those changes, we also need to fundament the reason. We need to let management know why, although we would love to comply, it is more important to keep the process going.

Nice to have: Retrospective and Sprint Review

If you got to this point, then you are in a really good place. I will not go deep on these two milestones, but I will say why I think they are important and you should do them.

Retrospectives allow you to see how the team feels in general. If things are going bad, you will feel the team’s discomfort. If things are going well with your initiatives, feel free to feed yourself from the good vibes the team is having, and keep going! A happy team provides better results, and at the end, the organization will be more efficient, spending less money and going faster.

Regarding Sprint demos, they are important, you can read about them in any Scrum book to know what to expect from them. But I find it interesting to see how people feel about them. There is a strong sense of accomplishment and pride after a demo. The team feels ready to take on the next battle every two weeks!

To be fair, changes will come

If your product is already in production, chances are that you will need to fix issues coming from there, in the middle of the sprint. These issues will not be sprint goal-complaints, but it would not be wise to say NO. We need to fix them. So, what can we do in these cases?

Along several projects, I have seen different strategies to take on these scenarios:

  • The X-Team: this team (actually named like that) was in charge of that kind of support. Their hours were not taken into account as team capacity, so they worked outside the sprint, as a second team. The people in this team rotated every two weeks (every sprint), so everyone knew what to do and how the team worked. This approach has the advantage of not hurting the sprint, but it loses a bit of velocity (we have lees people).
  • There is a time window allocated for production issues. Per sprint, we know we will have some issues, so we reserve time (even story points) to fix them. This approach has similar advantages and disadvantages to the previous one.
  • Defer those issues to the next sprint: sometimes, production issues are not that critical, so we can treat them as if they were just another ticket.

There is no silver bullet, but the good thing is that, if you reached up to this concern, it means your current process is pretty good!