Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Monday, November 17, 2014

Fragile Agile

One of the twelve core principles of the Agile Methodology is as follows:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

It would seem intuitively obvious that in order to maintain a constant pace indefinitely, the team would need to collaborate and bolster itself to make this even remotely feasible. At minimum, each team member ought to have a "satisfactory" level of competence in the various areas of expertise integral to an Agile team. Satisfactory doesn't necessarily imply expert.

In Final Patrol: True Stories of World War II Submarines by Don Keith, the author describes the following regarding the training of submarine crews both past and present:
Sub sailors were (and still are) required to graduate from submarine school, where they combined classroom learning with actual onboard training, but they were not finished yet. When they got aboard their first boat, they had to be trained until they could pass a rigorous examination in order to verify that they could take any station on a vessel and perform each job in a satisfactory manner. Once they passed their qualification exam, they were awarded a patch or pin that showed two dolphins, nose to nose. One of a sub sailor's proudest days was when he received his "twin dolphins" and could wear them on his dress uniform. The alternative for those who were not able to pass within a reasonable time was to be assigned to other duty. Incidentally, that procedure is still in place today on nuclear submarines.

In my experience, an Agile team's roles have included software developer, business analyst, and tester. My primary specialty has been software development, but thanks to my wide array of tasks and experience, I am wholly capable of a level of expertise over and above satisfactory with regard to the business analyst and tester roles.

Let's assume that a dump truck happens to transform my brains into goo just as I'm crossing a busy New York intersection. How does this impact the team? Suddenly, there's a gap in expertise and productivity. Not only is one who specializes in software development absent, but one who can also more than competently handle the business analyst and tester roles is removed from the equation.

How does this affect the team's velocity? How does this impact the team's ability to achieve the stakeholders' goals?

I'd wager negatively.

In my view, a relatively slim chance does exist that a superstar could emerge from among those remaining team members for whom software development is not their forté. Perhaps they've been paying especially close attention in pair programming sessions. Typically, though, I'd guess velocity would be decreased for a given sprint while the company investigates either transferring a software development specialist from another department, or hiring someone completely new to the company.

Let's apply this scenario to your modern ballistic nuclear submarine

Perhaps the chief weapons officer (let's call him "weaps" for short) trips and inexplicably falls into a bulkhead, rendering him dead. 

http://amzn.to/14BuTBp


Based on Don Keith's information, at least one other member of the submarine's crew possesses the bare minimum qualifications to perform weaps' job, and should it be necessary for weaps to launch a torpedo or nuclear missile, someone else on his team will be able to do this. Perhaps not with the expertise or finesse of weaps, but at least with the bare minimum capability, which means the task can at least be completed.

Can the same be said of the "typical" Agile team, especially your Agile team? 

If not, stakeholders should be very concerned.