Michael McCormick - Re-inventing Agile Through the Science of Invention and Assembly

is VP of Software Engineering at Salesforce. Michael holds several engineering patents in mobile, IoT, and microservices systems design and wrote a top 10 iPhone app (Photography, 2011). A lover of language, Michael knows English, Spanish, French, German, Norwegian, and a little bit of Hindi. A composer of music, he plays classical and electric guitar, bass, and piano, and he has also been known to sing. With his family, he enjoys playing music, strategy card games, biking, playing outside, traveling, reading out loud, and watching 1980s movies. Michael values finding the hidden gems and turning disparate skill sets into creative innovation.

Sometimes you need something to completely break before you realize how many pieces went into it. And seeing what those pieces actually are gives you a chance to understand it in an entirely different, deeper way. From this atomized state, you have ultimate flexibility in how you put it back together, and ultimate visibility to all the possible combinations. There are no preconceived notions. No pre-assembled bits. Just a knowledge of what the thing needs to do once you put it back together.

That was my situation. I had been given a software development project and team in crisis. This product was promised to customers. This product was promised to internal enablement teams. In three months. The project and team were completely broken.

Like a first responder arriving at an accident scene, I had urgent triage to do on the victims.

I interviewed each developer. I scoured the Jira project and design documents. This is what I learned.

The project had been handed to a few senior developers by a senior executive via a set of gap-filled verbal summary descriptions of the vision, heard slightly differently each time. A product manager, who was over-allocated, had made a best effort in his free time to spread his inferences of the senior executives vision, dosed with some practical reality and his own opinions as well, across a dozen Epics in Jira, usually with a single line such as Give end user ability to view activity or what could best be characterized as a to-do: Admin experience.

The handful of developers were left to float for a few months, drawing up design documents and continuing the lines of inference down to the User Story level. They spent some time writing code, spiking, coming up with questions, getting unspecific answers, and then just moving forward with whatever made the most sense to them at the time.

Then, in an effort to speed delivery, a dozen more developers were added to the team, and the engineering manager was quickly overwhelmed as he still had two other teams to manage. The engineering manager delegated scrum master duties to one of the original core developers and largely disappeared from daily interactions with the team. The newly ordained scrum master started all the sprint rituals with the new team, from daily standups to retrospectives. There was still no full-time product manager.

With increasing pressure to provide a commitment to the pre-ordained delivery date, they did their best to figure out what they were trying to build. Each developer took ownership of an Epic and, feeling the pressure, sized them optimistically, sometimes predicting completion in as little as a week, without time to study the code or plan the design.

They plunged forward, working on Epics with few or no User Stories, delivering code as a best guess for what they needed to do. If there were a User Story or two, they were also one-liners, and not sized. They were brought into existence just before they were needed or, if earlier, they were abandoned or forgotten, because the project had no backlog set up. Much work was done without any User Story to track it at all.

Labels were created and applied to categorize the state of or grouping of a story, and as those things changed, the labels did not. Each developer had their own interpretation of what many of the labels actually indicated. Reports were created to give metrics to the labels, and as they drifted out of functional usefulness, they were abandoned but not removed.

Many Epics contained User Stories that seemed to no longer apply to the Epic. Duplicate User Stories seemed to exist, with subjects like Logging implementation for users and User logging. User Stories implied and referred to, but did not link to, designs that did not exist in any identifiable location.

There was no backlog. There was no plan for sequencing and tracking work, or predicting when it would be completed, except for a spreadsheet of Epics and owners and sizing which was used during standups to update on progress toward Epic completion.

No matter how much time a developer spent on the work, at every standup the amount of estimated time left to complete the work was the same. If estimates changed, there would be challenges and lectures from senior management. Having to plan or detail, the developers could not respond with any organized story, justifications, or nuance. Senior management bullied them into hiding their confusion. Every day, the update was the same, lots of work was done, progress was made, and the amount of work remaining stayed the same.