TIEKE Brief #10 on Agile

by

Last Tuesday, on 4th of May, I was participating the TIEKE Brief #10 “Scrum – ketterästi” as a speaker. I was closing the brief with a title “Reality Check”. There is much hype and unfounded optimism on Scrum and Agility that I felt it was appropriate to try to ground some of that. Scrum and Agile is hard. Change is hard. It’s easy to write bad software expensively; it’s very hard to try to do as good software as you only can with as little waste as possible. It is known that most Agile transitions fail to meet the expectations.

While the presentation should be appearing also on the TIEKE site, I’ll post it to my presentations page (also linked to this post). It’s in Finnish and in a very much simple format. Should I expand in text? Okay, will do quickly…

Agile isn’t a silver bullet. It doesn’t solve most of the problems typical organizations have. It will expose them. It’s up to the organizations to fix their bad habits or poor operation. Scrum is pretty quiet on “how” (purposefully, because it isn’t a methodology), so we must turn our attention to other sources. Lean Software Development gives a pretty good overview on the kind of product development Agile environments should foster. An upcoming book by Stephen Denning, labeled Radical Management, takes a more comprehensive look at how businesses can become radically better. Dan Pink made a great case in his TED talk about how rewards are actually damaging our businesses and our innovation. Etc. There’s lots to learn for us.

One reason Agile transitions go awry is that many managers perceive it as “yet another methodology” and fail to grasp at the ideological change behind Agility. THEY have to change, too. THEY have to understand that the whole organization must rethink how it works and what it values (not all in one swoop, but eventually). THEY need to get the whole organization excited and energized, and steer the whole organization to a new direction. Nothing will change, if nothing is changed.

On a more general note, I reminded that responsibility cannot be outsourced. The organization is ultimately responsible for its own business, because if shit hits the fan, no-one will bail them out (unless they are banks or the Greek government). Contracts may be used to also hurt the other party grievously, but doing so will not remove the fact that the project is failed and the time spent on it is already gone (along with a possible window of opportunity or significant business value). Traditional approach is trusting a lot on agreements, whereas Agile approach rests the responsibility and opportunity to steer the project to the customer, as it should be. The organization can, in concrete terms, keep responsibility in their own hands. Of course, that doesn’t magically remove problems and mistakes from projects, but the organization remains in the best possible position to act on them.

As a second general note, I claimed that a project without a solid vision and a good understanding of constraints fails even before it has started. How do you steer a project to its destination if you don’t know what it is? Or how much you can spend time or money on it? You don’t, of course, so it’s imperative to understand them. Don’t start development until you do.

A lot of the focus in Agile processes is on having the right people on board and by having them communicate openly. And that doesn’t mean well designed reporting (although that may be part of it). It means talking to each other, within the project and to people outside the project. Face-to-face, if you can. Avoid information bottlenecks (like the traditional project manager) and promote many-to-many discussions and information radiators. Get users involved as much as you can. And so on.

Lastly I emphasized that Agile isn’t a cost savings scheme but a value increasing scheme. As a consequence of generating value more effectively most Agile projects also save costs, but if cost savings are the main focus, organizations very easily save in the wrong places (i.e. in the beginning and from communication) and therefore ruin (or at least damage) their success chances. Based on personal experiences, I’d say that Agile projects cost more in the early phases of the project than the traditional approach. But so would the traditional project if it tried to make sure people know each other and talk about important things together. Many problems traditional projects have are because they don’t.

I’m not sure that was quickly, but let’s hope you got this far. If you did, please leave comments on what you think of my points and opinions. Do you think I’m going the right way?

Advertisements

4 Responses to “TIEKE Brief #10 on Agile”

  1. Petri Heiramo Says:

    Lare Lekman also posted about his presentation in the TIEKE event:

    http://ketteryys.fi/2010/05/04/ketteryytta-julkishallintoon/

  2. Jarno Says:

    Hi, Petri!

    Thanks for a great presentation! And yes, I do think you are headed in the right direction.

    I have a couple of comments on your presentation and opinions but let me first begin with a short story:

    A Product Owner is working in a large software company with a development team of just a few people. The product is fairly mature and has some outside customers.
    The Product Owner’s superior wants to change the product in a way that requires major changes in its architecture, for example. The development team estimates the changes might take two sprints, i.e. one month in their case. The Product Owner tells this to her superior and is questioned whether the change is really that big and the developers are being honest in their estimates.
    The Product Owner and her team both trust in each other. The superior has a degree in business and only knows about Scrum what she has been told by her Product Owners. Both the superior and her superior have previously asserted that software will be developed using Scrum and best practices.

    See the differences between your presentation and how things are done in the example organization? I bet there are thousands of organizations like that one. That story is real, by the way.

    From what I have seen so far, I completely agree with you about managers failing to “get” what Agile is about. Most of us (software people) are not in the position to be able to coach management and are probably wondering what could be done to make things better. How would you begin remedying the situation? Should we train more of our management into Agile and Scrum? What kind of training would you suggest? What if the management thinks we are doing fine as it is? (Yes, I know the real answer is to start running away from organizations like that but that may not be applicable for most people 🙂

    You stated that Agile projects are most likely doomed if they focus on cost savings and not creating more value. I am making the assumption that we mostly do projects for creating more customer value. Therefore, I would generalize your claim so that we risk failing projects by focusing on anything else than creating more value to our customers. I have seen projects focus on following a process, on cutting costs of the development organization, on fulfilling a project manager’s desires for power, etc. What I remember of all those projects is that they all failed savings costs, being in schedule and making the customer happy. Which is very sad.

    Keep up the good work!

    • Petri Heiramo Says:

      Hi Jarno,

      You’re putting forth quite typical stories. Organizations are being led with wrong mindset and strategy.

      But how to train your management? Frankly, it’s pretty damn hard if your management doesn’t want it themselves. It might be possible to make the problems visible in some way, and present that visibility to management, but I’ve seen also that strategy fail many times. One approach is to find a champion who does listen and could then drive the issue forward with higher authority. The best champion would of course be the CEO. One classic scenario of Agile adoption goes through a crisis of some sort. At that stage, the management is willing to try anything to keep the business afloat. Creating a sense of impending doom, even if the company isn’t in one yet, can also work. “Unfortunately”, a lot of companies are not in such a dire situation, so they can keep going on like they are. The management just may be wondering why, despite all efforts, people are unhappy at work, customers complain and maybe move away, and everything in the company seems to be getting slower and more difficult over time.

      If the management does listen, I can only recommend hiring a coach to tell the management more about Agile. In a smaller company, or in case of individuals, signing up on a Certified Scrum Product Owner (CSPO), or equivalent, gives a good two-day kickstart. For larger companies it probably makes more sense to contact a coach directly and arrange a private meeting. In the latter case, the company can ask direct questions and can get direct feedback to their issues. Obviously, one single day is not going to open up all issues, but it will be the start.

      Books are obviously a good source of information, and cheap, but I find that management people have rarely enough time to read them properly to understand them right.

      In any case, it is critical that management isn’t looking for a quick fix. If they do, they will “find” many, but when used, they fail to deliver the value and typically creates comments like “tried it, didn’t work”.

  3. Jarno Says:

    Thanks for the reply!

    Stirring up things to create a crisis that big might be juuust a little out of my reach 😉 I’ll see if there’s something else I can do…

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


%d bloggers like this: