What I Really Want to Do

6.8.2010 by

I can’t sleep tonight. My mind is racing. I’m getting to what I really want to do.

I’ve been training people in Agile methods and Scrum for quite a few years now. I’ve seen change happen, I’ve seen people regaining enjoyment at their work, I’ve seen people crank out almost error free code faster than ever before, I’ve seen people conquer problems that seem quite impossible. But none of that is enough.

It is not enough because none of that is creating a sustainable change in their environment. The organizations where these things happen still keep promoting a different environment, an environment where old formalities of management reign, where command-and-control and task-oriented mindset reduces people to doing their work instead of solving problems in collaboration with others. These organizations rule the business scene of today.

Or actually, they don’t. But because they are so many and the different companies are so few, no-one really sees that they don’t. Being different and better is a business advantage so great that many companies want to keep it that way. But there is hope that a change is coming.

And that’s what I really want to do.

No Agile transformation will stick without change in the corporate management style. Every low-level success will eventually be stiffled out or will fade as the people involved will leave in a hope of finding a better place to work, a place where they would be appreciated. This is one reason why e.g. so many top-notch IT professionals join Reaktor, because there they are.

I really want to help companies, and particularly their management boards, to tap into the real thing – the innovation and dedication of their people in creating value. In doing so, I’m willing to not use the work “Agile” because so many C-level people incorrectly assume “Agile” is just for development work. I don’t want to create unsolicited hopes for people unless I can also help the management start transforming the whole organization to support those people’s work.

There is actually no secret to this all. I mean, there is no secret because the roots of this change are displayed all over the internet and published in many books. It all is merely ignored by the majority of business management.

What I really want to do is change that. I want to be part of the movement that is trying to wake up the business management layer from its Sleeping Beauty dream (because the ideas are a hundred years old and based on managing unskilled labor). Does that make me a prince? Maybe not :).

I don’t yet know how I will achieve what I really want to do. I know the key things in how the organizations should change, and I know how to effect the change in lower levels of the organization. What I don’t yet know is how to catch the ear of the C-level people so that they would listen. Am I not charging enough money? Or am I lacking the charisma of Jari Sarasvuo? Or was he merely charging enough money?

Sillyness aside, if there are senior executives who are not satisfied with the results they are getting from their leadership and are seeking ways in which they can make the world better for their employees and their customers (and of course, their investors), drop me a note and let’s explore a better future together. I’m sure I have a lot to learn from them as well.

Your Greatest Risk Is Poor Project Leadership

5.6.2010 by

Systemation writes in their blog about poor project management being the biggest project risk. I agree. Yet I think the blog fails to recognize that the project manager centred and plan driven approach itself is also a major risk for project success. Just like typical waterfall projects (or ones with long increments) omit the most cost effective risk mitigation strategy of incremental development, traditional project management typically omits building collective commitment as a source for getting visibility and low level actions to project risks.

But I won’t belabor the Agile/Traditional divide. What I want to look at is lack of good project leadership as a risk for Agile projects. Given that I agree on the risk, let’s look at corresponding five steps to improve Agile project leadership (note – leadership, not management).

  1. All Scrum team members (I’m using the term in the broad sense as that includes the product owner, ScrumMaster and all the development team members) must receive training in the fundamentals. While some of that training can be given in typical training environment (CSM/CSPO classes, etc.), some is most effectively given in a coaching format within the project itself. Too many projects and organization omit the last item, but it actually happens to be the most cost efficient form of training/coaching.
  2. The organization and people working in it must agree on some standard framework for project leadership and management. One size doesn’t fit everyone, so the framework must allow appropriate project level modifications. There should be sufficient internal mentoring to ensure appropriate following of the agreed framework and to ensure all project members have sufficient skills to use it effectively. Also there should be a mechanism by which the project organization routinely reflects on the framework and adapts it to changing business environment and needs.
  3. All project members should have access to the tools needed to manage the work and use the framework effectively. Note that I didn’t say “software tools”. Many most effective project management tools aren’t software based. But when the organization decides to use a tool, it must support the agreed process (and not the other way around – the organization adapts to the tool).
  4. Projects should strive to deliver fully working functionality in every iteration. The ruthless visibility this provides into real progress is the basis for estimation and tracking.
  5. The organization must support the projects in their leadership. The teams must be given appropriate time and resources to do their work right and must not be requested to do shortcuts or disregard good practices. Product owners must have support for their long-term planning and vision setting. ScrumMasters need to be supported in their activities for improving project leadership and removing obstacles from getting work done. This is MUCH more involved than most organizations think. It really means understanding what Agile is, what it takes to do it right, and what is needed from the management itself.

Just like the five actions the Systemation CEO believed will improve project management, I believe that the above five actions will improve Agile project leadership. However, action 5 needs significant clarification in Agile context.

Let me know if you want me to expand on that. Also let me know if you agree / disagree with my comments.

TIEKE Brief #10 on Agile

10.5.2010 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?

First CSPO course! I mean, a public one…

10.5.2010 by

I’m holding a CSPO course in June, on 10th – 11th June (that’s Thursday and Friday). I’ve done several private ones and I’m curious to see if there is interest for a public one. So if you are in a position responsible for product development activities or a customer buying Agile projects, this course is for you.

