Martin Fowler's Blog, page 28

Bliki: OutcomeOriented

People who sponsor development of software usually aren’t very interested in
development metrics such as velocity or frequency of deployment to production. They care
more about business benefits that the software will deliver such as lower manual effort,
better sales conversion, greater customer satisfaction, i.e business outcomes.
Outcome-oriented teams are those that are mandated and equipped to deliver business
outcomes, such teams have people with the capability to carry out all necessary
activities to realize the outcome.. By contrast, ActivityOriented teams are neither
equipped nor mandated to do so. They can only perform one of several activities required
to realize an outcome.

A mandate to deliver a business outcome is very different from a mandate to deliver a
certain amount of scope. Scope delivery is easy, relatively speaking. Outcome
realization requires real collaboration between those who understand the problem and
those who can fashion various levels of solution for it. Initial attempts at solution
lead to a better understanding of the problem which leads to further attempts at better
solutions. This doesn’t work where the product management organization is separate from
the development (scope-delivery) organization.

Outcome-oriented teams are necessarily cross-functional (multidisciplinary) whereas
ActivityOriented teams are typically mono-functional (single specialty). In the most
traditional scenario, an outcome might simply be defined in terms of a project. The
project is funded on the basis of a business case and therefore the desired outcome is
to realize what is promised in the business case. However, depending on the size of the
project it may be organized as one or more teams. When these teams are set up along
activity boundaries it becomes an activity-oriented project (or program) organization.
On the other hand, we achieve an outcome-oriented organization by dividing the overall
outcome into sub-outcomes and assigning sub-outcomes to cross-functional teams that are
self-sufficient in terms of people required to deliver the sub-outcome.

Sriram's book goes into more detail on how to build an effective IT organization
using outcome-oriented structures.

A potential problem of outcome-orientation is that people working in the same
activity don’t get to mentor and learn from each other. To mitigate this, set up
communities of practice along with expert community leads who have the ability to mentor
and the budget to organize community events, buy books and arrange for training.

Executing big projects with an outcome-oriented setup is definitely better than doing
so with an activity-oriented setup. That said, an outcome-oriented approach really
shines when we move away from a project-centric funding model. In projects executed with
outcome-oriented teams, the teams don’t live as long as the outcome is relevant to the
business. They are disbanded at the end of the project which means we lose sight of the
outcome until another release in the same area is funded with another team. This also
leads to a problem of instability of management and reporting structure. These are
limitations of the project-centric mode of IT execution, which can be overcome with a
Business Capability Centric organization (post coming soon).

Acknowledgements

Special thanks to Martin Fowler for his guidance with the content, help with publishing and for the nice illustrations.



Share:

if you found this article useful, please share it. I appreciate the feedback and encouragement

Bliki: ActivityOriented

Any significant software development effort requires several different activities to
occur: analysis, user experience design, development, testing, etc. Activity-oriented
teams organize around these activities, so that you have dedicated teams for
user-experience design, development, testing etc. Activity-orientation promises many
benefits, but software development is usually better done with
OutcomeOriented teams.

Traditionally, big businesses with large IT departments (Enterprise IT) have tended
to execute IT development projects with a bunch of activity-oriented teams drawn from a
matrix IT organization (functional organization). The solid-lined arms of the
matrix (headed by a VP of development, testing and so on) are usually along activity
boundaries and they loan out “resources” to dotted-lined project or program organizations.
Common justifications for doing so include:

It helps standardization of conventions and techniques in development if all
developers report into a single organization (arm of the matrix). Same for testing
etc.

It helps the cause of mentoring, training and nurturing the competency in general
if all developers have long-lived development/engineering managers. Same for testing
etc.

It helps maximize utilization of talent (and thereby improve cost-efficiency) by
staffing projects from pools of supposedly fungible developers, testers etc.

However, activity-oriented teams are prone to optimize for their own activity and not
for the bigger picture of delivering useful software. This is a consequence of what they
are held responsible for and how they are measured. It is common for a team of only
developers to only be measured by their velocity. If they are only tasked with
delivering scope, they will not think about whether it is going to solve the problems it
was meant to. Even if they do so, they may be discouraged by the product management team
- another activity-oriented team that is only responsible determining the spec.

Organizing by activity gets in the way of lowering batch size of work that is
handed-off between teams. A separate team of testers won’t accept one story at a time
from a team of developers. They’d rather test a release worth of stories or at least all
stories in a feature at a time. This lengthens the feedback loop, increases end-to-end
cycle time and hurts overall responsiveness.

