What follows are a few suggestions for adopting enterprise agile development successfully.

1. The traditional functionally-organized engineering group won't work. Splitting up software development into program management, user experience, product management, development, quality engineering, and documentation is too restrictive. Instead, establish Centers of Excellence. Each Center should focus on a core function such as team leadership (e.g. Scrum Masters), product ownership, user experience, system architecture, information management, quality, publications, etc.
2. Form Special Interest Groups driven by the CoEs to define, implement and monitor new guidelines. Keep the guidelines minimalist and simple. Guide the teams. Don't legislate them.
3. Establish team-based metrics to track team (and workgroup) performance, not individual productivity. Be clear about individual roles and responsibilities.
4. Establish a common vocabulary and standard rules (such as the 'definition of done') to be used by every workgroup.
5. Automate as much as you can. a) Workgroups should have the option of using physical or electronic boards. However, those boards will have to be rolled-up into an overall project status board. The rollups will have to be electronic to promote transparency. b) Automated regression testing is a critical success factor. Don't skimp on it. c) Consider an internal social networking tool for information sharing such as Yammer or Salesforce.com's Chatter.
6. Conduct retrospectives at the workgroup level and among workgroups. Inter-group communication and software handoffs will likely need improvement.
7. Get professional help. Good training and coaching are invaluable. Don't try to do this alone. Select a few staff members to become internal coaches/mentors (a kind of train the trainer approach).
8. Focus attention on 2-3 workgroups and get them to high levels of excellence in advance of everyone else so they can be role models. You'll be tempted to treat all workgroups the same and attempt to synchronize them at the same competency level. That's unlikely to be successful. Workgroups will perform at different levels. Embrace it.
9. Expect and encourage mistakes, that's right, encourage mistakes. Being truly agile means making mistakes and learning from them.
10. Set target delivery dates and hold them firmly. Everyone needs to recognize that the company is serious about meeting dates. Just be sure to give the workgroups the flexibility they need to determine what to deliver by the due dates.

As someone who has watched a couple of companies struggle to understand how to make agile work these suggestions are fascinating. Personaly, I've felt enterprises don't put enough into CI/CD to allow Agile to succeed but he idea of CoE's takes that idea and applieas to to each discipline imo.

What I like about the CoE's is that while a traditional functionaly organized team won't work, there still are these problems that fall along one or more functional domains. Lets just take *testing* as one example. Testing isn't just one thing but a whole litany of things. Sure deveolpers can focus on Unit Test while the old QA hats can focus on Functional testing but what about Smoke Test or Performance test? They require a much more cross functional approach becausr they can be so many things and require system knowledge of the app and the infrastructure.

I can confess that I don't personaly appreciate the need to automate roll ups of an overall project status board I do think the idea of automating Testing is key but I'd expand that idea beyond just functional regression. As I said in my previous post, tool(s) are needed that everyone can use here. Collaboration on the writing of test and the ability to share or run the test of others is so foundational to overall collaboration and success. In a way, test one great way to ensure a *common understanding* of the application with executable specifications sitting on the top of that heap.

With a solid testing foundation you are also in a position to *expect and encourage mistakes*. Everybody makes mistake but nobody likes leaked defects.

In my spirit of top 10 list having 11 items on them, I'd add, at the #1 spot, *Define what Done means!* It's not enough to say Done means Delivered unless that criteria is applied to the end of the iteration and not the Delivery Date. To have to be done at the end of a sprint/iteration really forces your hand on a lot of the technical practices that really enable Agile to succeed.