agile

Blog Post: In Agile, Don’t Focus on Fast

There’s a lot to approve of in this Agile post by Mario Moreira, saying that we shouldn’t confuse short iterations of shippable code with rushing to get something out just for release sake. You see posts like this a lot from evangelists of the framework, because you never want to swing the pendulum the other direction:

“Building the wrong thing fast is like driving a dragster that races off the motorway when the road twists and turns as they often do.”

The same can be said for topics like documentation, planning, and communication. When some take a class on Scrum, Lean, XP or any other Agile framework, it’s not a far stretch to change your thinking towards all three. 

It’s just not practical to put out software with zero documentation and planning. You can’t over-communicate. Definitely can’t expect that slashing meetings will result in large projects out in a couple of sprints.

How do you find the balance?

It’s impossible to have a “one size fits all” answer for every company. Products without any legacy code or minimal support needs can get away with less documentation. Some teams get away without a grooming session, or a daily standup. There’s always customizations you can make to fit your needs. Wouldn’t be very agile without it.

When focusing on the speed of delivery, ask your stakeholders what’s more important: time, budget or scope. When that decision is made, you know how to write your go-to-market plan.

One last note: “fast” is always in the eye of the beholder. Just because your boss uses the word in a presentation, doesn’t mean his definition is the same as yours. “Fast” may mean a 3-month release cycle instead of six. It may mean a 6-month release instead of 12. Shippable code means it could be released, so don’t freak out when you hear it. 

Blog Post: In Agile, Don’t Focus on Fast

Read more "Blog Post: In Agile, Don’t Focus on Fast"

Blog Post: All Feedback Is Important

Make no mistake, when you are a serial entrepreneur trying to find the next billion dollar idea to be purchased by a large corporation, there’s a lot of knowledge in this blog post from Brett Berson of First Round Capital. You must be the true essence of agile to take an idea and slowly craft it into seed money.

For the rest of us, please feel free to take this article with a grain of salt.

Granted, I do not spend extended periods of time trying to find the next big thing. I am committed to providing value to the customers of Dealertrack Interactive and deliver well written guidelines of that value to my development teams.

That means getting feedback.

Some of the feedback comes from Google. Other aspects are from the business end of our company, as well as customers. In the end, the best feedback comes from a combination of all three.

I do not mean to degrade the value of this work. While the next big thing could be on the tip of my tongue, I have made quite a career of taking the ideas and thoughts of others and crafting them into a reality. Good product managers can also find hidden gems within their field with research and lots of time interviewing every single stakeholder.

Cherish the feedback you have the opportunity to receive. While not every idea has the same value, it is all on the road we travel. Sometimes, it takes a little work to reach the end.

Blog Post: All Feedback Is Important

Read more "Blog Post: All Feedback Is Important"

Blog Post: Work Estimates Stink…Sometimes

I love reading articles that question old business processes and point out the fallacy that at one point in time were shoved down our throats as “the way things are.” This article by Michael Dubakov at Target Process is one of my favorite because it involves one of the most cherished tenets of software design: work estimates.

Make no mistake, you have at one point in your career wasted a ton of time trying to figure out how long work you needed to do was going to take.

This applies to a ton of industries, not just IT. My father, who is an electrical contractor, uses estimates to know how much to charge for his services. He needs to accurately know how much his time is worth so that he can appropriately charge for it on an hourly basis when he hands a bill to customers. 

Same for developers, although in many medium-to-large-sized companies it is difficult for a developer to know this information. In reality, the financial worth of his or her time may not be valid because there are sales and accounting reps for that. What they do need, is an effective way to take a sprint and cut it into chunks so that work can properly be slotted into it.

In a sense, that is what your time is worth.

Now, as a product owner, it is my job to push the development team just enough to reach for a little more work than they would originally assign themselves. That is the tough challenge of a PO or Scrum Master. We must know when to push and when to lay off. 

This is where points comes into play.

With the advent of Agile methodologies, “pointing” a story became the new way to measure the work a team would try to accomplish in a sprint. Over time, this measurement is averaged to calculate the team’s velocity. Just how is this point measurement reached?

