Does Iterative Development Stifle Innovation?

“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?

Agile Manifesto Signatory

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.”

What the Customer Wants

During a recent customer design session (combination requirements meeting and design discussion), I was surprised when one of the stakeholders quoted me as saying that it was the development team’s job to build whatever the customer wants. I paused for a second and thought, “What did I say that was interpreted that way?” I know I would never intentionally tell a customer that our job is to build whatever they want. Our job is, of course, to build what the customer needs. There is a world of difference in those two statements and I took care to explain that difference to all of the stakeholders at the table. Neither of the teams truly knows what the application we’re developing will look like in the end. We all have ideas (at least as many different ideas as there are people on the team). My job as an agile project leader and business analyst is to facilitate communication between all of the players in a way that uncovers customer needs and results in a system that can meet those needs in way that our customers find at least acceptable (but hopefully exceptional).

The 6 Sins of Project Leadership

So many PM articles focus on the nuts and bolts of project management practices. In this post, LeRoy Ward focuses on how to lead projects and project teams. I can’t agree with the need for authenticity enough (sin #5). As one of the commenters points out, being authentic is about being the genuine you. You don’t have to highlight your warts for everyone to see, but it’s OK to admit that you don’t know the answer while also demonstrating confidence in your ability to figure it out (hint: that doesn’t mean you have to do it by yourself…see sin #2).

LeRoy’s suggestion that you act as the CEO of your project (sin #1) has come into to sharper focus for me recently. I’ve worked on many projects where getting all the details right was more important than getting the project done. I’m not suggesting that buggy or half-baked software should go into your production environment, but PMs should be looking for ways to get working portions of software projects in the hands of the customers as early as possible. In the past few years, I’ve started evangelizing about how a system waiting to go to production provides no value to the organization.

Check out the article. It’s a good read.

NOTE: Projects At Work requires registration to read. This will result in some graymail, but Projects At Work consistently delivers good content to my Inbox as well.