I recently answered a question that goes like this:
In an IT organization that is structured to align with business modes and functions by silos; each silo with its own set of IT roles (PM’s, BA’s, Dev’s, and QA’s) how would Agile work on projects that span these siloed teams?
When it comes to sprints and sprint planning, how do these dependencies get called out and planned for? Do other product owners attend those planning sessions? Do you have to implement a scrum of scrums?
My $ .02. I am assuming this is a rather large project, with 20-80 staff comparable to projects I’ve been a part of before.
1) For the duration of this project, structure the teams by functional specialty. Silos will kill you. I’m talking about a UI team, database team, processing (or whatever makes sense for your type of software systems), systems architecture/workflow, etc. Teams have lead developers or systems engineers, but there’s 1 PM. QA/test is a single team. This increases team cohesion as you’ve got people who are good at/interested in a particular aspect of development together sharing knowledge. There is no ‘throw it over the wall’ – only work together to make my UI interface with your control system, etc.
2) Build interfaces first, build everything with automated unit and integration testing from the beginning. Automated build & test either with scripted daily builds or automated builds triggered by check on your code repository. (find interface issues and bugs immediately) Make sure you have a software architect and software configuration manager who know what the hell they are doing.
3) For delivery mechanism, go with Lean – Kanban. There are many software tools available like LeanKitKanban for tracking multiple teams and this kind of visual system makes it really easy to see where the bottlenecks and dependencies are.
4) Product owners / key stakeholders have a regular priorities session, they all work off the same shared backlog. There is only 1 backlog for the project. If you are doing Kanban, sprint planning goes away. When someone wants something done because it’s an ’emergency’ they either have to wait until the next product owner tag-up or negotiate with another product owner. It’s all one one board so you just walk up to it and talk about it.
Thoughts?
As a Consultant that works with Government we have been introducing Agile in solution development using platfrom based development. Agile requires an organizational culture shift that will be and is slow to evolve in the public sector.
As a word of caution, it is my past experience that even in private sector organizations that have embraced Agile methodologies, large development projects do not do Agile well. So I would recommend starting with small projects that don’t span multiple businesses units to start introducing Agile to project teams and start evolving the culture from there.
This is a great post and Harry’s comments say it as well. The problem with trying to integrate across silos won’t be solved by the apps devt method…but needs to be addressed in the coining the project itself.
I did systems development in private sector and we did exactly as described. The company pulled staff from all groups involved, put them under one PM. We were all sent to training, not to learn code but to establish a consistent method of communication, development ( so every screen looked and functioned consistently), testing and follow-up. As Harry mentioned, even in private sector Agile might not do well, but I think that is more due to the multiple personalities that have to meld in a large project (or a small project for that matter.) The training program had the added advantage of giving the development team a chance to get to know each other. A week away from our silos to develop a good understanding of our objective and become a team.
So true Harry – I didn’t address it directly but items 1 – 4 would REQUIRE a culture change to make happen – and/or in the process of executing these items a culture change would need to ensue. It’s a chicken or the egg problem – I think you need something like this in order to foster the necessary culture change. You can’t simply change culture and then go implement a structure like this, they are two sides of the same coin.
Cool Janina, what is your retrospective on that experience you had in the private sector?
Good points but your title gave me the impression that I could still do agile with a silo structure. I agree that agile requires the destruction of silos but that will take some time and is really a project on its own.
That’s why Adaptive Project Framework is my preferred method. I can realize the benefits of agile but still operate in a silo environment. That is because the work in the Mid-Level WBS can easily be parceled out among the silos. This will require more coordination on the PM’s part but functional managers are more easily persuaded to allow their employees to work part-time on a project rather than give up their employees for a long duration.
I agree with Other Harry and Mark – large agile projects are a challenge for everyone. We’ve been successful with two strategies.
If possible, break the project into multiple projects that are loosely coordinated. (To avoid overcomplicating coordination see: http://www.softwareinsanity.com/2012/09/controlling-pmo-cancer_28.html).
The other strategy is to start with the 800# gorilla, If the project is really to deliver for multiple stakeholders, pick one. When they’re on board and operational, future projects bring on the others. It is possible to start with the lesser served (willing and needy) and then tackle the800# gorilla, but usually a longer course and more politically sensitive.
Regarding Josh’s advice to use Kanban – I’d warn you away from that. Kanban is designed to give the customer accountability for decision making – prioritization of the backlog. In a new software project, this can be dangerous. Most customers do not have the experience or discipline to drive this process. Much like handing your car’s steering wheel to a 2-year-old, you’ll be swerving all over the place.
Thanks for the comments Harry. I’m not sure if there’s a big difference between an agile backlog and a kanban backlog, they can be implemented in many ways with varied degrees of customer involvement.
I’d love to hear stories about the customers driving the backlog like a 2-year-old though, those would be enlightening I’m sure.
An interesting article in FCW: http://fcw.com/articles/2013/01/28/agile-it-managers.aspx