How to scale Agile in IT Service company (not product based)
Hello everyone!
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).
At the moment we have more or less 40 developers, 5 UI/UX designer, 3 functional testers and 3 Ops Engineer.
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 are 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 situations like projects that, for example, requires just two Java developer or projects where we just need to develop the frontend, cause 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
What, exactly, do you mean by "scale Agile"? Often, to scale Agile means to coordinate the work of many teams on a single product and/or between teams working on a portfolio of products. However, it doesn't seem like either of these apply to your situation.
I'm also not sure what problems you are encountering. What is the issue if the work requires just two Java developers or where you are just developing the frontend? Neither of these really seem like problems to me.
I wouldn't get too caught up in thinking that Agile assumes fixed, cross-functional teams. Cross-functional teams, yes. The fixed and stable teams relate to how teams develop and the early formulation of how people work together can impede productive, valuable work. If you have people who frequently work together, you could minimize some of this. There are also techniques for effectively managing changes to team composition, but I don't know if these techniques apply to your environment.
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.
It sounds like you currently have a project execution model, and limited or poor visibility over actual products. How is value for your products then being maximized? Before you consider agile scaling, do you have even just one team that is able to account for product value, and to optimize it empirically by releasing work in one month time-boxes or less?
NB in Scrum a service is considered to be a Product, since it has value to be accounted for and maximized.
Hi Thomas Owens, thanks for your answer
I'm also not sure what problems you are encountering
Sorry my bad! Nowdays we are struggling playing to a Tetris-like game, allocating people for 2 hours on this project, 4 hours on that one and the remaining hours on the other one. Many projects has a long development queue before considering them done, so there's many time this situation where we need to disturb a developer from his current project because we need to allocate him some hour per day to fix something he delivered on an old project.
Since we need to scale in the next future of other 20-30 developers we were start asking us if there's a better way manage things.
Maybe Agile is not the answer, maybe we need something completely different.
Are our doubts a little more clear?
Thanks
Hi Ian Mitchell, thanks for your answer
It sounds like you currently have a project execution model, and limited or poor visibility over actual products.
Yes we deliver projects, not products
do you have even just one team that is able to account for product value, and to optimize it empirically by releasing work in one month time-boxes or less?
We tend to structure ourself, internally, like scrum teams, even if our customers wants the projects delivered with a waterfall approach. Most of our projects are already delivered in two weeks time-boxes. But our teams are specifically made for that project, with the "right" amount of developers, testers and ops.
Our main problem is to deal with fragmented resource allocation: as I was saying we don't have fixed agile teams as we've got lots of projects which doesn't require a whole 8-person team, but maybe just 2 developer.
Would it be ok to spread projects on fixed teams, instead of people on projects? How could we manage scarce resources?
Are you sure that projects are being "delivered"? I'd suggest that projects are a means for delivering something else...such as valuable products and services. Without a clear line of sight to value, and how it is accounted for and maximized, no agile outcomes can really be expected.