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?
I can’t believe I’ve never added my name to the Agile Manifesto before. I feel like I’ve probably tried before, but must have botched it somehow. Anyway, hopefully today’s my day. Here’s my endorsement:
“Collaborative teams of developers and customers can achieve great things. The foundation of collaboration is communication. The Agile Manifesto and Agile Principles are not a prescriptive process for managing projects, but instead serve as a vision or framework around which teams build their own development or project management processes. The genius of Agile Alliance was to recognize that, while each project and project team faces different challenges, this collaborative philosophy can help focus a team’s approach, resulting in more effective, productive project efforts.”
I was recently confronted with a familiar situation: a customer telling my team how to design the system during a requirements session. For those of you unfamiliar with application development projects, let me explain the scenario this way; you’re building a new house and you tell your architect that you will need a place to store all of your gardening tools and lawn equipment. You instruct her to design a second-story storage area into your garage. “Wait,” says the architect, “I think I can get you all the storage that you need if we just add a built-in shed on the back of the garage.”
“No,” you insist, “the second-floor storage area is just the ticket.” What should the architect do? What should my development team do? The way I see it, we have a handful of choices:
- Beg for forgiveness (not permission) and do it
the right wayour way.
- Debate with the customer until we’re blue in the face about the right way to do it.
- Sell the customer on
the right approachour approach.
- Throw our hands up and walk away form the project.
- Just Do It (the customer way).
Here’s what happens in the first four scenarios above:
- We tick off the customer, probably miss their vision and end up owning (responsible for) the feature/process/system in the end.
- We tick off the customer, waste a ton of time debating over pointless details and end up right back where we started.
- We convince the customer our approach is best, probably miss their vision and end up owning the feature/process/system in the end.
- Tick off the customer, get reprimanded for not making it work and hopefully don’t get fired or sued.
More often than not, the best approach is to swallow our pride and “Just Do It.” I know what you’re thinking. I’m taking the easy way out. “Just Do It” the customer way and then blame them when the project goes down in an inferno of failure. Except, that is not what I’m recommending. No, what I’m suggesting is that there is a strong possibility that neither of you is right and that by insisting that you are (or even quietly believing you are), you are setting the project up for failure.
How can this be, though? Developers know how to write software. We’ve studied database normalization, object relational mapping, decoupling and user experience design. We’re the experts…in software design. But are we experts in the customer’s business? While we may have years of subject matter experience, how well do we understand our customer’s specific business processes? Even if we have spent many years inside the customer’s team, working with them and their current systems, we may not understand their vision for the project. Heck, even the customer may not truly understand their vision for the project.
As an Agile practitioner, I believe that respecting the customer’s requirements is important. It’s important not just because the agile manifesto says so, but because (along with the rest of the principles covered in the manifesto) it’s the most effective way to uncover the real requirements. I’m not suggesting that we should blindly follow the customer’s lead into a situation that my team or I believe to be ill-conceived. I’m saying that we should respectfully explore the customer’s ideas. Doing so in small, well-planned chunks will usually bring more clarity to the goal that the customer is trying to achieve. So maybe I should rephrase my approach as “Just Go With It.” By exploring the customer’s vision/concept/requirement, we allow ourselves to understand more about them, while also showing the customer that we are listening to them. Not only does this improve our understanding of the customer’s vision, but it also develops credibility with the customer, which hopefully makes it more likely for them to respect you and your vision down the road.