I’ve been an Apple fanboy since my days using an Apple ][+ back in 1981. Apple has always been about design, but with Steve Jobs return in 1997 and the rise of Jony Ive, the focus on good design reached an entirely new level. I’m fascinated by how Apple makes this work. In many projects I’ve worked on, good design is seen as a luxury to be considered “if there’s time at the end of the project.” Hint: there’s never time at the end of the project. I think good design is part of the technical excellence that must be the foundation of all projects in order for them to be flexible, sustainable and maintainable. For a glimpse into who Jony Ive is and how he’s changed Apple and industrial design, check out the interview.
“Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.” – My Primary Criticism of Scrum, by Mike Cohn
I came across the above blog post from Mike Cohn today and it got me thinking about whether and how my development teams innovate. It is definitely easy to get into a rut, where the team is constantly focused on the simplest possible solution and burning down. It is up to the project leads (Project Manager or Technical Lead) to be intentional about encouraging innovation within the boundaries of the agile process. For our project teams, this is a two step process:
First, project leads must look for opportunities to innovate. Sometimes this will result directly from a Retrospective improvement. Other times, the project leaders need to recognize when a project has a need for innovative solutions and the space and time to pursue those solutions. There is no science here, this is a balance of project resources (people and time) against the value of the innovation.
Second, once we make the decision to explore a new technology, approach or process, we break down the steps to complete this exploration. We define a user story, estimate the story and break it down into smaller stories as necessary. Next we task out the steps needed to satisfy the story or stories and, finally, we execute the stories in time boxed iterations.
I’ve found it useful to place time limits on research tasks. Research is one of those activities that can go down the rabbit hole. When asking developers their Definition of Done for research tasks, it’s not uncommon to hear, “I’ll know it when I see it.” I could work with the developer to force them to define “done” for the story or task, but instead I usually just say ask them how long they want to spend on the research (e.g., four hours, full day, whole week). We use that time frame as a hard stop to discuss the next steps in the process. For example, is more research needed, should we implement the solution or is the approach is unworkable?