CSPO courses are funny in a sense. In a perfect world, they would not be needed. In a perfect world, every ScrumMaster would have the knowledge, experience and skill to train the PO’s in their projects or organizations. Given the many people I’ve had in my PO courses, I can testify that we are not living in a perfect world (… obviously there are many other reasons for that assessment, too… ). Therefore I’m hoping I will be able to help individuals and organizations in their adoption of Scrum and Agility, and give many ScrumMasters some help in getting their projects working :).

For more information on the course, check out this link:

http://www.scrumalliance.org/courses/20094656-certified-scrum-product-owner

To sign up, just send me email to petri.heiramo@gmail.com.

Turku Agile Day 2010

20.3.2010 by

Hi,

The Turku Agile Day 2010 was worth the visit, even if I was there only for the second day when the presentations were held. Hopefully someone with first hand experience will write about the workshops.

It was great to see another successful Turku Agile Day. Speakers were great, schedule was well managed, there was a lot to learn, and the conference dinner was very good (especially the atmosphere in the selected restaurant).

Like with most events for me, it started a little “slow”. I came to the venue, registered in and immediately found some familiar people. As usual, the first chats of the day are a bit light and no-one really seems to have readiness for more analytic discussion. I’ve felt the same in almost all events I’ve been in (half a dozen or so Agile ones), but like usual, around noon things started to change. People get “warmed up”, first presentations give something to talk about, and all that starts leading towards more and more interesting discussions. I have to say that the dinner really topped up this event really nicely. The discussions were very entertaining there, and very educational. I wish I could have such discussions with other trainers and Agilists on a more regular basis. 🙂

The presentations will be coming to conference website at some point, so I won’t repeat the details. Suffice it to say that there was a lot of variance between the presentations and all the ones I saw were very professional and entertaining. It’s great to see such high level of quality and substance even “in a relatively local event” (although it is certainly the second biggest Agile event in Finland :)). I really applaud the organizers, not only for attracting such good speakers, but also making the event highly available for local students who thus get access to world-class Agile presentations and info at a very affordable price and accessibility. If they take half of the advice to heart, and take it to work life with them, Turku will soon rival Helsinki as the Agile capital of Finland. I really wish the organizers find the strength to keep organizing these events.

I had a presentation in the event, too, later in the afternoon. I had chosen a topic that I think is quite important and which I don’t necessarily see enough in action. Too few SM’s (at least in my subjective evaluation) have the awareness and ability to train the customer and “sell” Agility effectively to their customers. Obviously, that’s not the only area in which we all certainly need improvement, but in order to get a shot at doing an Agile project, you need to get one first. I’ve uploaded the presentation here, but to summarize a few things, Scrum assumes that the ScrumMaster is capable of, and takes the responsibility for, training the customer in the use of Agility and helping that person be an effective PO. Scrum doesn’t assume that PO’s know their role in advance. They are expected to know the domain and market, and be able to use that information to continuously prioritize the work to be done for maximal business value. So in 99% of the cases they rely on SM’s for guidance.

On one sense, it’s a high bar. On another sense, unless meeting that bar, how can we assume that the projects will succeed, if the SM can’t coach the PO? Honestly, looking at some SM’s I’m not all too surprised that there are failed Scrum / Agile projects. Of course, learning these things takes time. Hopefully my notes will help SM’s in finding the right understanding, words and training capability to work as effective SM’s. I also hope that these people will find more support from other sources.

I will soon update this post with some sample presentation / training sets that can be used early on in the customer contact to create sufficient understanding for Agility in the customer organization and enable possible Agile sale. Until then, signing off,

Petri

Welcome to Agilecraft blog site

25.2.2010 by

Agilecraft Oy/Ltd is a brand-new one-man Agile training, coaching and consulting shop. The “one man” is Petri Heiramo who has over a decade of experience in software projects and almost as much in developing software development processes at Digia. Last four and a half years have been spent on learning and deploying Scrum and Agile, in an effort to make Digia’s software development processes exceed market expectations and to provide deep job satisfaction to the people at Digia.

In Agilecraft, he is now independent of corporate priorities and can focus his attention to the issues closest to his heart (workwise) – the Agile methods and promoting their use in companies and other organizations. It should be pretty accepted in our industry that Agile methods can provide boost to customer satisfaction, employee satisfaction and business performance, but it is not easy to get to those benefits. Or rather, some things are easy, but they will reveal issues in our corporate culture that will limit the benefits, and that can kill the initiative outright. Removing those impediments can be very difficult – and can only be done by the companies themselves. However, outside coaching can help in seeing those obstacles and in finding the ideas and ways for improvement.

Agilecraft can provide public and private training courses such as:

  • Certified ScrumMaster (CSM)
  • Certified Scrum Product Owner (CSPO)
  • Scrum Team Training
  • Agile Thinking and Scrum Introduction

Petri was the first Finn to get the Scrum Alliance’s Certified Scrum Trainer certificate in late 2008. The CSM and CSPO courses that he runs can certify the participants with the Scrum Alliance certificates.

If you are interested in the help Petri could provide, contact him via email or call +35840-7092526. More information about Agilecraft, Agility and stuff will come here (hopefully) soon. Also blog posts on important topics will start appearing here.