2

I work for a company which is trying to understand how to scale Agile. We are an IT Service company, we don't work on one product, we develop many IT projects at the same time for our customers and we don't do body rental. We usually develop frontend (SPA, mobile apps) and backend (mostly Backend-For-Frontend).

Currently, when we obtain a new project from a customer, we set up a team specifically for that project. Then, we usually adopt Scrum or Kanban methodology to deliver that project and, at the end, we dismiss the team and we allocate those persons on other projects.

So our Agile adoption is based on single projects, it's not something done at organization level.

We start asking us if there's a better way manage things, considering that Agile assumes to create fixed, cross-functional teams that don't change also at the end of the project (if I've understood well), that should follow just one project at the time, but then we are struggling figuring how we could manage projects that, for example, requires just two Java developer or projects where we just need to develop the frontend, because the backend is delivered by another company or directly by the customer.

These are situations that I can't define "exceptions" as they are pretty normal in our environment.

Are we just looking the problem from a wrong perspective? What we should change?

Thanks a lot for your hints

Improve this question
3
  • Agile teams work best when they stay together across multiple projects.
    – Todd A. Jacobs ♦
    Jan 27, 2021 at 15:10
  • Hi @ToddA.Jacobs, thanks for your answer. Are you saying is that Agile teams should work on multiple projects at the same time (if their capacity allow them to), or just that once they finish one project we shouldn't dismiss the team, but we should let them work, unchanged, on the next one? What if next project is smaller and not all the devs are 100% full? What if is bigger? How should we manage those differences?
    – Gianluca
    Jan 27, 2021 at 15:24
  • 1
    You keep teams working on a single project at a time, and keep the teams together for new projects. You can then add or remove teams if you need to scale. Don't fall prey to the 100% utilization fallacy; you aren't optimizing for utilization, you're optimizing for teamwork and process flow.
    – Todd A. Jacobs ♦
    Jan 27, 2021 at 15:41

2 Answers 2

Reset to default
1

Agile Manifesto touches upon things like requirements, team, project, collaboration between dev & business, documentation. It's not about organizations. It's about teams and projects.

You can extrapolate it to other areas of life (including organizations) by applying similar principles, meaning: do what's most effective; if it stopped being effective - change it. There's no "right Agile" - it's going to be different depending on people and circumstances. So the idea is not to build paradize, but to adopt to the changing realities.

Improve this answer
1
  • I agree. "Agile," like every other technical project-management conceptualization, is something that many people now agree is "a useful concept." Now, given that the OP says his/her organization is now making good-to-them use of other approaches, then they should just feel free to "cabbage" any other useful ideas that they see in "Agile" and use those ideas to further improve their process. Because the process is what matters. "If any change, whatever it is, it actually helps the actual organization, then: It Is Good.™"
    – Mike Robinson
    Jan 27, 2021 at 19:32
0

Agile is a set of values and principles that create a container within which you organize your work and your teams. Some Agile methods - like Scrum - are more prescriptive, some - like Kanban - are less.

You say you already use Kanban and Scrum for your projects, but then you ask "what we should change?" Well, are there any issues with what you are already doing? Is there a problem you are trying to solve and you doubt that your existing practices are solving it? Your mentioned nothing about that.

Kanban should work nicely for your particular context. Scrum is more rigid, but you could also use it if you can guarantee to have stable teams throughout the project and that all the necessary skills to build the software are present within the teams.

Without knowing more, my suggestion in this case would be to take this question to the people doing the work itself. Ask them what worked and what didn't. What they would keep and what they would do differently. Ask if they prefer Kanban or Scrum or some other practices (on all the projects or on specific types of projects). Ask them to look over their retrospectives and their impediment logs on the various projects they worked on and see what obstacles or dependencies they faced, etc.. Then try to gain an understanding from that, and maybe build a database of good team practices that future teams can pull from.

And finally, make sure you won't impose those practices on all the teams, across all the projects; in Agile, teams need to self-organize.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.