Jump to content

Task-Force Driven Development


Jimi Wikman

188 views

 Share

On Twitter I have engaged in a rather long set of discussions regarding mob programming and during one of those discussions Steve Bishop talked about Task-Force Driven Development as a concept. This is kind of how I am used to working as well, even if we do it slightly differently than what Steve describes. So I thought I should try to explain how I am used to working and how I think we should work in certain situations.

So this is the tweet from Steve in response to a tweet posted by Woody. The way Steve describe his concept it is a form of a small task-force that scramble, or swarm, around a feature for the duration of that feature. So in a sense it becomes a mini project where you ensure everyone that is needed to realize the feature is present for the duration of that feature's development.

I think this makes sense, but in my experience you don't need all the people involved around all the time, because there is a lot of time during the realization of a feature where input or brainstorming is not required. So the way I am used to working is with focused efforts to clarify the need of the feature and then to work together to find a solution before we build it. This is all part of the requirement process for me as that is where a good idea is fleshed out to become tangible and then defined in terms of how to realize it.

So the way things usually go is this:

  1. An idea is hatched somewhere, by someone. It does not really matter where or by whom.
  2. The idea is explored briefly by the people that are responsible for the budgets to see if it has any value to it that fit what the organization goals are, or if it is valuable in an area where we do not have a goal yet (gap).
  3. If it is deemed to be valuable and we want to invest in it, then we start working on defining it and find the best solution. The purpose of defining things is to ensure everyone understand what we are trying to achieve and have the developers feel confident that they can take the responsibility to realize the idea into production. In order to do this we bring in everyone that needs to be involved, which should always include 4 roles as the bare minimum: Developer, Tester, Need Owner and UX. If the idea involves multiple teams, then we always add the people we need from the other teams as well to coordinate work and plans.
  4. The outcomes of this collaboration are to define the solution design, activities needed and to create plans for those activities. These plans are to ensure we can work on the idea at a reasonable pace and that we have room for the unforeseen (risks) to mitigate stress and to avoid wasting time replanning all the time.
  5. During the work all involved individuals are working close together so if questions or problems comes up we can address them quickly and adjust any plans that are affected right away.

To a hammer everything is a nail...

Now, if you read this and your mind is set to oppose everything that is not defined as agile or Agile then you probably scream that this is waterfall right now, which is neither true nor false. So let us break things down into activities and see where we end up:

  • We think of something we think can add value
  • We verify if the value is worth pursuing
  • We collaborate on how to realize the value
  • We set expectations and coordinate with others that are affected by the realization of the value
  • We continuously reevaluate the work done to realize the value based on unexpected events

As you can see these steps are done in Waterfall and any Agile framework as well. It is also used in pretty much every other methodology as well. It is just your interpretation based on your assumptions of me that writes this that tint what I have written in either direction.

Back to Steve again

So when I read Steve's concept it reminded me of our third step where we collaborate on how to realize the value. Now Steve just posted a tiny fragment of his concept obviously so I could be way off because I interpreted his description wrong (to a hammer and all that...), but if my interpretation is right, then his concept basically extend the way I have been working for years to a more cohesive form over time.

I see many benefits in this approach and I think there are many use cases for when this is the better choice. I also think there are many use cases when this might be wasteful, so I think the best way to utilize this concept is to try it out and see in what situations it adds additional value and in what situations it adds unnecessary cost to the value creation.

I hope to learn more from Steve on how his concept works in practice and I also hope to learn more about his theories about this concept and discuss it with him in more detail.

I love new concepts and trying to see where they fit into my perspective of things so I can reevaluate my own understanding and learn new things.

How about you?

 Share

0 Comments


Recommended Comments

There are no comments to display.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...