The List Is Not Enough Rikard Edgren
If you just do what’s on the list of things to do, I think you can accomplish decent things, but nothing great.
I don’t dare saying this is a general truth for everybody creating something new, so let’s focus on software development.
There are many management models, and many of them boils down to something like “do the things on this prioritized list”, and the list might be items in a detailed project plan, a Backlog, test cases or sticky notes.
As an attack, and a defense, of these systems I’m saying:
to accomplish something great you got to do a lot more than what is on the list
The reason for this is that you cannot in advance know about all important things and possibilities that are associated with what your team is trying to accomplish.
Great software has even more than the right capabilities, impeccable reliability, super-performance and perfect usability.
There are no Gods in software development that can specify the details in advance.
And if there was an almighty capable of doing this, it would take too much time to read and understand all items on the list.
If the input for the software is taken from the actual demands of the customers, you can give them what they want, but not necessarily what they need, and probably not something that will be very valuable for many customers. And the item on the list will probably focus on functionality, without all implicit details around quality characteristics that can sum up to a great product.
So the solution is to take height for this, for example by
* not performing (detailed) time estimation and planning
* allocate time for “creative slack”
* pad all estimates with an appropriate percentage
* add extra time for polishing (that must be spread out from start to finish)
* rotate free, unscheduled roles
* encourage everybody to pursue interesting things that emerge
* perform one unscheduled “good” thing for every other item on the list
* schedule vague items that can mean almost anything
* but most importantly: have skilled people doing their best to create valuable software
The item “schedule vague items that can mean almost anything” confuses me a bit. Just scheduling time also can mean “anything”. I such cases I think you do need to just schedule time for them, but clarify a bit more how the timeslots should be spent, i.e. “do research” or “implement a prototype” or “clarify with customer”.
I have seen to many devs being given the task to work on something that was unclear without any idea on where to start.
I agree that “mean almost anything” is too vague.
“shedule vague items” is enough, with good examples like yours.
We should also remember that different persons want and/or need different vagueness/freedom.
All of the above, or no list at all, might be heaven for some, but chaos to others.
Finding the balance for your team and organization is very difficult.
In the end, it’s all about the people.
Is there anyone out there not doing like this?
If there are 1 zillion certified scrum masters out there, there ought to be a lot of things detailed in the sprint backlog.
Really, it is all about how detailed you are as a project manager/scrum master/team member to convert the items in the requirement list/product backlog into tasks in order to complete the requirement/user story.
I would rather suggest the opposite!
There are so many things that are taken height for that are unnecessary.
Or only use the bullet “allocate time for “creative slack”” if you have skilled and experienced testers.
Henrik, I’m not sure I understand your comment, or maybe my post was very unclear.
– “anyone out there not doing like this”
I honestly believe that in a majority of workplaces there is nothing more than “buffer slack” (small things you do in between tasks) available to do things that aren’t on the list.
– “…there ought to be a lot of things detailed in the sprint backlog…”
yes, that’s my issue, all things are put in the backlog, and you do the prioritized ones.
those good things where the benefit isn’t thought to be big will never be done, but in many cases those together might make the product great, or enable the product to becoming great.
– “I would rather suggest the opposite!”
Is this for “pad all estimates with an appropriate percentage” or for the whole post?
You don’t really mean “only do exactly what’s on the list”?
The “padding” I have seen generally is done because things take longer than you think, people are sick etc, it’s not done in order to do things outside the lists.
I think doing things outside the list comes naturally for testers using an exploratory approach; when you see something interesting you often just test it, you don’t put it on a list for future prioritization.
But for testers following detailed test cases I don’t think there is room for this.
And for developers in Waterall-esque environments I think the list rules.
In Scrum-like environments I think it’s the same, but there is more freedom for individuals to put things on the list, and make their case.
As I understand Kanban, a core item is to work on a limited number of things concurrently. To also do items outside the list would be against the essence of this thinking.
In the end, I think it is a matter of control.
“anyone out there not doing like this” – This was ironic, but with some truth in it. It all depends on the culture in the team, and many times there is a good understanding for testing tasks that aren’t easy to estimate time for. And if there are 1 zillion certified Scrum Masters this would be “by the book” (even if I doubt that it happens, hence the irony).
“yes, that’s my issue, all things are put in the backlog, and you do the prioritized ones.” Do you mean a Product Backlog? I was talking about Sprint Backlog. A Sprint Backlog contains all tasks that you identify that you want to accomplish during the Sprint. It is not a prioritized list.
I am not sure what I meant by suggesting the opposite! 🙂
What I think I meant was that there are so many times where I see that it has become routine to take height for a lot of things without thinking about the context.
In most projects you need to motivate the cost (even if it is hard) since there is a budget for a project; to come up with a balanced and justified budget is golden and in order to do this you need to consider the cost for the test project. And it is the project manager that is responsible for the budget, so I’ll guess that if the project manager wants “to accomplish something great” he/she must support and sanction “to do a lot more than what is on the list”.
If we talk about Kanban, the things on the list might be very vague. And it could be a list of testing tasks. And it could be without a time estimate.
I do think that I agree with what you suggest as a whole.
But as I interpret you, the “list” you talk about is focused on functionality (E.g., “And the item on the list will probably focus on functionality, without all implicit details around quality characteristics that can sum up to a great product.”). I often see “lists” where testing tasks are separate or disconnected from functionality.