Hehe, I opened a can of worms. :)

First, “agile” is just a set of tools and techniques. Which ones you use depends on your team and your environment, and you CANNOT get stuck in non value-add BS. Your organization has to be willing to allow a team to change things that don’t work.

My infrastructure teams, data warehousing teams, integration frameworks teams, data management/MDM, and the core architecture teams do best with Scrumban or pure Kanban.

My business applications teams do best with “lightweight” Scrum. There is some waste in core Scrum we don’t do.

My back-end financial
systems do best with “agile RUP,” which for me is traditional iterative development. This is because financial/accounting rules do not change often and they are in a very controlled environment. Scope is not flexible.

And my mobile and web tech teams are what most people think of as traditional agile. That’s where you have to be able to turn on a dime in that world, as Charles knows well.

We have some hard and fast practices everyone has to follow:

1. We have the same monthly release window for everyone. That’s so the business can consume the rate of change. This rule does not apply to WebTech.

2. Every team has development, QA, and any other roles embedded. Cross-functional.

3. QA has to be comfortable before a user plays with it so we don’t make asses out of ourselves.

4. We deploy to Production after the business accepts it, no exceptions.

5. We build backlogs. We have to be able to know how much work we’re looking at and how to organize it.

6. If developers and/or QA can’t write a test case we don’t understand it enough to start building it.

7. Tasking. We do large ones…design, Dev, QA. That maps to Kanban if my teams decide to switch anything. But, if we’ve got a story with more than a week of time planned we need to break down the STORY, not add more tasks.

8. We demo and we prototype to show progress. Paper doesn’t count.

9. PMs don’t tell us how to work. That was huge. We will show them at any time where we are in finishing stories but we will not do 500 line project plans.

10. If teams time box, they have to be 4 weeks or less.

11. We always look to automate wherever it makes sense.

12. No compromising on quality. We will not deliver crap, we will think, we will not be idiots.

13. We respect introverts and extroverts and organize for both.

14. We have fun. A lot of it.

15. Daily standups. 15 mins or less. Discuss impediments or needs only. No status report, no design, just let the team know what you need.

That’s it. It’s rare we don’t deliver very well. But it takes discipline and a full-time lead like me so teams can work different ways and we can still hold all of the teams together on massive projects. It works, but we’ve been doing this for 8 years and I have been since 1997.

And I’d NEVER be in a car that long with someone I didn’t know very well and I would be very quiet and respectful of the other person. I read mostly. Introvert.