When Will <Insert Cool Feature Name Here> Be Complete?
I love working with dynamic teams that strive to iterate on ideas and build something that works first, then improve it by adding features and enhancements that provide tremendous business value. Working on a team recently, I encountered the question that I chose as the title for this post: “When will the feature be complete?”
Notice the words in that question. It may appear to be semantics, but I think the choice of words is significant. Often in Agile, we talk about the definition of done (DoD). The DoD is extremely important because it’s an agreement we make as a team. The whole team has put a lot of thought into the DoD and it provides a standard that we can use each sprint to ensure that we are contributing to the forward progress of the project and not just creating more technical debt.
So, which word in the question do you think gave me pause and spurred me to write this blog post? That’s right “complete.” When is any feature “complete” and how can I, as a single team member, tell you when the feature will be “complete?”
To give a bit of context, this is a fluid team where people are rolling on and off the project almost weekly. There isn’t a formal backlog and most team members aren’t familiar with Agile. This may seem like blasphemy to many Agile adherents, but the point I want to make here is that I treat the person who posed this question as a business stakeholder. Even though the person is part of delivery team, this team is configured mostly of business customers and a very small technical team. There are many dysfunctions within this team, but it’s an awesome way to test Agile and try different configurations within the Agile principles.
My larger point is this: the feature is complete when it provides the business value that is sought. It could be complete now. Does it need that other bell? Will that extra whistle really make the feature “complete?” Maybe. Business customers are often called to be proxies for our larger user base and I see this as a good thing. Sometimes, however, proxies try to think of every conceivable use case and are sure that they need to solve for all of them. Often times, however, this results in Lowest Common Denominator (LCD) solutions that are over-complicated in their desire to be “simple.”
Users today are smart. They spend a lot of time with technology and they know what is new and interesting before most IT or development shops do. We need to recognize that, although, reducing clicks is generally a good thing, if it’s taken too far, it is patronizing and makes users feel stupid. More than that, users can figure things out quickly nowadays. If they get stuck, provide help along the way. Maybe a well-crafted label, an intuitively placed usage note, or a thoughtfully considered visual metaphor will give the user what they need to keep moving forward on your site or with your App. Everything doesn’t have be solved by technology. We’re people, be social, talk, and introduce new features to your users as humans. Do it in person: we can run demos, brown-bag talks, or, if the physical distance is too great, fire up a Skype session. We have a tremendous opportunity to deliver what people need without reducing it to the ridiculous.
So, when will the feature be complete? I don’t know. I do know, however, when it will be done in this sprint and if you tell me your perspective and we discuss what is needed and have a human conversation about what will provide true value, we’ll be a lot closer to the feature being “complete.”
What are your thoughts on this question? Please share your comments, observations, rants, or other helpful insights in the comments!