This is the last part of the ‘product delivery process’ series. The first part was about the core principles of the process (and you can read about it here), and the second part was about getting familiar with each part of the delivery chain (and you can read about it here).

In this part we’ll cover what it means to be ‘agile’ and what are my recommendations for managing this aspect. So let’s dive into it.

You can find tons of articles and posts on the web about what ‘being agile’ means. For me it means the following:

Delivering incremental value to the various stakeholders using quick and short iterations.

At the end of the day – agile development methodology is a counter-approach to the legacy waterfall methodology where we used to build-build-build and then try to deliver to the customer a big juicy version. Those who’ve tried it can tell it usually doesn’t end well. 

Very often the troubles start much before it is handed to the customer. The integration phase turns out to be a complete disaster when the various components of the version refuse to ‘talk’ to each other and all the bugs with the APIs and their parameters surface in the open. And when you are finally done and hand it to the customer – the customer tells you that this is not really what they wanted or that it behaves differently from what they have expected.

Anyway – if you haven’t tried it yourself – I can spare you a huge amount of time and confirm all the bad stories you’ve read about the waterfall methodology on the web. I tried it and it’s a complete mess.

Being Agile

Assuming you don’t need any further convincing regarding why you should take an agile approach – let’s dive into how I suggest implementing it on the very practical level.

Ok – so there are quite a few agile methodologies out there, where Kanban and Scrum being the most common I’ve seen, but there are also Extreme Programming, Feature Driven Development, Crystal and more…

Personally, I’ve only experienced first hand the two major ones – Kanban and Scrum, so I am not going to discuss the other ones (nor I know personally any team which is applying any of those across all my network).

Now, before I will call out my favorite approach I want to repeat what I emphasized in the first part. This is super important and should keep echoing in your head until you fully embrace it:

The methodology needs to serve you (and your team) and not the other way around!

The teams who have worked with me are tired of hearing me say that, because I do say it a lot. Especially when I see that a specific team member is complaining that we are not sticking to the methodology ‘format’ or ‘rules’. So let me emphasize it again – there are no rules. You need to work with your team and come up with a methodology you all feel comfortable with and results in high productivity and efficiency across the chain. This should be your KPI when measuring whether the methodology you implemented works for you or not.

Kanban or Scrum?

I’ll provide a super short description for the two just to make sure we’re on the same page:

Scrum

In Scrum you work with sprints, where each sprint should encompass several user stories that by implementing them you will provide an incremental value for your product to some stakeholders. The sprints are ideally immutable once they start.

Kanban

In Kanban you basically have a prioritized queue of tasks/features. Each team member picks a task when they finish working on their previous task, and there are some transparent and clear stages each task needs to go through before it makes it to production (the Kanban board). Kanban is more dynamic and flexible than Scrum in the sense that the queue of tasks can change at any moment (high priority tasks can be put on top, or the order of the tasks can be modified at any moment based on real life events).

 

My personal preference is crystal clear, and I’m aware that I might annoy some people now. If I do – just recall the above – there are no rules. I’m gonna share my personal preference and explain why it is my preference. But if something different works for you and your team – great! I’d actually be happy to hear about it in the comments.

 

So – if I had to choose between the two as an approach for product development I’d definitely choose Scrum (with some modifications, see below). Now let me explain why:

In theory, Kanban offers the maximum flexibility and should be the most efficient method of dealing with tasks. Each team member picks the task from the top of the queue and works on it the fastest that they can. Simple, right?

My personal experience shows that this approach fails miserably in real life because:

1. The team members miss the big picture
2. The lack of a clear delivery date may cause the team members to work on a task indefinitely, trying to ‘perfect’ them for production (tons of testing, code reviews, optimizations, etc…)
3. There is no clear ETA when things are going to be delivered to the various stakeholders. This causes a lot of difficulty when talking to customers and trying to provide a clear date of when the feature can be delivered to them. It also causes big challenges with planning or executing upon a roadmap.
4. The various people in the company are getting used to ‘shove in’ requests and promote feature requests at any moment. Causing a real chaos and killing any attempt to have a concrete delivery plan. 

 

There are additional downsides to the ones listed above, but I think the main downside is the one not written anywhere (at least I didn’t see it mentioned anywhere on the web):

Kankan may result in a ‘non-results-oriented’ state of mind of the team members who are part of the delivery chain.

You see, with Kanban, the members of the delivery chain, and specifically the developers may get into a state of mind in which there are no commitments and no dates. Not because they don’t care or don’t want the product to succeed, but rather because no one is in the position to demand that of them due to the philosophy behind the methodology.

“Hey man, I’m working on it as fast as I can – it will be ready when it’s ready. Now please stop interrupting me.”

This is the main approach the various stakeholders (me included) will run into when trying to get some commitments from the team. Again, not because they don’t care, but rather because they were never asked to commit to a deadline to begin with.

I do think Kanban can work very well for the Dev-Ops teams, customer support or anything which is ‘ticket-based’. But I’d never adopt this methodology for product development.

Applying Scrum

So Scrum is my preferred choice since it doesn’t suffer from the downsides above. But what does it mean practically? Do I adopt it as it is?

Well, not exactly…

When the team and I agree to have Scrum as our base methodology I usually push to make some changes when we establish the product delivery process.

First – we don’t have a ‘Scrum Master’ since, again, we’re not in the business of serving any methodology. Instead, we have a process owner, and I usually take it on myself, or assign it to one of my subordinates. The goal is simple – the owner needs to make sure the delivery process works in the most efficient manner and features are getting out fast and in high quality. If we spot a bottleneck, or a stage which is not working efficiently – we take a deep dive and see what we can do to resolve this.

 

