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.
- 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.
- 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.
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.
- Create a backlog of user stories, prioritize them, and post them in columns by the projects they belong to.
- 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.
- Post the relevant story cards on a story wall or kanban board so what you’re doing has visibility.
- 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.
- Go!
It’s really that simple. Now go try it for yourself, or post a comment and let me know what you think.