Home > Adoption, Culture, DAD discussions, Goal-Driven, Philosophies > Does your team own its process or merely rent it?

Does your team own its process or merely rent it?


Process ownership

An important philosophy within both the agile and lean communities is that a team should own its process. In fact, one of the principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The idea is that teams should be empowered to tailor their approach, including both their team structure and the process that they follow, to meet the unique needs of the situation that they find themselves in. Teams that own their process will tailor it over time as they learn how to work together, adopting new techniques and tweaking existing ones to increase their effectiveness.

As with most philosophies this one is easy to proselytize but not so easy to actually adopt. When it comes to process improvement, teams will exhibit a range of behavior in practice. Some teams see process as a problem and actively seek to ignore process-related issues. Some teams are ambivalent towards process improvement and generally stick with what they’ve been told to do. And some teams see process improvement as an opportunity to become more effective both as a team and as individuals. This range of behaviors isn’t surprising from a psychology point of view although it can be a bit disappointing from an agile or lean point of view. It has led me to think that perhaps some teams choose to “own” their process but many more still seem to prefer to simple rent it.

The behaviors of people who rent something are generally different than those who own something. Take flats for example. When you rent a flat (called an apartment in North America) you might do a bit of cosmetic work, such as painting and hanging curtains, to make it suitable for your needs. But people rarely put much more effort than that into tailoring their rental flat because they don’t want to invest money in something that isn’t theirs, even though they may live in the flat for several years. It isn’t perfect but it’s good enough. When you own a flat (called a condo in North America) you are much more likely to tailor it to meet your needs. Painting and window dressings are a good start, but you may also choose to renovate the kitchen and bathroom, update the flooring, and even reconfigure the layout by knocking down or moving some walls. One of the reasons why you choose to own a flat is so that you can modify it to meet your specific needs and taste.

You can observe similar behaviors when it comes to software process. Teams that are merely “process renters” will invest a bit of time to adopt a process, perhaps taking a two-day course where they’re taught a few basic concepts. They may make a few initial tailorings of the process, adopt some new role names, and even rework their workspace to better fit the situation that they face. From then on they do little to change the way that they work together. They rarely hold process improvement sessions such as retrospectives, and if they do they typically adopt changes that require minimal effort. Harder improvements, particularly those requiring new skills that require time and effort to learn, are put off to some point in the distant future which never seems to come. Such behavior may be a sign that this “team” is not even be a team at all, but instead a group of individuals who are marginally working together on the same solution. They adopt the trappings of the method, perhaps they spout new terminology and hold the right meetings, but few meaningful changes are actually made.

Process owners behave much differently. Teams that own their process will regularly reflect on how well they’re working and actively seek to get better. They experiment with new techniques and some teams will even measure how successful they are implementing the change. Teams that are process owners will often get coaching to help them improve, both at the individual and at the team level. Process owners strive to understand their process options, even the ones that are not perfectly agile or lean, and choose the ones that are best for the situation they find themselves in.

The Disciplined Agile Delivery (DAD) framework is geared for teams that want to own their process. The DAD framework is process goal-driven, not prescriptive, making your process choices explicit and more importantly providing guidance for selecting the options that make the most sense for your team. This guidance helps your team to get going in the right direction and provides options when you realize that you need to improve. DAD also supports multiple lifecycles because we realize that teams find themselves in a range of situations – sometimes a Scrum-based lifecycle makes sense, sometimes a lean lifecycle is a better fit, sometimes a continuous delivery approach is best, and sometimes you find yourself in a situation where an exploratory (or “Lean Startup”) lifecycle is the way to go.

You have choices, and DAD helps guide you to making the choices that are right for you in your given context. By providing process guidance DAD enables your team to more easily own its own process and thereby increase the benefit of following agile or lean approaches.

About these ads
  1. Dave Dame
    March 3, 2014 at 7:53 am

    Great analogy. It really drives home the need to own the process to make it their own.

  2. Anonymous
    March 3, 2014 at 8:08 am

    I’ve (fortunately) experienced more of the process owner condition, but I’ve observed and experienced process renting as of late with teams who feel they are “… forced to be Agile.” I can see that the culture around these “forced” teams convinced them that they didn’t have a voice in how they worked (so they opted for self-directed models undermining Scrum adoption preferring to have tech leads hand out the work.) My voice attempting to convince them otherwise has worked on occasion but not always. Senior management has often acquiesced in favor of keeping their senior technical staff engaged versus advocating for more transparent and collaborative practices. Scott makes some powerful point above (and I winced a few times, too, based on recent experience.) Timely post.

  3. steven
    March 5, 2014 at 1:55 pm

    I barely have time to finish my tasks, I dont have time to rework a process. Just tell me what works, what I need to do and I’ll do it. Call it “renting”, but unless someone supplies me with a big enough down payment of time for me to “own” the process, then I’ll just keep renting. It is not for lack of interest, just lack of resources.

  4. Dave Dame
    March 6, 2014 at 7:31 pm

    I don’t think owning the process always has to be a big time investment, rather, consistent refactoring of the process to refine it to help make it work for your team/organization. Refactoring the process is good for all the same reasons why you refactor your code…to optimize it…

  5. March 7, 2014 at 8:33 am

    Exactly. As I recently wrote athttp://disciplinedagiledelivery.wordpress.com/2014/03/06/improve-retrospectives-with-process-goals/ you can also improve your approach to retrospectives, and thereby increase your effectiveness at improving your process incrementally, via the DAD framework’s goal driven approach.

  6. Duane Banks
    March 24, 2014 at 8:47 am

    Scott, does process ownership imply that the process is outside of any established PMO framework?

  7. March 24, 2014 at 10:02 am

    Duane, not at all. The team the process follows reflects the overall environment in which they work. This is something that we make clear in DAD’s concept of being enterprise aware. A delivery team will need to conform to the overall governance process within their organization, for example, although on the other hand the governance process also need to evolve to reflect the realities faced by agile teams. It’s a two-way street.

  8. April 9, 2014 at 7:19 am

    So how often have you seen a team that is renting because they have effectively been told they are not allowed to buy? As in management says they must do SCRUM but, no there is no $$ for training or coaching, and due to delivery deadlines (that they agreed to prior to planning) there is no time so we can’t afford to have people out of the office for training. And there is no budget to even get a qualified SCRUM master for the team (the tech lead is supposed to just read up on it and do the best they can).

    Any advice on that type of scenario. The team may want to own but have no support to take that step. Only a truly exceptional team will find a way to own their process in this case.

  9. April 9, 2014 at 8:46 am

    What I typically see is that the team doesn’t even know they can buy. They take a two or three day course, they may read an article or two (and sometimes even a book, egads!), and then the pretty much do what they were told.

    I do often see situations where management tells them to own their process but they either don’t know what to do or they don’t take the initiative (often because they’re too busy building stuff).

    I do see the problem you describe, a lot in fact, where the organization doesn’t want to pay for coaching or even to hire a few experienced people to flesh out the team a bit better.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 624 other followers