Some teams have “rockstar” developers who only work on “spikes.” A spike is a story where a developer is assigned the task of figuring out how to accomplish something. The outcome of a spike is a prototype, or roadmap for reaching a prototype. Included in the task might be to evaluate different methods of accomplishing something, do you use one database or another? Or a spike might simply be to try out something that was discussed with the greater group, seeing that a simple end-to-end implementation can be accomplished.
This is the piece of the puzzle I couldn’t figure out by myself. I needed to see it in action, implemented well, to understand what I was missing. I’ve seen a lot of stories sliced wrong, and some sliced well. Slicing stories properly can be the difference between a high performance team, and one floundering. A story – a task or ticket – is a slice of work that is defined by a product owner.
The first big “Agile” change I implemented was standup. Without it you can’t even begin to know what’s going on in your team, let alone help accomplish all it needs. But all standup is, is a daily window into what everyone is doing. That helps you know what’s going on, on a day-to-day bases. But that doesn’t help you take control over what’s getting done. The second most impacting element of Agile I implemented was limiting Work In Progress (WIP).
Early on as a manager, I came across Agile methodologies, but wasn’t able to get training in it, so I had to figure out how to implement it myself. After reading countless books and immersing myself in whatever I could find online, I was able to implement several key elements. But I still was missing a few crucial pieces. It was only after working in a self-described “academic” Agile – with a capital ‘A’ – environment that I know now what I was missing.