High speed IT calls for motivated teams. Autonomy is a key motivator for teams.
However, activity oriented organization can only be granted so much autonomy because
they tend to use it for optimizing their sphere of activity.

A variation of activity-oriented organization are super-specialized teams that may result
in the following ways:

Tool or skill centric teams: e.g. a WebSphere Portal Server team or a BizTalk
team

Architectural Layer teams: e.g. a presentation layer team, middleware team, data
layer team.

They are problematic because they have a narrow focus and they tend to optimize for
team performance rather than the big picture. For sure, some tools may need specialists
but that is no reason to isolate them in a separate team. Specialization isn’t the
problem; organizing along lines of specialization is.

What works better

Software development is an iterative design process. In order to achieve true
iteration and realize the value of fast feedback, its activities need to be performed
with a single team (having a common reporting line) as far as possible. Many internet
business and independent software vendors (ISVs) already operate in this way.

Sriram's book goes into more detail on how to build an effective IT organization
using agile approaches.

Activity-oriented organization may be attractive from the perspective of maximizing
utilization but it comes in the way of maximizing value-addition and end-to-end
responsiveness. In today’s business climate, market responsiveness (time-efficiency)
is more important than cost-efficiency especially when it comes to capital expenditure
items such as software development. Besides, solid-line reporting should be aligned to
the most important goals which are responsiveness and value-addition.

In order to effectively nurture competencies in the absence of an aligned reporting
structure, set up communities of practice along with expert community leads who have the
ability to mentor and the budget to organize community events, buy books and arrange for
training. These communities also help with standardizing conventions and techniques
without going overboard with standardization. As for having a stable reporting manager,
it is only an issue in project-centric IT. A Business Capability Centric setup (post
coming soon) allows
for stable reporting managers.

Acknowledgements

Thanks to Bill Codding, David Wang (Wang Wei), James Lewis, Kief Morris, Patrick Kua, Patrick Sarnacke, Steven Lowe and Venkatesh Ponniah for their comments. Special thanks to Martin Fowler for his guidance with the content, help with publishing and for the nice illustrations.



Share:

if you found this article useful, please share it. I appreciate the feedback and encouragement

photostream 97

Arnold Arboretum, Boston, MA

Basics of Web Application Security: Hash and Salt Your Users' Passwords

If you need to store your users' passwords, it's essential that you never store
them plainly. Instead you must store a cryptographic hash of them, so that people
who get access to your database don't get the passwords. Cade and Daniel explain
how to do this properly: salting the hash to avoid lookup table attacks, and using
an appropriate hashing algorithm to defend against well-equipped attackers.

Refactoring a javascript video store

The simple example of calculating and formatting a bill for a video store opened my
refactoring book in 1999. If done in modern Javascript, there are several directions you
could take the refactoring. I explore four here: refactoring to top level functions,
to a nested function with a dispatcher, using classes, and transformation using an
intermediate data structure.

photostream 96

Burano, Italy

Videos of my talk at YOW! Nights

Last month I was in Australia and gave a couple of talks at YOW! Nights. The talk in Sydney was captured on
video and was just posted to YouTube. Like most such talks, I actually gave a suite of talks, so they wisely split the talk
into the three videos, each of which is 20-30 minutes.

My first talk was on microservices,
which is a talk that’s been captured a couple of times on video. However my two other
talks were captured for the first time. My Event Sourcing talk
describes the technique of event sourcing and its interesting advantages. While it
was one my first small talks, this is the first time it’s been caught on video. My
final talk was a brand new talk on Infrastructure as
Code, which I gave for the first time while in Australia.

Born for it

The stereotype of the socially-awkward, white, male programmer has been around
for a long time. Although "diversity in tech" is a much discussed topic, the
numbers have not been getting any better. On the contrary, a lot of people inside
and outside of the IT industry still take it for granted that this stereotype is
the natural norm, and this perception is one of the things that is standing in our
way to make the profession more inclusive and inviting. So where does this image
come from? Did the demographics of the world's programmer population really evolve
naturally, because "boys just like computers more"? What shaped our perception of
programmers? Birgitta Böckeler digs
into some possible explanations.

Basics of Web Application Security: Protect Data in Transit

As well as protecting your input and output, you also need to protect data in
transit. Cade and Daniel outline why and how to use https to ensure your users
can't be snooped on in the coffee shop. (I can think of someone who intends to
follow their advice shortly :$ )

photostream 95

Florence, Italy