Next, there is the sprint. Here, also, we make some tweaks over the official definitions of the methodology. Whether the sprint is two weeks or three (or something else) – it doesn’t that matter. I mean, it has its implications, but those aren’t dramatic. What’s important about the sprint is the commitment for delivery. You get a full alignment within all different people & roles who are taking part in the delivery process. And once they commit to that – you can start communicating this to the outer circles – first – to the internal stakeholders (business, sales and product marketing) and then to the external stakeholders.

Of course things often don’t go as planned – so take your buffers, but at least you have some kind of an ETA.

Now, what sprint consists of?

That’s also something that you need to discuss with your team. My advice is that the cornerstone of the sprint would be the user stories and hence the team will commit to what user stories will get delivered by the end of the sprint.

That may sound obvious, but actually most Scrum documentation doesn’t define properly what is a ‘user story’.

Implicitly it means that you need to align the team on the terminology first. So let’s talk about it for a second to make sure we’re on the same page:

In the agile world we have ‘epics’ and ‘user stories’. Their definition may vary depending on who you ask. My suggestion (based long experimentation with these terms) is to use these definitions, as proved to be simple & consistent over time:

Epic

A full blown feature. Very often it doesn’t fit within one sprint.

User Story

A breakdown of an Epic to functional parts where each part delivers an incremental value of its own.

 

If you stick to these definitions, and also use them properly in your product specifications (I will show you how in later posts) then the team will get the hang of this quite fast (from my personal experience, at least).

So, back to the sprint – a sprint consists of user stories and by that it’s guaranteed to deliver incremental value on one feature or more when it’s done. For small features you can simply commit to the epic instead as it will probably be ‘flat’ (won’t contain user stories).

Sprint Planning

Scrum defines the sprint planning as the meeting where we agree which user stories will make it into the sprint. On the high level – that’s accurate. But the small details matter.

First – who is invited to this meeting?

My suggestion – group leaders, team leaders, the product analyst, the UX/UI designer and product marketing. Not the developers and not the QA team members. Why? C’mon – let’s let them work. We don’t want to cause any unnecessary context switches.

Second – who is suggesting what user stories to promote? Well, you and/or your subordinates, of course, but also the R&D – by promoting tech debt items. Both of you (product and R&D) need to come prepared, while deciding the priority prior to the meeting and then just discussing what fits.

Seriously, if you don’t do your homework before this meeting you are going to waste a lot of time for all participants.

In terms of the ratio between product stories to R&D stories – I found having 20% of each sprint devoted to tech-debt items to be a good rule of thumb.

During this meeting you’ll add all your candidates to the pool and based on the various teams capacity (mainly R&D and QA, but also analysts and designers) – you’ll probably have to make some sacrifices. If everything fits – it probably means you didn’t do your homework and didn’t come with enough candidates.

Half an hour for small teams or one hour for bigger teams should be enough. I recommend having this meeting at the beginning of the week prior to the week the next sprint is starting.

Why so much time in advance?

Well – here is the twist – the team leaders and the various participants are going to make commitments based on their general understanding of the stories. Usually, those rough estimations are simply not good enough (either too optimistic or too pessimistic). And this is why I always push to have another meeting I call ‘sprint finalization’ a couple of days later. This will provide enough time for the team leaders to present the suggested sprint to their team members and get their feedback back.

If the estimations turned out to be ok – then even a Slack message saying that ‘we’re good with the sprint’ can be enough and there is no need for this second meeting. However, more probable, from what I’ve seen, is that one of the team leaders will get back to you and say – “man, sorry, but my guy says this feature is actually double the price”. In that case you’ll need to do some shuffling or maybe even take one item off the sprint – but it’s worth it, believe me – because now you have much higher chances to meet the sprint goals. This will increase everyone’s confidence in the process and also increase the internal stakeholders’ trust in you in the sense that if you committed to a deadline – you are going to deliver.

 

Last – some Kanban evangelists complain that the immutable nature of the sprint prevents the organization from being able to respond to outside changes fast enough. My response to that is:

Other than production issues, which should indeed take precedence and make their way in even though the sprint already started – the rest can safely wait. All the other requests can wait for a couple of weeks. Nothing bad will happen – I assure you.

Do try to keep your sprints shorter than 3 weeks and in parallel start ‘educating’ the business and the customer success guys that the R&D is delivering in blocks of 2-3 weeks. They will adjust. I’ve personally witnessed how the VP of partnerships who was working with the biggest companies in the industry started talking to partners about having this feature ‘in the next sprint’, rather than promising them that he’ll immediately put it into the works.

You will experience it yourself – once your colleagues from the business and customer success departments will see that things are actually delivered when you tell them it’s going to be delivered – they will walk the extra mile toward you and ask customers and partners to wait patiently. But you need trust and reputation for this to kick in.

 

Ok. So these are the essentials on how to be agile.

Wait – what about grooming, retrospect, demo and the other Scrum stuff?

Well – in short – I do think you should put in the calendar a monthly retrospect where each team can bring up items to discuss and improve.

As for the rest – those are optional from my perspective. I don’t see a need for them (especially given my philosophy towards backlogs which I’ll present in the future). That being said – I am aware that others are enforcing these practices and are happy with that.

So again – there are no rules. Do whatever works for you as long as it serves you and the process.

 

With this in mind – I think we can safely conclude this short series. It’s been a bit more intense than I originally planned, but I’m sure you can handle this 🙂

I’ll be happy to address questions on any of the parts of the series, and I can assure that I’m going to elaborate further on some of the topics here in future posts.

 

As always – if you think others can benefit from it – feel free to forward it to them. And if you liked the post you are more than welcome to ‘like’ it.

Thank you and until next time 🙂