Just finished reading “The Arms of Krupp”, by William Manchester. It was kind of a project… but I will say
1) It’s very readable, and even made me laugh at points and
2) Is a fascinating view of the rise and fall of Germany through the lens of its most famous arms merchant.
The interesting thing was the story of artillery and the ‘big guns’ that Krupp became famous for. The company only became the size it was AFTER some epic leaps in technology that made steel cannon possible… up until that time, artillery was made of iron (heavy, prone to breakdown) or bronze (incredibly time-consuming to make, could not be cast in sizes that could throw any kind of large-sized shell).
Napoleon, for example, basically fought with the same types of cannon that a general two hundred years before him would have fought with – squat, heavy, ungainly cast-iron brutes. It took a rampup in the maturity level of the team – a technical breakthrough – to make progress.
The same is true of your team. For Agile aficionados, micromanagement is evil – and every bad boss we’ve ever had has that strong leaning towards “These guys are lazy and they won’t work unless I’m looking over their shoulder telling them what to do.” Still, every team does have to go through a maturation process – “Storming / Norming / Performing” – and after a few weeks on the job you as a project manager should know if your team maturity-wise is able to take on commitments and deliver on a consistent basis. (Other teams will gladly tell you this!) So, let’s think about three levels of maturity for an Agile team:
- Does daily standups.
- Simple, easy to understand tools that are minimalist. We’re talking sticky notes here on a board.
- Lots of focus on pre-planning, mid-sprint demos, sprint closeouts.
- Less meetings, more business/owner collaboration on a daily basis.
- Tasks are no longer preassigned by developer – capacity is done at a team level.
- Top-shelf software delivery practices like XP, pair programming, etc.
- Meetings are minimal and usually held 1×1 – focus is on function not form. They’re loud and very collaborative and represent multiple points of view.
- Only a single meeting every sprint is needed – a quick signoff by the owner, and a planning session that punches out work prioritized by the business owner.
You got to walk before you can crawl. And, if the team can’t or won’t move forward in a coordinated way with complex tooling and ALM methodologies – take away the tools and get back to the basics. Make sure everybody knows their commitments and can sign off on them, and start from there.
There’s a couple of other lessons in the book that had Agile echoes, including the danger of overspecialization. For example, early on in the Russian campaign in WW2 the Germans were getting their heinies handed to them by the T-34, a very well-designed and functional utilitarian tank. All the commanders in the field were screaming about how it was blowing the doors off the underpowered, undergunned, and overdesigned German (Krupp-made) tanks… and begging Krupp to just copy the blueprints to the T-34 and roll out a German version.
Naturally, the company refused and stuck to their aging, artsy Disney-style “family” of highly specialized tanks. In the long run this meant that the Russians cranked out hordes of well-performing armor that overwhelmed the Germans through sheer numbers… while the Germans were trying to fix a logistical nightmare of overspecialized and prone-to-breakdown tanks that couldn’t hold up to field use.
The lesson here is… listen to your developers in the field. If something is working well for another team, don’t be too proud to try it… odds are its working for a reason. (And then, naturally, steal all the credit for your ‘genius’!!!)