Scrum experts such as Mike Cohn recommends taking a list of tasks and assign numbers of the Fibonacci sequence (1…2…3…5…8…13…20…and so on) to come up with your own version of the scale. That way, tasks or stories can be measured for future work. That begs the question of how you know if you are making an informed decision or not.

Is that even possible?

Too informed of a decision means that we are falling back into the waterfall method. Too little of information involved with that decision — what’s the point of having process to begin with?

Measurement must happen in some form, because there’s no way to inspect and adapt if you don’t. The trick to this scenario is deciding as a team (and department if your company has several scrum teams doing work) what is important to making informed decisions.

I’m fortunate enough to work at a company that requires just enough. There are times when the heads of product and project management require more paperwork for work from me, but that’s what I’m paid for. The team shouldn’t have to worry about it, they have great work to put out for our customers.

To be successful, I need software that works. The product line is vast and the requests from our clients are even bigger. We have to get work done effectively, which means spending just enough of our time estimating. Then we can funnel our attention to the tasks at hand, then transparently measure our performance internally and improve.

So work estimates stink, but only when you have to spend more time estimating than necessary. To generate 100% accurate estimates, work become less important than the process. Agile means to use just enough of a framework to be successful and then get out of our own way. 

Working software, over excessive documentation.

Blog Post: Work Estimates Stink…Sometimes

Read more "Blog Post: Work Estimates Stink…Sometimes"

Blog Post: @ev Is Bringing #Holacracy Mainstream

Ev Williams has made quite a name for himself. Not just with the software products he has helped create, but also in the way he runs a company. This post on Medium describes one of the principles of a social technology called holacracy.

Simply put, holacracy is a system for running an organization based upon ideas such as empowering employees, limiting office politics and boosting meeting efficacy.

I really liked the concept in this article, which involves ending meetings with a “closing round” by all attendees. It can be used for summary, takeaways, confirmation, affirmation, etc. Even with 30 seconds of concise dialogue, a ton of information could be communicated to team members going forward.

“Great meeting today. It highlighted that I need to follow up with marketing on their projections for the new product hitting production next month. It will allow sales to start generating buzz with customers beforehand.”

Try this out in your next planning session or retrospective. It allow confidence to be built, remind others of roadblocks and issues, or tasks to be confirmed before starting them.

Blog Post: @ev Is Bringing #Holacracy Mainstream

Read more "Blog Post: @ev Is Bringing #Holacracy Mainstream"

Blog Post: User Stories are Overrated?!?

Today’s link really got my blood boiling this morning, mainly because I have had Scrum training from Mike Cohn. I also hate it when people feel the need to go after the top people or businesses in an industry as a means of getting some notoriety. That may or may not be the case, nevertheless I watched the video from Tom Gilb seething.

After some Googling, I found out Gilb is a engineer and has made quite a career out of the inspection and metrics behind great software. I didn’t need to search to find this out, though, because that world view is clear from his approach to user stories.

That’s when it dawned on me that this video is a great teaching tool for product personnel. As I always say to my colleagues: user stories are the beginning of the conversation with development, not the end. The mistake I think Gilb makes is seeing stories by themselves as the sole piece of information an engineer needs to do complex work.

Having used this method of communicating requirements at several different companies, trying to lump all user stories in the same boat is hard. We all write them differently, and compile acceptance criteria differently. Within the same release, I am capable of providing a great amount of information that gives developers everything they need as well as the opposite. That’s where the conversation takes place.

Every engineer and architect I have spoken to have had their fair share of poorly written requirements. My favorite joke is to tell my team, “show me on the doll where the product owner touched you.” The challenge to my job is finding a way to meet them in the middle of the conversation and craft stories towards a method of delivering the best features possible.

So, instead of bashing Mr. Gilb for not reading and understanding Cohn’s methods, I would like to thank him for reminding me the purpose of my job. It’s not to stand in the way of great software, but making it easier and well thought out.

We involve stakeholders, help with design, converse with our teams, and document everything along the way. We are product managers, Tom, and our user stories can be your friends.

Blog Post: User Stories are Overrated?!?

Read more "Blog Post: User Stories are Overrated?!?"