Tag Archives: software project

Story Card Hell

Posted on by

I was recently asked the following question:

“I’ve been dropped into a situation best described as “story card hell.” How do I reduce complexity of the software project planning without losing features?”

The project was to replace an existing system. The behavior was largely known. As a result, the initial planning generated enough cards to feel like, “way too much detail up front.”

My answer:

Don’t lose the work you’ve done but don’t place more value in it than it has.

Step back to think of the application as a phased set of releases. Talk with the team and product owner about a way of delivering the system in meaningful pieces that customers could (and hopefully will) use. Get creative with defining those steps as long as they lead you down a path towards your ultimate goal.

Once you have that road map. Do an exercise with the team to group your existing stories into those releases. There will be a natural tendency to add and change stories. That’s fine but don’t get too distracted by it. The main point is to get a sense of the relative size of the releases and move the bulk of the stories out of your immediate planning concern.

Now focus on the first release. Spend more time on those stories but still not with the scrutiny of an iteration plan. Make/allow the team to live with ambiguity. Set up an agreed upon rule of thumb for how much bigger a “theme” is from a real “story” and let the team know it’s okay to discuss these things at the “theme” level.

Story Cards

Then prioritize your release backlog. Have the team chunk the remaining vague stories/themes into future iterations for that release. This is your release plan. Expect it to change. Again, you’re getting a rough sense of how many iterations in the first release and moving later stories out of your immediate concern.

Now you can focus in detail on the stories for the next one or two iterations without getting drowned in details. Don’t be surprised if future stories become irrelevant or drastically change as you get to the iteration within which they fall. It’s okay.

My answer was based on what we’ve tried to do at Oxygen with coaching on release planning from Hubert Smits.

Here’s the full thread off LinkedIn.

The buck stops… where?

Posted on by

A fundamental value of computer ethics, agile and Scrum is truth telling.

As developers we have an obligation to provide honest feedback around decisions that affect either the quality or value of software our employer asks us to create.

I am now the senior person dedicated to software in my company. If that means anything it is that my responsibility has expanded to protect the best interests of my employer on any project we undertake that has software development dependencies.

The profound challenge in this is that while the company has expanded my scope of Responsibility it has not necessarily expanded my scope of Authority. As a mid-size, growing company we give department heads great discretion. My company is also one of many with a structural distinction between online and IT related software development. Therefore my team has no direct role in some of the most visible outputs of our company.

As a result, I cannot have true accountability for some outcomes since I cannot change them. That does not absolve me of my ethical responsibility nor allow me to narrowly define success in my current role. That is why to take my job seriously is to take on a certain amount of anguish.

The obvious answer is that I never should have taken on the role unless I was given commensurate authority. Perhaps this is correct.

I accepted the promotion because I believe it raises the profile of my team and makes more visible the quality and value return they are producing. I also believe that while responsibility without authority is flawed, it is a common state of play for those of us who introduce agile practices into a company. Let’s be honest, introducing agile is an attempt to lead change. Since I am not an entrepreneur it is a given that I will have to earn trust at each step of the way in making that change.

So given these circumstances, what is my responsibility to my employer around truth telling? Who am I obligated to tell truth to? Let’s focus on questions of value and quality and leave aside safety or legal concerns because as dramatic as whistle blowing is, that is not my reality.

Basic risk management tells me that the person who’s interests are most damaged should a problem arise owns the risk. In a functioning Scrum organization this is the product owner — or as Yahoo calls them, the single wringable neck. This one person is held accountable to the performance of a product in the market place. It is to them that any concerns over the value or quality of a software product need to be raised.

As I’ve said, I have a Scrum team but I do not work in a Scrum organization. There are times when projects originating outside my team do not have a clear “single wringable neck”. This presents a huge challenge. Who will be most affected by a problem if no single person is assigned real accountability for the outcome of a software project?

I have decided after hard experience that in circumstances where there is no responsible and empowered product owner the person most affected by problems is the person most identified with our brand and our products, my CEO. Therefore my responsibility for truth telling is to her.

This is, to me, a freeing realization for in it lies great opportunity for my company. My CEO who has proven herself to be an exceptional product owner. If anyone on the business side understands agile principles and my ethical responsibility as a software developer it is her. If anyone is capable of creating positive change in my company it is her.

Therefore, in the spirit of my CEO’s own vision, I will expect the best of people while maintaining my integrity and independent judgment to serve the best interests of my company, our customers, my peers, and our society.