Can Agile methodology work in very small Dev teams?

This is a great question and topic and one so few ask!

 

The question is from a LinkedIn thread where the person posing the question works in a small dev group of 1 project lead, 1 developer and 1 tester; all who need to multitask on concurrent projects.

Scaling larger seems to be the most common theme, but what about scaling smaller? I’ve worked in companies where the total workforce was no more than a few dozen and the entire R&D team included maybe ten people. I’m certain there are a lot of these environments with the number of start ups that exist in just the region I live alone.

The first gut reaction to this question may be Sure! Of course! If you want to strive for …

• Constant communication to collaborate with your customers and users,
• Improved code quality, unit tests, and disciplined development,
• Constantly improving and working to get better,
• Delivering actual value rather than meaningless overhead for your customers and business,
• Delivering working software that meets your customer's needs and not just their wants (and sometimes worse; what they actually asked for!),
• etc …

but I suspect the question goes a lot deeper than that. If people in these types of work environments didn’t already know that they wouldn’t even be thinking about Agile let alone asking about it.

I also suspect that in most of these environments there are a lot of Hem and Haw type of people that debate the problem but ultimately take way too long to make a decision to move in a new direction ultimately they already knew deep down would benefit them. And ultimately, in too many of these cases, they become an ‘also ran’ company to their competition as a result. I’ve witnessed far too many small, medium and large companies do just that. And the one thing they all have in common? They’re all shadows of their former selves; if they actually still exist that is.

Now, that ground work laid, say you work in an environment where out of some necessity you have PMs, analysts, developers, testers, etc all multitasking across multiple projects even after study after study has shown the ‘productivity of multitasking’ to be no more than a mere fallacy at best and fooling ourselves at worst.

The problem actually comes from how the situation is being looked at rather than the situation itself; remembering the old adage “when you’re a hammer; everything looks like a nail.”

The reality is you can actually have everything you’re doing today and still achieve the above. And now some of you reading this are getting a bit incredulous, but I am in earnest here. Just bear with me a little further.

The first step is to get back to basics and look at the objectives of the Agile Manifesto, and stop looking for a tool or a process that your people are supposed to then subscribe to . Imagine, if you will, a small R&D group where everyone there has:

•  A specific and unique set of technical skills with minimal overlap between people.
• Multiple projects going on all at once mainly out of necessity rather than a lack of strategic planning. Example: Ever try to tell your spouse that you decided you were only going to do the dishes for the next month and they could do everything else around the house? Yeah, I bet that didn’t go so well for you either. Same thing here.
• A team of 2 or 3 people they work with at any one time.
• A strong desire to have some semblance of order in the chaos – including all the developers, testers, etc. Thus, user stories and their priorities are hardened each month with multiple sprints (2+) within that month; effectively making the plan for that month a scrum of scrums.
• A need to be fully utilized because that’s what keeps them motivated and what the business needs to stay profitable.

The second step is the phrase ‘Scrum is Agile; but Agile is not Scrum” – i.e. there is no singular "Agile Methodology"; there are actually 18 Agile methodologies and frameworks and counting at my last check, but I digress. That said, nothing but kudos to Jeff Sutherland, Ken Schwaber, Mike Cohn and all their predecessors. 

 

The third step is to look at kanban, lean, and probably one of the xDD methodologies to determine which best fits with your work environment’s existing culture. The latter part of this last sentence being very important as noted described in the picture below.

Here is a very brief example to show you what I mean.

 

Choose TDD, BDD or FDD to execute on that – Google them (just don’t go overboard and over-think this part) and choose one that looks like it currently approximates your current workplace culture.

1. Create a backlog of user stories, prioritize them, and post them in columns by the projects they belong to.
2. Figure out what ‘potentially shippable’ new feature—functionality or new block of code module(s) you want to exist at the end of the month.
3. Post the relevant story cards on a story wall or kanban board so what you’re doing has visibility.
4. Let everyone know that they alone own and are accountable for the story cards they selected to work on, they need to share progress on that card with everyone else, and they need to provide more granularity between ‘started’ and ‘done/complete’. AND you are there to support them in your leadership role to enable them to do just that.
5. Go!

It’s really that simple. Now go try it for yourself, or post a comment and let me know what you think.