I like to put here discussion that I had as reminder or inspiration. Don't be afraid, I kept the discussion form.
Agile Organization Structure - what works and what doesn’t?
Any tips on what has worked for an organization structure in an agile environment? Is your pre-production group a team and your post-production group another? Or are your teams by specialty? Other?
Additionally - how have you aligned your scrum boards? Each client on a separate board? All clients on a single board? Other?
Thanks in advance for your feedback!
-
On my side, it almost depends on the purpose of the organization. Software Development is one, R&D another, Finance another one, etc...
After several transformation, I can highlight a common pattern that there is no pre-production or post-production, there is only production.
One thing that still works: Management working as a team with clear Roles and Responsibilities and dynamic Governance and, transition in an organic way where early adopters are lever for next phases in a viral change manner.
Aligned Scrum boards: that's mandatory
Each client on separate board: Y/N, backlog are feature or product driven, not customer driven.
Hope it helps ;B)
Pierre
With respect to an IT organization:
I agree with Pierre: the traditional gate oriented work process silos need to be completely dismantled. In their place, I advocate coaching units, each specializing in a critical area of expertise, e.g., a test automation coaching unit, a deployment coaching unit. These units should not do: they should teach, and they should always be up on the latest things.
There also needs to be a QA function. Yes, there does. It does not sound agile, but it is, because it needs to operate differently from traditional QA. Agile QA needs to be focused on assessing test processes - not systems. The focus needs to be on test coverage. For example, agile QA should look at how each team is assessing test coverage, and determine if the approach is adequate, given the types of risks of the particular system. Since the assessment is for the test processes - not for the system being built - it never holds anyone up: it is not a gate. Agile QA needs to define what "test coverage" means for non-functional requirements areas such as security, reliability, maintainability, etc. If that is done, then all of assurance and governance reduces to test coverage - and that is something that an agile/CD/DevOps process can work with.
As far as product versus customer oriented backlog, the product oriented approach makes it easier to balance the work - unless work is heavily customer oriented (each customer essentially has its own product), but that is kind of a pathological situation.
C.
I work for a web development company and am the product owner over our implementation group. Have you coached any others in this industry? Right now the implementation team has one strategist, two designers, a developer and a product specialist. I know it is good to have cross functional teams, but my team starts a website implementation with a new client each month. With each implementation taking an average of seven months, today my team has nine client website implementations in process. Aka this current structure is not working!
One added twist is that we have a team of what we call client advisors which are basically a shepherd for the client. They help during implementation process and after launch they continue to support the client (which there is a separate group of designers, strategists, etc... that support the client post launch). I understand agile needs to have cross functional teams that focus on a certain task at hand, but with these team members supporting clients indefinitely I am wondering how this works.
Thanks for the questions. Here my point of view according my actual understanding:
1) so, you are managing a portfolio of projects. That’s tricky because you are increasing the complexity of development i.e. management. Prioritize and try to finish meaning instead working on several streams in parallel increase the risk of low value: you just gesticulate. Using LegoPlumbing means that your team knows its velocity and your early backlog has still the same weight (in story points). That helps to start finishing.
2) Like before, try to make things easy. 2 different backlogs and boards is a lot of waste and reduce operational excellence. One trick could be that your « client advisors » manages a buffer (sales pipe) until your team is ready to start.
3) Ideally, the same team follows the product in its whole lifecycle. Try to mix the teams in a DevOps manner then you can increase your capacities.
4) One board per project + 1 for the portfolio big picture.
Lego bricks and plumbing -- that's funny! Websites do seem that way!! Love it!
Maybe a strategist would be a good role to pitch. Like your idea.
Here are what I see as the current issues/constraints:
1) There is a dedicated implementation team of five people (plus me as Product Owner). We have nine projects in queue at different stages in the process. Issue being agile usually doesn't generally accept having this many projects in queue at once.
2) Our client advisors (that sound just like your relationship managers but only work on upsells after the project is initially sold -- we have a separate sales force), also assist with client relationship during the implementation process but only work on the billable or outside the scope items. This seems weird to me and off. I understand the company wants to start the relationship early but wonder if it's worth their time. But the issue is there is work in two different backlogs and scrum boards.
3) We have a production team that consists of similar roles to that of the implementation team but does the one off upsells from our client advisors and also does website redesigns for current clients. This is not necessarily an issue but me looking at processes and saying why is this team doing redesigns when our group does this day and day out?
4). My scrum board question was asked because we have nine projects in queue, all on the same board and have a massive backlog. I'd say that's a big issue!
Regarding implementation, I did coach xxx UK and several others like xxxxxx.
According your details, it looks that your business model is lego-bricks & plumbing?
Cross functional, in your model, is a could-have if your delivery cycles are short. If I understand you right, it seems that you are in charge in capacity planning, team building and project follow-up.
Now, if you change your role and you start to play Scrum Master and Product Strategist can play the PO? Do you need a strategist full time dedicated to the team? or can (s)he be a "floater" helping different teams on-demand?
Question: who is subordinate to constraint? reduce the constraint!
