Every month, V2COM leaders write about important topics in their areas of expertise.

In today’s article, Philip Breuer – our PMO – comments on the new methodologies used in the development of IoT products and especially comments on the impact that shorter sprints have brought to the company.

Enjoy it!

 

One-week sprints: a reality here in V2COM

 

Having a blast here at V2COM.

We are using Scrum and Agile to develop new IoT products. Our motto is “making IoT happen” – and we are living it every day.

We are doing 1 week sprints.

Are you crazy?!?

Maybe a little.

Many assumed (and suggested) that one-week sprints would be too short.

Many assumed (and suggested) that it would be better to (eventually) switch to longer sprints – at least 2 weeks.  Oh, the overhead of all the ceremonies, they said.

But rather than assume, we have proven and experienced and done and delivered.

By sticking to 1 week sprints, we are getting more iterations.

We get two sprint plannings for every one of a “normal” two-week sprint.  And this lets us be more nimble. And this lets us practice more. And we are getting better.

We are learning to plan better – especially since we need to do work this sprint to keep our velocity for the successive work we will do next sprint.

(Yes, there is an element of planning beyond the current sprint that empowers this sprint-to-sprint coordination and productivity.)

Our Daily Huddle/Stand-up meetings are never boring.  Everyone participates. Everyone is learning. During a one week sprint, there is less time or margin for waste. Interestingly, two things happen regularly: 

  1. Everyone wants to get out of the meeting as soon as possible – we have a lot to do and very little time to do it. There is always a client demo less than a week from now!
  2. We frequently stay together for extra time – in lieau of other meetings – to coordinate effort, reallocate resources, and to break down issues so we can meet the client objectives and SHOW what we built within the sprint.

My observation, based on my experience, is that there is a richness (bandwidth and fidelity) that is present here that has been lacking elsewhere.  Maybe things are brought into sharper focus due to the shorter sprints. Maybe the sense of commitment is greater with shorter sprints. Maybe it is because you can really see and touch the things we build (and when we don’t get it built, you can really see that easily too. Or NOT see it, rather. )

 

How about the incremental delivery, you might be asking?

Well, my observation is that delivering incrementally is a choice. We have to decide that we are willing to make the investment in change necessary to enable incremental delivery.

It takes a different way of thinking.

A willingness to think about what needs to be done – and how – in advance. But this anime is not enough. We also have to be committed to failing – and failing fast!

It is possible – even for large projects and for hardware projects.

And combined with the frequent client demos, we are able to course-correct, improve our skills and processes as individuals and a team, and really learn – much more rapidly.

Esquema de Scrum - sprint de uma semana

Speaking of client demos, we really get a lot out of these. For starters, we have goal-oriented and specific communications between the types of people that are often speaking different languages. These different ways of thinking and communication help is stay diverse and succeed as an organization. It is also the type of style difference that can lead to the “traditional” complaints about lack of information and an inability to communicate.

I don’t know about you, but the complaint between business and technology has been persistent and universal!  We are breaking through this barrier. I think it is because we are being specific – what do you think about this specific deliverable? I think this is a problem – what do you think? But if we don’t optimize that, how will we scale up with our client and keep costs under control.

 

Does the Agile methodology always work anywhere?

There has been work documented elsewhere about environments where Agil works and environments where it doesn’t work.  In my experience there is never a perfect fit. What we are after are results, and Agil is giving us a framework – and a belief system – for accomplishing these results.

The aspects of management and control that some describe as running counter to Agile: schedules, budgets, control, are accomplished through the framework we use to manage the business.  The team is able to focus on innovation within this operation.

 

Can the team also feel the advances?

As for the team, every member has commented on the improvement in the delivery (the team is producing better results, faster), operation (the team is working together), and communication (the members of the team are more aware of what the others are working on and able to help each other brainstorm and overcome obstacles.

What is next, you might ask?

For one thing, we are “becoming victims of our own success”.  As the team improves its delivery, the expectations, demand, and workload (ie. backlog) is growing.  This is a great problem to have, admittedly, but one that demands solutions.

The team is even getting a little impatient, ready to move on to the next “big” project.  Simultaneously, there are more and more requests being made as the clients become more aware of the delivery capability of the team.

The confidence of the team is rising, which is helping to fuel more valuable and efficient (i.e. direct) conversations and “debates” about various solution options.  Rather than simply doing what they are told, the team is responding constructively with options. This dynamic is a much more rapid solution iteration than executing the request to eliminate that option.

As the team improves its delivery capability, other challenges are presenting. For example, there is an increase in informal requests. This is putting pressure on other members of the team to capture the request for planning, prioritization, and delivery (to avoid having the request “missed” or “lost”).  So work needs to be done with some of the operational habits related to how requests are made and documented. And this improvement will help with ongoing improvement in the area of planning and prioritization (i.e. backlog grooming). And this will help improve the efficiency of the Sprint Planning – which will of course help improve the delivery from each sprint. And the continuous improvement cycle will continue.

 

What would I do differently if I had to do it all over again?

I think maybe I would have started earlier. The team was already working and there was a period of observational learning invested prior to introducing the new agil approach and scrum.  The sooner we start, the sooner we learn, and the sooner we can iterate on continuous improvement. But really excites me is not what we could have done differently. I am excited about where we are and all the opportunities we have to improve – improve ourselves, our operations, and the reality for our clients through our deliveries.

We are working on exiting solutions that help make the world a better place!

 

If you want to know more about V2COM fill out the form below