The Napoleon Corporal
The Napoleon Corporal
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Written by Derek Huetherat LeadingAgile.
To clarify, the members of the PO teams are mainly populated by a Product Owner (Product Lead) and facilitator (could be a Scrum Master), but from there we’ll include others like a development lead, a testing lead, and an architect. We use the team construct over a single person because we’re operating at scale, with multiple delivery teams. The Leads and Architects are thinking bigger-picture strategy and are aware of external dependencies that need to be avoided or dealt with. The goal is to progress work along, getting it ready for the delivery team. To help bridge the knowledge gap with the delivery teams, there are members of the delivery teams who will attend the progression workshops, mostly to play the part of the Napoleon Corporal. (I call them that, not the client)
For those unfamiliar with the term Napoleon Corporal:
Napoleon recognized how vital it was to have an enlisted soldier in the planning process. During every Battle Plans briefing Napoleon would have a Corporal shine his boots knowing that the Corporal was listening. Once the General Staff finished the brief, Napoleon would look down at the Corporal and asked if he understood the plan. If the Corporal answered, Yes Sir! The General would have his Staff execute the plan. If the Corporal answered, No Sir! The General would have the General Staff rewrite the plan.
It doesn’t matter if you’re doing textbook Scrum or something at scale. Your people still need a shared understanding. If not, you’re going to start seeing a lot of delays and a lot of rework.
When you have a Scrum or Kanban team, you’re not always getting “A” players. Sometimes it’s a real mixed bag. To expand the military metaphor, sometime you don’t get a Corporal. Sometimes, you get yourself a Boot Private. If work is outsourced, developers and testers won’t necessarily have domain experience. They might be great coders or testers but not experienced in financial, medical, or other verticals. You need to get them to understand the mission and the mission is not necessarily to write and test code. The shared understanding is how to solve a problem for the customer.
Depending on the experience of the delivery team, the conversation (and backlog) may need to be simplified enough to be understood by someone junior to a Corporal.
Published at DZone with permission of Mike Cottmeyer , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.